ИИ нашёл 20 000 новых уязвимостей. Компания всё равно может исправить только 200

Представим: за месяц инструменты с ИИ нашли 20 000 подтверждённых уязвимостей. Команды могут исправить, протестировать и выпустить изменения только для 200. Цифры условные. Ограничение вполне реальное: время людей и возможность безопасно менять работающие системы.

Это уже практический вопрос. В марте 2026 года Anthropic сообщила о 22 уязвимостях, найденных Claude в Firefox за две недели. Но даже в таком исследовании находку нужно проверить, а исправление — испытать. Исследование Anthropic.

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

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

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

Поэтому я бы начал разговор CISO и CTO с трёх решений. Первое — определить, что попадает в работу. Убрать дубли, проверить доказательства, объединить находки с общей причиной. Оценивать доступность системы извне, возможность эксплуатации, получаемые права и последствия для бизнеса. Одной оценки критичности недостаточно. Неподтверждённый отчёт ИИ должен оставаться на проверке, а не автоматически становиться обязательством разработки. Для признаков активной эксплуатации нужен срочный маршрут. Правила отбора не должны превращаться в способ спрятать неудобные находки.

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

Третье — закрепить ресурс. CISO, CTO и владельцы продуктов должны согласовать долю времени на устранение рисков, резерв для срочных случаев и условия пересмотра приоритетов. Оставленный риск получает владельца и дату следующего решения.

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

Моя позиция: расширение поиска должно сопровождаться решением о ресурсе на исправления. Иначе мы масштабируем прежде всего очередь.

Если завтра инструменты найдут в десять раз больше реальных уязвимостей, кто в вашей компании решит, какие продуктовые задачи уступят место их устранению?