Кейс: разработчики игнорируют сканер
Вопрос
Разработчики жалуются, что SAST выдаёт сотни ложных срабатываний, и просто нажимают «пропустить». Что вы сделаете?
Попробуйте сами
Ответьте вслух за 2 минуты, как на собесе. Потом сверьтесь с тезисами: что прозвучало, а что нет.
Показать ответ и разбор
Коротко
Что должно прозвучать в ответе
Измерить: долю ложных срабатываний по правилам
Отключить или переписать шумные правила, оставить блокирующими только точные
Добавить контекст фреймворка: санитайзеры, безопасные обёртки
Baseline для старого кода, фокус на новых изменениях
Удобная разметка «ложное срабатывание» с ревью AppSec
Обратная связь от команд и метрика доверия
Что могут спросить следом
- Как не пропустить настоящие уязвимости, отключая правила?
- Кто должен разбирать находки: разработчики или AppSec?
Разбор
Образцовый ответ: «Проблема реальная: если инструмент шумит, им перестают пользоваться. Сначала цифры: по каждому правилу, сколько находок отмечено как ложные. Обычно 20% правил дают 80% шума. Их отключаю или дописываю: учитываю наши санитайзеры и обёртки, чтобы анализатор понимал, что данные очищены. Блокирующими оставляю правила с высокой точностью, остальное в информационный отчёт. Старый код в baseline. Ложное срабатывание отмечается в один клик с комментарием, а AppSec выборочно проверяет такие отметки. Чтобы не потерять настоящие проблемы, отключённые классы покрываю другими способами: тестами, ревью, DAST».
Ответьте сами, а не прочитайте
В тренажёре вопрос попадёт в повторения и вернётся, когда начнёт забываться. Плюс билеты с зачётом: 20 вопросов, не больше 2 ошибок.