Sécuriser sa chaîne d'approvisionnement logicielle (supply chain)
Votre logiciel n'est jamais 100 % le vôtre : il repose sur des dizaines, voire des milliers de composants tiers. Si l'un d'eux est compromis, vous l'êtes aussi — souvent sans l'avoir jamais choisi. C'est le risque de supply chain logicielle, et il est devenu l'un des vecteurs d'attaque les plus redoutés.
L'essentieldécideur Une attaque de supply chain consiste à compromettre un fournisseur ou un composant que vous utilisez, pour vous atteindre indirectement. Les cas SolarWinds (2020) et XZ Utils (2024) ont montré l'ampleur possible. La parade tient en quatre mots : inventorier (savoir ce qu'on utilise vraiment), vérifier l'origine, surveiller les vulnérabilités, réagir vite.
Le risque transitif : une dépendance compromise vous contamine
Quatre contrôles pour maîtriser sa chaîne logicielle
Comprendre le risque technique
Dépendances transitives. Vous installez lib-A, qui dépend de lib-B, qui dépend de lib-X. Vous n'avez jamais choisi lib-X, mais elle s'exécute chez vous. Si elle est piégée, l'attaquant entre — c'est tout l'enjeu du risque transitif.
Les vecteurs typiques :
Compromission d'un composant légitime (XZ Utils / CVE-2024-3094 : une backdoor introduite par un mainteneur infiltré).
Compromission de l'éditeur et de sa chaîne de build (SolarWinds / SUNBURST).
Typosquatting : un paquet malveillant nommé presque comme un paquet légitime.
Dependency confusion : un paquet public piégé qui prend le pas sur votre paquet interne.
Les contrôles qui marchent
1. SBOM (Software Bill of Materials). La liste complète et tenue à jour de tous vos composants et versions (formats CycloneDX ou SPDX). On ne sécurise que ce qu'on inventorie.
2. Provenance & signatures. Vérifier l'origine et l'intégrité des composants (Sigstore, attestations SLSA). Refuser ce qui n'est pas signé ou vérifiable.
3. Surveillance continue. Croiser votre SBOM avec les bases de vulnérabilités (NVD, OSV, GHSA) pour être alerté dès qu'une de vos dépendances est touchée.
4. Épinglage & maîtrise. Figer les versions (lockfiles), limiter les sources, remplacer les composants abandonnés.
Le paradoxe : plus on réutilise du code (ce qui est sain et productif), plus la surface de supply chain grandit. L'objectif n'est pas d'arrêter de réutiliser, mais de savoir ce qu'on exécute et de pouvoir réagir vite.
En pratique chez vous
Générez un SBOM de vos applications critiques (la plupart des outils de build savent le faire).
Branchez une surveillance des CVE sur ces composants — c'est précisément ce que FactualRisk suit côté supply chain (OSV, GHSA).
Posez des règles : sources autorisées, versions épinglées, revue des nouvelles dépendances.
Évaluez vos fournisseurs clés (c'est aussi une attente de NIS2 sur la sécurité de la chaîne d'approvisionnement).