Vérification de la chaîne d'approvisionnement
Vérifier les charts Helm signés, les images de conteneurs signées et le SBOM publié avec chaque version de Scrydon.
Scrydon publie des charts Helm signés et des images de conteneurs signées à chaque version, ainsi qu'un SBOM. Cette page explique comment les vérifier.
Ce qui est signé
| Artefact | Outil de signature | Lieu de publication |
|---|---|---|
| Images OCI | Cosign | Registre OCI (configurable par canal de diffusion) |
| Chart Helm | Cosign + artefact OCI | Même registre que les images |
| SBOM | Attestation Cosign | Attaché à chaque image en tant qu'attestation Cosign |
| Provenance | Attestation de build compatible SLSA | Attachée à chaque image |
Vérification d'une image
# Découverte de la clé publiée pour le canal de diffusion
cosign verify \
--certificate-identity-regexp 'https://github.com/scrydon/.*' \
--certificate-oidc-issuer 'https://token.actions.githubusercontent.com' \
<registry>/scrydon/<image>:<version>cosign verify renvoie le payload de signature vérifié ou une erreur si la signature ne correspond pas.
Vérification d'un chart Helm
Les charts Helm sont signés en tant qu'artefacts OCI. Même commande que ci-dessus avec la référence OCI du chart :
cosign verify \
--certificate-identity-regexp 'https://github.com/scrydon/.*' \
--certificate-oidc-issuer 'https://token.actions.githubusercontent.com' \
<registry>/scrydon/helm/scrydon:<version>Récupération du SBOM
Le SBOM est attaché à chaque image en tant qu'attestation CycloneDX. Récupérez-le avec :
cosign download attestation \
--predicate-type 'https://cyclonedx.org/bom' \
<registry>/scrydon/<image>:<version> | jq -r '.payload | @base64d' | jq .Le SBOM liste chaque dépendance, version, licence et identifiant de vulnérabilité connu.
Vérification de la provenance
La provenance du build est également une attestation Cosign, au format SLSA :
cosign download attestation \
--predicate-type 'https://slsa.dev/provenance/v1' \
<registry>/scrydon/<image>:<version> | jq -r '.payload | @base64d' | jq .La provenance comprend :
- Le commit source.
- Le point d'entrée du build.
- L'environnement de build.
- Le déclencheur du build.
C'est ce qui est typiquement exigé par le règlement européen CRA, annexe I.1.2(h), et par les preuves de niveau SLSA 3.
Vérification en environnement déconnecté
Dans les déploiements en environnement isolé, les mêmes artefacts sont intégrés dans le package Zarf. La vérification s'effectue localement par rapport aux clés incluses dans le package — mêmes commandes cosign, avec le registre remplacé par le store Zarf local.
Que faire en cas d'échec de la vérification
Un échec de vérification signifie ne pas déployer. Soit l'artefact a été altéré, soit il n'a pas été publié par le pipeline de publication de Scrydon. Contactez le support de Scrydon avant de continuer.
Liens connexes
- Déploiement en environnement isolé — comment la vérification de la chaîne d'approvisionnement fonctionne en mode déconnecté.
- Conformité → CRA UE — ce que les régulateurs s'attendent à voir.
- Conformité → ISO 27001 — A.8.25 intégrité de la chaîne d'approvisionnement.