Securite de la supply chain logicielle
La dependance invisible
En 2026, les incidents supply chain ont augmente de 95 % par rapport a 2024 (2 526 incidents). Chaque logiciel moderne depend de centaines de composants tiers : bibliotheques open source, frameworks, outils de build. Chacun est un point d’entree potentiel.
La complexite de la supply chain logicielle moderne est vertigineuse. Une application web typique depend directement de quelques dizaines de packages, chacun ayant ses propres dependances. L’arbre total peut facilement atteindre des centaines ou des milliers de composants. La grande majorite de ces composants est maintenue par des individus ou de petites equipes, souvent sans ressources de securite dedicees.
SolarWinds (2020), XZ Utils (2024), et les multiples incidents de packages npm malveillants ont montre que des attaquants sophistiques sont prets a investir des mois voire des annees pour compromettre un composant largement utilise. La confiance que les organisations accordent a leurs dependances est une opportunite que les attaquants exploitent systematiquement.
Pourquoi c’est critique
- Effet multiplicateur : compromettre un seul composant touche tous ses utilisateurs (XZ Utils, SolarWinds)
- Confiance implicite : les developpeurs font confiance aux packages qu’ils installent
- Complexite : les arbres de dependances modernes contiennent des centaines de niveaux
- Detection difficile : le code malveillant est souvent cache dans les scripts de build, pas dans le code source
L’attaque XZ Utils illustre parfaitement le risque : un attaquant patient (Jia Tan) a passe deux ans a construire une reputation de mainteneur de confiance avant d’introduire une backdoor dans un utilitaire de compression utilise dans presque toutes les distributions Linux. La backdoor, tres sophistiquee, permettait un acces SSH non autorise. Elle a ete decouverte par hasard par un ingenieur Microsoft qui avait remarque une consommation CPU anormale.
Les types d’attaques supply chain
- Compromission de packages : injection de code dans npm, PyPI, crates.io (Shai-Hulud, GlassWorm)
- Backdoors dans les projets : contribution malveillante a un projet legitime (XZ Utils)
- Compromission CI/CD : injection dans les pipelines de build (Trivy/TeamPCP)
- Typosquatting : packages aux noms proches de packages populaires
- Compromission d’integrations SaaS : tokens OAuth voles (Drift, Salesloft)
Typosquatting et dependency confusion : des attaquants publient des packages avec des noms tres proches de packages populaires (colourama au lieu de colorama) ou exploitent la precedence des registres internes sur les registres publics. Des milliers de packages malveillants sont publies chaque semaine sur npm et PyPI.
Dependency confusion : technique decouverte par Alex Birsan en 2021 qui exploite la facon dont les gestionnaires de packages resolvent les conflits entre packages publics et prives. Un package public avec un nom identique a un package interne peut etre installe a la place du package legitime.
L’open source et le probleme de la maintenance
La majorite des composants open source sont maintenus par des benevoles sans compensation. Des projets critiques (OpenSSL, curl, Log4j) sont utilises par des milliards d’applications mais sont maintenus par une poignee de personnes.
Cette asymetrie entre criticite et ressources cree un risque structurel. Des initiatives comme l’Open Source Security Foundation (OpenSSF) et le programme Alpha-Omega cherchent a financer et securiser les projets open source les plus critiques.
Metriques de sante d’un composant open source :
- Activite recente des commits et des releases
- Nombre de mainteneurs actifs
- Presence d’une politique de securite (SECURITY.md)
- Score OpenSSF Scorecard
- Historique de gestion des vulnerabilites
Reglementation et conformite
Les reglements europeens NIS2 et le Cyber Resilience Act imposent aux organisations de maitriser leur supply chain logicielle. Le Cyber Resilience Act (CRA) exige notamment que les produits avec elements numeriques soient securises “by design and by default” et que les vulnerabilites soient traitees pendant toute la duree de vie du produit.
Aux Etats-Unis, l’Executive Order on Cybersecurity (2021) a impose le SBOM aux fournisseurs du gouvernement federal, creant un precedent qui se diffuse progressivement dans le secteur prive.
Cadre de references
SLSA (Supply-chain Levels for Software Artifacts) : framework de Google definissant 4 niveaux de securite pour les artefacts logiciels. SLSA 3 et 4 exigent la signature cryptographique des artefacts et l’attestation des buildpipelines.
SSDF (Secure Software Development Framework) : framework NIST (SP 800-218) pour le developpement logiciel securise, incluant des pratiques specifiques a la supply chain.
Sigstore : infrastructure open source pour la signature et la verification transparente des artefacts logiciels. Deja adopte par npm, PyPI, et les principaux ecosystemes.