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

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

Syft

Для чего

Syft строит SBOM по содержимому артефакта: распаковывает контейнерный образ по слоям, читает каталоги пакетных менеджеров и lock-файлы и составляет список компонентов с версиями, лицензиями и PURL. Это движок инвентаризации, который сам не ищет уязвимости — он отдаёт «список фактов», на который потом натравливают сканер (Grype, depscan).

Как применяют

Сканирование образа из реестра и каталога исходников с выводом в CycloneDX JSON:

syft registry.example.org/app:1.4.2 -o cyclonedx-json=sbom.cdx.json
syft dir:./src -o spdx-json=sbom.spdx.json

Каждый найденный пакет получает координату вида pkg:deb/debian/openssl@3.0.11-1~deb12u2?arch=amd64 или pkg:npm/lodash@4.17.21. Поддерживается scope --scope all-layers, чтобы увидеть пакеты, удалённые в верхних слоях образа.

Генератор, а не сканер Syft отвечает на вопрос «из чего собран артефакт», но не «что в нём уязвимо». Уязвимости ищет парный сканер (Grype) поверх того же SBOM. Не путайте пустой список уязвимостей с их отсутствием — на этом этапе их и не должно быть.

Сильные стороны

Широкое покрытие экосистем (deb, rpm, apk, npm, PyPI, Go modules, Java, Ruby, Rust) и каталогизаторы под каждый менеджер.
Один движок одинаково работает по образу, файловой системе и архиву; стабильные PURL на выходе.
Нативный экспорт в CycloneDX и SPDX без промежуточной конвертации.
Эталонный источник данных для парного сканера Grype — те же координаты, та же база каталогизаторов.

Ограничения

Слепая зона Syft видит только то, что заявлено пакетным менеджером. Статически слинкованные C/C++-зависимости и вендоренный (скопированный в дерево) код в инвентаризацию не попадают — для них нужен анализ бинаря (blint, ldd/readelf).

Видит только то, что заявлено пакетным менеджером: статически слинкованные C/C++-зависимости и вендоренный код в инвентаризацию не попадают.
Лицензия берётся из метаданных пакета; для точной юридической экспертизы её недостаточно, нужен сканер исходников.
CPE генерирует эвристически — для сопоставления с NVD по CPE возможны промахи, PURL надёжнее.

Offline / on-premise

Полностью офлайн: для построения SBOM сеть не нужна, бинарь самодостаточен. Образы можно подавать из локального tar (docker:archive / oci:archive) или из внутреннего реестра закрытого контура. Каталоги уязвимостей здесь не загружаются — обогащение происходит на стадии сканера.

Связанные темы

М05 Инструменты генерации SBOM · М16 Честный SBOM контейнеров · П03. Генерация SBOM через Syft · П06. Grype поверх готового SBOM · П38. Честный SBOM контейнерного образа · Grype · CycloneDX · Package URL