Les attaques de chaîne d’approvisionnement logicielle étaient longtemps un problème de grand compte : une dépendance de build compromise, à une échelle que peu de structures plus petites atteignaient. NIS2 change qui est réellement concerné. La directive étend les obligations de sécurité en descendant la chaîne de sous-traitance, ce qui veut dire qu’un prestataire informatique d’une PME-ETI, et souvent les fournisseurs de ce prestataire, héritent d’exigences qui s’arrêtaient auparavant aux grands groupes régulés. « On est trop petits pour être une cible » n’a jamais été tout à fait vrai ; ce n’est désormais plus non plus une réponse de conformité valable. La réponse pratique tient dans le pipeline que vous faites déjà tourner : savoir ce qu’il y a dans vos images, bloquer sur les vulnérabilités connues, et prouver d’où vient une image avant qu’elle ne tourne.

Le scan comme garde-fou de pipeline, pas comme réflexion après coup

Un scanner de vulnérabilités lit les couches d’une image, compare les paquets installés aux bases de CVE, et remonte ce qu’il trouve. Trivy et Grype sont les deux références open source ; les deux tournent comme étape de CI et peuvent tous deux faire échouer le build au-delà d’un seuil de sévérité :

# étape GitHub Actions
- name: Scan image
  uses: aquasecurity/trivy-action@0.24.0
  with:
    image-ref: registry.example.com/app:${{ github.sha }}
    severity: CRITICAL,HIGH
    exit-code: '1'   # fait échouer le job si des CVE correspondantes sont trouvées

Le garde-fou ne vaut que ce que vaut sa discipline de seuil. Faire échouer le build sur chaque trouvaille de sévérité moyenne dès le premier jour noie l’équipe sous le bruit et apprend à tout le monde à ignorer le scanner ; commencez par critical, ajoutez high une fois le backlog des trouvailles existantes trié, et traitez une exemption de scan comme vous traiteriez un test désactivé : documentée, bornée dans le temps, et revisitée. Le résultat du scan ne vaut aussi que ce que vaut la fraîcheur de la dernière exécution : une image construite une fois et déployée pendant des mois porte toutes les CVE publiées après coup contre ses paquets, d’où l’importance de rescanner sur calendrier les images déjà présentes dans le registre, pas seulement au moment du build.

SBOM : savoir ce qu’il y a dedans sans tout rescanner

Un Software Bill of Materials est l’inventaire qu’un scanner calcule déjà, conservé comme artefact plutôt que jeté après le scan :

syft registry.example.com/app:v1.4.2 -o cyclonedx-json > sbom.json

La valeur du SBOM apparaît plus tard, pas au moment du build : quand une nouvelle CVE est publiée contre une bibliothèque, vérifier l’exposition sur chaque image jamais livrée devient une requête sur des SBOM stockés, pas un rescan de chaque artefact historique qu’on n’est parfois même plus capable de reconstruire. Attachez-le à l’image comme artefact OCI aux côtés du build, et l’inventaire voyage avec ce qu’il décrit.

Signature keyless : prouver d’où vient une image

Le scan vous dit ce qu’il y a dans une image. La signature vous dit que l’image est bien celle que votre pipeline a réellement produite, pas une image de même nom poussée par quelqu’un d’autre disposant d’un accès en écriture au registre. L’approche traditionnelle, une clé de signature privée longue durée, ne fait que déplacer le problème de gestion de clé que le scan était censé éviter : une clé de signature fuitée et à laquelle tout le monde fait confiance est une dette plus lourde que l’artefact qu’elle protège.

cosign de Sigstore, en mode keyless, retire entièrement la clé stockée, en s’appuyant sur la même mécanique de fédération OIDC qui remplace les credentials cloud statiques dans un pipeline : le job de CI prouve son identité via un jeton OIDC de courte durée, une paire de clés éphémère est générée pour cette seule opération de signature, et un journal de transparence public (Rekor) enregistre définitivement la signature et l’identité qui l’a produite.

# depuis la CI, avec le jeton d'identité émis par OIDC déjà disponible
cosign sign --yes registry.example.com/app@sha256:1e9c...a41f

Aucune clé privée à stocker, à faire tourner, ou à voir fuiter, puisqu’aucune ne survit à l’opération de signature. Vérifier consiste en une consultation du journal de transparence et de l’identité enregistrée, pas en un secret partagé :

cosign verify \
  --certificate-identity="https://github.com/acme/app/.github/workflows/build.yml@refs/heads/main" \
  --certificate-oidc-issuer="https://token.actions.githubusercontent.com" \
  registry.example.com/app@sha256:1e9c...a41f

Vérifier à l’admission : le garde-fou qui compte vraiment

Une signature que personne ne vérifie ne protège rien. policy-controller (le webhook d’admission de Sigstore lui-même) ou la règle verifyImages de Kyverno peuvent exiger une signature valide et correspondante avant que le serveur API Kubernetes n’admette un pod :

# ClusterPolicy Kyverno, abrégée
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: verify-image-signatures
spec:
  rules:
    - name: check-signature
      match:
        resources:
          kinds: [Pod]
      verifyImages:
        - imageReferences: ["registry.example.com/*"]
          attestors:
            - entries:
                - keyless:
                    issuer: "https://token.actions.githubusercontent.com"
                    subject: "https://github.com/acme/app/.github/workflows/build.yml@refs/heads/main"

Une image non signée, ou signée par une identité que la politique ne nomme pas, est rejetée avant qu’un seul conteneur ne démarre, ce qui referme la boucle que le scan et la signature n’avaient qu’ouverte : ce qui a été scanné est ce qui a été signé, et seul ce qui a été signé tourne réellement.

Là où ça se range

Rien de tout ça ne remplace la sécurité réseau du cluster ; une NetworkPolicy en deny-all continue de gouverner ce qu’un pod peut joindre, quelle que soit la rigueur du contrôle avant admission. Les contrôles de supply chain répondent à une question plus en amont : est-ce bien la chose prévue qui tourne. N’importe quel pipeline qui publie vers un registre de conteneurs, y compris celui de ce site, qui pousse vers GHCR, est concerné. Câbler scan, SBOM et vérification de signature dans un pipeline qui n’a pas été pensé avec ça dès le premier jour est un travail courant dans une mission d’industrialisation CI/CD, et de moins en moins optionnel pour quiconque vend dans une chaîne d’approvisionnement régulée.