Безопасность цепочки поставки¶
Требования применяются к dependencies, container images и release-артефактам.
Уровни обязательности определены в корневом README.md.
DEP-SUP-001. Сканирование уязвимостей¶
Уровень: SHOULD
Применяется к: release pipeline и фактическому release-артефакту
Проекту следует сканировать фактический release-артефакт, если его формат поддерживается. Для неподдерживаемого формата следует проверять зафиксированное дерево зависимостей и доступное содержимое артефакта. Конфигурацию severity, ignored findings и условий отказа следует хранить в Git. Finding выше принятого проектом порога следует блокировать release.
Обоснование¶
Сканирование поставляемого состава обнаруживает уязвимости, которых может не быть в dependency manifest исходного дерева.
Проверка¶
- проверка jobs и reports для применимого artifact format;
- контролируемый vulnerable fixture;
- проверка блокировки release.
Исключения¶
Проект MAY не выполнять vulnerability scan без ADR. Для включённого scan ignore требует владельца, причины, срока и компенсирующих мер.
DEP-SUP-002. Актуальность базы уязвимостей¶
Уровень: MUST
Применяется к: каждому blocking scan
Сканер и vulnerability database должны иметь зафиксированную политику обновления. Невозможность получить базу допустимой давности должна завершать blocking scan ошибкой. Кэш не должен бессрочно скрывать обновления.
Обоснование¶
Устаревшая база создаёт ложный успешный результат.
Проверка¶
- проверка версии сканера и времени базы;
- тест недоступного registry базы;
- очистка кэша и повторный scan.
Исключения¶
Допустимая давность численно определяется security-политикой проекта.
DEP-SUP-003. SBOM release-артефакта¶
Уровень: SHOULD
Применяется к: каждому release-артефакту с зависимостями
Pipeline следует создавать Software Bill of Materials (SBOM) в CycloneDX или
SPDX для фактического release-артефакта. SBOM следует содержать неизменяемый
идентификатор артефакта по DEV-BUILD-003, включая digest при его
использовании, храниться как release artifact и сопоставляться с commit и
pipeline.
Обоснование¶
SBOM позволяет определить затронутые releases после обнаружения уязвимости.
Проверка¶
- schema validation SBOM;
- сопоставление artifact identifier, commit и pipeline;
- выборочная сверка пакетов с артефактом.
Исключения¶
Проект MAY не создавать SBOM без ADR. Артефакт без сторонних или системных зависимостей MAY не иметь SBOM, если это отсутствие подтверждается автоматической проверкой его состава.
DEP-SUP-004. Неизменяемая идентификация артефакта¶
Уровень: SHOULD
Применяется к: публикации и развёртыванию release image
Release image следует публиковать и развёртывать по digest. Если digest не
используется в deployment-конфигурации, следует применять уникальный
непереиспользуемый release tag или другой registry identifier, однозначно
связанный с содержимым по DEV-BUILD-003. Между обязательными проверками и
production следует продвигать тот же идентифицированный артефакт без
пересборки.
Обоснование¶
Digest связывает проверенный байтовый состав с развёрнутым артефактом.
Проверка¶
- сравнение release identifier и фактического image между registry и deployment;
- тест promotion между средами;
- проверка отсутствия build job при promotion.
Исключения¶
Проект MAY использовать непереиспользуемый release tag без digest; mutable tag не является достаточной заменой идентификатора версии.
DEP-SUP-005. Provenance сборки¶
Уровень: MUST
Применяется к: release image и доступным материалам сборки
Должны сохраняться commit SHA, pipeline ID, идентификаторы build images,
dependency lock-файлы и неизменяемый идентификатор результата по
DEV-BUILD-003. При наличии digest, SBOM или отчёта сканирования они должны
быть связаны с тем же результатом. Metadata должна позволять воспроизвести
сборку и определить, кто и каким защищённым pipeline создал артефакт.
Обоснование¶
Provenance связывает release с исходниками и проверками.
Проверка¶
- запрос provenance по release identifier;
- повторная сборка из указанного commit;
- проверка доступа к release pipeline.
Исключения¶
Криптографическая подпись artifact не требуется этим требованием до выбора корпоративного средства подписи.