В B2B-компании на 300 человек исследователь нашёл базу данных, доступную из интернета и защищённую слабой аутентификацией. На бумаге это выглядело как пожар: критическая серьёзность, внешний периметр, понятный путь атаки. Но реальная приоритизация уязвимостей быстро сломала красивую картинку: база оказалась сбрасываемым тестовым стендом для кандидатов на работу, а не хранилищем клиентских данных.
Кейс описывает The New Stack в материале Megan Carnegie от 14 сентября 2026 года. Главный вывод неприятен для команд безопасности, но полезен для бизнеса: сканер может найти дыру, AI может подсветить ещё десятки подозрительных мест, но ни один инструмент сам по себе не понимает, сколько компании будет стоить компрометация конкретного актива.
История с тестовой базой хорошо показывает, почему старый подход «сортируем по severity и бежим сверху вниз» всё хуже работает. Уязвимость выглядела опасной: база торчала в интернет, а аутентификация была слабой. Но после проверки выяснилось, что это не продакшен, не платёжный контур, не CRM и не система с персональными или клиентскими данными. Исправить такое всё равно нужно, но бросать туда первых доступных инженеров вместо проблем в боевых сервисах было бы дорогим способом выглядеть занятыми.
Основатель консультационной компании IOmergent Джон Роуз формулирует проблему проще: в безопасности всегда больше задач, чем людей и часов. AI и массовые инструменты сканирования не убрали этот дефицит, а местами усилили его. Команды получают события из IAM, firewall, endpoint-систем, облачных логов, vendor feeds и threat intelligence. Каждая запись умеет выглядеть срочной. Каждая просит тикет. Каждая делает вид, что именно она спасёт квартал.
На этом фоне CVSS остаётся полезной, но недостаточной шкалой. Базовые метрики Common Vulnerability Scoring System оценивают техническую серьёзность: вектор атаки, сложность эксплуатации, нужные привилегии, влияние на конфиденциальность, целостность и доступность. Проблема в том, что базовый балл специально рассчитан так, чтобы быть стабильным между разными средами. Он не отвечает на вопросы, которые волнуют CISO, CTO и владельца продукта: сервис виден из интернета или спрятан за сетевыми контролями, есть ли компенсирующие меры, крутится ли код в проде, влияет ли он на деньги и клиентов.
Более зрелая приоритизация уязвимостей начинается не с вопроса «какой балл?», а с вопроса «дотянется ли атакующий?». Средняя по CVSS проблема во внешнем сервисе, который ведёт к привилегированным аккаунтам или данным клиентов, может быть важнее критической находки в изолированном стенде. Дальше идут данные об эксплуатации: есть ли уязвимость в каталоге CISA Known Exploited Vulnerabilities, что показывает Exploit Prediction Scoring System, появились ли публичные эксплойты, меняется ли интерес атакующих. Ни один из этих сигналов не заменяет решение, но все они помогают отделить теоретическую дыру от риска, который уже стучит в дверь.
AI добавляет к этой картине двойной эффект. С одной стороны, модели и агенты помогают быстрее искать нетривиальные пути эксплуатации, связывать разрозненные сигналы и отвечать на вопросы SOC-аналитика: новая это проблема или старая, какие данные под угрозой, prod это или dev, как менялся риск за последние недели. С другой стороны, AI-разработка сама создаёт новый шум. В источнике упоминается академическое исследование более чем 20 000 исправлений, где код, исправленный LLM, вносил почти в 9 раз больше новых уязвимостей, чем код разработчиков. Для команд это не повод запрещать AI, а повод перестать относиться к нему как к магической уборщице backlog.
Практический вывод для русскоязычных IT-команд довольно приземлённый. Нужна не ещё одна доска с красными алертами, а понятная схема владения риском: кто принимает исключение, на какой срок, с какой датой пересмотра и при каких условиях тикет снова становится срочным. Если риск принят, он не исчезает. Он просто перестаёт жить в тёмном углу Jira, где его никто не трогает до инцидента.
Для бизнеса это означает, что безопасность всё меньше похожа на соревнование по количеству закрытых CVE. Побеждает не команда, которая чинит больше всех, а команда, которая чинит то, что реально бьёт по клиентам, деньгам, данным и доверию. Следующий этап, похоже, будет не про «AI нашёл ещё 500 проблем», а про то, кто сумеет превратить эти 500 проблем в 10-20 осмысленных задач для инженеров. Именно там приоритизация уязвимостей становится не отчётом для аудита, а нормальной операционной функцией компании.