Как читать авторский курс и нормативные материалы
Это учебные материалы, а не заключение о соответствии конкретного продукта. Организационные модели курса отделяйте от терминов стандарта: ППК в опубликованном проекте — машиночитаемый перечень, а живой реестр его версий является практикой сопровождения. Термин OSA в разных материалах имеет разный охват. Статус и обязательность нормативного документа проверяются отдельно; проект КАПО опубликован как проект первой редакции.
Практическая работа: от сырого артефакта соисполнителя до readiness
Цель
Своими руками провести один компонент через оба контура Организации и доказать, что граница факты ↔ решения соблюдена: генератор фактов только обогатил состав, сервис вердиктов только вынес решения и собрал readiness, а не дописал компоненты.
Вход
raw-bom.json— сырой CycloneDX от cdxgen для C/C++-компонента соисполнителя.- Каталог ELF-бинарников этого компонента (например,
./build/bin). - Доступ к развёрнутому сервису аудита/вердиктов и к Dependency-Track с подтянутым фидом БДУ/OSV.
Порядок выполнения
Шаг 1. Снимок «до»
Зафиксируйте baseline сырого SBOM: сколько компонентов, у скольких есть purl, у скольких нормализованная лицензия.
jq '[.components[] | select(.purl)] | length' raw-bom.json
jq '.components | length' raw-bom.json
Запишите два числа — это точка отсчёта качества фактов.
Шаг 2. Обогащение (контур фактов)
Запустите генератор фактов (enrichment-утилита) в Astra/Debian-окружении его единственной командой:
enrich-sbom raw-bom.json enriched-bom.json --component-path ./build/bin
Снимите снимок «после» теми же jq-запросами по enriched-bom.json. Покажите дельту: насколько выросло покрытие purl, появились ли DEB-компоненты и evidence binary-analysis.
Шаг 3. Таблица обогащения
Сведите 3–5 компонентов, у которых обогащение что-то изменило:
| Компонент | До (purl/лиц.) | После (purl/лиц.) | Источник обогащения |
|---|---|---|---|
| libssl3 | нет / строка | pkg:deb/... |
ELF → apt (DEB) |
| ... | ... | ... | PyPI / npm / Conan |
Шаг 4. Аудит и VDR (контур решений)
Загрузите enriched-bom.json в сервис аудита/вердиктов. Выпустите один лицензионный вердикт, импортируйте состав в Dependency-Track, прочитайте VDR. Соберите readiness-сводку релиза.
Шаг 5. Проверка границы
Сравните число компонентов в enriched-bom.json и в составе, который видит сервис вердиктов. Они обязаны совпадать: сервис решений не добавляет и не удаляет компоненты. Любое расхождение — дефект процесса, опишите его.
Шаг 6. Вывод
Оформите краткое решение о готовности: компонент готов / неполон / заблокирован, с обоснованием и сроком пересмотра.
Ожидаемый результат
- Снимки «до/после» с числовой дельтой покрытия
purl. - Заполненная таблица обогащения (Шаг 3).
- Один лицензионный вердикт и прочитанный VDR из Dependency-Track.
- Readiness-сводка с явным статусом и обоснованием.
Типичные ошибки - Запуск обогащения не в Astra/Debian → пустой DEB-маппинг, состав молча занижен. - «Зелёный» readiness при не подтянутом фиде VDR — это отсутствие данных, а не готовность. - Попытка отфильтровать лицензии на стадии обогащения — нарушение границы факты/решения.
Критерий зачёта
Показать преподавателю: (1) числовую дельту обогащения, (2) совпадение состава между двумя контурами, (3) хотя бы один вердикт + VDR, (4) readiness-вывод. Объяснить вслух, где на вашей схеме факт превращается в решение.
Нормативная связка
SSDF PS.3.2/RV.1 · ГОСТ Р 56939-2024 · CycloneDX ECMA-424 · Шаблон управленческой сводки готовности
Практики
П28. Поставка от нескольких исполнителей · П29. Readiness dashboard