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

Новый отчет показал, что исправления, применяемые для уязвимостей зависимостей, вызывают поломки в 75% случаев. Было обнаружено, что незначительные обновления ломают клиентов в 94% случаев, а для обновлений версий этот показатель составил 95%.

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

«По-видимому, наиболее простым решением является обновление до неуязвимой версии зависимости», — заявили авторы нового отчета по управлению зависимостями за 2024 год из компании Endor Labs, занимающейся безопасностью цепочки поставок программного обеспечения.

«Однако то, что в принципе кажется простым — в конце концов, вам просто нужно обновить идентификатор версии до неуязвимого, верно? — может вызвать проблемы совместимости и регрессии, которые нарушат работу приложения во время разработки».

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

SEE: Количество атак на безопасность цепочки поставок программного обеспечения выросло на 200%: новое исследование Sonatype

Уязвимости зависимостей не сообщаются и не устраняются достаточно быстро

В отчете также обнаружено, что существует несколько неотъемлемых проблем с отчетами об уязвимостях зависимостей и их исправлением, поскольку 69% рекомендаций публикуются на CVE, блогах, GitHub и аналогичных платформах после выпуска исправления. Медианная задержка между доступностью публичного исправления и публикацией рекомендации составляет 25 дней.

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

Библиотеки ИИ затрудняют управление уязвимостями

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

Фантомные зависимости — скрытые, необъявленные библиотеки в коде приложения — также чаще встречаются в проектах программного обеспечения AI и ML, утверждают авторы отчета. Проекты AI, как правило, пишутся на Python, языке, печально известном фантомными зависимостями, поскольку он допускает динамическую или косвенную установку пакетов, которая обходит файлы манифеста.

Фантомные зависимости составили значительную часть следа зависимости только для 27% предприятий, данные которых были проанализированы для этого отчета. Но в этой группе более 56% сообщили, что уязвимости библиотек были в их фантомных зависимостях.

Специалисты по безопасности перегружены неактуальными оповещениями об уязвимостях

Согласно отчету, четверть рекомендаций содержат неверные или неполные данные, что может привести к ложноположительным и ложноотрицательным результатам.

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

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

Без этого они не могут быстро отфильтровывать нерелевантные уязвимости, которыми являются многие из них. Команда Endor Labs обнаружила, что более 90,5% уязвимостей зависимостей с открытым исходным кодом в Java, Python, Rust, Go, C#, .NET, Kotlin и Scala на самом деле не могут быть использованы на уровне функций — то есть у них нет по крайней мере пути вызова из приложения к уязвимой функции в этой библиотеке.

СМ.: Открытый исходный код для коммерческих программных приложений распространен повсеместно, но также велик и риск

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

«Исследование оповещений обходится командам по безопасности (и командам по программному обеспечению) дорого, а попытки все исправить обходятся еще дороже», — добавил он.

Преимущества обновления 20 лучших компонентов Python

Обновление зависимостей до неуязвимых версий оказывает заметное влияние на количество соответствующих уязвимостей. Например, обновление 20 основных компонентов Python удаляет более 75% всех обнаруженных уязвимостей, включая 60% для Java и 44% для npm.

Кроме того, отфильтровывание уязвимостей зависимостей, которые недоступны — к которым нельзя получить доступ и которые нельзя использовать — и которые имеют оценку EPSS менее 1%, может значительно сократить количество, которое необходимо отслеживать специалистам по безопасности. Объединение их с фильтрами для уязвимостей, которые не имеют доступного исправления и не присутствуют в тестовом коде, оставляет только 4% уязвимостей Java и JavaScript и менее 1% уязвимостей Python, что сокращает затраты на исправление.

Авторы отчета пишут: «В сочетании с данными анализа достижимости на уровне функций и другими стратегиями определения области действия на основе контекста приоритизация EPSS часто настолько эффективна, что дополнительные, требующие больших усилий стратегии приоритизации (такие как проведение упражнений по оценке окружающей среды и времени CVSS для определения серьезности ситуации в вашей среде) часто оказываются ненужными».

«Это экономит затраты вашей организации на анализ уязвимостей».