Introduction
En 2026, la sécurité de la supply chain logicielle est devenue critique face à l'explosion des attaques comme SolarWinds (2020, impactant 18 000 organisations) ou Log4Shell (2021, vulnérabilité zero-day dans une dépendance Java). Ces incidents montrent que 80 % des breaches proviennent de tiers, selon le rapport Verizon DBIR 2025. Une supply chain insecure expose vos artefacts (packages npm, conteneurs Docker) à des malwares injectés en amont.
Ce tutoriel intermédiaire vous guide pas à pas : des menaces aux frameworks comme SLSA (Supply-chain Levels for Software Artifacts), en passant par des stratégies actionnables. Imaginez votre CI/CD comme une chaîne logistique physique : un maillon faible (dépendance compromise) contamine tout. Sécuriser cela réduit les risques de 70 % (selon Gartner). À la fin, vous saurez implémenter une politique robuste, bookmark-worthy pour tout lead DevSecOps.
Prérequis
- Connaissances de base en DevOps et CI/CD (GitHub Actions, Jenkins).
- Familiarité avec les conteneurs (Docker) et les registres (Docker Hub, ECR).
- Compréhension des SBOM (Software Bill of Materials) et des attaques en chaîne (ex. : XZ Utils 2024).
- Outils comme Sigstore ou Trivy pour les tests pratiques.
Comprendre les menaces principales
Les attaques sur la supply chain ciblent quatre phases : source, build, stage et deploy.
| Phase | Menace exemple | Impact |
|---|---|---|
| ------- | ---------------- | -------- |
| Source | Injection dans un repo tiers (npm typosquatting) | Code malveillant dans vos dépendances |
| Build | Compromission CI/CD (token GitHub volé) | Artefacts falsifiés |
| Stage | Poisoning de registre (Hugging Face 2024) | Images conteneurs infectées |
| Deploy | Runtime injection (via K8s manifests) | Exécution post-déploiement |
Adopter le framework SLSA
SLSA (prononcé 'salsa'), développé par Google, définit 4 niveaux de maturité pour sécuriser les artefacts logiciels. C'est un standard ouvert, adopté par GitHub et Cloud Native Computing Foundation.
| Niveau | Exigences clés | Exemple concret |
|---|---|---|
| ------- | ---------------- | --------------- |
| 0 | Basique (pas de protections) | Repo public sans signatures |
| 1 | Tamper-evident (logs immuables) | GitHub Actions avec provenance |
| 2 | Tamper-resistant (pas de nouveaux scripts) | Pipelines verrouillés, pas de bash dynamique |
| 3 | Trusted (tous inputs signés) | SLSA v1.0 pour conteneurs |
| 4 | Full (publishers hébergés) | Cosign + Rekor pour attestations |
Sécuriser phase par phase
Appliquez une défense en profondeur par phase.
1. Source :
- Générer des SBOM (via Syft ou CycloneDX) pour lister toutes dépendances.
- Politique : Auditer les vendors (score GitHub Security > 80/100).
2. Build :
- Utiliser des runners éphémères (GitHub-hosted).
- Checklist : Secrets scanning (TruffleHog), SLSA provenance.
3. Stage :
- Signer images (cosign) et scanner (Trivy, Grype).
- Mirror privé pour registres publics.
4. Deploy :
- Admission controllers K8s (Kyverno) pour valider signatures.
- Runtime monitoring (Falco).
Exemple concret : Chez Uber, implémentation SLSA + SBOM a détecté une vuln éphémère en 2h vs 48h manuellement.
Implémenter une politique globale
Créez une politique supply chain sous forme de charter :
- Gouvernance : Équipe DRI (Directly Responsible Individual) par projet.
- Audits : Trimestriels avec outils comme OpenSSF Scorecard (github.com/ossf/scorecard).
- Réponse : Playbook pour incidents (ex. : freeze des builds).
- Métriques : Taux de SBOM coverage >95 %, temps de détection <24h.
- Jour 1 : Inventory des dépendances (dependabot).
- Semaine 1 : SLSA niveau 1.
- Mois 1 : Signatures full.
Bonnes pratiques essentielles
- Toujours générer des SBOM : Intégrez-les nativement (npm ci --sbom).
- Signer tout : Cosign pour conteneurs, npm sigstore pour packages.
- Minimaliser la surface : Pinned versions (package-lock.json strict), zero-trust pour CI.
- Automatiser les scans : Gatekeeper en CI/CD (fail on vuln high).
- Diversifier fournisseurs : Pas plus de 20 % d'un même registry.
Erreurs courantes à éviter
- Ignorer les transitive deps : 70 % des vulns viennent d'elles ; utilisez
npm ls --depth=0. - Runners persistants : Faciles à compromettre ; préférez ephemeral.
- Pas de rotation secrets : Un leak Codecov coûte des millions.
- SBOM statiques seulement : Générez runtime SBOM pour conteneurs dynamiques.
Pour aller plus loin
Plongez dans les ressources officielles :
Découvrez nos formations Learni sur DevSecOps pour des ateliers pratiques SLSA et cas réels.