Повторные сканирования и проверка исправлений

Разработчик исправляет три уязвимости и просит выполнить повторное сканирование. Дальше следуют два вопроса, и это разные вопросы: исчезли ли старые уязвимости? и не появилось ли что-то новое из-за исправления? На этой странице описано, как ScanSuite отвечает на оба и как статус уязвимости меняется без ручного вмешательства.

Отсутствие — это не исправление

Очевидное решение — закрывать всё, о чём повторное сканирование не сообщило, — неверно, и стоит понять почему, прежде чем доверять всему остальному. Обнаружение — это вызов модели. Сканирование, которое проанализировало файл и ничего не сообщило, может означать, что дефекта больше нет, а может — что модель на этот раз его пропустила. Закрыть реальную уязвимость только потому, что сканирование промолчало, — худшее, что эта система может сделать.

Поэтому молчание трактуется как вопрос, а не как ответ. Когда сканирование охватило файл, но больше не сообщает о уязвимости в нём, отдельный агент проверки открывает текущий исходный код и принимает решение. Уязвимость считается устранённой только тогда, когда этот агент может указать на код, который её исправил.

Два способа выполнить повторное сканирование

Оба запускаются с формы SAST-сканирования; Verify Fixes доступен также прямо из списка уязвимостей: разработчик отмечает исправленные строки и нажимает запуск, не выбирая режим и не вводя шаблон файлов.

zoom_inУвеличить

Что решает повторное сканирование

После завершения сканирования каждая сохранённая уязвимость по этому репозиторию попадает ровно в одну из четырёх категорий. Их количества указываются в журнале сканирования:

Уязвимость уходит на проверку не после первого же «молчаливого» сканирования во всех режимах. Порог зависит от того, насколько весомы доказательства:

Проверка

Уязвимости, достигшие порога, по одной передаются агенту проверки исправлений. Он читает текущий исходный код в месте уязвимости и возвращает один из пяти вердиктов:

Доказательства сохраняются в записи и отображаются в её заметках о жизненном цикле — закрытие можно проверить позже:

Finding test-java-sast-c4d1f672fc16 closed as fixed: fixed (high confidence) |
src/main/java/com/scalesec/vulnado/User.java:39-49 shows fetch(String un) using a
PreparedStatement with the query "select * from users where username = ? limit 1",
followed by stmt.setString(1, un) and stmt.executeQuery().

Статусы и кто вправе их менять

Risk Accepted и False Positive — это решения относительно дефекта, в существовании которого все согласны, а это другой вопрос, чем то, содержится ли он ещё в коде. У сканера есть мнение о коде; у него нет мнения о том, что решила ваша организация. Поэтому менять эти статусы он не вправе — ни в одну сторону.

Каждое автоматическое изменение фиксирует, как оно произошло. Уязвимость, закрытая проверкой, несёт closure_source = scanner и свои доказательства; закрытая человеком — свои. Всегда можно понять, что есть что.

zoom_inУвеличить

Как включить автоматическое закрытие

Закрытие по инициативе сканера по умолчанию выключено. Включите его в Settings → Resolve findings verified as fixed. При выключенной настройке всё описанное выше всё равно выполняется и записывается в журнал — пропуски подсчитываются и отражаются в отчёте, — но статусы не меняются. Это осмысленный режим сам по себе: можно посмотреть, какие вердикты действительно выдаёт ваша кодовая база, прежде чем разрешать им закрывать задачи.

Как читать журнал сканирования

Повторное сканирование само описывает свои решения, называя уязвимости, а не просто считая их:

Reassessing only the 1 finding(s) this scan was asked to verify, of 1 selected.
Finding reconciliation: 0 confirmed, 1 covered but not reported (1 at or over the
1-miss threshold), 0 held by an analyst decision, 0 outside this scan’s coverage.
Verifying 1 finding(s) that this scan covered but did not report: test-java-sast-c4d1f672fc16
Finding test-java-sast-c4d1f672fc16 closed as fixed: fixed (high confidence) | ...
Fix verification: 1 closed on source-backed evidence, 0 still present, 0 left open.

Дедупликация описывается так же. Когда повторное сканирование снова обнаруживает то, что уже сохранено, журнал сообщает, к какой записи это было сведено и на каком основании, — так вы можете проверить корректность объединения, а не доверять счётчику.

Передача статусов в ServiceNow и обратно

ScanSuite не подключается к ServiceNow. Обмен идёт файлами в обе стороны — именно это и делает такую схему применимой там, где исходящую интеграцию никогда бы не согласовали.

1. 01
   Выгрузка

   На странице Vulnerabilities выберите Export → ServiceNow XLSX. Каждая строка содержит устойчивый идентификатор отслеживания уязвимости: у ServiceNow есть ключ, за который можно держаться.

2. 02
   Загрузка

   Импортируйте таблицу в ServiceNow своим обычным способом. В этом шаге нет ничего специфичного для ScanSuite.

3. 03
   Работа с заявками

   Ваш процесс в ServiceNow назначает и закрывает их так же, как всегда.

4. 04
   Возврат статусов

   Статусы, проставленные в ServiceNow, возвращаются в ScanSuite файлом и сопоставляются с уязвимостями по тому же идентификатору отслеживания. Там, где они расходятся с тем, что считает ScanSuite, расхождение показывается, а не перезаписывается молча.

zoom_inУвеличить

Весь этот обмен держится на идентификаторе отслеживания. Он выводится из идентичности записи — класса уязвимости, файла и репозитория, которому она принадлежит, — присваивается один раз и никогда не пересчитывается, так что идентификатор остаётся прежним при повторных сканированиях и между релизами. Два репозитория со случайно совпавшим путём к файлу никогда не перепутаются.

Как это связано с остальным

Повторное сканирование — вторая половина цикла, описанного в разделе Управление уязвимостями: там уязвимости загружаются, сопоставляются, проверяются и получают ответственных, а здесь — закрываются. О самих режимах сканирования см. Запуск сканирования с AI и Периодические и инкрементальные сканирования.