Как читать авторский курс и нормативные материалы
Это учебные материалы, а не заключение о соответствии конкретного продукта. Организационные модели курса отделяйте от терминов стандарта: ППК в опубликованном проекте — машиночитаемый перечень, а живой реестр его версий является практикой сопровождения. Термин OSA в разных материалах имеет разный охват. Статус и обязательность нормативного документа проверяются отдельно; проект КАПО опубликован как проект первой редакции.
NIST SP 800-218 SSDF
О документе
Secure Software Development Framework (SSDF) v1.1 — фреймворк безопасной разработки от NIST (США), выпущен в феврале 2022 года. Не привязан к языку или методологии; описывает практики как пары «что делать / как доказать» в четырёх группах: PO (Prepare the Organization), PS (Protect the Software), PW (Produce Well-Secured Software), RV (Respond to Vulnerabilities). Для федеральных поставщиков SSDF стал основой самоаттестации (CISA Secure Software Development Attestation) во исполнение EO 14028. Для курса SCA/OSA ключевы практики, связывающие сторонние компоненты, SBOM и реакцию на уязвимости.
Ключевые требования
- PW.4 — повторное использование готового ПО: использовать только проверенные сторонние компоненты, вести их инвентаризацию (фактически — SBOM) и отслеживать на протяжении жизни продукта.
- PS.3.1 / PS.3.2 — архивирование и происхождение релиза: сохранять каждый релиз и предоставлять данные о его составе (provenance, SBOM) потребителям.
- RV.1 — выявление уязвимостей: непрерывно собирать сведения об уязвимостях компонентов из внешних источников.
- RV.2 — оценка, приоритизация и устранение: триаж найденных уязвимостей с приоритетом и сроками, фиксация решений (включая «не затрагивает» через VEX).
- RV.3 — анализ первопричин и предотвращение повторения класса дефектов.
Что считать evidence
- SBOM/ППК на каждый релиз с историей версий (PW.4, PS.3.2) — доказательство инвентаризации и provenance.
- Результаты SCA-сканирования (Grype/Trivy/OSV-Scanner поверх SBOM) и поток уязвимостей из внешних источников (RV.1).
- VDR (документ результатов анализа уязвимостей) и VEX (статусы affected/not_affected/fixed) с обоснованием — evidence триажа по RV.2.
- CI security gate с порогами и журналом срабатываний — доказательство, что устранение встроено в пайплайн.
- Реестр исключений и принятых рисков со сроком пересмотра; запись об анализе первопричин по RV.3.
Маппинг на практики и шаблоны
- П03. Генерация SBOM через Syft, П08. Dependency-Track как портфель SBOM — инвентаризация компонентов (PW.4).
- П06. Grype поверх готового SBOM, П07. OSV-Scanner и lockfiles — выявление уязвимостей (RV.1).
- П09. VDR и VEX различие факта и решения, П35. VEX triage — оценка и решения (RV.2).
- П16. GitLab CI security gate, Требования к CI security gate — встраивание контроля в сборку.
- Политика управления уязвимостями компонентов, Регламент композиционного анализа ПО — операционализация RV/PW.
- Модули: Модуль М08 (цепочка поставки и OSA), Модуль М13 (трассировка и evidence).
- Смежно: NIST SP 800-161 Rev.1, ГОСТ Р 56939-2024 (аналог практик РБПО).
Ограничение
Это учебная карточка, а не официальный текст. Точные идентификаторы практик (PO/PS/PW/RV), формулировки задач и примеров сверяйте с оригиналом NIST SP 800-218 v1.1 и с регламентами Организации.