82% компаний живут с security debt — уязвимостями, которые остаются открытыми больше года. На этом фоне Dark Reading формулирует неприятно простой тезис: проблема не в том, что багов слишком много, а в том, что самые опасные из них слишком долго торчат наружу. Для разработчиков, CISO и IT-руководителей это прямой сигнал: пора перестать мерить безопасность количеством закрытых тикетов и начать считать окно атаки.
Об этом пишет Dark Reading в колонке Криса Уайсопала, основателя и chief security evangelist компании Veracode, опубликованной 18 июня 2026 года. Автор сводит разговор о security debt к двум вопросам: какие уязвимости в наших системах реально доступны атакующему и как долго они остаются в таком состоянии. На бумаге это звучит почти банально, но именно здесь, по его логике, ломается привычная модель приоритизации. Команды годами жили в режиме backlog management: сортировали находки по severity, спорили о критичности, переносили исправления между спринтами. Проблема в том, что атакующий не читает ваш Jira и не уважает CVSS как корпоративный ритуал.
Уайсопал обращает внимание на сочетание двух факторов. Первый: долгов по уязвимостям уже накоплено слишком много. Второй: доля багов, которые одновременно серьезны и с высокой вероятностью могут быть использованы, растет. В этой связке backlog перестает быть просто техническим хвостом и превращается в операционный риск. Автор отдельно подчеркивает, что у команд давно нет иллюзий насчет возможности «починить все». Новость в другом: окно между обнаружением уязвимости и ее реальной эксплуатацией продолжает сжиматься, а инструменты и техники для атак становятся доступнее. Иными словами, складировать проблемы «на потом» стало заметно дороже.
Практический вывод из статьи довольно жесткий. Начинать надо не со всей кодовой базы, а с малого числа приложений, где сосредоточен основной риск: систем, связанных с выручкой, чувствительными данными и внешним доступом. В статье они названы crown jewels, и именно туда, как правило, смотрит злоумышленник в первую очередь. Дальше — еще один фильтр: среди всех находок нужно вытащить те, которые имеют высокую или очень высокую критичность и при этом с высокой или очень высокой вероятностью будут эксплуатированы. По данным исследования, на которое ссылается автор, в эту зону попадает 11,3% уязвимостей. Цифра важна не потому, что она маленькая, а потому, что дает менеджерам и техлидам шанс перестать симулировать контроль над всем фронтом сразу.
Это довольно болезненно бьет по старой вере в универсальность severity-оценок. Уайсопал прямо пишет: высокий балл сам по себе уже не гарантирует верную очередность работ. Атакующим важнее другое — достижимость уязвимости в production, доступность приложения снаружи, наличие известного эксплойта и связь системы с чем-то ценным для бизнеса. Отсюда неприятный, но знакомый для практиков вывод: уязвимость средней тяжести в публичном сервисе может быть опаснее, чем критическая проблема во внутренней системе без внешнего доступа. Для российских и вообще русскоязычных IT-команд это звучит особенно актуально, потому что в реальных продуктах приоритизация часто по-прежнему строится вокруг формального compliance, дедлайнов релиза и условного «закроем critical до конца квартала». Логика статьи предлагает другой вопрос: что атакующий сможет использовать раньше, чем вы успеете это исправить.
Отдельный блок посвящен пропускной способности команд. Автор называет remediation capacity одним из главных ограничений современного application risk management. Уязвимости находят быстрее, чем разработчики и security-инженеры успевают их убирать, и именно этот разрыв подпитывает security debt. Если исправлениями занимаются только в моменты, когда у продуктовой команды «есть окно», очередь будет расти почти автоматически. Поэтому Уайсопал предлагает относиться к remediation как к отдельной функции с выделенным инженерным временем, понятными ожиданиями по срокам устранения и постоянной проверкой, не превышает ли входящий поток находок реальную способность команды их закрывать. Перевод на нормальный язык простой: если безопасность не сидит в планировании мощности рядом с фичами, потом она все равно туда вернется, но уже через инцидент.
Не менее показателен фрагмент про сторонние зависимости. По данным, приведенным в статье, 66% security debt в third-party code приходится на критические проблемы. Еще хуже то, что уязвимости в зависимостях живут дольше: медианный срок до устранения таких дефектов автор оценивает в 358 дней. Причины знакомы любому, кто обновлял стек в живом продукте: транзитивные зависимости разрастаются, апгрейды ломают обратную совместимость, ответственность за компонент размазывается между командами, а бизнес не горит желанием тормозить релиз ради очередного обновления библиотеки. В итоге именно open source и сторонний код тихо расширяют окно экспозиции, пока все обсуждают критичность багов в собственных сервисах.
Важнее всего в этой колонке даже не список советов, а смена метрики. Автор предлагает смотреть не на количество найденных и закрытых уязвимостей, а на exposure time — сколько времени критичная и пригодная к эксплуатации дыра существует до исправления или смягчения. Это более неприятный KPI, потому что он хуже подходит для красивых отчетов. Зато он ближе к реальной угрозе: именно в этом временном окне и работает атакующий. Если такая метрика начинает снижаться, программа безопасности правда уменьшает риск. Если нет, все разговоры о «сотнях закрытых задач» выглядят как бухгалтерия без экономического смысла.
Главный вывод тут, пожалуй, неудобен для всех сторон сразу. Security debt не исчезнет: уязвимостей всегда будет больше, чем ресурсов на их устранение. Но рынок, похоже, все меньше готов прощать компаниям долгие окна экспозиции в действительно важных системах. Для разработчиков это означает более жесткую привязку безопасности к SDLC, для менеджеров — необходимость торговаться не за число тикетов, а за время до фикса, а для бизнеса — признание простой вещи: иногда выпуск одной фичи позже дешевле, чем месяцы жизни с уязвимостью, которую давно можно было убрать.