Par où commencer avec la supply chain security

XZ Utils, Polyfill.io, tj-actions : les attaques récentes montrent que la supply chain logicielle ne concerne plus seulement les dépendances open source, mais aussi les pipelines CI/CD, les registres, les actions tierces et les artefacts publiés. L’objectif n’est pas de tout sécuriser d’un coup, mais de commencer par les contrôles qui réduisent réellement le risque.

Cette page vous aide à identifier votre problème principal, choisir la bonne rubrique, et passer à l’action cette semaine — sans vous perdre dans un guide exhaustif.

Les 4 portes d’entrée

Selon votre situation actuelle, commencez par la rubrique qui correspond à votre besoin prioritaire.

1. Vous manquez de visibilité sur vos composants

Symptôme : vous ne savez pas exactement ce qui compose vos artefacts, ni ce qui tourne réellement en production.

Commencez par :

SBOM de A à Z Inventorier tous vos composants

xBOM : l'écosystème complet Build, runtime, services, crypto, IA

VEX Qualifier les vulnérabilités

Syft Générer des SBOM en CLI

2. Votre pipeline est votre point faible

Symptôme : vos workflows CI/CD utilisent des actions taguées, ont des permissions trop larges, ou manipulent des secrets sans contrôle strict.

Commencez par :

OWASP Top 10 CI/CD Les 10 risques majeurs des pipelines

Hardening build Linux Sécuriser votre environnement de build

Gouvernance du code source Contrôler qui peut modifier quoi

Gitleaks Scanner les secrets dans le code

3. Vous voulez garantir l’intégrité de vos artefacts

Symptôme : impossible de prouver que vos images Docker viennent bien de vous, ni qu’elles ont été construites par votre pipeline légitime.

Commencez par :

Sigstore L'écosystème de signature keyless

Cosign Signer vos images conteneurs

in-toto Attestations de provenance

Provenance SLSA Niveaux de maturité

4. Vous devez évaluer, décider et vous conformer

Symptôme : vous adoptez des dépendances sans critères clairs, vous ne savez pas comment évaluer vos fournisseurs, ou vous devez préparer CRA/NIS2.

Commencez par :

OpenSSF Scorecard Évaluer la posture d'un projet

Sécuriser les dépendances Critères d'adoption

Kusari Automatiser les décisions go/no-go

TPRM technique Évaluer vos fournisseurs tiers

Auto-évaluation rapide

Répondez à ces 6 questions pour identifier vos lacunes et la rubrique à consulter en priorité.

Question	Si non, allez vers
Savez-vous ce qui compose vos artefacts (SBOM) ?	Inventaires et BOM
Savez-vous ce qui tourne réellement en production ?	xBOM / OBOM
Vos pipelines peuvent-ils être modifiés ou détourner des secrets ?	OWASP Top 10 CI/CD
Vérifiez-vous l’intégrité et la provenance de vos artefacts ?	Signer, attester, vérifier
Évaluez-vous vos dépendances et fournisseurs avant adoption ?	Évaluer et décider
Avez-vous identifié vos obligations CRA / NIS2 ?	Guide CRA

Les 5 quick wins à faire cette semaine

Pas le temps de tout lire ? Ces 5 actions réduisent immédiatement votre surface d’attaque.

Générez un SBOM sur un projet critique
Fenêtre de terminal
```
syft . -o cyclonedx-json > sbom.json && syft . -o table
```
Découvrez les dépendances transitives que vous ignoriez.
Scannez ce SBOM pour les CVE critiques
Fenêtre de terminal
```
grype sbom:sbom.json --fail-on critical
```
Corrigez d’abord les Critical et High.

Auditez vos workflows CI/CD

Remplacez les actions taguées par des SHA immuables :

# ❌ Dangereux
- uses: actions/checkout@v4

# ✅ Sécurisé
- uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11

Activez le scan de secrets
Fenêtre de terminal
```
gitleaks detect --source . -v
```
Intégrez en pre-commit ou en CI pour bloquer les PR contenant des secrets.
Définissez une règle simple

“Aucune image de production non signée ne sera déployée d’ici 6 mois.”

C’est un objectif clair qui oriente les prochaines étapes.

Parcours conseillé par rôle

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

Cette semaine :

Épinglez vos dépendances (versions exactes dans les lock files)
Installez un pre-commit hook Gitleaks
Lancez syft . -o table pour visualiser votre SBOM
Signez vos commits avec gitsign

Lectures prioritaires : SBOM, Gitleaks, gitsign

Checklist minimale

Action	Priorité	Fait
Générer un SBOM sur un projet critique	🔴 Critique	☐
Scanner les vulnérabilités (Grype, Trivy)	🔴 Critique	☐
Activer Dependabot ou GitLab Security	🔴 Critique	☐
Épingler les versions de dépendances	🔴 Critique	☐
Auditer les permissions CI/CD	🟠 Haute	☐
Épingler les actions GitHub sur SHA	🟠 Haute	☐
Scanner les secrets (Gitleaks)	🟠 Haute	☐
Signer les images (Cosign)	🟡 Moyenne	☐
Générer des attestations SLSA	🟡 Moyenne	☐
Déployer GUAC ou Dependency-Track	🟢 Avancé	☐

Conformité : ce qu’il faut savoir maintenant

Le Cyber Resilience Act (CRA) européen formalise l’importance du SBOM et de la documentation supply chain :

11 septembre 2026 : obligations de reporting des vulnérabilités
11 décembre 2027 : entrée en application des obligations principales (SBOM, délais de correction, notification d’incidents sous 24h)

Commencer maintenant vous donne 18 mois pour structurer vos processus sans précipitation.

Où aller ensuite

xBOM : l'écosystème complet Comprendre les inventaires au-delà du SBOM

Framework SLSA Atteindre les niveaux de maturité 1 à 3

GUAC Graphe de dépendances et corrélation

TPRM technique Évaluer vos fournisseurs tiers