Intégration dans la CI/CD

Le pipeline cible

1. build           → produit l'artefact
2. sbom-generate   → Build SBOM + Analyzed SBOM
3. sbom-validate   → schéma, score de qualité, écart build/analyzed
                     ↳ ÉCHEC si sous le seuil
4. sbom-sign       → signature + attestation de provenance
5. sbom-publish    → envoi à la plateforme de pilotage
6. policy-gate     → vulnérabilités, licences, VEX
                     ↳ ÉCHEC ou AVERTISSEMENT selon la politique
7. attach          → SBOM et signature attachés à l'artefact dans le registre
8. archive         → versement au coffre de preuves, indexé par empreinte

Les étapes 3 et 6 sont bloquantes. Les autres sont des étapes de production : leur échec doit également faire échouer la construction, faute de quoi des artefacts sans SBOM atteindront la production.

Exemple — GitHub Actions

jobs:
  build-and-attest:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      id-token: write      # signature sans clé longue durée
      packages: write
    steps:
      - uses: actions/checkout@v4

      - name: Construire l'artefact
        run: make build

      - name: Générer le SBOM (build)
        run: syft dir:. -o cyclonedx-json=sbom-build.cdx.json

      - name: Générer le SBOM (analyzed)
        run: syft "$IMAGE" -o cyclonedx-json=sbom-analyzed.cdx.json

      - name: Valider qualité et écart
        run: ./ci/validate-sbom.sh sbom-build.cdx.json sbom-analyzed.cdx.json

      - name: Signer
        run: cosign attest --predicate sbom-build.cdx.json --type cyclonedx "$IMAGE"

      - name: Publier vers la plateforme
        run: ./ci/publish-sbom.sh sbom-build.cdx.json

      - name: Politiques (vulnérabilités et licences)
        run: ./ci/policy-gate.sh sbom-build.cdx.json

Le principe est le même sur GitLab CI, Jenkins ou Azure DevOps : les étapes sont identiques, seule la syntaxe change. Les scripts validate-sbom.sh, publish-sbom.sh et policy-gate.sh sont communs à toutes les chaînes et versionnés dans un dépôt central — c’est ce qui garantit l’uniformité des seuils.

Les règles de blocage

Condition	Effet	Justification
SBOM non généré ou schéma invalide	Échec	Sans SBOM, pas de conformité possible
Score de qualité sous le seuil	Échec	Un SBOM incomplet donne une assurance fausse
Écart build / analyzed au-delà du seuil	Échec	Révèle du code non déclaré
Vulnérabilité critique exploitable, sans VEX	Échec	Annexe I : pas de vulnérabilité exploitable connue à la mise sur le marché
Vulnérabilité élevée, sans VEX	Avertissement + ticket	Traitement dans le SLA
Licence en liste noire pour ce contexte	Échec	Politique de licences
Licence en liste grise	Avertissement + ticket	Validation juridique
Signature ou attestation absente	Échec	Sans signature, le SBOM n’est pas une preuve

Les dérogations

Un blocage sans échappatoire est contourné, généralement en désactivant le contrôle. Il faut donc une dérogation encadrée :

1. demandée dans un ticket, avec justification ;
2. accordée par une personne identifiée — RSSI pour les vulnérabilités, juridique pour les licences ;
3. limitée dans le temps, avec une date d’expiration obligatoire ;
4. inscrite dans un fichier versionné à côté du code, lisible par le pipeline ;
5. expirée automatiquement : à la date, le blocage reprend.

Une dérogation permanente est une modification de la politique, et doit être traitée comme telle — pas comme une exception.

Les cas particuliers

Monorepos. Un SBOM par artefact publiable, pas un pour le dépôt. La difficulté est d’attribuer correctement les dépendances partagées ; les plugins natifs de la chaîne de build s’en sortent mieux que les générateurs génériques.

Constructions matricielles. Un artefact par combinaison système ou architecture, donc un SBOM par combinaison. Le SBOM d’une variante ne vaut pas pour les autres.

Constructions incrémentales et cache. Le cache peut masquer un changement de dépendance. Le SBOM doit être régénéré à chaque construction publiable, sans réutilisation de cache.

Artefacts tiers reconditionnés. Si vous republiez un artefact que vous n’avez pas construit, vous devez l’analyser — le SBOM du fournisseur, s’il existe, est un point de départ à vérifier, pas une pièce à reprendre telle quelle.

Le coût

La génération ajoute de quelques secondes à quelques minutes par construction, selon la taille de l’artefact et la méthode. Les leviers usuels :

• ne produire l’Analyzed SBOM que sur les constructions publiables, pas sur chaque proposition de modification ;
• mettre en cache les bases de vulnérabilités des outils, pas les résultats ;
• paralléliser génération et tests ;
• réserver le contrôle croisé complet aux branches de publication.

Ces optimisations ne doivent jamais réduire ce qui est produit pour un artefact livré : c’est le seul cas où la conformité se joue.