Tuxcare спонсировал этот пост.
Согласно последнему отчету о безопасности и анализе безопасности с открытым исходным кодом (OSSRA), 97% всех отсканированных кодовых баз содержат компоненты с открытым исходным кодом, в среднем более 900 таких компонентов на приложение. Более того, почти две трети этих компонентов являются транзитивными зависимостями. Это означает, что они библиотеки, которые втягиваются косвенно — и многие команды могут даже не осознавать, что они используют их.
Эта широко распространенная зависимость от открытого исходного кода, причем каждый компонент с открытым исходным кодом следит за своей собственной политикой поддержки и сроками, подвергает организациям дневные риски, которые выходят за рамки уязвимостей безопасности. Если они не управляются, эти риски могут неожиданно появляться в неожиданном масштабе. Понимание этих рисков является первым шагом, но последовательно и эффективно контролировать их имеет решающее значение.
Понимание жизненных циклов поддержки с открытым исходным кодом
В отличие от коммерческого программного обеспечения, которое обычно приносит с собой предсказуемые многолетние сроки поддержки, поддержка с открытым исходным кодом следует по другому пути:
Эта модель создает лоскутную одежду поддержки. В типичном приложении каждый компонент может находиться на разных часах, что означает, что некоторые библиотеки могут быть полностью поддержаны, в то время как другие уже не обслуживаются. Для проницательных организаций, которые уделяют большое внимание безопасности и соответствию, это может вызвать почти бесконечные головные боли.
Масштаб устаревших и уязвимых компонентов
В то время как с открытым исходным кодом ускоряется инновации, сохранение компонентов остается очевидной, но без ответа. Исследование OSSRA 2025 года показывает, насколько широко распространена проблема:
- 86% кодовых баз включают уязвимые компоненты с открытым исходным кодом.
- 91% используют устаревшие пакеты, причем большинство отстают более 10 версий за последним выпуском.
- 81% содержат уязвимости с высоким или критическим риском.
Эти цифры показывают, насколько системной проблема сегодня. Организации не просто управляют несколькими устаревшими библиотеками. Они управляют сотнями таких библиотек, часто не осознавая, как далеко они зашли от последних поддерживаемых версий.
Результатом является не только пробел в безопасности, который может быть использован киберпреступниками, но и оперативным бременем, поскольку команды пытаются управлять временем поддержки для сотен различных компонентов с открытым исходным кодом по всему стеку.
ЭОЛ и риски соблюдения требований
Это давление, чтобы оставаться безопасным, становится еще более серьезным при просмотре через объектив соответствия. Мандаты, в том числе FedRamp, PCI DSS, HIPAA и ISO 27001, требуют уязвимостей, которые будут исправляться в течение строгих сроков, часто всего лишь дни или недели для критических недостатков. Но когда компонент уже находится в конце жизни, нет никакой гарантии, что патч когда -либо будет доступен.
Даже если в настоящее время не известно уязвимостей, аудиторы обычно помечают компоненты EOL как риск соответствия, потому что их нельзя надежно исправить. А поскольку статус EOL часто обнаруживается в конце цикла, организации часто спешат обновления, чтобы избежать результатов аудита или регулирующих штрафов, и это поспешное действие может вызвать дополнительные проблемы.
Эти мандаты применяются ко всей цепочке зависимостей, не проводя различий между прямыми зависимостями и переходными. Если компоненты EOL появляются в счете материалов по программному обеспечению (SBOM) или сканированию организации, аудиторы часто помечают их, поскольку они представляют невозможный риск. И если уязвимый компонент существует где угодно в цепочке поставок, независимо от того, насколько глубоко его нужно решить.
Между тем, новая волна правил предназначена для другой аудитории: производителей устройств и устройств. Такие программы, как Марк кибер -траста сша и Закон о кибер -устойчивости ЕС, требуют, чтобы поставщики предоставляли исправления безопасности для всех программных компонентов, работающих на их оборудовании, включая зависимости с открытым исходным кодом, для всего жизненного цикла продукта.
Другими словами, традиционные рамки (PCI DSS, HIPAA, ISO 27001, FEDRAMP) возлагают ответственность за операторов программного обеспечения, в то время как новые правила (Mark Cyber Trust, Закон о кибер -устойчивости) сдвигают эту ответственность вверх по течению к производителям устройств. Это значительное новое бремя. В любом случае, неподдерживаемые или устаревшие пакеты с открытым исходным кодом больше не являются просто технической ответственностью; Они также могут стать заметной нормативной ответственностью.
Почему обновления никогда не бывают простыми
Даже когда обновления тщательно спланированы, они редко бывают простыми. Команды часто начинают с переписывания кода приложения для решения проблемы нарушения изменений или измененного поведения. Оттуда они должны обновлять цепочки зависимостей, чтобы разрешить конфликты и обеспечить совместимость.
Инструмент и инфраструктура обычно также требуют внимания. Системы сборки, трубопроводы CI/CD, упаковку, сценарии развертывания и даже изображения контейнеров часто требуют регулировки для соответствия новой версией. После этого приходит тестирование. Регрессия, интеграция, безопасность и тестирование производительности должны быть выполнены, чтобы обновление не ввело неожиданные побочные эффекты.
Наконец, команды должны обрабатывать процесс управления изменениями (то есть планирование развертывания, подготовка стратегий отката, обновление документации и обеспечение обучения персонала в новой среде). На практике то, что выглядит как «просто обновление», может волноваться по коду, зависимостям, инструментам, инфраструктуре и процессам, потребляющим тонны времени и ресурсов.
Стоимость приостановленных обновлений
Соглашения на уровне сервисов соответствия (SLA) и новые раскрытия уязвимости часто сталкиваются с неподдерживаемыми компонентами, оставляя организациям небольшим выбором, кроме как спешить с обновлением. Эта срочность обычно усиливает риск и стоимость.
Спешные обновления могут вызвать волну инцидентов после обновления, так как ошибки и срочные проблемы создают нестабильность между инженерными и операциями, вытаскивая команды с работы по дорожной карте и замедляя доставку. Под давлением крайнего срока команды также могут сокращать углы, и эти ярлыки часто прикрепляются к долговременному техническому долгу, который просто скипит в дополнение к будущему бремени по обслуживанию.
Финансовое воздействие не менее значительное. Укороченные временные рамки приводят к незапланированным затратам, от сверхурочной оплаты до временной инфраструктуры, расширенной среды тестирования или экстренных консультаций. В то же время, поспешная реализация может непреднамеренно представить новые риски, такие как неправильные конфигурации или новые уязвимости, которые в конечном итоге подрывают безопасность, которое было предназначено для восстановления. Это довольно затруднительное положение.
Таким образом, в то время как обновления сложны в лучших обстоятельствах, спечные обновления могут превратить необходимую техническую деятельность в источник нестабильности, затрат и перерасходов.
Варианты, помимо всего лишь обновления
Не каждое заявление может или должно быть обновлено в графике, продиктованном сроками соответствия или внезапными раскрытиями уязвимости. Приоритеты бизнеса, сложность интеграции и риск разрушения часто делают «просто обновлять» непрактичный ответ.
В течение многих лет организации имели ограниченные альтернативы. Расширенная поддержка иногда была доступна, но обычно только для конкретных компонентов. Остальная часть стека осталась открытой, оставив команды с небольшим выбором, кроме как ускорить повышение после окончания поддержки сообщества.
Сегодня эта картина меняется. Новые услуги предлагают расширенную поддержку широкого спектра компонентов с открытым исходным кодом в разных операционных системах, времени запуска, библиотек, структур разработки и приложений. Предоставляя текущие исправления безопасности, а также обеспечение совместимости, полное покрытие дерева зависимостей и отслеживание происхождения, организации могут оставаться в безопасности далеко за пределами официального конца жизни. Эти возможности помогают гарантировать, что программное обеспечение остается проверенным, а также продолжает поддерживать строгое соответствие посредством своевременного восстановления в цепочке поставок программного обеспечения.
Tuxcare-это живой инноватор по исправлению и Linux Security, предлагающий доступные решения для кибербезопасности, которые предоставляют поддержку предприятия, предоставляемые организациям всех размеров в любой отрасли. Узнайте больше последних из Tuxcare Trending Stories YouTube.com/thenewstack Tech, которые движутся быстро, не пропустите эпизод. Подпишитесь на наш канал YouTube, чтобы транслировать все наши подкасты, интервью, демонстрации и многое другое. Группа подпишитесь с эскизом. Artem Karasev является старшим менеджером по маркетингу продуктов для бесконечной поддержки Luxcare для программного обеспечения с открытым исходным кодом. Подробнее от Artmem Karasev
