Les attaques de la chaîne d'approvisionnement logicielle

Plutôt que d'attaquer une cible directement, les attaquants visent un maillon en amont : une dépendance open source, un composant, un fournisseur de logiciel, un pipeline de build. Une seule compromission peut toucher des milliers d'organisations, comme l'ont montré plusieurs incidents majeurs.

Compromettre un fournisseur, une bibliothèque open source ou un outil de build pour atteindre, d'un coup, tous ceux qui l'utilisent. À lire aussi : Protéger une API · DevOps CI/CD · Rançongiciels.

01 — De quoi on parle

Les attaques de la chaîne d'approvisionnement logicielle, en clair

Plutôt que d'attaquer une cible directement, les attaquants visent un maillon en amont : une dépendance open source, un composant, un fournisseur de logiciel, un pipeline de build. Une seule compromission peut toucher des milliers d'organisations, comme l'ont montré plusieurs incidents majeurs.

02 — Pourquoi c'est en vogue

Ce qui pousse le sujet

• Les logiciels modernes reposent sur des centaines de dépendances externes.
• Effet de levier énorme pour l'attaquant : un point d'entrée, des milliers de victimes.
• Réglementations qui imposent désormais un « inventaire des composants » (SBOM).

03 — Ce que ça change

Les effets concrets

• La sécurité ne s'arrête plus à son propre code : elle inclut ses fournisseurs et ses dépendances.
• Montée des pratiques : SBOM, signatures, provenance des artefacts, revue des dépendances.
• Exigences contractuelles de sécurité vis-à-vis des fournisseurs.

04 — Comment s'y prendre

Par où commencer

• Tenir un inventaire des composants (SBOM) et des dépendances, et le mettre à jour.
• Épingler les versions, vérifier les signatures, surveiller les vulnérabilités connues.
• Limiter les droits des pipelines de build et isoler les secrets.
• Évaluer la sécurité des fournisseurs critiques et prévoir un plan de repli.

05 — Points de vigilance

Ce qu'il faut garder en tête

• Impossible d'auditer chaque dépendance : il faut prioriser les plus critiques.
• Les mises à jour automatiques peuvent aussi introduire du code malveillant.
• La confiance dans un fournisseur ne dispense pas de contrôles.

06 — Questions fréquentes

Questions fréquentes

Qu'est-ce qu'un SBOM ?

Un « Software Bill of Materials » : la liste des composants et dépendances d'un logiciel, pour savoir ce qu'on exécute et réagir vite en cas de faille.

Faut-il éviter l'open source ?

Non : il est partout et souvent bien maintenu. Il faut le gérer : inventaire, versions épinglées, veille, signatures.

Par où commencer ?

Inventorier ses dépendances et fournisseurs critiques, épingler les versions, et surveiller les vulnérabilités.

07 — Ressources & liens

Où aller, concrètement