Ваши зависимости устарели на 278 дней, а конвейеры сборки не защищены

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

Среди изученных сред 87% организаций имеют как минимум одну эксплуатируемую уязвимость в работающих сервисах, что затрагивает 40% этих сервисов. Эта ситуация указывает на постоянное накопление «технического долга» в области безопасности внутри развёрнутых программных стеков.

Отставание в зависимостях продолжает расти

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

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

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

Обновления создают новые угрозы

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

Такая практика увеличивает вероятность внедрения вредоносного кода, который ещё не был выявлен экосистемой. Быстрое внедрение стало обычным делом в автоматизированных конвейерах сборки.

Угрозы цепочки поставок выходят за рамки библиотек и затрагивают системы сборки. Использование GitHub Actions остаётся повсеместным в средах разработки.

«Организации, которые находят правильный баланс, рассматривают обновление зависимостей как непрерывную инженерную практику, а не как разовое мероприятие по безопасности. Интегрируя строгие автоматизированные наборы тестов непосредственно в свои CI/CD-конвейеры, эти команды могут уверенно относиться к обновлениям зависимостей как к обычным коммитам кода», — сообщил Help Net Security Кеннеди Тумей, исследователь и пропагандист безопасности приложений в Datadog.

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

Контроль процессов сборки остается ограниченным

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

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

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

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

Критичность уязвимостей меняется в контексте

Степень серьезности уязвимости меняется при учете контекста выполнения. Только 18% критических уязвимостей зависимостей остаются критическими после такой корректировки.

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

Тумэй сказал: “Руководители по безопасности должны оценивать, приводит ли перерасстановка приоритетов к улучшению среднего времени на устранение (MTTR), поскольку уязвимости с более высокими скорректированными оценками должны со временем значительно сокращаться. Поскольку инженерные команды больше не перегружены большим объемом номинальных “высоких” или “критических” находок, они могут сосредоточить усилия на действительно важных проблемах и устранять их быстрее”.

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

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

Признаки улучшения нагрузки на исправление

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

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

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

Подверженность рискам остается широко распространенной

Практики разработки по-прежнему делают акцент на скорости. Кодирование с помощью ИИ и автоматизированные конвейеры развертывания укрепляют быстрые циклы выпуска.

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

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

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

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

Скачать: Синий отчет 2025 раскрывает, как средства безопасности работают на практике