90% активов с проверенным владельцем — порог, ниже которого метрики по remediation быстро превращаются в красивую бухгалтерию. Бэклог уязвимостей часто растет не потому, что компании плохо сканируют инфраструктуру, а потому что никто точно не знает, кто должен чинить конкретный сервер, сервис или приложение. Для русскоязычных IT-команд это знакомая боль: тикеты есть, CVE есть, SLA есть, а владельца с полномочиями и временем — не всегда.
Как пишет Dark Reading, проблема не в нехватке новых сканеров уязвимостей. Автор материала Нишант Шарма, специалист по кибербезопасности с опытом более 14 лет в vulnerability management и application security, формулирует ее жестче: компании путают видимость с управляемостью. Купить инструмент, который найдет больше проблем, проще, чем навести порядок в ownership, CMDB и инженерных приоритетах.
Типичный сценарий выглядит почти комично, если бы не последствия. Бэклог уязвимостей дорастает до уровня совета директоров, после чего бизнес покупает более широкий охват сканирования, более частые проверки, threat intelligence и панель, где все видно в одном окне. Через год у компании действительно лучше видимость. Только теперь она смотрит на еще больший список незакрытых проблем.
Шарма приводит показательный пример: после включения аутентифицированного сканирования серверного парка количество найденных проблем за один квартал выросло втрое. Инфраструктура за это время не стала втрое опаснее. Команда просто перестала жить в удобном неведении. В этом и ловушка: если программу безопасности оценивают по числу открытых findings, расширение покрытия формально ухудшает картину. Команды быстро учатся не смотреть туда, где потом придется объясняться.
Сканирование масштабируется покупкой лицензии, исправление — нет. У remediation есть физические ограничения: инженерные часы, окна изменений, совместимость приложений, зависимость от vendor patch, допустимый downtime и приоритеты продуктовой команды. Если уязвимость попала в тикет, это еще не значит, что у назначенного человека есть право менять платформу, возможность трогать legacy-приложение или место в спринте.
Dark Reading выделяет несколько провалов, которые маскируются под один большой бэклог уязвимостей. Первый — у актива нет владельца. Это худший вариант: находку невозможно нормально эскалировать, потому что эскалировать не к кому. Второй — владелец есть, но без полномочий: например, патч зависит от вендора, платформой управляет другая команда, а приложение заморожено контрактом. Третий — полномочия есть, но нет capacity: исправления конкурируют с feature delivery в том же backlog. Четвертый — нет последствий: SLA нарушается, но отчет уходит только в security, а не руководителю команды-владельца.
Из этого следует неприятный для многих security-отделов вывод: главный рычаг — не новый сканер, а точная и поддерживаемая карта asset-to-owner. Не департамент, не абстрактная инфраструктура, а человек или постоянная команда, которую можно пинговать, включать в SLA и выводить на уровень инженерного руководства. Карта не создается один раз: реорганизации, миграции, списание серверов и смена команд постоянно ее ломают.
Для зрелой программы управления уязвимостями полезнее смотреть не только на число открытых находок. В материале предлагаются более практичные метрики: среднее время исправления по командам-владельцам, соблюдение SLA вместо простой доли закрытых тикетов и процент инфраструктуры с подтвержденным владельцем. Последний показатель особенно важен: если ниже 90%, остальные графики легко врут, потому что часть активов просто выпадает из управленческой модели.
Есть и хороший сигнал для бизнеса. В одном из описанных кейсов time-to-remediate сократился с 45 до 10 дней, а соблюдение SLA выросло с 30% до 95% за шесть месяцев. Ключевым изменением была не магическая кнопка в инструменте, а автоматическая маршрутизация findings на конкретные owning teams, отчетность по просрочкам на уровень инженерного руководства, нормальный процесс исключений и отдельная эскалация для активов без владельца.
Для разработчиков это означает меньше хаотичных срочных просьб от security и больше предсказуемой работы. Когда remediation получает владельца, приоритет и понятные границы, исправления можно планировать вместе с релизами, а не вставлять их ночью между регрессией и демо для клиента. Для IT-директоров и CISO вывод еще проще: открытые уязвимости — это не только технический долг, но и тест на качество управления инженерной организацией.
Следующий этап в vulnerability management, похоже, будет менее глянцевым, чем рынок сканеров хотел бы признать: меньше разговоров про единое окно, больше скучной дисциплины вокруг владельцев, SLA и права менять системы. Компании, которые первыми разберут эту оргструктурную часть, будут закрывать риски быстрее даже с теми же инструментами, что и соседи по отрасли.