Компания уже платит за отложенную безопасность — просто не видит счёт

В большинстве компаний security debt не существует как управленческая категория.

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

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

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

По данным Verizon DBIR 2026, эксплуатация программных уязвимостей стала начальным вектором уже для 31% исследованных утечек, обойдя использование украденных учётных данных. Это не означает, что каждый инцидент является результатом security debt. Но показывает, насколько дорого может обходиться неспособность быстро обнаруживать, оценивать и устранять накопленные технологические риски. (Verizon)

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

Security debt возникает похожим образом, но его последствия отличаются.

Это накопленный объём осознанно или неосознанно отложенных решений, из-за которых система становится:

Security debt появляется, когда компания:

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

Сводить security debt к backlog уязвимостей слишком просто.

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

Например, компания может регулярно устанавливать обновления, но при этом не иметь достоверного реестра активов. Она может внедрить MFA, но сохранить общие сервисные учётные записи. Может проводить тестирование безопасности перед релизом, но не включать threat modeling в момент принятия архитектурных решений.

Контроли формально существуют. Однако каждое изменение требует всё больше ручного анализа, исключений и согласований.

Именно так security debt начинает начислять проценты.

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

Компания платит ими, когда:

Чем больше долг, тем меньше у бизнеса вариантов.

В определённый момент компания уже не выбирает лучшее решение. Она выбирает единственное решение, которое совместимо с накопленными ограничениями.

Во время атаки WannaCry в 2017 году были затронуты как минимум 81 из 236 больничных трастов Англии и ещё 603 организации первичной медицинской помощи.

Национальное аудиторское управление Великобритании установило, что заражённые организации использовали необновлённые или неподдерживаемые версии Windows. До атаки NHS Digital выпускала предупреждения о необходимости обновления, но не существовало формального механизма проверки того, выполнили ли организации рекомендации. (National Audit Office (NAO))

Неподдерживаемая система может продолжать выполнять свою бизнес-функцию. Пользователи не видят проблемы. Отчётность может оставаться зелёной.

Но вокруг такой системы постепенно возникает инфраструктура долга:

В итоге технологическая устарелость превращается в риск непрерывности бизнеса.

Когда была раскрыта уязвимость Log4Shell, многим организациям оказалось недостаточно просто получить исправленную версию библиотеки.

Сначала нужно было ответить на более сложный вопрос: где именно она используется?

CISA рекомендовала организациям инвентаризировать все активы с Log4j, зафиксировать версии компонентов, даты обновления, привилегии учётных записей и расположение систем в корпоративной архитектуре. Отдельно подчёркивалось, что эксплуатация уязвимости могла продолжаться длительное время. (CISA)

Компании, у которых не было прозрачности программных зависимостей, фактически обнаружили ещё один вид security debt — долг знания.

Продукт работал. Но организация не знала точно:

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

Частая реакция — занести все недостатки в единый backlog и начать последовательно их закрывать.

Но security debt нельзя управлять только количеством задач.

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

Например:

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

Поэтому организации нужен не просто backlog, а реестр security debt, связанный с бизнес-рисками.

NIST рекомендует документировать сценарии киберриска через вероятность, последствия, уязвимые активы и допустимость риска, а затем интегрировать их в общий профиль enterprise risk management. (NIST Computer Security Resource Center

Для каждого элемента долга я бы фиксировал не только техническое описание, но и управленческий контекст.

ПолеЧто необходимо зафиксироватьЭлемент долгаЧто именно было отложено или принято как исключениеПричина появленияОграничение сроков, бюджета, архитектуры, поставщика или компетенцийСвязанный активСистема, продукт, данные или бизнес-процессСценарий рискаЧто может произойти и при каких условияхВладелецКто принимает решение о сохранении долгаОсновная суммаОценка ресурсов, необходимых для устраненияПроцентная ставка рискаНасколько быстро растёт риск и стоимость дальнейшего исправленияКомпенсирующие мерыЧто временно снижает вероятность или последствияСрок действия решенияКогда долг должен быть пересмотренТриггер погашенияКакое событие делает устранение обязательным

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

Её можно оценивать по пяти факторам:

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

Неподдерживаемый компонент на периметре, который нельзя обновить без изменения нескольких продуктов, — высокую.

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

Не каждый результат сканирования является долгом. И не каждый долг обнаруживается сканером.

В реестр должны попадать устойчивые архитектурные, процессные и технологические ограничения.

Запись «устаревшая версия фреймворка» почти ничего не говорит руководителю.

Запись «невозможность оперативно обновить интернет-сервис, через который проходит 40% клиентских обращений» создаёт основу для решения.

ИБ может обнаружить и оценить долг. Но она не должна единолично владеть всеми бизнес-последствиями его сохранения.

Ими могут стать:

Если security debt не конкурирует за ресурсы наравне с функциональностью, он будет откладываться бесконечно.

Руководству важно видеть:

Я не считаю, что наличие security debt свидетельствует о незрелости компании.

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

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

Security debt — это не перечень старых недостатков. Это стоимость решений, последствия которых компания перенесла в будущее.

Компания уже платит за отложенную безопасность.

Платит временем разработчиков, сложностью изменений, ручными контролями, зависимостью от legacy-систем и неспособностью быстро реагировать на новые уязвимости.

Иногда этот долг оправдан. Но только до тех пор, пока организация видит его, оценивает проценты и сохраняет возможность выбрать момент погашения.

Если же долг не учтён, момент выбирает уже не компания.

Его выбирают новая уязвимость, отказ поставщика, регулятор или злоумышленник.

Какой вид security debt обходится вашей организации дороже всего: устаревшие системы, архитектурные компромиссы, исключения из политик или незнание собственных зависимостей?

Подписывайтесь на мой ТГ канал: @ib_decisions