Как модна сегодня тема ASOC. И правда, всем давно стало понятно, что процессы AppSec начинают работать только тогда, когда есть возможность выстроить как можно больше этих процессов и собрать как можно больше данных о потенциальных проблемах безопасности в одном единственном и по возможности удобном инструменте, который на сегодняшний день называется ASOC.
Предлагаем сперва затронуть тему самых базовых функций ASOC - нормализация и дедупликация результатов.
Что важно в ASOC c точки зрения дедупликации?
Дедупликация по как можно большему количеству настраиваемых критериев, да еще и между результатами от разных сканеров!
Наиболее прошаренные скажут - критерий "сканеры" можно не учитывать в результатах сканирования при дедупликации, но как быть с тем, что одна и та же уязвимость может называться по разному в разных сканерах? А если пытаться определить уязвимость по CWE, то они по-разному могут определяться разными сканерами…
Конечно у нас заготовлен ответ на подобный вопрос. Наш ASOC - CyberCodeReview даст вам возможность справиться с дедупликацией между разными сканерами!
Он поддерживает 2 механизма дедупликации - базовый и продвинутый.
Базовый механизм дедупликации
С базовым механизмом все достаточно понятно, хотя даже здесь есть о чем рассказать - вы можете самостоятельно выбрать скоуп определения дубликата: искать дубликаты в рамках одного репозитория, одной ветки, одного хоста, домена и так далее. Или не учитывать этот критерий вовсе.
Также можно выбрать более общий скоуп - искать дубликаты в рамках одного продукта, либо в рамках одной группы продуктов, либо вообще во всем ASOC без учета продукта и его группы! Итого - вы можете искать дубликат как для определенной ветки в репозитории, так и для всего ASOC без учета каких-либо сужающих скоупов.
Продвинутый механизм дедупликации
Продвинутый механизм дедупликации как раз призван решить проблему дедупликации между разными сканерами. Например, вы внедрили 2 сканера поиска уязвимостей - semgrep и gosec. Один для pattern-based анализа, другой для семантического. Могут ли они разными способами обнаружить одну и ту же уязвимость? Конечно, да. Допустим, это и произошло - и semgrp и gosec нашли одну и ту же потенциальную уязвимость.
Для того, чтобы решить проблему дедупликации между двумя сканерами, вам сперва необходимо определить какой из двух сканеров вам милее (файндинг какого сканера будет считаться оригиналом, а какого дублем и будет удален) и добавить правило дедупликации.
Оригиналом я буду принимать, например, файндинг Semgrep, поскольку его описание для потенциальной уязвимости лучше. В правиле дедупликации я выбираю один из критериев "Scanner", он будет для оригинального файндинга "Semgrep". Следующее условие, точно идентифицирующие мой файндинг - "title", значение которого будет названием этой уязвимости. Указываем его. Для дубликата я указываю "Scanner" - "gosec" и "title" соответствующий названию уязвимости у gosec. Последнее, что остается, указать критерии поиска дублей - в моем случае эти критерии будут - "Same Product", "Same File Path", "Same Line Number". Соответственно на этом создание правила дедупликации закончено, можно сохранять.
Если в следующий раз будет найдена одна и та же уязвимость, для которой мы только что создали правило дедупликации, двумя сканерами, оригиналом будет считаться уязвимость, найденная Semgrep. То, что нашел gosec, удалится.
А ваш ASOC такое умеет? Если нет, тогда приходите к нам!