Как читать авторский курс и нормативные материалы
Это учебные материалы, а не заключение о соответствии конкретного продукта. Организационные модели курса отделяйте от терминов стандарта: ППК в опубликованном проекте — машиночитаемый перечень, а живой реестр его версий является практикой сопровождения. Термин OSA в разных материалах имеет разный охват. Статус и обязательность нормативного документа проверяются отдельно; проект КАПО опубликован как проект первой редакции.
Билет 09
Теоретический вопрос
Объясните OSA (Open Source Analysis/Administration) как контроль источника компонента, а не только его состава. Что такое controlled repository и proxy-режим, чем они отличаются от «качать пакеты прямо из публичного реестра»? Раскройте роль подписи и provenance (Sigstore, SLSA, in-toto): почему подпись SBOM и доказуемое происхождение сборки закрывают классы угроз (подмена артефакта, скомпрометированный upstream), которые сам по себе SBOM не закрывает?
Практический вопрос
Мини-кейс В сборку проникла зависимость, которой нет в controlled repository: разработчик добавил её напрямую из публичного реестра в обход proxy. Опишите, как это обнаружить (политика controlled repository, аудит источников), как восстановить provenance компонента и какой контроль не дал бы этому произойти. Где здесь граница между фактом (что попало в сборку) и решением (допустить ли источник)?
Что должен показать ответ
- Источник факта: журнал controlled repository / proxy и provenance-метаданные (SLSA/in-toto) о происхождении артефакта.
- Инструмент: controlled repository + proxy-режимы; подпись SBOM через Sigstore; SLSA/in-toto attestation.
- Владелец решения: допуск источника и режим proxy — за владельцем OSA-процесса, не за разработчиком в обход политики.
- Нормативная опора: SLSA, in-toto, NIST SP 800-161 Rev.1, NIST SP 800-218 SSDF.
- Evidence: подписанный SBOM, attestation о сборке; требования к controlled repository.