Как кастомное правило SAST остановило security pipeline и усложнило выход релизов
Ситуация: в компании есть отдел DevSecOps и отдел AppSec. За работу security pipeline отвечает DevSecOps. Но, кастомные правила для SAST (используется в security pipeline) могут создавать оба отдела.
Однажды руководитель AppSec случайно увидел в доступных сетях Wi-Fi точку с провокационно-политическим названием. При чём тут SAST? А при том, что это привело его к мысли: "а вдруг в код кто-то добавит такие же лозунги? Нужно сделать кастомное правило на SAST!" Сказано-сделано. Руководитель центра на планёрке идею поддержал: "он действует проактивно, чего я ожидаю и от других".
Не прошло и дня как security pipeline перестал работать. Сначала работа security pipeline стала занимать уйму времени. Потом хорошенько так забилась база ASOC. Причиной стало кастомное правило SAST. Какое именно "нехорошее" слово вкладывалось в логику правила сейчас станет ясно. Правило реагировало на putIn (чаще всего это было на название функции). И таких сработок было - тысячи. Я не знаю всех подробностей работы security pipeline. Но, знаю: он не работал в блокирующем режиме (есть история когда при блокирующем режиме вообще останавливалась разработка и бизнес терял деньги). При этом он перестал завершаться успешно (со слов отдела DevSecOps). Т.е. по сути для проектов не было готового отчёта безопасности, создаваемого на основе работы security pipeline. Поэтому мы не могли согласовать такие проекты для размещения в продакшене. В итоге правило пришлось удалить, а базу ASOC - чистить. Ну, а создатель того правила - до сих пор эталон проактивности.
P.S. Оба действующих лица (руководитель AppSec и руководитель центра) - это те же лица, которых я указывал в статье А ты точно работал 2 месяца назад в этот день? А чем докажешь?
