Quand votre serveur télécharge l’image app:1.4.2, comment savoir qu’il s’agit bien de celle construite par votre pipeline, et non d’une version substituée par un attaquant qui a obtenu un accès au registre ? Le nom et l’étiquette ne prouvent rien. La signature des images, avec Sigstore et son outil Cosign, permet de vérifier l’origine d’un artefact avant de le déployer, sans avoir à gérer de clés privées. Mais 2026 a aussi montré ses limites : une signature prouve qui a construit, pas ce que contient l’artefact.
L’essentiel en 30 secondes
- Cosign signe des images de conteneurs et d’autres artefacts ; la signature est stockée dans le registre, à côté de l’image.
- Le mode sans clé (keyless) lie la signature à l’identité du pipeline (par exemple un workflow GitHub Actions précis), attestée par un certificat éphémère et enregistrée dans un journal de transparence public.
- La vérification doit contrôler l’identité exacte : dépôt, fichier de workflow, branche. Vérifier « qu’il y a une signature » ne suffit pas.
- En mai 2026, des paquets malveillants publiés par le ver Mini Shai-Hulud portaient des attestations de provenance valides : la signature complète l’analyse, elle ne la remplace pas.
Comment fonctionne Sigstore
- Le pipeline s’authentifie auprès de Fulcio, l’autorité de certification de Sigstore, avec son jeton OIDC (GitHub Actions, GitLab CI, Google, etc.).
- Fulcio délivre un certificat valable quelques minutes, qui contient l’identité du pipeline.
- Cosign signe l’artefact et la signature est inscrite dans Rekor, le journal de transparence. Sa nouvelle version, Rekor v2, est disponible depuis octobre 2025 et nécessite Cosign 2.6 ou 3.0.1 au minimum.
- À la vérification, Cosign contrôle la signature, le certificat, l’inscription dans le journal et l’identité attendue.
Avantage majeur : aucune clé privée à stocker, à protéger et à faire tourner.
Signer dans le pipeline
Dans GitHub Actions, le job doit disposer de permissions: id-token: write (voir sécuriser ses pipelines). On signe toujours par empreinte (digest), jamais par étiquette :
# Signer l'image construite (mode sans clé)
cosign sign --yes registre.exemple.fr/app@sha256:<empreinte>
# Attacher le SBOM comme attestation signée
cosign attest --yes --type cyclonedx --predicate sbom.cdx.json \
registre.exemple.fr/app@sha256:<empreinte>Vérifier avant de déployer
cosign verify registre.exemple.fr/app@sha256:<empreinte> \
--certificate-identity "https://github.com/mon-organisation/mon-depot/.github/workflows/publication.yml@refs/heads/main" \
--certificate-oidc-issuer "https://token.actions.githubusercontent.com"
# Vérifier l'attestation SBOM
cosign verify-attestation --type cyclonedx \
--certificate-identity "https://github.com/mon-organisation/mon-depot/.github/workflows/publication.yml@refs/heads/main" \
--certificate-oidc-issuer "https://token.actions.githubusercontent.com" \
registre.exemple.fr/app@sha256:<empreinte>Cette commande échoue si l’image n’a pas été signée par ce workflow, sur cette branche. Un attaquant qui signerait depuis un autre dépôt, un autre workflow ou une branche de test serait rejeté.
Où placer la vérification
| Environnement | Mécanisme |
|---|---|
| Serveur Docker ou Compose | Script de déploiement qui exécute cosign verify puis déploie l’image par empreinte |
| Kubernetes | Contrôleur d’admission : Sigstore policy-controller ou règles verifyImages de Kyverno |
| Pipeline de promotion | Vérification avant copie de l’image vers le registre de production |
| Images tierces | Vérifier les signatures publiées par l’éditeur quand elles existent (de nombreux projets open source signent désormais avec Sigstore) |
Avec des clés, si nécessaire
Pour un environnement isolé d’Internet ou une politique interne, Cosign fonctionne aussi avec une paire de clés classique (cosign generate-key-pair, puis --key). La clé privée doit alors être protégée, idéalement dans un coffre (KMS ou OpenBao), et faire l’objet d’une procédure de rotation.
Les limites à garder en tête
- Une signature valide prouve l’origine, pas l’innocuité : si le pipeline est compromis ou si une dépendance malveillante a été intégrée, l’artefact piégé sera signé comme les autres. C’est ce qu’a montré Mini Shai-Hulud.
- Combinez donc signature, SBOM, analyse des vulnérabilités et surveillance des dépendances.
- Le cadre SLSA aide à évaluer le niveau de confiance de toute la chaîne de construction, au-delà de la seule signature.
Questions fréquentes
Le journal de transparence public révèle-t-il des informations ?
Il contient l’identité du signataire (par exemple le chemin du workflow et le dépôt) et l’empreinte de l’artefact. Pour des projets privés sensibles, une instance Sigstore privée est possible.
Que se passe-t-il si Sigstore est indisponible ?
La signature échoue dans le pipeline, ce qui bloque la publication. La vérification peut fonctionner hors ligne avec les éléments embarqués dans le paquet de signature, selon la configuration.
Faut-il signer aussi les binaires et les paquets ?
Oui, Cosign signe n’importe quel fichier, et les registres npm et PyPI prennent en charge des attestations de provenance basées sur Sigstore.
Par où commencer ?
Signez les images de vos applications dans le pipeline, puis ajoutez la vérification sur un premier environnement de production. Étendez ensuite aux images tierces critiques.
Sources
- Sigstore, documentation officielle (Cosign, Fulcio, Rekor).
- Sigstore, disponibilité générale de Rekor v2, 10 octobre 2025.
- Cloud Security Alliance, note sur Mini Shai-Hulud, mai 2026.
- SLSA, Supply-chain Levels for Software Artifacts.
Besoin d’un accompagnement ?
MPCÂBLE Solutions Informatiques (MPCSI) accompagne particuliers, entreprises, associations et collectivités depuis Gaudiès, en Ariège : sur site en Occitanie, principalement dans un rayon de 40 km (Pamiers, Foix, Mirepoix, Saverdun, Castelnaudary), et à distance partout en France. Nous sécurisons vos chaînes de construction et de déploiement lors d’un audit. Demandez un devis gratuit ou appelez le 05 32 42 99 98.
