Повторные сканирования и проверка исправлений
Как повторное сканирование определяет, что уязвимость исправлена, что оно вправе менять и как статусы выгружаются в ServiceNow.
Вы исправили уязвимость и хотите её закрыть. Здесь описано, что для этого сделать и как понимать результат.
Как подтвердить исправление
- 01Отправьте исправление в репозиторий
Сделайте коммит в ветку, которую будете сканировать: ScanSuite берёт код именно из неё.
- 02Отметьте исправленные уязвимости
На странице «Уязвимости» отметьте нужные строки и нажмите «Повторно просканировать выбранные: N». Откроется форма статического анализа в режиме «Проверка исправлений», где уже подставлены эти уязвимости и их продукт.
- 03Запустите сканирование
В режиме «Проверка исправлений» сканер читает только файлы с этими уязвимостями. Ход работы виден на странице сканирования, а каждое решение сразу попадает в журнал.
- 04Проверьте столбец «Статус»
Каждая отмеченная уязвимость получила новую оценку. Что означает каждый результат, показано в таблице ниже.

Как понимать результат
| Что вы видите | Что это значит | Что делать |
|---|---|---|
| Resolved с меткой «подтверждено» | Агент прочитал код и указал строки, в которых дефект исправлен. | Ничего. Наведите курсор на метку, чтобы увидеть доказательства, или найдите строку о закрытии в журнале сканирования. |
| После исправления всё ещё Open | Агент проверил код и по-прежнему видит дефект или не смог дать однозначный ответ. | Откройте уязвимость и прочитайте вердикт в заметках по обработке. Обычно там указана строка, которая всё ещё вызывает вопросы. |
| Open, красным, с меткой «открыто снова» | Уязвимость была закрыта, но это сканирование обнаружило её снова. | Это регресс: исправление откатили, или оно не закрывало этот путь. |
| Уязвимости нет в отчёте | Она уже была открыта и просто обнаружена повторно. В отчёт попадают только новые и повторно открытые уязвимости. | Ничего. Запись в списке не изменилась. |
| Risk Accepted или False Positive | Это решение команды. Сканирование не меняет такие статусы ни в какую сторону. | Ничего. Изменить их может только человек. |

Каждое подтверждение, пропуск и закрытие попадает и в Историю уязвимости со ссылкой на сканирование. На странице сканирования закрытые им уязвимости учтены в счётчике закрытые автоматически.
Если сканер перестал сообщать об уязвимости, она от этого не закрывается. Когда файл проанализирован, а уязвимость в нём больше не появляется, агент открывает текущий код и принимает решение. Он закрывает запись, только если может процитировать код, который её исправил, или если файла больше нет. Уязвимости, которые нашёл только межфайловый поиск, так проверяются, лишь если выбрать их для проверки исправлений.
Какое повторное сканирование выбрать
| Режим | Что переоценивает | Когда использовать |
|---|---|---|
| Проверка исправлений | Только отмеченные вами уязвимости. | Повседневная работа над исправлениями. Самый дешёвый режим, и он не закроет уязвимость, которую вы не отметили. |
| Полное сканирование | Все уязвимости репозитория. | Проверка перед релизом или после большого рефакторинга. Один запуск может закрыть сразу много уязвимостей. |
| Выбранная область, Инкрементальное сканирование, Отслеживание изменений | Всё, что входит в область сканирования. | Регулярные проверки. Здесь уязвимость отправляется на проверку только после двух сканирований подряд, которые её не нашли: узкая область даёт более слабое доказательство. |
Пока исправляете уязвимости, используйте режим Проверка исправлений. Он читает несколько файлов, а не весь репозиторий, и не трогает уязвимости, которые просто лежат в том же файле, что и отмеченные.
Проверка исправлений переоценивает и может закрыть только те уязвимости, которые ей передали; сколько их, указано в журнале. Другие уязвимости в тех же файлах она не закрывает. Кроме того, форма отключает поиск секретов, анализ зависимостей, анализ истории Git и межфайловый поиск: они выходят за пределы выбранных файлов. При необходимости их можно включить обратно.
Кнопка Запустить повторно в истории сканирований повторяет проверку исправлений с теми же уязвимостями.
Как сканирование меняет статусы
| Статус | Что может сделать повторное сканирование |
|---|---|
| Open, In Progress | Сканирование может закрыть уязвимость, но только при наличии доказательств. |
| Resolved | Уязвимость автоматически открывается снова, если дефект обнаружен повторно; устаревшие доказательства закрытия удаляются. |
| Risk Accepted, False Positive | Сканирование их никогда не меняет. |
Для каждого автоматического изменения сохраняется, как оно произошло, поэтому закрытие по доказательствам сканера всегда можно отличить от закрытия вручную.
Отключение автоматического закрытия
Автоматическое закрытие подтверждённых исправлений включено по умолчанию. Это настройка команды: на странице Команды, на вкладке ИИ, в карточке Как ИИ обрабатывает уязвимости установите для параметра Закрывать уязвимости, исправление которых подтверждено значение Выключено. Повторные сканирования по-прежнему будут переоценивать уязвимости и записывать вердикты в журнал, но закрывать уязвимости придётся вручную. Форма проверки исправлений и журнал сканирования заранее предупредят, что запуск ничего закрыть не сможет.
Эта настройка относится к уязвимостям AI SAST. Для сохранённых уязвимостей Semgrep есть отдельный параметр — «Закрывать уязвимости, которые повторное сканирование больше не находит» в карточке «Уязвимости сканеров на странице «Уязвимости»» на вкладке «Сканирование».
Журнал сканирования
Журнал не просто считает уязвимости, а называет каждую. Если вы не согласны с решением, его можно проследить до кода, на котором оно основано:
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 already resolved and still not
reported, 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) |
src/main/java/com/scalesec/vulnado/User.java:40-47 uses the parameterized query
"select * from users where username = ? limit 1" and binds un with setString(1, un).
Fix verification: 1 closed on source-backed evidence, 0 still present, 0 left open and
unverified.| Термин в журнале | Значение |
|---|---|
| confirmed | Сканирование снова обнаружило уязвимость. Она остаётся открытой. |
| covered but not reported | Файл проанализирован, уязвимость не обнаружена. Когда число таких пропусков достигает порога для режима, уязвимость уходит на проверку. |
| held by an analyst decision | Статус Risk Accepted или False Positive. Такие уязвимости не трогаются. |
| already resolved and still not reported | Уязвимость уже закрыта, и сканирование с этим согласно. Делать ничего не нужно. |
| outside this scan's coverage | Файл не анализировался, поэтому сканирование ничего о нём не утверждает. |
Передача статусов в ServiceNow
ScanSuite не подключается к ServiceNow: статусы передаются файлом.
- 01Выгрузка
Выберите продукт на странице «Уязвимости» и нажмите «Экспорт» → «XLSX для ServiceNow». В каждой строке в поле Vulnerability ID записан идентификатор уязвимости.
- 02Импорт в ServiceNow
Загрузите файл обычным способом. Со стороны ScanSuite здесь ничего особенного не требуется.
Один файл решает обе задачи: открытые уязвимости и уязвимости в работе передаются со статусом Open, а исправления, подтверждённые ScanSuite, — со статусом Fixed. Поэтому одна загрузка и заводит новые заявки, и закрывает исправленные. Уязвимости в статусах Risk Accepted и False Positive в файл не попадают: такие решения принимаются в процессах ServiceNow.

Идентификатор присваивается один раз и больше не пересчитывается. Поэтому в консоли, журнале сканирования, JSON-отчёте и заявке уязвимость обозначена одной и той же строкой.
Как это связано с другими разделами
Как уязвимости попадают в платформу и кто за них отвечает, описано в разделе Управление уязвимостями. О режимах сканирования читайте в разделах Запуск сканирования с ИИ и Периодические и инкрементальные сканирования.
Проверено: 2026-09-30