Supply chain security¶

Garantir l'intégrité de chaque maillon — du code source au déploiement en production.

La chaîne d'approvisionnement logicielle¶

La supply chain d'un système couvre tout le chemin de la source au déploiement : code source, dépendances, build, image Docker, configuration, déploiement. Un attaquant qui compromet un maillon de cette chaîne peut injecter du code malveillant sans toucher directement au système cible.

Les vecteurs d'attaque courants :

• Image Docker modifiée dans un registre non sécurisé
• Dépendance npm/pip malveillante (typosquatting, maintainer compromis)
• Artefact de build remplacé pendant le transit
• Pipeline CI compromise (injection dans les scripts de build)
• Configuration modifiée entre le build et le déploiement

Les incidents réels sont nombreux : SolarWinds (2020, build compromise), Codecov (2021, script bash modifie dans la CI), event-stream (2018, dépendance npm detournee), ua-parser-js (2021, maintainer compromis). Chacun exploitait un maillon différent de la chaîne.

SBOM — Software Bill of Materials¶

Un SBOM est un inventaire exhaustif de toutes les dépendances d'un artefact : bibliotheques directes et transitives, versions, licences, provenance. Il permet de répondre immédiatement à la question "est-ce que cette vulnérabilité CVE-XXXX nous affecte ?" sans auditer manuellement chaque service.

Formats standards¶

Les deux formats sont interoperables et largement supportes. CycloneDX est plus courant dans le contexte sécurité, SPDX dans le contexte compliance et licences.

Outils de génération¶

Intégration dans la CI¶

Le SBOM devient un artefact de première classe dans le pipeline CI. Il est généré à chaque build, signe avec l'image, et stocke dans le registre.

# Extrait de pipeline CI (GitHub Actions)
- name: Build image
  run: docker build -t myapp:${{ github.sha }} .

- name: Generate SBOM
  run: syft myapp:${{ github.sha }} -o cyclonedx-json > sbom.json

- name: Scan vulnerabilities
  run: grype sbom:sbom.json --fail-on critical

- name: Sign and push
  run: |
    cosign sign myapp:${{ github.sha }}
    cosign attach sbom --sbom sbom.json myapp:${{ github.sha }}

Les outils de scanning de vulnérabilités (Grype, Trivy) utilisent ensuite le SBOM pour identifier les composants affectes par de nouvelles CVEs — sans avoir a re-analyser l'image complète.

Une pratique courante : configurer une alerte automatique quand une nouvelle CVE critique est publiee pour un composant present dans un SBOM en production. L'équipe est notifiee en quelques minutes au lieu de découvrir la vulnérabilité lors du prochain scan planifie.

Signature des artefacts et Sigstore¶

cosign¶

cosign est l'outil de la fondation Sigstore pour signer les images OCI. La signature est stockee dans le registre OCI lui-même, couplee à l'image.

# Signer une image
cosign sign --key cosign.key myregistry.io/myapp:v1.2.3

# Verifier une image
cosign verify --key cosign.pub myregistry.io/myapp:v1.2.3

cosign supporte aussi la signature "keyless" via Sigstore Fulcio — pas besoin de gérer une clé privee. L'identité est prouvee via OIDC (Google, GitHub, Microsoft), et le certificat éphémère est enregistre dans le log de transparence.

Sigstore — infrastructure de transparence¶

Sigstore est une infrastructure de transparence pour les signatures logicielles. Trois composants clés :

graph LR
    DEV[Developpeur / CI] --text--> OIDC[Identity Provider\nGitHub, Google]
    OIDC --text--> FULCIO[Fulcio\nCA ephemere]
    FULCIO --text--> CERT[Certificat ephemere]
    CERT --text--> SIGN[Signature]
    SIGN --text--> REKOR[Rekor\nLog de transparence]
    SIGN --text--> REG[Registre OCI]

L'avantage du modèle keyless : pas de clé privee a protéger, pas de rotation de clé a gérer. L'identité est liee au fournisseur OIDC. Le log de transparence Rekor permet de vérifier qu'une signature existait à un instant donne et n'a pas été retro-datee.

SLSA — Supply chain Levels for Software Artifacts¶

SLSA (prononce "salsa") est un framework de niveaux de maturité pour la sécurité de la supply chain. Il définit des exigences progressives pour garantir l'intégrité des artefacts produits.

Les niveaux SLSA¶

Provenance SLSA¶

La provenance est un document qui atteste comment un artefact a été construit : quel code source, quel builder, quels parametres, quand. La provenance est signee et peut être vérifiée independamment.

{
  "_type": "https://in-toto.io/Statement/v0.1",
  "subject": [{
    "name": "myapp",
    "digest": { "sha256": "abc123..." }
  }],
  "predicateType": "https://slsa.dev/provenance/v0.2",
  "predicate": {
    "builder": { "id": "https://github.com/actions/runner" },
    "buildType": "https://github.com/actions/workflow",
    "invocation": {
      "configSource": {
        "uri": "git+https://github.com/acme/myapp@refs/heads/main",
        "digest": { "sha256": "def456..." }
      }
    }
  }
}

Objectifs par criticite¶

Pour la plupart des systèmes, SLSA 2 est la cible pragmatique : build automatise dans une CI connue avec une provenance signee. Le rapport effort/valeur est le plus favorable.

in-toto — attestations de la supply chain¶

in-toto est un framework pour attester chaque étape de la supply chain logicielle. La ou SLSA se concentre sur la provenance du build, in-toto couvre l'ensemble du pipeline : code review, build, test, scan, déploiement.

Concept¶

Chaque étape de la supply chain produit une attestation signee ("link") qui enregistre les inputs et les outputs de l'étape. Un "layout" définit les étapes attendues et qui est autorise à les exécuter.

graph LR
    CODE["Code review\n(attestation signee)"] --text--> BUILD["Build\n(attestation signee)"]
    BUILD --text--> TEST["Tests\n(attestation signee)"]
    TEST --text--> SCAN["Security scan\n(attestation signee)"]
    SCAN --text--> DEPLOY["Deploiement\n(verification)"]
    LAYOUT["Layout\n(regles attendues)"] --verifie--> DEPLOY

Utilisation avec cosign¶

cosign peut stocker des attestations in-toto dans le registre OCI aux cotes de l'image :

# Attacher une attestation de provenance
cosign attest --predicate provenance.json \
  --type slsaprovenance \
  myregistry.io/myapp:v1.2.3

# Verifier les attestations
cosign verify-attestation \
  --type slsaprovenance \
  myregistry.io/myapp:v1.2.3

Vérification au déploiement¶

Un admission controller Kubernetes intercepte chaque tentative de déploiement et vérifié que l'image est signee par une clé de confiance. Les images non signees ou signees par une clé inconnue sont refusees avant même de démarrer.

Outils d'enforcement¶

Politique Kyverno¶

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: verify-image-signature
spec:
  validationFailureAction: enforce
  rules:
    - name: verify-cosign
      match:
        resources:
          kinds:
            - Pod
      verifyImages:
        - imageReferences:
            - "myregistry.io/*"
          attestors:
            - entries:
                - keys:
                    publicKeys: |-
                      -----BEGIN PUBLIC KEY-----
                      MFkwEwYHKoZI...
                      -----END PUBLIC KEY-----

Vérification au-delà de la signature¶

La vérification peut aller au-delà de la signature simple :

Pipeline de référence¶

Un pipeline de supply chain security complet combine tous ces éléments :

graph TD
    SRC["Code source\n+ commit signe"] --text--> CI["Pipeline CI\n(infra verifiee)"]
    CI --text--> BUILD["Build hermetique"]
    BUILD --text--> SBOM["SBOM generation\n(Syft)"]
    BUILD --text--> SIGN["Signature\n(cosign)"]
    SBOM --text--> SCAN["Vulnerability scan\n(Grype)"]
    SIGN --text--> REG["Registre OCI\n+ attestations"]
    SBOM --text--> REG
    SCAN --pass--> REG
    REG --text--> ADM["Admission controller\n(Kyverno)"]
    ADM --text--> K8S["Deploiement K8s"]
    SCAN --fail--> BLOCK["Deploiement bloque"]

Chapitre suivant : Valider et gouverner — mesurer, réviser, maintenir l'architecture dans le temps.