Comment auditer la supply chain logicielle de votre entreprise en 7 etapes

La supply chain logicielle est devenue le vecteur d attaque privilegie des acteurs etatiques et cybercriminels les plus sophistiques. SolarWinds en 2020, Codecov en 2021, 3CX en 2023, et plus recemment DAEMON Tools en mai 2026 : chaque annee apporte son lot d attaques ou des logiciels de confiance, distribues depuis des sources officielles, se revelent etre des chevaux de Troie. Pour les entreprises francaises soumises a NIS2, l audit de la supply chain logicielle n est plus un luxe mais une obligation reglementaire explicite.

Ce guide presente les 7 etapes operationnelles pour auditer la supply chain logicielle de votre entreprise, de l inventaire initial au monitoring continu. Chaque etape est accompagnee d outils concrets, de metriques de succes et de conseils de priorisation adaptes aux PME et ETI francaises.

— Etape 1 : dresser l inventaire complet avec un SBOM

Le SBOM (Software Bill of Materials) est la pierre angulaire de tout audit supply chain logicielle. Il s agit d un inventaire exhaustif de tous les composants logiciels utilises dans votre entreprise : bibliotheques open source, frameworks, SDK tiers, plugins, extensions et outils utilitaires. Sans SBOM, vous ne pouvez pas savoir ce que vous devez proteger.

Commencez par scanner l ensemble de vos environnements avec des outils comme Syft (open source, Anchore) ou Trivy (open source, Aqua Security). Ces outils analysent les fichiers de manifeste (package.json, pom.xml, requirements.txt, go.mod, Gemfile.lock) ainsi que les binaires deployes et les images de conteneurs. Le format de sortie recommande est CycloneDX 1.5 ou SPDX 2.3, les deux standards reconnus par l industrie et compatibles avec les exigences NIS2.

Pour une PME avec 20 a 50 applications metier, cette etape prend generalement 1 a 2 semaines. L objectif est d atteindre une couverture de plus de 95% du parc applicatif. N oubliez pas les logiciels utilitaires installes par les equipes IT (DAEMON Tools, WinRAR, 7-Zip, PuTTY, etc.) qui ne sont souvent pas dans la CMDB mais constituent des vecteurs d attaque, comme l actualite recente l a demontre.

— Etape 2 : analyser les dependances avec un SCA

Une fois le SBOM genere, l etape suivante est l analyse de composition logicielle (SCA - Software Composition Analysis). Il s agit de croiser chaque composant identifie avec les bases de donnees de vulnerabilites connues (NVD, OSV, GitHub Advisory Database) pour identifier les failles actives dans votre parc.

L outil de reference open source est OWASP Dependency-Track, qui ingere les SBOM CycloneDX et fournit un tableau de bord en temps reel des vulnerabilites par projet. Pour les equipes qui preferent une solution geree, Snyk, Sonatype Nexus Lifecycle ou JFrog Xray offrent des fonctionnalites supplementaires comme la remediation automatique et l integration CI/CD. L enjeu n est pas seulement de detecter les CVE critiques mais aussi d identifier les dependances transitives : une application peut n utiliser directement que 10 bibliotheques, mais ces 10 bibliotheques en importent 200 autres, dont certaines peuvent etre vulnerables ou abandonnees.

— Etape 3 : verifier les signatures et la provenance

L attaque DAEMON Tools de mai 2026 a demontre que la signature numerique seule ne suffit pas. Neanmoins, la verification de signature reste une couche de defense essentielle qu il faut completer, pas abandonner. L objectif de cette etape est de verifier que chaque composant logiciel provient bien de son editeur legitime et n a pas ete altere en transit.

Pour les artefacts de build (conteneurs, binaires), deployez Sigstore/Cosign pour signer et verifier les images de conteneurs dans votre pipeline CI/CD. Pour les packages open source, verifiez les signatures GPG sur les registres npm, PyPI et Maven Central. Pour les logiciels tiers (ERP, outils metier), demandez a vos fournisseurs leurs pratiques de signature et de distribution securisee. Documentez dans un registre les hash SHA-256 de chaque version validee par votre equipe securite : c est le hash pinning, qui vous permet de detecter toute modification ulterieure de l installeur ou du package.

— Etape 4 : scorer le risque de chaque fournisseur logiciel

Chaque composant logiciel tiers represente un niveau de risque different. L objectif de cette etape est d attribuer un score de risque a chaque fournisseur et composant pour prioriser les actions de remediation. Utilisez une matrice de scoring 5x5 qui croise deux axes : l impact en cas de compromission (donnees accedees, privileges, criticite operationnelle) et la probabilite de compromission (posture securite du fournisseur, historique de vulnerabilites, taille de l equipe de maintenance, age du dernier commit).

Pour chaque composant score en zone rouge ou orange, documentez les actions requises : mise a jour vers une version patchee, remplacement par une alternative, ajout de controles compensatoires (WAF, sandboxing, segmentation reseau) ou acceptation formelle du risque par la direction. Cette documentation est indispensable pour la conformite NIS2, qui exige une approche basee sur les risques et documentee.

— Etape 5 : tester l integrite des composants en production

L etape 5 consiste a verifier que ce qui tourne en production correspond effectivement a ce qui a ete valide par l equipe securite. C est la ou la plupart des attaques supply chain sont detectees trop tard : le composant a ete valide au moment de l installation, mais il a ete modifie depuis (mise a jour automatique compromise, injection post-deploiement, remplacement de binaire).

Mettez en place un processus de verification d integrite regulier. Pour les conteneurs, comparez les hash SHA-256 des images en production avec ceux du registre signe. Pour les binaires Windows, verifiez les signatures Authenticode et comparez les hash avec votre registre de hash pinning. Pour les applications web, surveillez les modifications du contenu statique (JavaScript, CSS) qui pourraient indiquer un compromis type Magecart. Des outils comme OSSEC, Wazuh ou Tripwire automatisent cette surveillance de l integrite des fichiers.

— Etape 6 : deployer un monitoring continu de la supply chain

L audit ponctuel ne suffit pas. Les vulnerabilites sont decouvertes quotidiennement, les mainteneurs de projets open source changent, les fournisseurs subissent des compromissions. Il faut un monitoring continu de votre supply chain logicielle. Configurez OWASP Dependency-Track pour ingerer automatiquement les SBOM a chaque build CI/CD et vous alerter en temps reel sur les nouvelles CVE affectant vos composants. Mettez en place des alertes sur les changements de mainteneur des projets open source critiques (via GitHub Watch ou des services comme Socket.dev).

Pour les fournisseurs commerciaux, utilisez des plateformes de notation cyber (SecurityScorecard, BitSight, RiskRecon) qui surveillent en continu la posture de securite de vos fournisseurs et vous alertent en cas de degradation. Completez avec une veille CTI (Cyber Threat Intelligence) sur les acteurs connus pour les attaques supply chain : groupes sinophones (APT41, Winnti), nord-coreens (Lazarus), et groupes cybercriminels russophones. Notre guide CTI cybersecurite et notre article sur la notation cyber des fournisseurs detaillent ces pratiques.

— Etape 7 : construire le plan de remediation et la gouvernance

La derniere etape transforme les resultats de l audit en un plan de remediation actionnable et une gouvernance perenne. Le plan doit inclure : la liste priorisee des composants a mettre a jour ou remplacer, les deadlines associees (CVE critique : 72 heures, CVE haute : 30 jours, CVE moyenne : 90 jours), les responsables par composant, et les procedures de validation post-remediation.

Cote gouvernance, formalisez une politique de gestion de la supply chain logicielle qui couvre : les criteres d acceptation d un nouveau composant tiers (vetting), le processus de mise a jour (frequence, tests, rollback), la gestion des composants en fin de vie (EOL), et les procedures d urgence en cas d attaque supply chain (playbook incident response). Integrez cette politique dans votre PSSI et votre dossier de conformite NIS2.

Pour approfondir chaque aspect de la supply chain security, consultez notre article sur les SBOM en entreprise, notre guide sur la securite de la supply chain logicielle et notre guide SCA.

— FAQ