Пиков / КАПО
Библиотека
Как читать авторский курс и нормативные материалы

Это учебные материалы, а не заключение о соответствии конкретного продукта. Организационные модели курса отделяйте от терминов стандарта: ППК в опубликованном проекте — машиночитаемый перечень, а живой реестр его версий является практикой сопровождения. Термин OSA в разных материалах имеет разный охват. Статус и обязательность нормативного документа проверяются отдельно; проект КАПО опубликован как проект первой редакции.

Регламент ретеста после исправления

Назначение

Регламент описывает, как подтвердить, что уязвимость действительно закрыта после обновления/патча/замены компонента, и что исправление не внесло новых компонентов или новых уязвимостей. Цель — закрывать findings только по evidence, а не «по факту коммита».

Когда применяется

Шаги

  1. Зафиксировать исходное. Записать CVE/БДУ, старую версию компонента (PURL) и старый VDR как базу сравнения.
  2. Пересобрать и перегенерировать SBOM. Получить SBOM из исправленной сборки тем же генератором фактов, что и исходный.
  3. Сверить версию. Убедиться, что уязвимый компонент действительно обновлён/удалён (diff PURL: было/стало).
  4. Перепрогнать анализ. Прогнать сервис аудита/вердиктов поверх нового SBOM; выгрузить новый VDR.
  5. Проверить целевую CVE/БДУ. Подтвердить, что конкретная уязвимость отсутствует или переведена в not_affected/fixed с обоснованием.
  6. Проверить отсутствие регрессии. Сравнить новый VDR со старым: нет ли новых findings и новых неучтённых компонентов (транзитивные зависимости).
  7. Проверить сборку (для C/C++). Сохранить build evidence: обновление версии должно быть видно в build inventory, а не только в манифесте.
  8. Оформить протокол. Заполнить карточку ретеста; приложить старый и новый VDR.
  9. Закрыть статус. Только при «целевая закрыта + регрессий нет» перевести finding в fixed.

Обновление, которое не доехало до бинаря Версия в манифесте изменилась, но в собранном артефакте остался старый компонент (кэш, vendored-копия, статическая линковка). Поэтому шаги 3 и 7 проверяют именно собранную поставку, а не декларацию.

Регрессия зависимостей Обновление одного компонента часто тянет новые транзитивные зависимости со своими уязвимостями. Ретест без сравнения полного VDR может закрыть одну CVE и внести три новых.

Карточка протокола ретеста

Поле Значение
Целевая уязвимость (CVE/БДУ)
Компонент: было → стало (PURL)
Тип исправления обновление / патч / замена / митигация
VDR до / после ссылки
Целевая закрыта? да / нет (VEX-статус)
Новые findings? нет / перечень
Build evidence (C/C++) ссылка / н/п
Результат закрыто / возврат в triage
Исполнитель (роль) / дата

Связь с курсом