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

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

Что проверять на проекте

Чек-лист аудитора по терминологии и границам. Здесь проверяется не зрелость инструментов (это в поздних модулях), а то, что команда понимает и различает базовые сущности и не выдаёт одно за другое.

Как пользоваться Каждый пункт — «да / нет / частично» с одним конкретным доказательством. «Да на словах» без артефакта засчитывается как «нет».

  1. Единый словарь. Существует ли согласованное определение SCA, OSA, SBOM, ППК, VEX, VDR, доступное команде? Все ли называют SBOM входом SCA, а не его результатом?

  2. SBOM ≠ безопасность. Не путают ли «есть SBOM» с «SCA внедрён»? Есть ли поверх SBOM сопоставление с уязвимостями и лицензиями, или перечень существует сам по себе?

  3. Различение VDR и VEX. Хранится ли список найденных уязвимостей (VDR) отдельно от решений о применимости (VEX)? Не называют ли голый список CVE «VEX-ом»?

  4. Обоснованность VEX. Сопровождается ли каждый not_affected полем justification? Нет ли массового «не затрагивает» без обоснования (маскировка риска вместо управления им).

  5. Граница SCA/OSA закрыта с двух сторон. Проверяется ли не только состав и версии (SCA), но и происхождение/целостность компонента (OSA): откуда пришёл пакет, подписан ли, разрешён ли политикой.

  6. Контролируемый источник. Есть ли контролируемый репозиторий/прокси, или зависимости тянутся напрямую с произвольных внешних зеркал (открытая угроза подмены при поставке, ГОСТ Р 58412-2019 п. 5.5.1)?

  7. Транзитивные зависимости в зоне внимания. Анализируется ли состав глубже прямых зависимостей? Понимает ли команда, что угроза 5.3.2 чаще приходит через зависимость зависимости?

  8. Не-CVE угрозы учтены. Есть ли понимание, что protestware/закладки не имеют CVE и не ловятся списком версий? Описан ли механизм, который их адресует (контроль источника, а не очередной SCA-скан)?

  9. Привязка к модели угроз. Может ли команда сказать, какие угрозы из ГОСТ Р 58412-2019 закрывает её процесс (5.3.2, 5.3.3, 5.5.1), а какие остаются открытыми?

  10. Security-by-design, а не «потом». Встроен ли учёт состава в жизненный цикл (выбор и приёмка компонентов), или SCA воспринимается как разовая проверка перед релизом?

  11. Заимствованные компоненты идентифицируемы. Есть ли ППК/паспорт по сторонним библиотекам с устойчивым ключом (имя, версия, экосистема, purl)? Без этого ни одна угроза состава не трассируется.

  12. Решения имеют автора и дату. У любого VEX-решения и принятия риска есть автор, дата и обоснование? Иначе это не управленческое решение, а аноним.

Нормативная и шаблонная опора