Бэклоги проблем безопасности приложений продолжают расти в крупных портфелях разработки. Отчёт Veracode «Состояние безопасности программного обеспечения 2026» приводит цифры, подтверждающие знакомую операционную модель: исправления отстают от обнаружения, а старые уязвимости остаются открытыми в течение многих циклов выпуска.

Результаты 2026 года по сравнению с базовым уровнем 2025 года (Источник: Veracode)
Анализ охватывает 1,6 миллиона уникальных приложений, прошедших статический и динамический анализ, анализ состава программного обеспечения и ручное тестирование на проникновение через платформу Veracode. Область исследования включает коммерческих поставщиков ПО, аутсорсеров и проекты с открытым исходным кодом, что даёт обзор различных моделей поставки и кодовых баз.
Технический долг в безопасности определяется как известные уязвимости, оставшиеся неисправленными более года. Этот показатель описывает накопленную подверженность рискам, которая сохраняется в течение многих циклов разработки, даже когда охват сканирования и обнаружение улучшаются. Определение также отделяет рутинную работу по исправлению от пунктов бэклога, которые уже пережили несколько циклов планирования, включая неоднократные отсрочки из-за изменений в дорожной карте и заморозок выпусков.
Технический долг в безопасности был выявлен у 82% организаций в 2026 году, что выше показателя в 74% в 2025 году. Эта метрика отражает долю организаций, имеющих как минимум одну известную проблему старше года, и указывает на широко распространённую проблему бэклогов в отрасли.
Критический технический долг в безопасности также увеличился, то есть долгоживущие недостатки, имеющие как высокую степень серьёзности, так и высокую эксплуатируемость. Veracode измерил критический технический долг в безопасности на уровне 60% организаций в 2026 году, по сравнению с 50% в 2025 году, что свидетельствует о том, что старые проблемы часто относятся к категории наивысшего риска.
Технический долг в безопасности — это проблема времени в той же степени, что и проблема объёма. Старые проблемы, как правило, сохраняются в коде, который команды не решаются менять, например, в устаревших сервисах, общих библиотеках или приложениях, связанных с доходными бизнес-процессами. Это замедляет исправление и может сделать обсуждения рисков повторяющимися для руководителей инженерных подразделений. Программы, отслеживающие долг, в итоге сводятся к спорам о владении, окнах для изменений и допустимом уровне риска для систем с высокой бизнес-зависимостью. Управление часто сводится к вопросам: кто отвечает за исправление, что финансируется и какие команды могут принять исключения по рискам.
Крис Вайсопал, главный евангелист по безопасности в Veracode, в беседе с Help Net Security отметил, что сокращение долга по безопасности должно выйти за рамки технических бэклогов и перейти под контроль высшего руководства. «Сокращение долга по безопасности — это не просто техническая задача, а бизнес-императив. Долг по безопасности должен стать ключевым показателем эффективности на уровне совета директоров, при этом ИБ-директора должны возглавить работу по обращению с ним как с финансовым долгом: его нужно измерять, управлять им и активно сокращать. Это требует отслеживания как общего, так и критического долга, с установлением квартальных целей по его снижению и увязкой этих усилий с бизнес-целями и ключевыми результатами».
Он добавил, что устойчивый прогресс требует изменений в инвестициях и политике. «Перераспределяя инвестиции в сторону автоматизации и исправлений с помощью ИИ, уделяя приоритетное внимание «жемчужинам короны» — наиболее важным для бизнеса приложениям, формализуя принятие рисков и внедряя политики вроде «исправлять высокорисковые уязвимости до выпуска», организации могут поддерживать безопасные и устойчивые системы».
Вайсопал также указал на измеримые цели управления. «Например, за шесть месяцев организация может сократить критический долг по безопасности на 25%, вдвое уменьшить средний возраст высокорисковых уязвимостей и обеспечить, чтобы доля высокорисковых уязвимостей в приложениях-«жемчужинах короны» оставалась ниже 10%».
Общая распространённость недостатков в приложениях в 2026 году составила 78%. Находки остаются обычным явлением среди проверяемого массива, и эта метрика соответствует повседневной реальности, когда большинство портфелей несут смесь унаследованных и вновь появляющихся слабостей.
Концентрация уязвимостей, оцененных как высокосерьёзные и высокоэксплуатируемые, достигла 11,3% в 2026 году, увеличившись с 8,3% в 2025 году. Этот сдвиг отражает долю недостатков, которые попадают в категорию с более высоким операционным риском, особенно в сочетании с внешне доступными сервисами и широко распространёнными зависимостями.
Расстановка приоритетов становится операционной дисциплиной, когда возможности по исправлению остаются ограниченными. Программам необходим повторяемый способ увязывать проблемы с критичностью для бизнеса, доступными путями атаки и экспозицией во время выполнения, чтобы команды могли сосредоточить усилия на наиболее значимых слабостях в самых важных системах.
Уайсопал заявил, что организациям необходимо пересмотреть подход к оценке и измерению снижения уязвимостей. «Успех в сокращении долгов по безопасности зависит от фокуса. Направляйте команды на небольшое подмножество уязвимостей, которые одновременно являются высоко эксплуатируемыми и способны нанести катастрофический ущерб организации, если их не устранить. Накладывая потенциал эксплуатации поверх системы CVSS, организации добавляют критически важный бизнес-контекст и создают «скоростную полосу» для уязвимостей высокого риска, требующих немедленного внимания».
Он также призвал к изменениям в метриках и инструментарии для поддержки этого сдвига. «CISO должны сместить акцент метрик с подсчёта общего числа уязвимостей на измерение снижения эксплуатационного риска. Чтобы поддерживать скорость разработки и сделать исправление беспрепятственным, интегрируйте автоматизированные исправления непосредственно в рабочие процессы разработки и используйте инструменты управления состоянием безопасности приложений для объединения и приоритизации обнаруженных проблем. Такой подход гарантирует, что безопасность станет катализатором, а не препятствием для инноваций».
Скорость устранения по всем типам сканирования, измеряемая как период полураспада, составила 243 дня в 2026 году, снизившись с 252 дней в 2025 году. Улучшение сокращает среднее время воздействия, но по-прежнему оставляет долгий период, в течение которого известные проблемы остаются открытыми в нескольких релизах.
Критический долг сторонних компонентов составил 66% в 2026 году, снизившись с 70% в 2025 году. Этот показатель отражает, где находятся наиболее опасные долгоживущие проблемы, и он продолжает указывать на управление зависимостями как на ключевую область контроля для многих программ AppSec и безопасности продуктов.
Исправление в цепочке поставок часто подразумевает больше, чем просто применение патча. Обновление зависимости может потребовать регрессионного тестирования, работ по обеспечению совместимости и координации между сервисами, использующими один и тот же набор пакетов. Контроль в этой области часто вращается вокруг видимости прямых и транзитивных зависимостей, регулярного графика обновлений и защитных механизмов, снижающих попадание уязвимых компонентов в конвейеры сборки.
Чёткое владение и актуальность инвентаризации важны, потому что командам необходимо знать, какие сервисы используют какие пакеты, прежде чем исправление сможет продвигаться быстро. Многие CISO также рассматривают контроль зависимостей как способ сократить повторяющиеся оповещения, стабилизировать планирование выпусков и обеспечить доказательства для аудиторов, когда те спрашивают, как отслеживаются и обновляются уязвимые компоненты.

Загрузите: Исследование Blue Report 2025 раскрывает реальную эффективность средств защиты