Comment proteger votre chaine d'approvisionnement logicielle en 7 etapes

— Etape 1 : Cartographier l'integralite de vos dependances

Avant de securiser quoi que ce soit, vous devez savoir exactement ce qui compose votre logiciel. C'est le principe fondamental de toute demarche de securite supply chain, et c'est aussi le point ou la majorite des organisations echouent. Selon une etude Synopsys de 2025, 96 % des bases de code commerciales contiennent du code open source, et en moyenne 77 % du code total d'une application provient de composants tiers.

La cartographie ne se limite pas a vos dependances directes — celles que vous declarez explicitement dans votre package.json, pom.xml ou requirements.txt. Elle doit couvrir l'ensemble de l'arbre de dependances transitives. Un projet Node.js moyen qui declare 30 dependances directes embarque souvent plus de 800 paquets transitifs. Chacun d'entre eux constitue une surface d'attaque potentielle.

Concretement, voici comment proceder :

• ▶ Inventoriez tous vos projets et repositories. Incluez les applications internes, les microservices, les scripts de deploiement, les images Docker et les outils de build. Un composant oublie dans un coin de votre GitLab peut devenir le vecteur d'une compromission.
• ▶ Analysez les dependances de chaque projet avec des outils comme OWASP Dependency-Check, Snyk Open Source, ou npm audit / pip-audit selon votre ecosysteme.
• ▶ N'oubliez pas les composants non declares : polices de caracteres, images, fichiers de configuration embarques, binaires pre-compiles, conteneurs de base. Tout composant externe est un maillon de votre supply chain.
• ▶ Documentez les fournisseurs SaaS et les API tierces. Un webhook vers Stripe, une integration Slack, un service d'envoi d'emails : chaque connexion externe est un vecteur potentiel.

L'objectif de cette premiere etape est d'obtenir une vue exhaustive de votre surface d'exposition. Sans cette visibilite, toutes les etapes suivantes reposent sur des fondations incompletes.

— Etape 2 : Generer et maintenir un SBOM (Software Bill of Materials)

Le SBOM est au logiciel ce que la liste d'ingredients est a l'alimentation : un inventaire structure, lisible par des machines, de tous les composants qui constituent votre application. Depuis l'Executive Order 14028 de la Maison Blanche en 2021, le SBOM est passe d'un concept theorique a une exigence reglementaire. En Europe, le Cyber Resilience Act (CRA) entre en application progressive et impose la fourniture d'un SBOM pour tout produit contenant des elements numeriques.

Deux formats dominent le marche :

Un SBOM n'a de valeur que s'il est maintenu. Un SBOM genere une fois et jamais mis a jour donne un faux sentiment de securite. Integrez la generation automatique du SBOM dans votre pipeline CI/CD : a chaque build, un nouveau SBOM est produit, versionne et stocke. Des outils comme Syft (Anchore), Trivy (Aqua Security) ou cdxgen (OWASP) permettent de generer des SBOM en quelques secondes directement dans vos workflows GitHub Actions, GitLab CI ou Jenkins.

Sur le plan reglementaire, la directive NIS2 — transposee en droit francais depuis octobre 2024 — impose aux entites essentielles et importantes de maitriser les risques lies a leur chaine d'approvisionnement. Cela passe concretement par la capacite a documenter, a tout moment, la composition de vos logiciels. Le SBOM est l'outil qui repond a cette exigence.

— Etape 3 : Implementer l'analyse de composition logicielle (SCA) en continu

L'analyse de composition logicielle (SCA — Software Composition Analysis) est le mecanisme qui donne vie a votre SBOM en le croisant avec les bases de donnees de vulnerabilites connues. Sans SCA, votre SBOM est un document statique. Avec SCA, il devient un radar qui vous alerte en temps reel lorsqu'une de vos dependances est affectee par une nouvelle CVE.

L'integration de la SCA dans votre pipeline CI/CD doit suivre une logique de quality gates progressifs :

Au-dela des vulnerabilites, la SCA couvre egalement la conformite des licences. Integrer une bibliotheque sous licence AGPL dans un produit commercial proprietaire peut avoir des consequences juridiques serieuses. Les outils SCA modernes comme Snyk, Black Duck ou FOSSA identifient automatiquement les conflits de licences et vous alertent avant qu'une decision technique ne devienne un probleme juridique.

Le point cle est la continuite. Un scan SCA realise une fois par trimestre ne suffit pas. En moyenne, 70 nouvelles vulnerabilites sont publiees chaque jour dans la base NVD. La dependance qui etait saine hier peut devenir critique demain. Seule une integration automatisee et continue garantit une detection dans des delais acceptables.

Avis d'expert

« La SCA est le minimum vital, pas le maximum. Trop d'organisations la considerent comme une corvee de conformite alors qu'elle devrait etre un reflexe de developpeur. Quand un scan SCA bloque une pull request, ce n'est pas un obstacle : c'est une vulnerabilite qui ne sera jamais deployee en production. Sur les missions d'audit que nous menons chez WebGuard Agency, nous constatons que les equipes qui integrent la SCA des la phase de developpement corrigent 3 fois plus vite que celles qui la subissent en fin de cycle. »

Sophie Marchand, Consultante en securite applicative — WebGuard Agency

— Etape 4 : Verifier l'integrite et la provenance du code

Savoir quels composants vous utilisez (etapes 1 et 2) et verifier qu'ils ne contiennent pas de vulnerabilites connues (etape 3) ne suffit pas. Vous devez egalement vous assurer que les composants que vous telecharges sont bien ceux que leurs auteurs ont publies — et qu'ils n'ont pas ete modifies en transit ou sur le registre.

L'attaque contre CodeArtifact en 2023 et les multiples campagnes de typosquatting sur npm et PyPI illustrent parfaitement ce risque. Les attaquants publient des paquets portant des noms proches de bibliotheques populaires (colorsss au lieu de colors), ou compromettent directement les comptes des mainteneurs pour injecter du code malveillant dans des versions legitimes.

Les mecanismes de verification d'integrite comprennent :

• ▶ Les lock files (package-lock.json, Pipfile.lock, go.sum) : ils fixent les versions exactes et les hash de chaque dependance. Commitez-les toujours dans votre repository et ne les regenerez jamais manuellement sans revue.
• ▶ La signature de code avec Sigstore : Sigstore (Cosign, Fulcio, Rekor) permet de signer et verifier les artefacts logiciels de maniere transparente et sans gestion de cles complexe. Les conteneurs, les binaires et les SBOM peuvent etre signes a chaque build.
• ▶ Les builds reproductibles : assurez-vous que deux compilations du meme code source produisent un binaire identique, bit a bit. Cela garantit qu'aucune injection n'a eu lieu pendant le processus de build.
• ▶ La verification GPG des commits : imposez la signature des commits dans vos branches protegees pour garantir la provenance de chaque modification de code.

— Etape 5 : Appliquer le principe Zero Trust a vos fournisseurs

Le modele de securite perimetrique — « tout ce qui est a l'interieur est de confiance » — a prouve ses limites depuis longtemps. Mais dans la supply chain logicielle, de nombreuses organisations continuent d'accorder une confiance implicite a leurs fournisseurs. Un prestataire SaaS a acces a votre API ? Il a probablement un token avec plus de permissions que necessaire. Un partenaire vous fournit un SDK ? Il tourne peut-etre avec les droits de votre application.

L'approche Zero Trust appliquee a la supply chain repose sur trois principes :

Concretement, mettez en place un processus d'evaluation des fournisseurs (vendor risk assessment) qui couvre : la securite de leurs pratiques de developpement, leurs certifications (ISO 27001, SOC 2), leur politique de notification des incidents, leur capacite a fournir un SBOM, et les clauses de droit d'audit dans vos contrats. Des plateformes comme SecurityScorecard ou BitSight permettent un monitoring continu de la posture de securite de vos partenaires.

— Etape 6 : Mettre en place une politique de reponse aux incidents supply chain

Meme avec les meilleures defenses, un incident supply chain peut survenir. La question n'est pas « si » mais « quand ». La difference entre une organisation resiliente et une organisation paralysee se joue dans la preparation. Un plan de reponse aux incidents (IRP) specifique a la supply chain doit completer votre IRP general.

Ce plan doit couvrir plusieurs scenarios specifiques :

• ▶ Compromission d'une dependance open source : vous decouvrez qu'un paquet npm que vous utilisez contient du code malveillant. Votre plan doit prevoir l'identification rapide de tous les projets affectes (grace au SBOM), le rollback vers une version saine, et la communication aux equipes.
• ▶ Fuite de credentials d'un fournisseur SaaS : un partenaire vous informe que ses systemes ont ete compromis et que vos tokens d'acces ont potentiellement ete exfiltres. Votre plan doit prevoir la rotation immediate des secrets, la revocation des acces, et l'audit des actions realisees avec les credentials compromis.
• ▶ Injection dans votre pipeline CI/CD : un attaquant compromet votre systeme de build pour injecter une backdoor dans vos artefacts. Votre plan doit prevoir la verification d'integrite de tous les builds recents, la reconstruction depuis des sources verifiees, et la notification des clients affectes.

Chaque scenario doit definir clairement : qui est responsable de quoi (matrice RACI), les canaux de communication (internes et vers les autorites — l'ANSSI en France impose un delai de notification de 24h pour les entites NIS2), les procedures techniques de containment et de remediation, et les criteres de retour a la normale.

Testez ce plan au moins une fois par an via des exercices de simulation (tabletop exercises). Un plan non teste est un plan qui ne fonctionne pas.

Avis d'expert

« Lors de nos audits, nous constatons que 80 % des organisations disposent d'un plan de reponse aux incidents generique, mais moins de 15 % ont un volet specifique a la supply chain. Or, un incident supply chain est fondamentalement different : il touche potentiellement des centaines de clients en cascade, les vecteurs de compromission sont indirects, et les delais de detection sont souvent bien plus longs. C'est justement cette specificite qui rend la preparation indispensable. »

Sophie Marchand, Consultante en securite applicative — WebGuard Agency

— Etape 7 : Former vos equipes et integrer la culture de securite supply chain

Les outils et les processus ne valent que ce que les personnes qui les utilisent en font. La derniere etape — et peut-etre la plus importante sur le long terme — consiste a ancrer la securite de la supply chain dans la culture de votre organisation.

Cela passe par plusieurs actions concretes :

• ▶ Former vos developpeurs aux risques supply chain. Ils doivent comprendre pourquoi il est dangereux d'ajouter une dependance sans l'evaluer, comment verifier la reputation d'un paquet avant de l'integrer, et quelles sont les bonnes pratiques de gestion des secrets dans le code.
• ▶ Mettre en place un programme de Security Champions. Identifiez un developpeur referent par equipe qui sera forme en profondeur sur la securite applicative et servira de relais au quotidien. Ce champion securite revoit les ajouts de dependances, challenge les choix techniques et remonte les alertes SCA aux bonnes personnes.
• ▶ Etablir une politique d'approbation des dependances. Toute nouvelle dependance devrait passer par un processus de validation : nombre de mainteneurs, frequence des mises a jour, couverture de tests, historique de vulnerabilites, licence compatible. Automatisez autant que possible avec des outils comme Socket.dev ou Phylum.
• ▶ Realiser des exercices de phishing et de social engineering cibles sur la supply chain. Simulez une tentative de compromission d'un compte npm, un email frauduleux se faisant passer pour un fournisseur, ou une pull request malveillante sur un projet interne. Mesurez les reactions et ameliorez la sensibilisation en continu.

La securite de la supply chain n'est pas un projet ponctuel : c'est un processus continu qui doit etre integre dans le quotidien de vos equipes, au meme titre que les tests unitaires ou les revues de code. Les organisations qui reussissent sont celles ou la securite est une responsabilite partagee, pas le domaine reserve d'une equipe isolee.

— Questions frequentes

— Pour aller plus loin

Approfondissez votre comprehension de la securite supply chain avec ces ressources complementaires :

• ▶ Attaques supply chain en entreprise : comprendre le risque — Analyse detaillee des vecteurs d'attaque et des cas recents.
• ▶ Comment se proteger contre les attaques supply chain — Strategies defensives et retours d'experience terrain.
• ▶ Analyse de composition logicielle (SCA) : guide complet — Tour d'horizon des outils et methodologies SCA.
• ▶ Publications de l'ANSSI — Guides et recommandations de l'agence nationale de securite.
• ▶ NIST Software Supply Chain Security — Framework et bonnes pratiques internationales.