Как читать авторский курс и нормативные материалы

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

Что проверять на проекте: политики, исключения, принятие риска

Чек-лист аудитора. Цель — убедиться, что решения по сторонним компонентам управляемы: пороги формализованы, исключения имеют владельца и срок, gate и реестр синхронизированы.

Политика приёмки и пороги

[ ] Существует утверждённая политика приёмки сторонних компонентов (не на словах), с датой и владельцем процесса.
[ ] Пороги выражены измеримо и привязаны к машинному факту: CVSS-порог (с указанием версии метрики и условия «есть фикс»), deny/allow-list лицензий по SPDX-идентификаторам, правило instant-fail для malware.
[ ] Политика различает контексты применения: проприетарный дистрибутив vs внутренний инструмент, прод vs тестовый контур (порог по лицензиям и severity может отличаться).
[ ] Severity-порог дополнен механизмом эксплуатируемости (VEX), а не работает вслепую по одному CVSS.

Security gate

[ ] Gate реально включён в CI/CD и deterministично блокирует то, что описано в политике (а не «отчёт ради отчёта»).
[ ] Каждое подавление в конфиге gate (ignoreUntil/suppress/ignore-file) ссылается на ID карточки исключения — «голых» mute нет.
[ ] Дата подавления в gate совпадает с expiry соответствующей карточки в реестре.

Реестр исключений и принятие риска

[ ] Реестр исключений существует, ведётся централизованно и доступен аудитору.
[ ] У каждой записи есть: компонент с версией (PURL), привязанный finding, тип решения, обоснование, компенсирующая мера, автор (роль владельца риска), дата открытия и expiry.
[ ] Нет исключений без срока пересмотра; нет «активных» исключений с истёкшим expiry (либо закрыты, либо пересмотрены).
[ ] Для истёкших исключений finding фактически вернулся в блокирующий статус, а не остался «тихо принятым».
[ ] Принятие риска подписано тем, у кого есть полномочия (по роли), а не дежурным разработчиком; объём риска соразмерен уровню решающего.
[ ] Решения трассируемы до версии компонента, даты поставки и источника (можно соотнести с SBOM/VDR).

Красные флаги Десятки findings со статусом «ignored» прямо в сканере без ссылки на реестр; исключения без expiry или с давно истёкшим сроком; принятие риска без компенсирующей меры; gate, который ничего не блокирует, потому что «иначе встанет разработка»; одно и то же исключение, переоформляемое годами без попытки фикса.

Связи

Политика приемки сторонних компонентов · Реестр исключений · Порядок принятия риска · Требования к CI security gate · П30 · ISO IEC 27001 · NIST SP 800-218 SSDF.