Что проверять на проекте: VDR/VEX

Чек-лист аудитора по управлению уязвимостями поверх SBOM. Проверяется не «есть ли сканер», а замкнут ли цикл «факт → решение → действие → ретест». Подробный порядок выпуска решения: VEX в процессе РБПО.

VDR — получение фактов

• [ ] Сканирование от SBOM, а не вслепую. VDR строится поверх SBOM релиза (Grype/Dependency-Track) или поверх lockfile (OSV-Scanner) — есть воспроизводимая команда и зафиксирована версия сканера и дата баз.
• [ ] Несколько источников. Находки сверяются минимум по двум базам (NVD/OSV/GHSA) и обязательно с БДУ ФСТЭК для проектов под регулятора; расхождения не теряются.
• [ ] Свежесть баз. Есть процедура обновления уязвимостных БД сканера; для офлайн-контура — порядок доставки обновлений (Порядок обновления БДУ).
• [ ] Покрытие. VDR строится по прямым и транзитивным зависимостям; «0 находок» расследуется как возможный дефект координат (PURL/CPE), а не как «чисто».

VEX — решения

• [ ] VDR и VEX разделены. Факт (что нашли) и решение (применимо ли) — разные сущности в артефактах, а не «отметка прочитано» в сканере.
• [ ] Issuer определён. VEX выпущен от имени ответственной за продукт стороны (Product Security / PSIRT / AppSec / РБПО + владелец продукта), а не от имени NVD/БДУ/OSV или сканера.
• [ ] Состояния используются по назначению. Каждая обработанная находка имеет одно из: not_affected / affected / fixed / under_investigation.
• [ ] Обоснования из разрешённого списка. Все not_affected несут justification (например, code_not_reachable, vulnerable_code_not_present); пустых и свободных формулировок нет.
• [ ] Evidence привязан к продукту. Для not_affected есть доказательства применимости именно к версии продукта: SBOM/ППК, build log, reachability/call graph, конфигурация, тест или triage issue. Upstream VEX/advisory используется как evidence, но не заменяет решение производителя продукта.
• [ ] Действие для affected. Для affected указан response (update, rollback, workaround_available) и привязка к задаче/релизу.
• [ ] fixed замыкает цикл. Исправленные находки помечены fixed, на следующем скане не «загораются» заново.

Управляемость

• [ ] Владелец. У каждой находки/группы есть владелец (роль, не сканер и не «команда вообще»).
• [ ] SLA по severity. Заданы сроки реакции по уровням (например, Critical / High / Medium) и они соблюдаются; есть отчёт по просрочкам (Политика управления уязвимостями компонентов).
• [ ] Ретест и срок жизни решения. under_investigation и affected пересматриваются регулярно; not_affected имеет триггер пересмотра (новая версия компонента, новый релиз) (Регламент ретеста после исправления).
• [ ] Исключения и принятие риска. Долгоживущие affected/not_affected без фикса оформлены как осознанный риск с датой пересмотра (Порядок принятия риска).
• [ ] Трассируемость и обмен. VDR/VEX выгружаются в стандартном формате (CycloneDX/OpenVEX), привязаны к версии продукта и могут быть переданы заказчику/получены от соисполнителя (Порядок загрузки VDR из Dependency-Track).

Стоп-сигналы аудита Массовый not_affected без обоснований; VEX «выпущен» базой уязвимостей или сканером; upstream advisory автоматически перенесён на ваш продукт без анализа сборки; единственный источник (только NVD, без БДУ); находки без владельца и SLA; not_affected, оформленный для давно сменившейся версии продукта; «0 находок» при богатом составе зависимостей. Любой из них означает имитацию триажа, а не управление уязвимостями.