У компании может быть 40 тысяч открытых уязвимостей и вполне вменяемая защита. А может быть всего несколько сотен замечаний и одна забытая система на границе сети, которая перечёркивает все красивые показатели. Поэтому считать долг по безопасности количеством CVE почти так же полезно, как оценивать финансовое положение компании по числу неоплаченных счетов без учёта сумм.
Под долгом по безопасности разумнее понимать известные организации слабые места, отклонения и временные компромиссы, которые решили пока не устранять. Устаревшая операционная система, исключение из многофакторной аутентификации, открытый наружу административный интерфейс, сервис без владельца, секрет в старом репозитории, неподдерживаемая библиотека, временно разрешённый слишком широкий сетевой доступ. Проблема появляется не только потому, что защита несовершенна. Проблема появляется, когда отклонение известно, но продолжает жить.
Сам термин пока нельзя считать строгим отраслевым стандартом. Исследователи по-разному проводят границу между техническим долгом, уязвимостями и собственно долгом по безопасности. В исследовании 2024 года авторы прямо указывают на отсутствие общепринятого определения. Для директора по информационной безопасности, CISO, такая неопределённость даже полезна. Вместо ещё одного модного термина компания может создать собственную операционную модель и включать в неё только то, чем действительно можно управлять.
Долг по безопасности начинается не с CVE
Не каждая уязвимость превращается в долг. Новая проблема, для которой ещё нет исправления, обходного решения или разумной компенсационной меры, представляет риск, но организация пока ничего не отложила. Аналогично неизвестную уязвимость невозможно сознательно погасить. Долг возникает в тот момент, когда компания уже знает о разрыве между текущим и приемлемым состоянием, знает возможное решение, но оставляет разрыв на будущее.
Поэтому в реестр долга должны попадать не только непропатченные CVE. Там же находятся устаревшие системы, просроченные исключения из политик, постоянные локальные администраторы, забытые учётные записи, неподдерживаемые сетевые устройства, ручные процессы управления сертификатами, отсутствие журналирования на критичной системе и другие известные слабости. Общий признак один. Проблему можно сформулировать как конкретное отклонение и назвать действие, которое уменьшит риск.
Такое определение сразу убирает много шума. Сканер может ежедневно создавать тысячи технических находок, но CISO не обязан превращать каждую находку в отдельный пункт долговой книги. Несколько сотен одинаковых уязвимых узлов могут представлять одну системную проблему, например устаревшую версию платформы или сломанный процесс обновления. Управлять нужно причиной и затронутым контуром, а не размером выгрузки из сканера.
Одна запись должна описывать решение, а не только проблему
Главная ошибка при создании реестра долга выглядит безобидно. Команда переносит туда результаты сканеров практически без обработки. Получается ещё один список CVE с оценками CVSS, только теперь список торжественно называется «security debt». Через несколько месяцев в нём десятки тысяч строк, владельцы перестают смотреть на очередь, а руководство видит только график, который почти не двигается.
Рабочая единица долга должна отвечать на несколько практических вопросов. Где находится проблема, какой бизнес-процесс зависит от системы, кто отвечает за решение, как выглядит целевое состояние, что мешает исправить отклонение сейчас и когда решение пересмотрят. Если команда не может назвать владельца и следующий шаг, перед ней не управляемый долг, а плохо описанный риск.
| Поле | Что фиксировать |
|---|---|
| Объект | Система, сервис, приложение, компонент или группа однотипных активов |
| Отклонение | Конкретная разница между текущим и принятым безопасным состоянием |
| Последствие | Какой сценарий атаки или сбоя становится возможным |
| Экспозиция | Доступность из интернета, внутренних сегментов, партнёрских сетей или только локально |
| Владелец | Команда или руководитель, который может принять решение и выделить ресурсы |
| Компенсация | Сегментация, фильтрация, ограничение прав, мониторинг или другая временная защита |
| Способ погашения | Обновление, миграция, изменение архитектуры, конфигурации или вывод системы |
| Срок пересмотра | Дата, после которой исключение нельзя автоматически считать действующим |
Полезно отдельно записывать причину отсрочки. «Нельзя обновить» почти ничего не объясняет. Формулировка «новая версия не поддерживает контроллер производственной линии, замена контроллера запланирована на ноябрь» уже позволяет обсуждать стоимость, срок и временные меры. Хороший реестр превращает техническую проблему в управленческое решение.
Как выбирать очередь погашения
Сортировка только по CVSS выглядит объективно, но даёт ложное чувство точности. CVSS прежде всего описывает техническую тяжесть уязвимости. Оценка не знает, есть ли уязвимый продукт в интернете, хранит ли система платёжные данные, существует ли рабочий эксплойт, стоит ли перед сервисом дополнительный фильтр и насколько болезненно пройдёт остановка. Подробно различия между CVSS, EPSS и SSVC разобраны в сравнении SecurityLab.
Первый сильный сигнал даёт каталог KEV американского агентства CISA. В каталог попадают уязвимости, для которых подтверждена эксплуатация в реальных атаках. Для частной компании KEV не устанавливает обязательный срок исправления, но хорошо отвечает на вопрос, где теоретический риск уже превратился в практику злоумышленников.
Второй сигнал даёт EPSS. Модель оценивает вероятность эксплуатации опубликованной CVE в ближайшие 30 дней и пересчитывает показатели ежедневно. EPSS не знает контекст конкретной компании и не измеряет ущерб, поэтому превращать показатель в готовый «рейтинг риска» нельзя. Высокая вероятность эксплуатации малозначимого внутреннего сервиса и меньшая вероятность атаки на критичный пограничный узел требуют разных решений.
Для спорных случаев полезна методика SSVC, которая связывает свойства уязвимости и среды с рекомендуемым действием. В актуальной документации терминология постепенно смещается от «дерева решений» к «таблице решений», но принцип остаётся прежним. Организация должна не получать магическое число, а последовательно отвечать на вопросы об эксплуатации, воздействии, доступности системы и допустимой реакции.
| Сигнал | Как влияет на очередь |
|---|---|
| Подтверждённая эксплуатация | Резко повышает срочность |
| Высокая экспозиция | Пограничные и доступные извне системы получают дополнительный приоритет |
| Критичный бизнес-процесс | Повышает потенциальный ущерб даже при умеренной технической оценке |
| Высокий EPSS | Показывает повышенную вероятность практической эксплуатации CVE |
| Рабочая компенсационная мера | Может дать время на безопасное обновление или миграцию |
| Большой возраст долга | Сигнализирует о системной неспособности закрыть проблему |
| Повторение одной причины | Требует исправлять процесс или архитектуру, а не отдельные симптомы |
Возраст долга иногда важнее количества
Пять тысяч свежих находок после подключения нового сканера выглядят страшнее пяти старых исключений. На практике старые исключения могут быть опаснее. Если временное разрешение живёт три года, пережило двух владельцев системы и никто уже не помнит исходную причину, компания потеряла контроль над риском. Возраст долга показывает не столько техническую опасность, сколько качество управления.
В 2026 году ISACA предложила собственный Security Debt Index, который учитывает тяжесть, длительность и скорость появления новых проблем. Полезнее воспринимать такую модель как индикатор направления, а не как физическую единицу киберриска. Даже авторы подхода описывают индекс как средство для сравнения динамики, а не точный универсальный измеритель.
Для большинства компаний достаточно нескольких понятных показателей. Сколько критичного долга появилось и сколько закрыто за месяц, каков медианный возраст открытых записей, сколько исключений просрочено, какая доля критичных внешних систем содержит известные проблемы, сколько систем вышло из поддержки и какие причины постоянно создают новые записи. Такие показатели быстро показывают неприятную правду. Иногда команда закрывает тысячи тикетов, а общий риск продолжает расти.
Скорость погашения ничего не значит без скорости появления
Отчёт «за квартал закрыли 800 уязвимостей» звучит хорошо только до вопроса, сколько проблем появилось за тот же период. Если открыли 1200 новых, долговая позиция ухудшилась. Поэтому полезно смотреть на два потока одновременно, входящий и исходящий. Для каждой существенной категории долга нужно понимать, приходит ли новых проблем больше, чем компания успевает устранять.
Такой подход помогает отличить временный завал от сломанного процесса. Допустим, после инвентаризации нашли сотню серверов со старой версией операционной системы. Команда мигрирует по двадцать серверов в месяц, новых устаревших серверов не появляется. Долг контролируем. Если одновременно каждый месяц ещё десять систем достигают конца поддержки без плана замены, перед CISO уже не проект миграции, а постоянный источник нового долга.
То же правило работает в разработке. Если статический анализ регулярно находит одинаковый класс ошибок, бессмысленно бесконечно праздновать закрытые дефекты. Нужно менять шаблоны кода, библиотеки, проверки сборки или архитектурные ограничения. Погашение симптомов без устранения источника напоминает попытку вычерпывать воду, не закрывая кран.
Исключение без даты превращается в постоянную дыру
Безопасность редко может требовать немедленного исправления каждой проблемы. Иногда обновление ломает совместимость, остановка недопустима, производитель ещё тестирует патч или замена оборудования займёт полгода. Отсрочка сама по себе не говорит о плохом управлении. Опасной отсрочку делает отсутствие владельца, компенсационной меры и даты пересмотра.
Любое принятое исключение должно иметь срок жизни. Когда срок заканчивается, решение принимают заново с актуальными данными. Продление тоже считается новым решением и не должно происходить автоматически. Такая простая дисциплина быстро обнаруживает «временные» разрешения, которые живут годами только потому, что однажды никто не захотел спорить перед релизом.
Отдельно стоит работать с неподдерживаемыми системами. Старую платформу далеко не всегда можно безопасно обновить, поэтому долг погашают не только патчем. Помогают сегментация, сокращение сетевой доступности, отдельные правила контроля, минимизация привилегий и план вывода из эксплуатации. Компенсационные меры уменьшают риск, но не должны маскировать отсутствие конечной даты миграции.
Как перестать производить новый долг
Бесконечно разгребать старый долг бесполезно, если организация создаёт новый быстрее. Здесь управление долгом соприкасается с архитектурой, разработкой и эксплуатацией, но не требует превращать программу в огромный проект DevSecOps. Начать можно с мест, где одни и те же проблемы появляются регулярно.
Если серверы выпадают из обновлений, сначала исправляют инвентаризацию и назначение владельцев. Если команды постоянно просят исключения для секретов и доступов, меняют процесс выдачи и хранения секретов. Если продукты неожиданно достигают конца поддержки, жизненный цикл фиксируют ещё на этапе закупки. Если ошибки конфигурации возвращаются после каждого развёртывания, проверку переносят в шаблоны инфраструктуры и автоматические правила.
Такой подход совпадает с логикой NIST CSF 2.0, где управление киберриском рассматривается не как набор отдельных технических действий, а как постоянная функция с определёнными ролями, приоритетами и ответственностью. Для долга по безопасности особенно полезна именно управленческая часть. Компания должна заранее решить, кто имеет право принять риск, кто оплачивает его последствия и когда принятое решение возвращается на пересмотр.
Что сделать за первые 90 дней
В первый месяц не нужно пытаться собрать идеальный реестр всей компании. Лучше выбрать несколько критичных контуров, например внешние сервисы, средства удалённого доступа, инфраструктуру аутентификации и наиболее значимые бизнес-системы. Из сканеров, аудитов, заявок на исключения и сведений об устаревшем оборудовании собирают известные отклонения, объединяют однотипные проблемы и назначают владельцев. Уже на таком ограниченном наборе быстро становится видно, какие данные компания вообще не умеет получать.
Во второй месяц стоит ввести правила очереди. Подтверждённая эксплуатация, внешняя доступность, критичность системы, вероятность атаки, наличие компенсационных мер и возраст долга дают достаточно контекста для первых решений. Одновременно вводят срок жизни исключений. Не требуется сложная математическая формула с весами до третьего знака. Если модель нельзя объяснить владельцу продукта за несколько минут, команда, скорее всего, построила слишком сложную модель.
Третий месяц нужен не для красивой панели, а для проверки динамики. Руководство должно увидеть, сколько значимого долга появилось, сколько закрыто, что продолжает стареть и какие причины создают новые проблемы. После этого выбирают два или три системных источника долга и финансируют их устранение. Такой подход обычно даёт больше эффекта, чем очередная кампания «закрыть все критические CVE до пятницы».
Как понять, что программа работает
Хороший показатель не обязан постоянно стремиться к нулю. В живой инфраструктуре долг будет возникать всегда. Меняются системы, появляются уязвимости, заканчивается поддержка продуктов, бизнес идёт на осознанные компромиссы. Здоровая программа отличается не отсутствием долга, а способностью быстро увидеть новый долг, назначить владельца, оценить риск и принять решение.
У руководства должна появиться возможность задать простой вопрос и получить такой же простой ответ. Какие известные компромиссы сегодня создают наибольший риск для бизнеса и что компания с ними делает. Если для ответа CISO приходится показывать сорок страниц выгрузки сканера, реестр ещё не работает. Если можно назвать несколько главных зон, их владельцев, сроки и динамику, долг уже стал управляемым.
Главный сдвиг здесь скорее организационный, чем технический. Долг по безопасности не нужно превращать в ещё одну абстрактную оценку зрелости. Полезнее относиться к нему как к портфелю отложенных решений. Каждый пункт когда-то появился по конкретной причине, должен иметь цену дальнейшего ожидания и в какой-то момент обязан либо исчезнуть, либо получить новое осознанное решение. Именно такая модель отделяет управление риском от бесконечной борьбы с красными строками в отчёте.