L'attaque de la chaîne d'approvisionnement logicielle en une page

Pourquoi forcer mille portes quand on peut se faire livrer par le fournisseur, signature comprise, avec le bon de livraison et les remerciements du client ?

L’essentiel

• On attaque le fournisseur pour atteindre ses clients. Le code malveillant entre en amont (une dépendance, un outil de build, un serveur de mise à jour) et descend la chaîne avec le reste, porté par les mécanismes mêmes qui inspirent confiance : registre officiel, pipeline maison, signature de l’éditeur, mise à jour automatique.
• SolarWinds, 2020. Des attaquants installés dans l’environnement de build de l’éditeur ont glissé une porte dérobée (SUNBURST) dans les mises à jour du logiciel de supervision Orion, compilées et signées normalement. L’éditeur a estimé à moins de 18 000 le nombre de clients ayant installé une version piégée ; l’affaire a été découverte en décembre 2020.
• xz-utils, 2024 (CVE-2024-3094). Un contributeur a gagné en deux ans la confiance du projet jusqu’à en devenir comainteneur, puis a publié les versions 5.6.0 et 5.6.1 avec une porte dérobée visant le serveur SSH de certaines distributions Linux. Le code piégé était caché dans les archives publiées et les fichiers de test, pas lisible tel quel dans le dépôt. Un développeur l’a repérée fin mars 2024 en cherchant pourquoi SSH prenait une demi-seconde de trop, avant qu’elle n’atteigne les versions stables des grandes distributions.
• event-stream, 2018. Le mainteneur d’un paquet npm très utilisé, lassé, en a confié la maintenance à un volontaire, qui a ajouté une dépendance (flatmap-stream) contenant un code destiné à voler les portefeuilles d’une application de bitcoins précise. Personne n’avait rien piraté : on avait simplement demandé gentiment.
• Le typosquattage se passe de tout cela : publier lib-dates en comptant sur ceux qui voulaient lib-date, ou sur un outil qui l’invente à leur place.
• Les parades : versions verrouillées avec empreintes (fichier de verrouillage, aucune mise à jour silencieuse), SBOM (SPDX ou CycloneDX) pour savoir ce qui est embarqué et retrouver vite un composant mis en cause, signatures et attestations de provenance vérifiées avant installation (Sigstore pour signer, SLSA pour décrire et durcir la fabrication), builds reproductibles qui permettent à un tiers de retrouver le même binaire, et pipelines au moindre privilège (secrets courts, droits limités, pas d’accès au réseau inutile).
• Aucune ne suffit seule. Le verrouillage fige aussi une version déjà piégée, le SBOM inventorie sans juger, la signature atteste l’origine et rien d’autre. Ensemble, elles réduisent les occasions et accélèrent la détection.

Idées reçues, et fausses

• « L’open source est sûr parce que tout le monde lit le code. » Faux. Tout le monde peut le lire, ce qui n’a jamais obligé personne. xz-utils était maintenu presque seul par un bénévole épuisé, et la porte dérobée n’était pas là où l’on regarde. Elle a été trouvée par un utilisateur qui mesurait un temps de connexion, pas par une foule de relecteurs.
• « Signé veut dire sain. » Faux. Une signature prouve qui a produit l’artefact et qu’il n’a pas changé depuis. Les mises à jour piégées de SolarWinds étaient signées par SolarWinds, en bonne et due forme. Le cachet de la poste n’a jamais garanti le contenu de la lettre.
• « Nous n’utilisons que des paquets populaires. » Faux. event-stream l’était, c’est précisément pour cela qu’il intéressait. La popularité attire les attaquants plus qu’elle ne les décourage.
• « Nous avons un SBOM, donc nous sommes protégés. » Faux. Le SBOM est un inventaire. Il dit très bien ce que vous avez installé, y compris la version piégée, et il le dit vite, ce qui est déjà beaucoup le jour où l’alerte tombe.

Pour aller plus loin : La chaîne d’approvisionnement logicielle · Attaques supply chain et protection des dépendances · Maîtriser le risque des dépendances transitives · SLSA : niveaux Build, provenance in-toto et vérification · SBOM pour inventorier les composants réellement exécutés · Pourquoi les builds reproductibles échouent souvent · Sécuriser les secrets et permissions CI/CD.

À lire aussi

• Générer un SBOM CycloneDX dans un pipeline CIGénérer, distribuer et exploiter automatiquement une nomenclature logicielle avec Syft, Grype et une surveillance continue des vulnérabilités.
• Gérer les risques tiers et la chaîne logicielleCette page traite de la gestion des risques liés aux fournisseurs, dépendances et composants de la chaîne d'approvisionnement logicielle.
• Vérifier une chaîne de compilation reproductibleFondations de la compilation reproductible, des attaques de build et de la vérification moderne de la chaîne de compilation.
• Images Docker de base et confiance héritéeGérer la généalogie des images de base Docker pour maîtriser la confiance, les vulnérabilités et l'exploitation.

Pages voisines

L'attaque de la chaîne d'approvisionnement logicielle en une page

Elle cite

• Attaques supply chain et protection des dépendances
• La chaîne d'approvisionnement logicielle
• Maîtriser le risque des dépendances transitives (npm, pip, Maven, Go)
• Pourquoi les builds reproductibles échouent souvent
• SBOM pour inventorier les composants réellement exécutés
• Sécuriser les secrets et permissions CI/CD
• SLSA : niveaux Build, provenance in-toto et vérification