Все пользуются открытым кодом, но исправления выходят с опозданием

Корпоративные команды безопасности полагаются на открытое программное обеспечение в инфраструктуре, конвейерах разработки и рабочих приложениях, даже если они не выделяют его в отдельную категорию технологий. Открытый код стал стандартным строительным блоком во многих средах, а операционные риски теперь выглядят как типичные проблемы корпоративной безопасности: задержки с установкой обновлений, фрагментация версий и устаревшие платформы, которые остаются в работе дольше запланированного.

В Отчёте о ландшафте открытого ПО на 2026 год от TuxCare описывается растущее присутствие открытого кода, которое расширяется благодаря инициативам разработчиков, при этом инциденты безопасности по-прежнему тесно связаны с неустранёнными уязвимостями.

Инструменты разработчиков стимулируют внедрение

Использование открытого ПО в корпоративной среде больше определяется практиками разработки, чем стратегией выбора операционных систем. Языки программирования и фреймворки для разработчиков оказываются наиболее широко используемыми компонентами с открытым исходным кодом в организациях, наряду с базами данных, инструментами для контейнеризации и облачной инфраструктурой.

Это отражает реальный путь проникновения открытого кода в компании. Команды разработки внедряют языки, библиотеки и инструменты для скорости и гибкости, и затем эти компоненты становятся частью производственных систем. Со временем команды безопасности получают в наследство длинную цепочку зависимостей, которую бывает сложно отследить традиционными методами инвентаризации активов.

«Главный пробел — не в том, чтобы узнать, что уязвимо. А в том, чтобы быстро устранить проблемы, не нарушив работу продакшена», — заявил Артём Карасёв, старший менеджер по продуктовому маркетингу в TuxCare. «Слишком много команд осознают свою уязвимость задолго до инцидента, но всё равно становятся его жертвами, потому что обновления не успевают попасть в развёртывание вовремя».

Карасёв отметил, что проблема часто сводится к операционным ограничениям, с которыми команды безопасности борются годами. «Решение — адаптировать процесс установки исправлений к требованиям бесперебойной работы с помощью поэтапного внедрения, строгого мониторинга и планов отката, а также автоматизировать рабочий процесс исправлений, а не только сканирование, путём назначения ответственных, стандартизации согласований и встраивания тестирования в конвейер», — пояснил он.

В результате управление рисками открытого ПО часто становится побочным продуктом безопасности приложений и операций DevOps, напрямую связанным с тем, как создаётся и развёртывается программное обеспечение.

Linux остаётся широко распространённым, но размеры развёртываний обычно поддаются управлению

Многие компании отмечают, что развёртывания Linux достигли масштаба, требующего серьёзного подхода к обновлениям и планированию жизненного цикла, даже если общий парк систем остаётся сравнительно небольшим.

Часто эти развёртывания сосредоточены в сервисах бэкенда, инфраструктурных платформах и средах разработки. Подобная структура имеет тенденцию к неравномерному росту, когда разные команды управляют различными дистрибутивами и циклами обновлений в зависимости от требований рабочих нагрузок.

Это порождает типичную проблему масштабирования: организации начинают с парков Linux, которыми можно управлять неформально, а затем вырастают в среду, где необходимо централизованное планирование жизненного цикла и управление обновлениями.

Лидирует Ubuntu, а старые дистрибутивы остаются в строю

Ubuntu — наиболее широко используемый дистрибутив Linux среди корпоративных респондентов, при этом Debian также занимает сильные позиции. Остальная часть парка Linux распределена между смесью корпоративных и устаревших платформ.

Заметная доля респондентов по-прежнему полагается на CentOS, включая версии, поддержка которых уже прекращена. В отчёте также отмечается значительное внедрение сообществом пересборок, таких как AlmaLinux и Rocky Linux, что отражает стремление оставаться в знакомой экосистеме Linux, сохраняя стабильность и совместимость.

Многие организации сообщают о одновременной работе нескольких версий CentOS, что говорит о поэтапном характере миграционных проектов. Старые системы могут долгое время оставаться в эксплуатации рядом с новыми, особенно когда приложения сложно перепроверить или пересобрать.

Карасёв отметил, что подобный сдвиг в жизненном цикле создаёт накапливающиеся проблемы для безопасности и эксплуатации. «В то же время организациям требуется более жёсткий контроль над зависимостями и транзитивными библиотеками, проверки жизненного цикла, предотвращающие неожиданности с окончанием поддержки, и чёткая модель управления расширенной поддержкой, чтобы оставаться на неподдерживаемой версии было осознанным риском, а не чрезвычайной ситуацией», — сказал он.

Расширенная поддержка стала распространённым решением

Миграция с CentOS не привела к появлению единого доминирующего пути замены. Организации разделились между переходом на другие дистрибутивы и покупкой расширенной поддержки жизненного цикла для продления работы существующих развёртываний.

Отчёт связывает эту тенденцию с типичными ограничениями корпоративной ИТ-инфраструктуры. Работы по миграции требуют времени, тестирования и доступности персонала. Проблемы совместимости приложений могут замедлять обновления платформ, а некоторые рабочие нагрузки остаются привязанными к старым версиям операционных систем из-за критически важных бизнес-зависимостей.

Расширенная поддержка в этом контексте часто рассматривается как решение по управлению рисками. Она позволяет организациям сохранять защиту с помощью обновлений безопасности, пока они работают над долгосрочными проектами модернизации.

Карасёв отметил, что расширенная поддержка часто используется как временный мост, даже когда команды осознают, что конечная цель — это миграция. Во многих организациях решения о платформах по-прежнему связаны с операционной стабильностью и ограничениями контроля изменений.

Инциденты безопасности остаются обычной операционной реальностью

Почти половина опрошенных организаций сообщили о киберинциденте за последний год. Немного большая доля организаций не столкнулась с инцидентами за этот период, что отражает разную степень подверженности рискам в различных средах.

Отчёт также указывает, что крупные организации сообщают об инцидентах чаще, чем небольшие, что соответствует операционной реальности: большая площадь атаки и более сложные производственные среды. Крупные организации также обычно имеют более развитые системы обнаружения и отчётности, что может повышать заметность событий, которые небольшие компании могут пропустить.

Такая частота инцидентов говорит о том, что безопасность открытого исходного кода теперь стала частью повседневной операционной безопасности предприятий во многих отраслях.

Неисправленные уязвимости по-прежнему являются причиной компрометаций

Ключевая тема в выводах — многие инциденты по-прежнему связаны с известными уязвимостями, для которых уже существовали исправления. Около шести из десяти организаций, пострадавших от инцидентов, заявили, что их последний инцидент произошёл, когда патч уже существовал, но не был применён, что почти не отличается от показателей предыдущего года.

Во многих организациях задержки с установкой исправлений остаются одним из основных факторов, способствующих возникновению угроз безопасности. Даже когда у организаций есть инструменты сканирования и данные об уязвимостях, развёртывание часто замедляется требованиями управления изменениями, окнами простоя и необходимостью проверки патчей на совместимость с производственными зависимостями.

Карасёв отметил, что эта схема хорошо изучена, но изменить её без дисциплины процессов сложно. «Слишком много команд осознают свою уязвимость задолго до инцидента, но всё равно оказываются под ударом, потому что исправления не успевают попасть в развёртывание», — сказал он. Он добавил, что многим организациям необходимы программы обновлений, построенные с учётом требований к бесперебойной работе, где поэтапные внедрения и возможность отката являются стандартной практикой.

Управление уязвимостями часто ограничивается рабочими процессами и кадрами, а не осведомлённостью о том, что нужно исправить.

В среде открытого исходного кода проблема усугубляется глубиной зависимостей, фрагментированными дистрибутивами Linux и долгоживущими системами, привязанными к устаревшим программным стекам. Открытое ПО стало основой корпоративной ИТ-инфраструктуры, и многие организации по-прежнему работают с процессами обновлений, которые не успевают за изменениями.

Ожидания аудита смещаются в сторону доказательств и глубокой проверки стека

Программы управления обновлениями долгое время формировались под влиянием регуляторных требований, внутренних правил управления и сроков соответствия. Результаты отчёта показывают, что многим организациям по-прежнему сложно последовательно выполнять обновления в средах с большим объёмом открытого ПО, особенно когда производственные системы зависят от устаревших платформ или разветвлённых цепочек зависимостей.

Карасёв заявил, что давление на программы обновлений растёт, потому что аудиторы и покупатели задают другие вопросы, чем несколько лет назад. «Сроки установки исправлений — не новость, особенно в регулируемых средах. Меняется то, что покупатели и аудиторы ожидают в качестве доказательств и насколько глубоко они готовы проверять программный стек», — пояснил он.

По его словам, организации вынуждают переходить к более прямой технической проверке выполнения работ по обновлению. «Тренд — больше доказательств и меньше бумажной работы, с растущим давлением в сторону системных подтверждений того, что обновления действительно были развёрнуты вовремя, а исключения обрабатываются дисциплинированно», — сказал Карасёв.

Этот сдвиг также распространяется на закупки программного обеспечения и контроль цепочек поставок. «Мы также видим, что SBOM и происхождение ПО становятся реальными условиями закупок: контракты требуют более чёткого указания происхождения компонентов и обязательств по их жизненному циклу», — добавил он.

Карасёв отметил, что внимание всё чаще сосредотачивается на управлении зависимостями, где многие компании до сих пор не имеют надёжного контроля. «Фокус смещается на уровень зависимостей, внедряя проверки в CI/CD и управление компонентами, поскольку именно там накапливаются риски, связанные с открытым исходным кодом», — сказал он. «Детали будут различаться в зависимости от региона, но направление едино: ужесточение требований к цепочке поставок и увеличение числа защитных условий, инициируемых заказчиками».

Скачать: Отчёт Tines "Голос безопасности 2026"