Par où commencer avec la supply chain security

Mise à jour : 30/12/2025

Vous connaissez maintenant les menaces : XZ Utils, Polyfill.io, tj-actions… Les attaquants ciblent vos dépendances, vos pipelines, vos registres. La question n’est plus “pourquoi s’en préoccuper” mais “par quoi commencer”.

Ce guide vous donne un parcours progressif en 4 niveaux avec des actions concrètes à exécuter dès aujourd’hui. Chaque étape inclut les commandes à lancer, les outils à configurer, et les pièges à éviter.

Le parcours en 4 niveaux

Parcours progressif de maturité supply chain : 4 niveaux de fondamentaux à
gestion continue

Niveau	Objectif	Temps
1. Fondamentaux	Visibilité sur vos dépendances	1-2 jours
2. Pipelines	Sécuriser la chaîne de build	1 semaine
3. Intégrité	Prouver la provenance	2-4 semaines
4. Opérations	Industrialiser à l’échelle	Continu

Auto-évaluation rapide

Avant de foncer, situez-vous :

Question	Si non	Priorité
Savez-vous quelles dépendances vous utilisez ?	→ Niveau 1	🔴 Critique
Vos dépendances sont-elles à jour ?	→ Niveau 1	🔴 Critique
Vos pipelines CI/CD sont-ils sécurisés ?	→ Niveau 2	🟠 Haute
Vos images sont-elles signées ?	→ Niveau 3	🟡 Moyenne
Avez-vous des attestations de provenance ?	→ Niveau 3	🟢 Avancé

Niveau 1 : Les fondamentaux (Quick wins)

Objectif : obtenir une visibilité complète sur ce que contient votre application.

Temps estimé : 1-2 jours.

Comprendre le problème

Votre application Node.js déclare 15 dépendances dans package.json. Mais après npm install, votre dossier node_modules contient 500+ packages. Ce sont les dépendances transitives — les dépendances de vos dépendances.

Ces composants invisibles représentent votre surface d’attaque réelle. Log4Shell était une dépendance transitive que la plupart des équipes ignoraient avoir. Sans inventaire, impossible de savoir si vous êtes vulnérable.

Les concepts clés

SBOM (Software Bill of Materials) : l’inventaire exhaustif de tous les composants de votre application. Pensez-y comme la liste d’ingrédients d’un produit alimentaire — vous savez exactement ce que vous consommez.

CVE (Common Vulnerabilities and Exposures) : les failles de sécurité documentées et référencées. Chaque vulnérabilité connue a un identifiant unique (ex: CVE-2024-3094 pour XZ Utils). 👉 Comprendre les CVE

Dépendances épinglées : figer les versions exactes pour éviter qu’une mise à jour automatique n’introduise du code malveillant. C’est la différence entre lodash: 4.17.21 (fixe) et lodash: ^4.0.0 (peut changer).

Mettre en pratique

Inventorier vos dépendances avec un SBOM

Syft analyse votre projet et produit un inventaire complet au format standard CycloneDX ou SPDX.
Terminal window
```
# Installer Syft
curl -sSfL https://raw.githubusercontent.com/anchore/syft/main/install.sh | sh -s -- -b /usr/local/bin

# Générer un SBOM au format CycloneDX (le plus répandu)
syft . -o cyclonedx-json > sbom.json

# Voir un résumé lisible
syft . -o table
```
Résultat attendu : un fichier JSON listant toutes vos dépendances. Vous découvrirez probablement des composants dont vous ignoriez l’existence.

👉 Guide complet SBOM
Scanner les vulnérabilités connues

Maintenant que vous avez l’inventaire, cherchez les failles connues (CVE) dans vos dépendances.
Terminal window
```
# Installer Grype
curl -sSfL https://raw.githubusercontent.com/anchore/grype/main/install.sh | sh -s -- -b /usr/local/bin

# Scanner à partir du SBOM
grype sbom:sbom.json

# Version stricte : échoue si vulnérabilité critique
grype sbom:sbom.json --fail-on critical
```
Résultat attendu : une liste de CVE avec leur sévérité. Priorisez les Critical et High — les autres peuvent attendre.

👉 Guide Grype
Activer les alertes automatiques

Configurez votre forge pour être notifié des nouvelles vulnérabilités.

GitHub : Settings → Security → Dependabot alerts (2 clics) 👉 Guide Dependabot

GitLab : CI/CD → Security → Dependency Scanning (inclus dans Ultimate)

Ces alertes vous préviennent quand une nouvelle CVE touche vos dépendances, même si vous ne scannez pas manuellement.
Épingler vos dépendances

Verrouillez les versions pour éviter les mises à jour silencieuses.
package.json
```
{
  "dependencies": {
    "lodash": "4.17.21",    // ✅ Version exacte
    "express": "^4.18.0"    // ❌ Peut changer silencieusement
  }
}
```
requirements.txt
```
requests==2.31.0    # ✅ Version exacte
flask>=2.0          # ❌ Trop permissif
```
Pourquoi ? Un attaquant qui compromet un paquet peut publier une version malveillante. Si vous acceptez automatiquement les mises à jour, vous l’installez sans le savoir.

SBOM de A à Z Inventorier tous vos composants

Syft Générer des SBOM en CLI

Trivy Scanner vulnérabilités, secrets et IaC

Grype Scanner de vulnérabilités Anchore

Niveau 2 : Sécuriser les pipelines

Objectif : empêcher un attaquant de modifier votre code pendant le build.

Temps estimé : 1 semaine.

Comprendre le problème

Votre code source est propre, vos dépendances sont scannées. Pourtant, l’attaquant peut encore gagner. Comment ? En ciblant le pipeline CI/CD qui transforme votre code en artefact déployable.

SolarWinds est l’exemple parfait : le code source était intact, mais le pipeline de build injectait une backdoor dans le binaire final. 18 000 clients compromis, dont des agences gouvernementales américaines.

L’attaque tj-actions de mars 2025 a touché des milliers de repos en modifiant une action GitHub populaire. Les secrets CI/CD se retrouvaient dans les logs publics.

Les concepts clés

Actions GitHub épinglées sur SHA : un tag comme @v4 peut être modifié par l’auteur à tout moment. Un SHA (@b4ffde65...) est immuable — il pointe toujours vers le même code.

Principe du moindre privilège : un workflow ne devrait avoir que les permissions strictement nécessaires. Par défaut, GitHub donne accès à tout le repo — c’est trop.

Secrets dans l’historique : un secret commité par erreur reste dans Git même après suppression du fichier. L’historique conserve tout. Il faut scanner avant le commit. 👉 Guide complet Secrets Scanning

Mettre en pratique

Auditer vos workflows CI/CD

Avant de modifier quoi que ce soit, faites l’état des lieux.

Questions à poser :
- Quels secrets sont accessibles ? Sont-ils nécessaires ?
- Quelles actions tierces utilisez-vous ? Les connaissez-vous ?
- Les permissions sont-elles minimales ?
- Qui peut modifier les workflows ?
👉 OWASP Top 10 CI/CD
Épingler les actions GitHub sur des SHA

Les tags (v4, latest) peuvent être modifiés par l’auteur. Un SHA est immuable.
.github/workflows/build.yml
```
# ❌ Dangereux : le tag peut changer
- uses: actions/checkout@v4

# ✅ Sécurisé : SHA immuable
- uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11
```
Comment trouver le SHA ? Allez sur le repo de l’action, cliquez sur le tag, et copiez le SHA complet du commit.

L’outil pin-github-action ↗ peut convertir automatiquement vos tags en SHA.
Réduire les permissions au minimum

Par défaut, les workflows GitHub ont accès à tout le repo. Restreignez.
.github/workflows/build.yml
```
# Permissions globales minimales
permissions:
  contents: read

jobs:
  build:
    runs-on: ubuntu-24.04
    # Permissions spécifiques si besoin
    permissions:
      packages: write  # Seulement pour ce job
```
Règle : commencez avec permissions: {} (aucune), puis ajoutez uniquement ce qui est nécessaire.
Scanner les secrets dans le code

Un secret commité par erreur reste dans l’historique Git, même après suppression.
Terminal window
```
# Installer Gitleaks
brew install gitleaks  # ou via releases GitHub

# Scanner le repo
gitleaks detect --source . -v

# En pre-commit hook
gitleaks protect --staged
```
Intégrez ce scan dans votre CI pour bloquer les PR contenant des secrets.

👉 Guide Gitleaks

Je vous renvoie vers le guide complet sur la sécurité des workflows CI/CD pour approfondir.

Sécurité GitHub Actions Bonnes pratiques détaillées

OpenSSF Scorecard Évaluer votre posture sécurité

Gitleaks Détecter les secrets dans le code

Niveau 3 : Intégrité et provenance

Objectif : prouver cryptographiquement d’où viennent vos artefacts.

Temps estimé : 2-4 semaines.

Comprendre le problème

Vous avez sécurisé vos dépendances et vos pipelines. Mais comment un consommateur de votre image Docker sait-il qu’elle vient bien de vous ?

Sans preuve cryptographique, un attaquant peut :

Remplacer votre image dans le registry par une version malveillante
Publier une image avec le même nom sur un registry public
Modifier l’image pendant le transfert réseau

La signature et les attestations résolvent ce problème. Elles créent une chaîne de confiance vérifiable : “cette image a été construite par ce workflow, à partir de ce commit, par cette personne”.

Les concepts clés

Signature keyless : traditionnellement, signer nécessite de gérer des clés privées (stockage, rotation, révocation). Sigstore élimine ce fardeau en utilisant votre identité existante (Google, GitHub, Microsoft) pour générer des certificats éphémères.

Attestation SLSA : une signature prouve qui a signé. Une attestation prouve comment l’artefact a été construit — quel repo, quel commit, quel workflow, quelles dépendances. C’est la traçabilité complète.

Admission controller Kubernetes : un composant qui intercepte les requêtes de déploiement et peut les refuser si l’image n’est pas signée. Kyverno et Connaisseur sont les plus utilisés.

Mettre en pratique

Signer vos images conteneurs

Cosign (projet Sigstore) permet de signer sans gérer de clés privées. Le mode “keyless” utilise votre identité OIDC existante.
Terminal window
```
# Installer Cosign
brew install cosign  # ou via releases GitHub

# Signer une image (mode keyless - ouvrira un navigateur)
cosign sign mon-registry.io/mon-image:v1.0.0

# Vérifier une signature
cosign verify mon-registry.io/mon-image:v1.0.0 \
  --certificate-identity=dev@example.com \
  --certificate-oidc-issuer=https://accounts.google.com
```
Ce qui se passe : Cosign utilise votre compte Google/GitHub/Microsoft pour prouver votre identité, puis enregistre la signature dans un log public (Rekor) pour transparence.

👉 Guide Cosign

Générer des attestations SLSA

Une signature prouve “qui” a signé. Une attestation SLSA prouve “comment” l’artefact a été construit (quel repo, quel commit, quel workflow).

jobs:
  build:
    # ... votre build habituel ...
    outputs:
      digest: ${{ steps.build.outputs.digest }}

  provenance:
    needs: build
    uses: slsa-framework/slsa-github-generator/.github/workflows/generator_container_slsa3.yml@v2.0.0
    with:
      image: mon-registry.io/mon-image
      digest: ${{ needs.build.outputs.digest }}

Résultat : une attestation JSON signée prouvant que l’image a été construite par votre workflow GitHub, pas par un attaquant.

👉 Guide SLSA

Vérifier avant déploiement Kubernetes

Configurez votre cluster pour refuser les images non signées.

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: verify-image-signature
spec:
  validationFailureAction: Enforce
  rules:
    - name: check-signature
      match:
        resources:
          kinds:
            - Pod
      verifyImages:
        - imageReferences:
            - "mon-registry.io/*"
          attestors:
            - entries:
                - keyless:
                    subject: "dev@example.com"
                    issuer: "https://accounts.google.com"

Alternatives : Connaisseur, Sigstore Policy Controller.

Signer vos commits Git

Prouvez que c’est bien vous qui avez écrit le code, pas quelqu’un qui a compromis votre compte.

# Installer gitsign
brew install sigstore/tap/gitsign

# Configurer Git pour utiliser gitsign
git config --global commit.gpgsign true
git config --global gpg.format x509
git config --global gpg.x509.program gitsign

# Vos commits seront maintenant signés automatiquement
git commit -m "feat: nouvelle fonctionnalité"

👉 Guide gitsign

Cosign Signature keyless avec Sigstore

SLSA Framework Niveaux de maturité supply chain

Niveau 4 : Gestion continue

Objectif : opérationnaliser la sécurité supply chain à l’échelle.

Temps estimé : continu (mise en place initiale : 1-2 mois).

Comprendre le problème

Vous gérez 50 microservices, chacun avec son SBOM, ses vulnérabilités, ses images signées. Une nouvelle CVE critique est publiée. Question : quels services en production sont affectés ?

Sans centralisation, répondre prend des heures — vérifier chaque repo, chaque SBOM, chaque déploiement. Avec les bons outils, la réponse prend quelques secondes.

L’autre défi est le bruit. Un scanner qui remonte 500 CVE dont 480 ne vous concernent pas est inutile. Vous avez besoin de qualifier les vulnérabilités pour vous concentrer sur les vrais risques.

Les concepts clés

Graphe de dépendances : GUAC et Dependency-Track construisent un graphe reliant vos artefacts, leurs SBOM, leurs vulnérabilités et leurs attestations. Une requête comme “quels pods utilisent log4j ?” devient triviale.

VEX (Vulnerability Exploitability eXchange) : un document standardisé qui indique si une CVE vous affecte réellement. “Oui, on a log4j, mais le code vulnérable n’est jamais exécuté dans notre configuration” — c’est un VEX not_affected.

Conformité CRA/NIS2 : le Cyber Resilience Act européen (2027) impose des SBOM, des délais de correction, des notifications d’incidents. Anticiper maintenant évite la panique plus tard.

Mettre en pratique

Centraliser les données de sécurité

GUAC agrège vos SBOM, vulnérabilités et attestations SLSA dans un graphe interrogeable. Dependency-Track offre une alternative plus mature avec une interface web complète.
Terminal window
```
# Démarrer GUAC localement
git clone https://github.com/guacsec/guac.git
cd guac
make start-compose

# Ingérer un SBOM
guacone collect files sbom.json

# Interroger : quels artefacts sont affectés par CVE-2023-xxxx ?
guacone query vuln CVE-2023-44487
```
Alternative : Dependency-Track (plus mature, interface web complète).

👉 Guide GUAC
Automatiser la qualification VEX

Toutes les CVE ne vous concernent pas. Un document VEX (Vulnerability Exploitability eXchange) indique si une CVE s’applique réellement à votre contexte.
vex.json
```
{
  "statements": [{
    "vulnerability": "CVE-2023-44487",
    "status": "not_affected",
    "justification": "vulnerable_code_not_in_execute_path",
    "statement": "Le code HTTP/2 vulnérable n'est pas utilisé dans notre déploiement"
  }]
}
```
Cela réduit le bruit des scanners et permet de se concentrer sur les vrais risques.

👉 Guide VEX
Préparer la conformité CRA/NIS2

Si vous vendez des logiciels en Europe, le Cyber Resilience Act (2027) impose :
- SBOM obligatoire pour chaque produit
- Correction des vulnérabilités dans des délais définis
- Notification des incidents sous 24h
Commencez maintenant à structurer vos processus.

👉 Guide CRA
Évaluer les dépendances avant adoption

Avant d’ajouter une nouvelle dépendance, vérifiez :
Terminal window
```
# Score OpenSSF Scorecard
scorecard --repo=github.com/express/express

# Vérifier : mainteneurs actifs ? Tests ? Releases signées ?
```
Critères minimum :
- Score Scorecard > 5/10
- Dernière release < 6 mois
- Au moins 2 mainteneurs actifs
- Historique de réponse aux CVE

Checklist rapide

Imprimez cette checklist et cochez au fur et à mesure.

Action	Niveau	Priorité	Fait
Générer un SBOM	1	🔴 Critique	☐
Scanner les vulnérabilités	1	🔴 Critique	☐
Activer Dependabot/GitLab Security	1	🔴 Critique	☐
Épingler les versions	1	🔴 Critique	☐
Auditer les workflows CI/CD	2	🟠 Haute	☐
Épingler les actions sur SHA	2	🟠 Haute	☐
Permissions minimales	2	🟠 Haute	☐
Scanner les secrets (Gitleaks)	2	🟠 Haute	☐
Signer les images (Cosign)	3	🟡 Moyenne	☐
Attestations SLSA	3	🟡 Moyenne	☐
Vérification K8s (Kyverno)	3	🟡 Moyenne	☐
Signer les commits (gitsign)	3	🟡 Moyenne	☐
Déployer GUAC/Dependency-Track	4	🟢 Avancé	☐
Automatiser VEX	4	🟢 Avancé	☐
Conformité CRA	4	🟢 Avancé	☐

Parcours par rôle

Selon votre fonction, priorisez différemment.

Votre impact : vous êtes en première ligne pour intégrer les bonnes pratiques dès l’écriture du code.

Actions prioritaires :

Épingler les dépendances dans vos fichiers de lock
Pre-commit hooks : Gitleaks pour les secrets, Trivy pour les vulnérabilités
Comprendre le SBOM de votre projet : syft . -o table
Signer vos commits avec gitsign

Temps : 1 heure de setup, puis intégré à votre workflow quotidien.

Erreurs fréquentes à éviter

Pour aller plus loin

Une fois le niveau 4 atteint, vous avez une supply chain mature. Continuez avec :

Sigstore : l'écosystème complet Cosign, Fulcio, Rekor — signature keyless expliquée

Framework SLSA Atteindre les niveaux de maturité SLSA 1 à 3