SecurityFlow Кабинет лицензий , откроется в новой вкладке

Документация / Руководство пользователя / Уязвимости

Жизненный цикл уязвимости

Обновлено 20 октября 2026

Статус разбора показывает, на каком этапе уязвимость: ждёт разбора, подтверждена, передана исполнителю, закрыта. От статуса зависят SLA, WRT, задачи Jira и уведомления. Статус меняют люди, правила валидатора, автозакрытие сканера и интеграция с Jira.

Статусы

Код Статус Кнопка перевода Что значит Этап SLA В WRT по умолчанию
1 "Не обработано" "Вернуть" Новая или возвращённая уязвимость, ждёт разбора "Дней до верификации" нет
2 "В работе" "Верифицировать", из закрытых - "Открыть заново" Уязвимость подтверждена, ждёт исполнителя "Дней до назначения" да
3 "Назначено" - У задачи Jira есть исполнитель "Дней до решения" да
0 "Решено" "Решить" Уязвимость устранена не считается нет
4 "Отклонено" "Отклонить" Ложное срабатывание или неприменимо не считается нет
5 "Временно принят риск" "Временно принять риск" Риск принят до даты не считается нет
6 "Постоянно принят риск" "Постоянно принять риск" Риск принят без срока не считается нет

Статус 2 в списке называется "В работе", а в шагах карточки и сообщениях - "Верифицировано". Это один и тот же статус.

В карточке уязвимости статус показан шагами: "Создано", "Верифицировано", "Назначено", "Решено"; для принятого риска - "Принят риск до {дата}" или "Постоянно принят риск".

В API статус - поле current_sla_level (код). В адресах смены статуса используется код или имя: resolved, unverified, verified, rejected, risk_accepted_temporarily, risk_accepted_permanently.

Правила переходов

  • Core не ограничивает порядок: уязвимость можно перевести из любого статуса в любой другой, кроме "Назначено".
  • "Назначено" ставит интеграция с Jira, когда у задачи появляется исполнитель. Вручную этот статус не ставится.
  • При ручной смене статуса Core стирает отметки автоматики и даты прежних статусов и ставит дату нового: верификации, решения, отклонения или принятия риска. Дата создания и дата назначения исполнителя в Jira сохраняются.
  • Если верифицировать уязвимость, у задачи которой в Jira уже есть исполнитель, она сразу получает статус "Назначено".

Кто переводит

Из В Кто или что переводит
- (новая) "Не обработано" Обработчик импорта: новая уязвимость из отчёта. Человек при ручном создании выбирает статус в форме
любой "В работе" Человек ("Верифицировать", "Открыть заново"). Правило валидатора с действием "Верифицировать". Jira: задача перешла в статус, сопоставленный с "В работе"
"В работе" "Назначено" Интеграция с Jira: у задачи появился исполнитель. Чья задача учитывается - команды безопасности или продукта, - задаёт настройка "Использовать задачу команды ... для сопоставления статуса и приоритета"
любой "Решено" Человек ("Решить"). Автозакрытие сканера с действием "Решить": уязвимости нет в новом отчёте того же сканера, она получает тег auto-closed. Jira: статус задачи сопоставлен с "Решено"
любой "Отклонено" Человек ("Отклонить"). Правило валидатора "Отклонить". Jira: статус задачи сопоставлен с "Отклонено"
любой "Временно принят риск" Человек: число дней или дата. Правило валидатора "Временно принять риск". Jira: сопоставленный статус
любой "Постоянно принят риск" Человек. Правило валидатора "Постоянно принять риск". Jira: сопоставленный статус
любой "Не обработано" Человек ("Вернуть"). Jira: статус задачи сопоставлен с "Не обработано"
"Решено" "Не обработано" Обработчик импорта: та же уязвимость снова пришла в отчёте и включено "Переоткрывать решённые уязвимости" (по умолчанию включено). Уязвимость, решённая автозакрытием, возвращается, когда сканер снова её находит
любой удалена Человек (удаление). Автозакрытие сканера с действием "Удалить". Правило дедупликатора удаляет дубликат. Удаление ассета вместе с уязвимостями или удаление продукта

Предпросмотр правил валидатора отбирает только уязвимости в статусе "Не обработано" (Автовалидатор).

Уязвимость, которой статус выставила автоматика, отмечается: фильтры "Подтверждено автоматически", "Отклонено автоматически", "Решено автоматически", "Автоматически подтверждено правилом", "Автоматически решено настройками сканера". В карточке, в блоке "Затронуто", видно правило или сканер, например "{действие} с помощью {правило}" или "Решено: {сканер}". Ручная смена статуса снимает признаки автоматики (auto_verified, auto_rejected, auto_resolved и др.); записи в блоке "Затронуто" остаются.

Сопоставление статусов Jira и статусов уязвимостей настраивается на шаге "Сопоставление статусов задач" интеграции: каждому статусу задачи - один статус уязвимости, кроме "Назначено" (Jira).

Временно принятый риск

  • Срок задаётся при переводе: "Временно принять на {N} дней" или "Или выберите дату". N по умолчанию - "Дней по умолчанию для проверки временно принятых уязвимостей" в "Глобальные настройки" → "Обслуживание" → "Рабочий процесс", после установки 30.
  • В API срок - поле accept_duration_days в теле запроса смены статуса, не меньше 1.
  • Остаток дней виден в карточке ("Принять до") и в API (accept_duration_days_remaining).
  • Срок можно продлить. Сократить его меньше уже прошедших дней нельзя: ответ 400 Minimum value is N.

Следите за сроками

Отсортируйте список уязвимостей со статусом "Временно принят риск" по остатку дней (ordering=accept_duration_days_remaining) и возвращайте истекшие в работу кнопкой "Верифицировать" или массовым действием "Задать статус".

Что происходит при смене статуса

Новый статус Jira DefectDojo
"В работе" Создаются задачи, если включено "Создавать задачу в Jira автоматически при верификации уязвимости" (глобально или в продукте) и задач ещё нет verified
"Отклонено" Задачи удаляются, если включено "Удалять задачи для отклоненных уязвимостей" (по умолчанию включено) set-false-positive
"Решено" - mitigated
"Не обработано" - unset-false-positive
любой Задачи переводятся в статус Jira, у которого для нового статуса уязвимости включено "двустороннее обновление" -

События DefectDojo формируются только для уязвимостей из DefectDojo и при включённой интеграции. Синхронизация с DefectDojo - по запросу (DefectDojo).

При ручной смене статуса одной уязвимости или выборки до 24 уязвимостей Core отправляет событие уведомлений status_changed с отметкой "Вручную". В правиле уведомления можно отобрать переходы по статусам "Было" и "Стало" и способу "Как изменено" (Уведомления).

Массовая смена статуса для выборки больше 24 уязвимостей выполняется в фоне: интерфейс показывает "Запланировано ...".

Порядок автоматики: от импорта до Jira

Путь уязвимости:

отчёт → Core → обработчик импорта → "Не обработано" → валидатор → "В работе" → задача Jira → "Назначено" → "Решено"
  1. Приём отчёта. Core проверяет запрос, выбирает продукт, создаёт ассеты и аудит, ставит отчёт в очередь и отвечает 202 (Импорт отчётов).
  2. Разбор отчёта. Обработчик импорта в фоне:
    • разбирает отчёт логикой разбора сканера и переводит критичность сканера в уровни Core;
    • применяет базовую дедупликацию: уязвимость, совпавшая по отпечатку с уже известной в области дедупликации, второй раз не создаётся; решённый оригинал переоткрывается, если включено "Переоткрывать решённые уязвимости" (Дедупликация);
    • если на сканере включено автозакрытие, решает или удаляет уязвимости этого сканера, которых нет в новом отчёте (Настройки сканеров в Core);
    • создаёт новые уязвимости в статусе "Не обработано" и связывает их с аудитом.
  3. Уведомление об импорте. Уходит событие findings_imported ("Уведомление об импортированных уязвимостях").
  4. Валидация на импорте. Если включено "Валидировать уязвимости на импорте", правила валидатора применяются к уязвимостям этого импорта. По окончании - событие import_validator_finished ("Уведомление о завершении валидации") (Автовалидатор).
  5. Фоновые правила. Валидатор, дедупликатор и правила CVSS работают циклами: проход по базе, пауза "Частота запуска (в секундах)", снова проход. Каждый цикл работает, только если он включён (Дедупликация, Правила CVSS).
  6. Верификация и Jira. Уязвимость переходит в "В работе" - вручную или правилом. При включённом автосоздании Core создаёт задачи Jira. Связь задач с эпиками групп описана в Группы уязвимостей.
  7. Работа в Jira. Вебхук Jira сообщает Core об изменениях задачи. Появился исполнитель - уязвимость получает "Назначено". Статус задачи сменился - статус уязвимости меняется по сопоставлению.
  8. Закрытие. Уязвимость решена в Core или в Jira. Решение в Core переводит задачи в статус Jira с двусторонним обновлением. Если сканер больше не находит уязвимость, её закрывает автозакрытие, когда оно включено на сканере.

API

Метод и путь Назначение
POST /api/v1/findings/{id}/set-status/{status}/ Сменить статус одной уязвимости. Для статуса 5 тело {"accept_duration_days": 14}. Уязвимость уже в этом статусе - 409 Finding already has status N
POST /api/v1/findings/bulk/set-status/{status}/?<фильтр> Сменить статус выборке. Без фильтра - 400. Больше 24 уязвимостей - ответ 202, смена в фоне
GET /api/v1/findings/{id}/affected-by/ Какие правила, сканеры и аудиты затронули уязвимость
GET /api/v1/findings/counters/triage-status/?<фильтр> Число уязвимостей по статусам: {"0": 12, "1": 40, ...}

Пример: отклонить уязвимости продукта 7 в каталогах tests.

curl -sS -X POST \
  "https://core.example.ru/api/v1/findings/bulk/set-status/rejected/?product=7&file_path__icontains=/tests/" \
  -H "Authorization: Token <токен>"