Как читать авторский курс и нормативные материалы
Это учебные материалы, а не заключение о соответствии конкретного продукта. Организационные модели курса отделяйте от терминов стандарта: ППК в опубликованном проекте — машиночитаемый перечень, а живой реестр его версий является практикой сопровождения. Термин OSA в разных материалах имеет разный охват. Статус и обязательность нормативного документа проверяются отдельно; проект КАПО опубликован как проект первой редакции.
Чек-лист честного SBOM контейнерного образа
Назначение
Рабочая форма проверки, что SBOM контейнерного образа отражает реальное содержимое образа, а не только то, что удобно нашёл сканер. Цель — поймать слепые зоны: удалённые в верхних слоях файлы, бинарники без метаданных, секреты, мульти-стейдж-сборки и внешние загрузки в рантайме.
Когда применяется
- Приёмка готового образа от соисполнителя или из внешнего реестра.
- Подготовка релизного evidence для контейнеризированного продукта.
- Расследование подозрительно «чистого» отчёта (нулевой VDR при сложном образе).
Слои
- [ ] Образ распакован (
docker save), просмотренmanifest.jsonи история слоёв. - [ ] Сделан diff слоёв: найдены файлы, удалённые в верхних слоях, но оставшиеся в нижних.
- [ ] Проверены файлы, добавленные и затем «скрытые» (whiteout).
ОС
- [ ] Определён базовый дистрибутив:
/etc/os-release,/usr/lib/os-release,/etc/alpine-release,/etc/issue. - [ ] Зафиксирована версия базового образа в SBOM.
Пакеты
- [ ] Считаны базы пакетных менеджеров:
dpkg/apk/rpm. - [ ] Проверены кэш пакетного менеджера и логи установки (следы доустановки).
Языковые зависимости
- [ ] Найдены lockfiles и manifests для JS / Python / Ruby / Java / PHP / Rust / Go.
- [ ] Сопоставлены объявленные зависимости с реально присутствующими файлами.
Бинарные metadata
- [ ] Извлечён Go build info из бинарей.
- [ ] Проверены Rust bin-метаданные, ELF imports, встроенные версии.
- [ ] Помечены packed/stripped бинарники как зоны пониженного доверия.
Обфускация и слепые зоны
- [ ] Отмечены компоненты без package metadata.
- [ ] Проверены следы multi-stage build (артефакты без манифеста сборки).
- [ ] Найдены внешние загрузки в рантайме (
curl/wgetв entrypoint, скачивание зависимостей при старте).
Секреты
- [ ] Просканированы все слои, архивы, конфиги и история сборки на секреты и ключи.
- [ ] Проверено, что удалённый в верхнем слое секрет не остался в нижнем.
Provenance
- [ ] Есть attestation: cosign / Witness / in-toto / SLSA.
- [ ] Зафиксированы build command и хэши material/product.
- [ ] Подпись/attestation проверены, а не только присутствуют.
Правило принятия SBOM образа приемлем только при явном списке источников фактов и ограничений (что сканер не покрыл). Нулевой отчёт по уязвимостям без проверки coverage, metadata и слоёв — это не evidence, а отсутствие проверки.
Удалённое ≠ отсутствующее Файл, удалённый командой в Dockerfile, физически остаётся в нижнем слое и доступен. Сканер по финальной ФС его не покажет, но он есть в образе — поэтому обязателен diff слоёв.
Связь с курсом
- Модуль: М16. SBOM for AI и честный SBOM контейнерных образов
- Практики: П37. Контейнерный образ слои секреты и удаленные файлы · П38. Честный SBOM контейнерного образа · П05. Trivy как генератор и сканер
- Нормативка/инструменты: CISA Minimum Elements for SBOM · SLSA · in-toto · Docker BuildKit
- Связанные шаблоны: Чек-лист SBOM for AI · Соглашение о качестве данных SBOM · Чек-лист качества CycloneDX