Sécurité de la supply chain logicielle

En décembre 2021, la vulnérabilité Log4Shell a exposé une réalité inconfortable : la plupart des organisations ne savaient pas si elles utilisaient Log4j. La bibliothèque était présente dans des milliers d’applications, souvent comme dépendance transitive invisible. Les équipes ont passé des semaines à auditer manuellement leurs systèmes pendant que les attaquants exploitaient la faille.

Cette crise a révélé un problème structurel : nous ne savons pas ce qui compose nos logiciels. La supply chain logicielle — l’ensemble des composants, processus et personnes impliqués dans la création d’un logiciel — est devenue le maillon faible de la sécurité.

Qu’est-ce que la supply chain logicielle ?

La supply chain logicielle englobe tout ce qui contribue à la création et à la distribution d’un logiciel :

Composant	Exemples	Risques associés
Code source	Votre code, contributions externes	Injection de code malveillant
Dépendances	npm, PyPI, Maven, Go modules	CVE, typosquatting, compte compromis
Outils de build	Compilateurs, bundlers, CI/CD	Compromission du processus de build
Artefacts	Images Docker, binaires, packages	Tampering, substitution
Infrastructure	Registries, CDN, serveurs de déploiement	Man-in-the-middle, compromission

L’ampleur du problème

Les chiffres donnent le vertige :

Une application Node.js moyenne a 600+ dépendances (directes et transitives)
80% du code d’une application moderne vient de dépendances tierces
En 2023, 245 000 packages malveillants ont été détectés sur les registries publics
Le temps moyen pour détecter un package compromis : 430 jours

Les trois piliers de la sécurité supply chain

La sécurisation de la supply chain repose sur trois piliers complémentaires :

Pilier	Question	Solution
Transparence	Qu’est-ce qui compose mon logiciel ?	SBOM
Intégrité	Mon logiciel a-t-il été modifié ?	Signatures, SLSA
Provenance	D’où vient mon logiciel ?	Attestations, logs de transparence

Ces trois piliers se renforcent mutuellement. Un SBOM sans vérification d’intégrité peut être falsifié. Une signature sans SBOM ne dit rien du contenu. Une attestation sans les deux manque de contexte.

SBOM : l’inventaire des composants

Un SBOM (Software Bill of Materials) est la liste exhaustive de tous les composants d’un logiciel : dépendances directes, transitives, licences, versions.

Pourquoi un SBOM est essentiel

Sans SBOM, vous êtes aveugle. Quand une vulnérabilité comme Log4Shell est annoncée, vous devez pouvoir répondre en minutes, pas en semaines :

Question	Sans SBOM	Avec SBOM
Suis-je affecté par CVE-2024-XXXX ?	”Je ne sais pas, il faut vérifier”	Requête automatique : oui/non
Quelles applications utilisent OpenSSL < 3.0 ?	Audit manuel de tous les projets	Export filtré instantané
Quelles licences sont présentes ?	Analyse juridique coûteuse	Liste générée automatiquement

Formats de SBOM

Deux formats dominent l’écosystème :

Format	Origine	Forces	Cas d’usage
CycloneDX	OWASP	Riche en métadonnées de sécurité, VEX intégré	Sécurité, vulnérabilités
SPDX	Linux Foundation	Standard ISO, focus licences	Conformité, juridique

CycloneDX
SPDX

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.5",
  "components": [
    {
      "type": "library",
      "name": "lodash",
      "version": "4.17.21",
      "purl": "pkg:npm/lodash@4.17.21",
      "licenses": [{ "license": { "id": "MIT" }}]
    }
  ]
}

{
  "spdxVersion": "SPDX-2.3",
  "SPDXID": "SPDXRef-DOCUMENT",
  "packages": [
    {
      "SPDXID": "SPDXRef-Package-lodash",
      "name": "lodash",
      "versionInfo": "4.17.21",
      "licenseConcluded": "MIT"
    }
  ]
}

Génération de SBOM

Plusieurs outils permettent de générer des SBOM :

# Avec Syft (Anchore) - recommandé
syft packages dir:. -o cyclonedx-json > sbom.json

# Avec Trivy
trivy fs --format cyclonedx -o sbom.json .

# Pour une image Docker
syft packages registry.example.com/myapp:v1.0.0 -o spdx-json > sbom.json

Intégration CI/CD

name: Generate SBOM

on:
  push:
    branches: [main]

jobs:
  sbom:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Generate SBOM
        uses: anchore/sbom-action@v0
        with:
          format: cyclonedx-json
          output-file: sbom.json

      - name: Upload SBOM
        uses: actions/upload-artifact@v4
        with:
          name: sbom
          path: sbom.json

SLSA : le framework de maturité

SLSA (Supply-chain Levels for Software Artifacts, prononcé “salsa”) est un framework qui définit des niveaux de sécurité progressifs pour la supply chain.

Les quatre niveaux SLSA

Niveau	Exigences	Ce que ça prouve	Effort
SLSA 1	Provenance documentée	Quelqu’un a documenté le build	Faible
SLSA 2	Provenance générée automatiquement	Le système de build a généré la provenance	Moyen
SLSA 3	Build isolé, provenance non falsifiable	Le développeur ne peut pas falsifier	Élevé
SLSA 4	Build hermétique, reproductible	N’importe qui peut vérifier	Très élevé

Anatomie de la provenance SLSA

Une attestation de provenance SLSA contient :

{
  "_type": "https://in-toto.io/Statement/v1",
  "subject": [{
    "name": "ghcr.io/myorg/myapp",
    "digest": { "sha256": "abc123..." }
  }],
  "predicateType": "https://slsa.dev/provenance/v1",
  "predicate": {
    "buildDefinition": {
      "buildType": "https://github.com/slsa-framework/slsa-github-generator/container@v1",
      "externalParameters": {
        "source": {
          "uri": "git+https://github.com/myorg/myapp@refs/heads/main",
          "digest": { "sha1": "def456..." }
        }
      }
    },
    "runDetails": {
      "builder": { "id": "https://github.com/slsa-framework/slsa-github-generator/.github/workflows/generator_container_slsa3.yml@refs/tags/v1.9.0" },
      "metadata": {
        "invocationId": "https://github.com/myorg/myapp/actions/runs/123456789"
      }
    }
  }
}

Cette attestation prouve :

Quoi : L’image ghcr.io/myorg/myapp avec ce digest
D’où : Du repo myorg/myapp, commit def456...
Comment : Via le workflow GitHub Actions generator_container_slsa3.yml
Quand : Run ID 123456789

Implémentation SLSA 3 avec GitHub Actions

name: Release with SLSA

on:
  push:
    tags: ['v*']

jobs:
  build:
    outputs:
      digest: ${{ steps.build.outputs.digest }}
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Build and push
        id: build
        run: |
          docker build -t ghcr.io/${{ github.repository }}:${{ github.ref_name }} .
          docker push ghcr.io/${{ github.repository }}:${{ github.ref_name }}
          echo "digest=$(docker inspect --format='{{index .RepoDigests 0}}' ghcr.io/${{ github.repository }}:${{ github.ref_name }} | cut -d'@' -f2)" >> $GITHUB_OUTPUT

  provenance:
    needs: build
    permissions:
      actions: read
      id-token: write
      packages: write
    uses: slsa-framework/slsa-github-generator/.github/workflows/generator_container_slsa3.yml@v1.9.0
    with:
      image: ghcr.io/${{ github.repository }}
      digest: ${{ needs.build.outputs.digest }}
      registry-username: ${{ github.actor }}
    secrets:
      registry-password: ${{ secrets.GITHUB_TOKEN }}

Sigstore : l’écosystème de signature

Sigstore simplifie radicalement la signature d’artefacts en éliminant le problème le plus complexe : la gestion des clés privées.

Le problème historique

Avant Sigstore, signer un artefact nécessitait :

Générer une paire de clés
Stocker la clé privée de manière sécurisée
Distribuer la clé publique
Gérer la rotation des clés
Révoquer les clés compromises

Cette complexité explique pourquoi peu de projets signaient leurs artefacts.

L’approche keyless de Sigstore

Sigstore utilise des certificats éphémères liés à votre identité OIDC (GitHub, GitLab, Google) :

Vous vous authentifiez via OIDC
Fulcio émet un certificat de courte durée (10 minutes)
Vous signez avec ce certificat
La signature est enregistrée dans Rekor (log de transparence)
Le certificat expire, mais la signature reste vérifiable

Résultat : Pas de clé privée à gérer, mais une traçabilité complète.

Les composants Sigstore

Composant	Rôle	Analogie
Cosign	CLI pour signer/vérifier	Le stylo qui signe
Fulcio	Autorité de certification	Le notaire qui vérifie l’identité
Rekor	Log de transparence	Le registre public des actes
Gitsign	Signature des commits Git	Cosign pour Git

# Signer (ouvre une fenêtre d'authentification OIDC)
cosign sign ghcr.io/myorg/myapp:v1.0.0

# Vérifier
cosign verify \
  --certificate-identity "https://github.com/myorg/myrepo/.github/workflows/release.yml@refs/tags/v1.0.0" \
  --certificate-oidc-issuer "https://token.actions.githubusercontent.com" \
  ghcr.io/myorg/myapp:v1.0.0

# Générer une paire de clés
cosign generate-key-pair

# Signer
cosign sign --key cosign.key ghcr.io/myorg/myapp:v1.0.0

# Vérifier
cosign verify --key cosign.pub ghcr.io/myorg/myapp:v1.0.0

Vérification dans Kubernetes

Kubernetes peut vérifier les signatures avant de déployer une image :

# Policy Kyverno
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: verify-signatures
spec:
  validationFailureAction: Enforce
  rules:
    - name: verify-cosign-signature
      match:
        resources:
          kinds: [Pod]
      verifyImages:
        - image: "ghcr.io/myorg/*"
          key: |-
            -----BEGIN PUBLIC KEY-----
            ...
            -----END PUBLIC KEY-----

Sécuriser les dépendances

Les dépendances sont le vecteur d’attaque le plus courant dans la supply chain logicielle. Plusieurs pratiques complémentaires réduisent significativement ce risque.

Épingler les versions

Ne laissez jamais le gestionnaire de packages choisir la version :

// ❌ Dangereux
{
  "dependencies": {
    "lodash": "^4.17.0",  // Accepte 4.17.x, y compris futures versions compromises
    "express": "*"        // N'importe quelle version !
  }
}

// ✅ Sécurisé
{
  "dependencies": {
    "lodash": "4.17.21",  // Version exacte
    "express": "4.18.2"
  }
}

Utiliser des lock files

Les lock files (package-lock.json, yarn.lock, Pipfile.lock) garantissent des builds reproductibles en figeant l’arbre complet des dépendances :

# Installer uniquement ce qui est dans le lock file
npm ci  # Pas `npm install`

Vérifier les checksums

# npm vérifie automatiquement les checksums du lock file
npm ci --ignore-scripts  # Bonus : désactive les scripts post-install

# Python avec pip-tools
pip-compile requirements.in --generate-hashes
pip-sync requirements.txt

Scanner les vulnérabilités

# npm audit
npm audit --audit-level=high

# Trivy (multi-écosystème)
trivy fs --severity HIGH,CRITICAL .

# Grype (Anchore)
grype dir:.

Roadmap d’implémentation

La sécurisation de la supply chain est un voyage, pas une destination. Plutôt que de tout implémenter d’un coup, adoptez une approche progressive qui construit la maturité par étapes :

À retenir

SBOM : Savoir ce qui compose vos logiciels (obligatoire pour répondre aux CVE)
SLSA : Framework de maturité, viser niveau 2 minimum
Sigstore : Signature keyless, plus d’excuse pour ne pas signer
Dépendances : Épingler, verrouiller, scanner, vérifier
Progressivité : Commencer par la visibilité, puis intégrité, puis provenance

Mettre en pratique

Pipeline sécurisé Intégrer la sécurité supply chain dans vos pipelines.

Guides d'implémentation SBOM, SLSA, Sigstore : guides pas à pas avec les outils.