Проверка безопасности - отдельный класс работы, а не более строгий обзор кода. Управляемых типов два: ревьюер проверяет изменения до слияния, а сканер регулярно проходит по кодовой базе в состоянии покоя. Оба работают поверх облачных агентов и автоматизаций, и обоим нужен хотя бы один инструмент или внешний сервер - чтобы доставить результат или добрать контекст. Разница с обычным обзором в вопросе, который задают коду: не правильно ли он написан, а что с ним можно сделать снаружи.
Разница между двумя типами не в строгости, а в моменте и в предмете. Ревьюер ищет новые уязвимости, которые появляются вместе с изменением: свежая проверка прав, новый способ собрать запрос, новая точка входа, новое место, где данные пользователя попадают туда, где их не ждали. Сканер ищет то, что уже живёт в коде и никем не замечено, - в том числе то, что пропустили при вводе и что стало проблемой позже, когда рядом появился другой код. Один смотрит на дельту, другой на состояние; ни один не заменяет другого.
Локальная проверка добавляет третий момент - до отправки. По умолчанию она сравнивает все изменения ветки, включая незакоммиченные, с базовой веткой. Если база другая или нужно посмотреть только рабочее дерево, это указывают явно. Мелочь, но именно из-за неё бывает недоумение: человек ждёт проверки последнего коммита, а получает разбор всей ветки, включая то, что он сам считал давно закрытым.
Полезно один раз свести три варианта в таблицу: что запускает каждый и для чего он предназначен. Ниже такая карта. Она же напоминает про доступность: локальные команды обзора появились в определённых версиях и на определённых поверхностях, и часть поддержки в командной строке может быть заявлена как готовящаяся. Это тот случай, когда возможность стоит проверить в своём окружении до того, как строить на ней процесс.
| Проверка | Что запускает | Назначение |
|---|---|---|
| Ревьюер безопасности | События пул-реквеста | Новые уязвимости до слияния |
| Сканер уязвимостей | Расписание | Существующие и пропущенные ранее проблемы |
| Локальная проверка | Ручной запуск до отправки | Ранняя обратная связь по текущей ветке |
Требование хотя бы одного инструмента у управляемых проверок выглядит формальностью, но за ним стоит здравая мысль: находка, которой некуда попасть, не существует. Проверка должна уметь либо оставить результат там, где его увидят, либо дотянуться до контекста, без которого вывод будет неверным, - до трекера, до системы задач, до внутреннего источника знаний о сервисах. Поэтому доставку продумывают вместе с самой проверкой, а не после: адресат, формат и то, что происходит с находкой, если адресат недоступен.
Самое главное в работе с находками - не сам поиск, а жизненный цикл. Нужны определение уровней серьёзности, владелец у каждой находки, срок реакции, процедура осознанного исключения и подтверждение того, что исправление действительно закрыло проблему. Без этого поток находок превращается в фон: он есть, но на решения не влияет. Список, который только растёт, перестают читать примерно так же быстро, как перестают читать журнал с включённым отладочным уровнем.
Процедура исключения заслуживает отдельного внимания, потому что её обычно и не заводят. Часть находок будет неверной, часть - верной, но неприменимой в вашем контексте. Если такие случаи некуда деть, их просто игнорируют молча, и через месяц молчаливо игнорируют уже всё подряд. Явное исключение с автором, причиной и сроком пересмотра стоит дёшево и делает поведение честным: видно, что решение принято, а не забыто. Признак отсутствия такой процедуры простой - одна и та же находка возвращается в каждом прогоне, и каждый раз её заново кто-то читает.
Отдельно стоит оценка того, исправлена ли находка. Автоматическая оценка полезна для аналитики: она показывает динамику и помогает планировать. Но закрывать критичные находки должен человек или процесс безопасности - потому что подтверждение исправления и есть та часть, где цена ошибки максимальна. Автоматическая пометка исправлено на самом деле означает похоже на исправленное, и разница между этими двумя формулировками измеряется инцидентами.
Инженерный вывод простой: агенты безопасности дают охват, но не дают процесса. Они находят кандидатов в проблемы, а дальше начинается обычная работа: приоритизация, владельцы, сроки, исключения и подтверждение. Внедрять их стоит вместе с этим процессом, иначе через месяц у вас будет большой список находок и никакого изменения в защищённости.
Типичные провалы предсказуемы. Считать проверку безопасности разновидностью обзора кода. Ждать от локальной команды разбора одного коммита, когда она смотрит на всю ветку. Внедрить сканер без владельцев и сроков. Не завести процедуру исключений и получить молчаливое игнорирование. И закрывать критичные находки автоматической оценкой вместо человека.