Как управлять рисками безопасности и соответствия нормативным требованиям, связанными с Open Source-компонентами с истекшим сроком службы (end-of-life, EOL), особенно со скрытыми зависимостями в приложениях? Об этом на портале The New Satck рассказывает Артем Карасев, старший менеджер по маркетингу продуктов компании TuxCare, занимающейся поддержкой Open Source Software (OSS) на протяжении всего жизненного цикла.

Согласно последнему отчету по безопасности и анализу рисков открытого исходного кода (OSSRA), 97% всех просканированных кодовых баз содержат Open Source-компоненты, причем в среднем на одно приложение приходится более 900 таких компонентов. Более того, почти две трети этих компонентов являются транзитивными зависимостями. Это означает, что они представляют собой библиотеки, которые подключаются косвенно, и многие команды могут даже не подозревать, что используют их.

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

Понимание жизненного цикла поддержки Open Source

В отличие от коммерческого ПО, которое обычно предполагает предсказуемые многолетние сроки поддержки, поддержка Open Source следует другому пути:

  1. Этап поддержки сообществом. Большинство проектов начинается с активной разработки, осуществляемой мейнтейнерами и контрибуторами. Исправления безопасности, новые функции и обновления выпускаются регулярно, но продолжительность и последовательность поддержки сильно варьируются от проекта к проекту.
  2. Дополнительная поддержка для предприятий. Когда поддержка сообщества заканчивается, некоторые популярные проекты предлагают для предприятий платную дополнительную поддержку с определенным жизненным циклом. В рамках этой поддержки в течение нескольких лет могут предоставляться исправления безопасности и обновления стабильности, но большинство проектов не предлагают такую дополнительную опцию.
  3. Конец жизненного цикла (EOL). После окончания всей поддержки, либо по завершении обслуживания сообществом для небольших проектов, либо после окончания поддержки для предприятий для более крупных проектов, дальнейшие исправления не выпускаются. На этом этапе организации сталкиваются с необходимостью обновления, и это может происходить в довольно короткие сроки.

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

Масштабы устаревших и уязвимых компонентов

Хотя Open Source ускоряет инновации, поддержание компонентов в актуальном состоянии остается очевидной, но нерешенной проблемой. Исследование OSSRA 2025 г. иллюстрирует, насколько широко распространена эта проблема:

  • 86% кодовых баз содержат уязвимые Open Source-компоненты;
  • 91% используют устаревшие пакеты, причем большинство из них отстают от последнего релиза более чем на 10 версий;
  • 81% содержат уязвимости с высоким или критическим уровнем риска.

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

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

Риски, связанные с EOL и комплаенсом

Это давление, связанное с необходимостью обеспечения безопасности, становится еще более серьезным, если рассматривать его с точки зрения комплаенса. Нормативные требования, включая FedRAMP, PCI DSS, HIPAA и ISO 27001, требуют устранения уязвимостей в строгие сроки, часто всего за несколько дней или недель в случае критических недостатков. Но когда компонент уже находится в конце своего срока службы, нет гарантии, что патч когда-либо будет доступен.

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

Эти требования применяют ко всей цепочке зависимостей, не делая различия между прямыми и переходными зависимостями. Если EOL-компоненты появляются в спецификации ПО (SBOM) или отчетах о сканировании организации, аудиторы часто отмечают их, поскольку они представляют собой риск, который невозможно устранить с помощью исправлений. И если уязвимый компонент существует где-либо в цепочке поставок, независимо от того, насколько глубоко, его необходимо устранить.

Между тем, новая волна нормативных требований нацелена на другую аудиторию: производителей устройств и приборов. Такие программы, как US Cyber Trust Mark и EU Cyber Resilience Act, требуют от поставщиков предоставлять патчи безопасности для всех программных компонентов, работающих на их оборудовании, включая Open Source-зависимости, на протяжении всего жизненного цикла продукта.

Другими словами, традиционные нормы (PCI DSS, HIPAA, ISO 27001, FedRAMP) возлагают ответственность на операторов ПО, в то время как новые нормативные акты (Cyber Trust Mark, Cyber Resilience Act) перекладывают эту ответственность на производителей устройств. Это значительная новая нагрузка. В любом случае, неподдерживаемые или устаревшие Open Source-пакеты больше не являются только технической проблемой; они могут стать и значительной проблемой с точки зрения комплаенса.

Почему обновления никогда не бывают простыми

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

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

Наконец, команды должны заняться процессом управления изменениями (т. е. планированием внедрения, подготовкой стратегий отката, обновлением документации и обеспечением обучения персонала работе в новой среде). На практике то, что выглядит как «просто обновление», может повлиять на код, зависимости, инструменты, инфраструктуру и процессы и потребовать огромного количества времени и ресурсов.

Цена поспешных обновлений

Соглашения об уровне обслуживания (SLA) и раскрытие информации о новых уязвимостях часто сталкиваются с неподдерживаемыми компонентами, оставляя организациям мало выбора, кроме как поспешно провести обновление. Такая срочность, как правило, увеличивает риски и затраты.

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

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

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

Варианты, выходящие за рамки простого обновления

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

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

Сегодня ситуация меняется. Новые сервисы предлагают расширенную поддержку для широкого спектра Open Source-компонентов в операционных системах, средах выполнения, библиотеках, средах разработки и приложениях. Благодаря предоставлению постоянных патчей безопасности наряду с обеспечением совместимости, полным покрытием дерева зависимостей и отслеживанием происхождения, организации могут оставаться в безопасности даже после официального окончания срока службы. Эти возможности помогают обеспечить возможность аудита ПО, а также продолжать поддерживать строгое соответствие требованиям за счет своевременного устранения проблем по всей цепочке поставок ПО.