⚙️ Теория
🔗 Supply chain security в CI/CD
Риск не только в исходном коде, но и в build/release цепочке. Цель: доказуемо связать артефакт с процессом сборки.
🧩 SLSA как модель зрелости
SLSA задает требования к:
- целостности сборки;
- отслеживаемости provenance;
- защите pipeline от подмен.
Практически это roadmap повышения доверия к сборке, а не "включить один инструмент".
✍️ Подпись и attestations (Sigstore/Cosign)
cosign позволяет:
- подписывать контейнерные образы;
- публиковать attestations (например, provenance/SBOM);
- верифицировать подпись на этапе deploy/policy-check.
⚠️ Типичные ошибки
- подписывать артефакт, но не проверять подпись в delivery;
- генерировать provenance, но не связывать его с policy;
- хранить ключи без защищенной ротации/доступа.
❓ Что нужно уметь объяснить
Почему подпись без verification бесполезна?
Потому что угроза снимается только в точке принятия решения (admission/deploy), где подпись и provenance действительно проверяются.
Что важнее: уровень SLSA или скорость релиза?
Это компромисс. Нужен поэтапный рост зрелости, при котором контроль усиливается без блокировки delivery.
Где быстрый win?
Подпись образов + обязательная проверка подписи и provenance перед rollout.
🧪 Практика
1. Подпись контейнерного образа
cosign sign registry.example.com/app:1.0.02. Верификация подписи
cosign verify registry.example.com/app:1.0.03. Attestation verification
cosign verify-attestation registry.example.com/app:1.0.04. Guardrails
- сделать verification обязательным gate в CD;
- ограничить, кто может выпускать подписанные релизы;
- хранить provenance вместе с релизными артефактами.
🧾 Вывод
SLSA + cosign закрывают доверие к цепочке поставки, если есть не только подпись, но и обязательная проверка на этапе релиза.