Комментарии 3
Добрый день! Спасибо за данные статьи, очень полезный и интересный материал.
Похожим образом выстроил процесс у себя, но с DD, как инструмент аггрегации всех уязвимостей для appsec команды, разработчики доступа туда не имеют чтобы их не нагружать и не пугать. Вкратце перед каждым сканом есть job в pipeline которая сначала создает структуру в DD, далее запускаются все сканы и после сканирований все отчеты загружается в DD, после чего из него отдельная job через API DD вытягивает все уязвимости в gitlab output в похожем формате как у Вас для анализа разработчикам.
Но хотелось бы подробнее узнать, как Вы выстроили процесс исключений для различных сканнеров SAST/SCA и др, а именно как выглядит структура файла конфигурации исключений (так как у всех инструментов он выглядит по разному и для Нас пока тяжело выработать унифицированный формат исключений) и как потом исключения добавляются в сами инструменты, создается отдельный скрипт который потом парсит этот файл и добавляет уже в параметры сканнеров или как-то иначе?
Заранее спасибо!
Добрый день. Постараюсь ответить коротко и емко)
У нас исключения работают поверх результатов сканеров. Сканер выдает результаты, скрипт вычитывает результаты и применяет исключения скачанные из S3 (yaml).
Исключения у нас применяются по идентификаторам уязвимостей, по файлам, по строкам в файла, CVE/CWE.
Сами исключения у нас есть общие, применяемые для всех проектов, и индивидуальные для проектов.
В какой-то момент, мы проанализировали все исключения и вычленили правила которые можно применить для сканеров (не сканировать директории с тестами, файлы .md, файлы openapi.yml). Положили это в конфиги самих сканеров, тем самым увеличили скорость сканирования.
Структура файла простая:
исключение для sast:
*исключение файндинга по id*
*исключение файлы в репозитории*
*исключение директории*
исключение для sca:
*исключение библиотеки*
*исключение CVE*
исключение для поиска секретов:
*исключение найденного секрета*
ну и в конце могут быть настройки для Quality Gate
Если есть вопросы, не стесняйтесь спрашивать)
Developer-центричный подход в обеспечении безопасности приложений