ИИ находит, люди чинят · 5/5 https://set.ki/post/CaZhnCy

Время до исправления: сколько проходит от получения отчёта об уязвимости до выпущенного исправления. Сначала решите, что запускает отсчёт: письмо, сообщение в чате или тикет. Повод даёт Регламент ЕС о киберустойчивости (CRA), но метрику он не задаёт.

С 11 сентября 2026 года статья 14 CRA обязывает производителей цифровых продуктов на рынке ЕС сообщать об уязвимости, которую уже эксплуатируют, национальной группе реагирования (CSIRT) и агентству ENISA. Раннее предупреждение в течение 24 часов, уведомление в течение 72; оба срока от момента, когда стало известно об эксплуатации. Итоговый отчёт не позднее чем через 14 дней после появления исправления или смягчающей меры.

Это сроки сообщения об эксплуатируемых уязвимостях, а метрика нужна для всех отчётов. Числового срока на исправление нет, но для новых продуктов с 11 декабря 2027 года CRA требует устранять уязвимости «без промедления». Триггер: «надёжные свидетельства» эксплуатации, а не сама находка (моё прочтение; по п. 218 пояснения Еврокомиссии, известная, но не эксплуатируемая в продукте уязвимость стороннего компонента обязательному сообщению не подлежит). Не юридическая консультация: подпадает ли продукт, решает юрист.

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

Срок делите на два отрезка: «получили отчёт → подтвердили, что проблема настоящая» и «подтвердили → выпустили исправление». Первый показывает, разбирают ли отчёты, второй — умеет ли команда быстро выпускать.

Стартапу три шага по порядку. 1. Назовите человека, который принимает отчёты и решает, что с ними делать, и положите на сайт security.txt. 2. Составьте перечень зависимостей с версиями (SBOM), чтобы отвечать на вопрос «затронуты ли мы». 3. Включите сканирование зависимостей в CI (автоматические проверки при каждой сборке), но лишь когда есть кому разбирать находки. Сканер без человека на триаже (первичном разборе находок) лишь растит очередь.

Патч без теста не принимайте, даже от ИИ-ассистента.

Legacy-команде тоже три шага. 1. Инвентаризация: что работает и что смотрит наружу. 2. Быстрый путь для security-патчей, чтобы не ждать планового релиза. 3. Человек на триаж с выделенными часами, а не «когда будет время».

Перед правкой старого кода зафиксируйте его поведение характеризационными тестами: они записывают, что код делает сейчас, даже если непонятно, правильно ли. Где быстро не исправить, ставьте временные меры (сегментацию сети, отзыв лишних прав) со сроком и владельцем.

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

Сколько дней у вас проходит от получения отчёта об уязвимости до выпущенного исправления, и кто в команде назовёт это число?

—

Ранее (4/5): чеклист из трёх вопросов к любому громкому заявлению об ИИ-находках - https://set.ki/post/MZ3A9uR

Cерия закончена.