Sécuriser la chaîne CI/CD : SBOM, provenance et SLSA

Une application peut être correctement développée puis altérée pendant sa fabrication ou sa livraison. La chaîne CI/CD automatise ces étapes et détient souvent des accès puissants. Pour lui faire confiance, il faut savoir ce qui a été construit, à partir de quelles sources et par quel processus, puis vérifier ces informations avant déploiement.

1. Séparer les preuves

L’artefact est le résultat livré : image de conteneur, paquet ou binaire. Son empreinte cryptographique, ou digest, permet de désigner un contenu précis. Un nom mutable comme latest ne suffit pas à rattacher durablement un rapport au contenu déployé.

2. Définir l’architecture de confiance

Séparez la validation de code non fiable, par exemple une contribution externe, des étapes ayant accès aux secrets de publication. Utilisez des environnements isolés et évitez qu’un job puisse modifier durablement celui d’un autre projet. Fixez les dépendances d’automatisation à des références immuables lorsque c’est possible, puis organisez leurs mises à jour.

La documentation de sécurité GitHub Actions détaille notamment les risques liés aux entrées non fiables, aux permissions et aux dépendances des workflows. Les principes doivent être adaptés à votre forge et à vos exécutants. Une identité fédérée de courte durée est préférable à un secret durable quand le fournisseur et le scénario le permettent.

3. Produire et analyser une SBOM de laboratoire

Installez des versions identifiées de Syft et Grype depuis leurs sources officielles selon votre procédure de vérification. Dans un dossier contenant uniquement une application de démonstration, ces commandes produisent un inventaire et un rapport. Elles écrivent des fichiers locaux ; Grype peut devoir récupérer sa base d’avis selon sa configuration.

syft version
grype version
syft dir:./application-demo -o cyclonedx-json=sbom.cdx.json
grype sbom:./sbom.cdx.json -o json > vulnerabilites.json

Le dossier doit exister et son contenu doit être autorisé à l’analyse. Rejouez ces commandes avec les versions retenues pour votre environnement. Examiner les codes de sortie est indispensable : un fichier vide après un échec n’est pas un rapport sans vulnérabilité. Conservez la version des outils, l’âge de la base et l’empreinte de l’artefact concerné.

En production, analysez le contenu effectivement livré, pas uniquement le répertoire source. Une dépendance ajoutée pendant le build pourrait autrement manquer. Le format CycloneDX facilite l’échange d’inventaires, mais le périmètre reconnu dépend du scanner et du type de logiciel.

4. Situer SLSA sans revendiquer un niveau fictif

La spécification SLSA v1.2, piste Build distingue une provenance existante au niveau L1, une provenance signée produite par une plateforme hébergée au niveau L2, puis des exigences de durcissement de la plateforme au niveau L3. Chaque niveau demande de satisfaire ses exigences ; la présence d’un fichier de provenance ne suffit pas à revendiquer L3.

Écrivez votre objectif comme une liste de contrôles à démontrer. Qui peut modifier le workflow ? Une contribution peut-elle accéder au secret de signature ? Un build peut-il influencer le suivant ? La vérification utilise-t-elle l’empreinte du contenu déployé ? Les réponses doivent être prouvées sur votre chaîne, pas déduites du nom d’un outil.

5. Vérifier avant de livrer

La documentation Cosign explique la vérification des signatures. Pour une signature sans clé durable, l’identité du certificat et l’émetteur attendus font partie des contrôles. Accepter n’importe quelle signature valide ne prouve pas que votre workflow a produit l’artefact.

Ajoutez des cas négatifs : empreinte différente, identité inattendue, provenance absente et rapport trop ancien. La politique doit refuser ou demander une décision explicite selon le risque. Une exception de livraison doit être limitée, tracée et réexaminée. Reliez ensuite les vulnérabilités applicables au pipeline KEV/EPSS et aux responsabilités de correction.

6. Recette et retour arrière

• Rejouer sur une application fictive avec une dépendance connue et vérifier sa présence dans la SBOM.
• Introduire une différence entre l’artefact analysé et l’artefact proposé : la vérification doit la détecter.
• Tester une identité de signature non attendue et une provenance manquante.
• Vérifier qu’un job non fiable ne lit pas les secrets de publication.
• Simuler une base de vulnérabilités indisponible et constater le comportement prévu.
• Conserver le dernier artefact approuvé et sa procédure de redéploiement.

Le retour arrière restaure une version de workflow approuvée ou redéploie un artefact identifié. Il ne doit pas désactiver silencieusement les vérifications ni réutiliser un secret potentiellement exposé. Ce guide présente la chaîne cible et sa recette ; aucun niveau SLSA n’est revendiqué pour votre infrastructure.

Sources et références

Références consultées le 10 octobre 2026. Les schémas sont des représentations pédagogiques ; les exemples et recettes proposés doivent être adaptés au périmètre réel.

• Anchore - Syft
• Anchore - Grype
• SLSA - Build track v1.2
• Sigstore - Vérification Cosign
• GitHub - Secure use reference