Ежегодный отчет Datadog о состоянии DevSecOps за 2026 год представляет собой глубокий анализ тысяч облачных сред, фокусируясь на критически важном балансе между скоростью разработки и безопасностью. В эпоху генеративного искусственного интеллекта (GenAI) и постоянно растущих рисков в цепочках поставок программного обеспечения (supply chain), этот отчет предоставляет ценные инсайты о реальных вызовах, с которыми сталкиваются современные организации.

Основные Выводы Отчета Datadog

• Высокий процент эксплуатируемых уязвимостей: Подавляющее большинство организаций — 87% — сталкиваются как минимум с одной известной, потенциально эксплуатируемой уязвимостью в своих развернутых сервисах. Примечательно, что такие уязвимости затрагивают до 40% всех действующих сервисов, подчеркивая масштаб проблемы.
• Зависимость от устаревших библиотек: Значительная часть сервисов, а именно 42%, функционирует на базе библиотек, поддержка которых прекращена (End-of-Life, EOL). Это создает серьезные риски безопасности и стабильности, поскольку EOL-продукты не получают обновлений безопасности.
• Растущая задержка в обновлении зависимостей: Медианная задержка в обновлении зависимостей составляет тревожные 278 дней от последней мажорной версии, что является ухудшением по сравнению с 215 днями в 2025 году. Среди наиболее отстающих платформ — Java со средней задержкой в 492 дня и Ruby с 357 днями, что указывает на хроническое пренебрежение обновлениями критически важных компонентов.
• Риск быстрых обновлений: Половина организаций принимает новые версии библиотек в течение 24 часов после их выпуска. Такой подход, хотя и направлен на ускорение разработки, создает высокий риск внедрения вредоносных или нестабильных версий, особенно в первые часы после релиза, когда потенциальные угрозы еще не выявлены.
• Использование непроверенных образов: Существенная доля организаций (32%) используют публичные образы Docker в течение суток после их создания, а 12% поступают аналогично с публичными образами AMI. Это указывает на доверие к непроверенным источникам и потенциальную уязвимость к атакам цепочки поставок через скомпрометированные образы.
• Отсутствие фиксации GitHub Actions: Почти три четверти организаций (71%) не фиксируют свои GitHub Actions по хешу коммита, что делает их уязвимыми к изменениям в репозиториях сторонних действий. Более того, 2% организаций используют ранее скомпрометированные действия без фиксации версии, что представляет прямой риск безопасности для их CI/CD процессов.
• Контекстуальная оценка уязвимостей: Применение контекстуальной корректировки серьезности уязвимостей, основанной на таких факторах, как EPSS (Exploit Prediction Scoring System), статус наличия эксплойта и среда развертывания, значительно сокращает количество действительно критических угроз. Только 18% первоначально классифицированных как "критические" уязвимостей остаются таковыми после такой оценки, что снижает их общее число более чем на 80%. Это позволяет командам сосредоточить усилия на наиболее значимых рисках.
• Вредоносные зависимости npm: Несмотря на меры безопасности, 1.6% организаций, активно использующих пакетный менеджер npm, столкнулись как минимум с одной вредоносной зависимостью в течение года, что подчеркивает постоянную угрозу со стороны вредоносного ПО в репозиториях пакетов.

Рекомендации для Улучшения DevSecOps

• Актуализация компонентов: Поддерживайте актуальность языков программирования и сред выполнения (рантаймов), активно избегая использования версий с истекшим сроком поддержки (EOL). Это обеспечивает доступ к последним исправлениям безопасности и новым функциональным возможностям.
• Фиксация зависимостей: Используйте полную фиксацию зависимостей по хешу SHA-коммита, особенно для GitHub Actions. Это гарантирует неизменность используемого кода и защищает от скрытых изменений в сторонних репозиториях.
• Периоды "охлаждения" для новых библиотек: Внедряйте периоды "охлаждения" (cooldown-периоды) для новых библиотек, например, в течение 7 дней, прежде чем разрешать их использование в продакшене. Можно использовать функционал Dependabot для автоматизации таких задержек, что дает время для выявления потенциальных уязвимостей.
• Частые деплои для безопасности: Повышайте частоту развертываний (деплоев). Согласно метрикам DORA, частые, небольшие деплои снижают "поверхность атаки" и позволяют быстрее выявлять и устранять проблемы безопасности, делая процесс более контролируемым.
• Регрессионное тестирование: Обязательно проводите тщательное регрессионное тестирование при крупных обновлениях зависимостей или компонентов. Это помогает убедиться, что новые версии не привели к непредвиденным уязвимостям или функциональным сбоям.
• Использование проверенных источников: При использовании образов AMI и Docker всегда отдавайте предпочтение проверенным источникам, таким как AWS Allowed AMIs или Docker Verified Creators. Это значительно снижает риск внедрения вредоносного кода через скомпрометированные образы.
• Контекстуальная приоритизация уязвимостей: Проводите корректировку серьезности уязвимостей, учитывая контекст: используйте EPSS для оценки вероятности эксплуатации, статус использования в продакшене и доступность публичных эксплойтов. Это позволяет приоритизировать усилия по исправлению на наиболее критических угрозах.
• Приоритет CI/CD безопасности: Рассматривайте системы CI/CD как высокоприоритетные активы. Внедряйте мониторинг их работы в реальном времени (runtime monitoring) и стремитесь к ограничению "радиуса поражения" (blast radius) в случае компрометации, чтобы минимизировать потенциальный ущерб.

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