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

❤️ Уровень данных
Основная проблема начинается с неполных и неточных данных об уязвимостях, которые, к тому же, медленно обновляются (в первую очередь здесь говорится про базу NVD и программу регистрации уязвимостей CVE):
➡️Медианное время оценки уязвимости в ПО с открытым исходным кодом в 2025 году составило 41 день, а для 35% от общего количества - более трех месяцев.
➡️Почти 65% уязвимостей в ПО с открытом исходным кодом, обнаруженных в 2025 году, до сих пор не имеют оценки CVSS.
➡️В базе NVD содержится немалое количество записей, в которых указаны неправильные диапазоны уязвимых версий и идентификаторов CPE, а также не указываются EOL (End Of Life)-версии ПО.
➡️По расчетам Sonatype, оценка CVSS каждой седьмой уязвимости рассчитана неверно и отличается на 3+ балла.

❤️Уровень потребления
Даже при наличии исправлений организации продолжают загружать и развертывать уязвимые компоненты, причин тому несколько:
➡️Закрепление зависимостей — единожды скачанная версия фиксируется (например, во внутренних репозиториях) и переиспользуется в новых проектах.
➡️Транзитивные зависимости — уязвимости попадают в проекты через несколько уровней вложенности дерева зависимостей, про которые зачастую никто не в курсе.
➡️Усталость от уведомлений — сканеры безопасности приносят огромные простыни уязвимостей без четкой приоритизации, что влияет, конечно же, на желание админов и разрабов что-то исправлять.
➡️Приоритет отдается скорости разработки — чтобы выполнить задачи бизнеса и уменьшить метрику Time To Market все жертвуют "гигиеной" кода.

❤️Уровень экосистемы
Зависимость от EOL-компонентов или "заброшенных" мейнтейнерами компонентов создает "вечные уязвимости", которые невозможно исправить и единственный путь — это масштабная миграция и переход на новые фреймворки, что, конечно, повлияет на сроки достижения бизнес-целей и доступность сервисов:
➡️Риск EOL характерен для всех экосистем (npm — 18,5%, Maven Central — 13,4%, PyPI — 11,6%, NuGet — 25,7%).
➡️До 15% используемых в организации зависимостей находятся в статусе EOL.
➡️Компания HeroDevs, которая занимается заказной доработкой неподдерживаемого ныне ПО с открытым исходным кодом, оценивает количество EOL-версий пакетов с известными уязвимостями в диапазоне от 81 000 до 400 000 шт.

⌨️Влияние ИИ-инструментов
Отдельно подсвечивается, что использование ИИ-инструментов кратно масштабирует выше описанные проблемы:
➡️ИИ обучается на неполных данных из NVD и транслирует эти "знания" в массы.
➡️Рекомендует исторически популярные версии ПО, которые зачастую содержат известные эксплуатируемые уязвимости, или находятся в статусе EOL.
➡️Генерирует манифесты с устаревшими версиями компонент и увеличивает (без подтвержденной необходимости) кол-во используемых зависимостей.

В качестве яркой лакмусовой бумажки всех описанных проблем в отчете приводится статистика скачиваний уязвимой версии библиотеки Log4j: за 2025 год уязвимая к атакам Log4Shell версия была скачана более 42 млн раз.😅

p.s. О предлагаемых авторами мерах по решению проблем — в следующем посте.

#vm #cve #nvd #ai #supplychain #risk #eol #software #vulnerability #sonatype #report