Risques de chaîne d'approvisionnement
Pourquoi le CRA s’y intéresse
L’essentiel du code d’un produit moderne n’a pas été écrit par son fabricant. Le règlement en tire la conséquence : il impose un inventaire, une diligence à l’intégration, et une remontée des vulnérabilités à l’amont. La chaîne d’approvisionnement est le sujet, le SBOM n’en est que l’instrument.
Typologie des attaques
| Type | Mécanisme | Cas documenté | Ce qui aurait aidé |
|---|---|---|---|
| Compromission d’un dépôt ou d’un mainteneur | Vol d’identifiants, prise de contrôle d’un compte de publication | ua-parser-js, oct. 2021 | Vérification de signature, épinglage d’empreintes |
| Compromission de la chaîne de construction | Injection dans l’environnement de build du fournisseur | SolarWinds, déc. 2020 · CCleaner, sept. 2017 | Attestations de provenance, builds reproductibles |
| Typosquattage | Paquet au nom proche d’un paquet légitime | Campagnes récurrentes sur les registres publics | Registre proxy interne, liste d’autorisation |
| Confusion de dépendances | Un paquet public prend le pas sur un paquet interne homonyme | Travaux de recherche, févr. 2021 | Espaces de noms réservés, priorité de résolution explicite |
| Paquet malveillant publié | Code hostile dès la première version | event-stream, nov. 2018 | Revue humaine des nouvelles dépendances, période de quarantaine |
| Vulnérabilité massive dans une bibliothèque ubiquitaire | Un défaut dans un composant présent partout | Log4Shell, déc. 2021 | SBOM centralisé : réponse en minutes au lieu de semaines |
| Porte dérobée par ingénierie sociale de long terme | Un contributeur gagne la confiance du projet, puis introduit un défaut subtil | xz / liblzma, mars 2024 | Diversité des mainteneurs, revue, builds reproductibles |
| Compromission d’un fournisseur commercial | Le produit tiers légitime devient un vecteur | 3CX, mars 2023 · Kaseya, juil. 2021 | Segmentation, moindre privilège, surveillance comportementale |
| Reprise d’un composant abandonné | Un tiers prend le contrôle d’un projet délaissé | polyfill.io, juin 2024 | Surveillance du changement de mainteneur |
| Détournement d’une étape de la chaîne de construction | Une action de CI réutilisée est repointée vers du code malveillant | tj-actions, mars 2025 | Épinglage par empreinte, moindre privilège des jetons |
Chaque cas est documenté, daté et sourcé dans Incidents de référence : ce qui s’est produit, ce qui aurait limité l’impact, et l’exigence du règlement que l’incident éclaire.
Ce que le SBOM permet — et ne permet pas
Permet : savoir instantanément quels produits et quelles versions livrées contiennent un composant donné. C’est la capacité de réponse, et elle transforme une crise de plusieurs semaines en une journée de travail.
Ne permet pas : détecter du code malveillant. Un paquet hostile correctement inventorié apparaît comme n’importe quel autre. Le SBOM répond à « qu’y a-t-il dedans », pas à « est-ce sain ».
Il faut donc le compléter par la vérification de provenance, la signature, la revue des nouvelles dépendances et le durcissement de la chaîne de construction.
Les contre-mesures
Sur les dépendances
- Registre proxy interne : toutes les dépendances transitent par un miroir contrôlé, jamais directement depuis un dépôt public.
- Épinglage de versions et verrouillage d’empreintes : le fichier de verrouillage est commité, et la construction échoue si une empreinte diffère.
- Espaces de noms réservés pour vos paquets internes, dans le registre public le cas échéant, afin de prévenir la confusion de dépendances.
- Quarantaine : une nouvelle dépendance n’est disponible qu’après un délai et une revue.
- Revue humaine des ajouts et des mises à jour majeures de dépendances sensibles.
Sur la chaîne de construction
Le sujet est traité en détail dans Sécuriser la chaîne de construction ; en résumé :
- Runners isolés, éphémères, sans accès réseau sortant non maîtrisé.
- Moindre privilège sur les jetons de publication ; jetons éphémères plutôt que secrets de longue durée.
- Séparation entre la construction et la publication.
- Attestations de provenance signées par le service de construction, pas par l’auteur du commit.
- Builds reproductibles, à terme, pour permettre la vérification indépendante.
Sur la détection
- Surveillance du changement de mainteneur et de licence sur les dépendances critiques.
- Analyse comportementale des scripts d’installation, qui sont un vecteur courant.
- Détection des écarts entre Build SBOM et Analyzed SBOM, qui révèle les introductions non déclarées.
Cartographier votre exposition
Un exercice à conduire une fois, puis à tenir à jour depuis la plateforme :
| Question | Ce qu’elle révèle |
|---|---|
| Quels composants sont présents dans plus de la moitié de vos produits ? | Les points de défaillance unique |
| Lesquels sont maintenus par une seule personne ? | Le risque de reprise ou d’abandon |
| Lesquels n’ont pas eu de publication depuis plus de deux ans ? | Les candidats à l’abandon |
| Lesquels sont profonds dans le graphe, hors de votre vue directe ? | Les angles morts de la diligence |
| Lesquels exécutent du code à l’installation ? | La surface d’attaque de la chaîne de build |
| Lesquels sont sous une licence à risque ou dont la licence a changé ? | Le risque juridique |
Cette cartographie n’a pas besoin d’être exhaustive pour être utile : les dix à vingt composants les plus critiques concentrent l’essentiel du risque, et leur traitement est finançable.
Le message pour la direction
Une attaque de chaîne d’approvisionnement ne se prévient pas entièrement. Ce qui se décide, c’est le temps de réaction. Sans inventaire centralisé, ce temps se compte en semaines et la réponse est incomplète ; avec, il se compte en heures et la réponse est exhaustive. C’est la valeur du dispositif, indépendamment de toute obligation réglementaire.