Une application moderne contient rarement plus de quelques pourcents de code écrit par vos équipes. Le reste vient de bibliothèques tierces, elles-mêmes dépendantes d’autres bibliothèques.
La question n’est donc pas seulement « mon code est-il sûr », mais « qu’est-ce que j’exécute exactement ».
Le problème des dépendances transitives
Vous choisissez dix bibliothèques. Chacune en utilise vingt. Celles-ci en utilisent d’autres. Une application courante embarque ainsi plusieurs centaines de composants, dont vous n’avez explicitement choisi qu’une infime partie.
Trois conséquences concrètes :
Vous ne savez pas ce que vous exécutez. Lorsqu’une vulnérabilité critique est publiée sur un composant très répandu, la première question est « l’utilisons-nous ? » — et la plupart des organisations mettent des jours à y répondre.
Vous héritez de la sécurité d’inconnus. Une bibliothèque maintenue par une seule personne bénévole peut être abandonnée, ou son compte de publication compromis.
La surface évolue sans décision. Une mise à jour mineure peut introduire de nouvelles dépendances que personne n’a validées.
La nomenclature logicielle
La réponse structurante est la nomenclature des composants — souvent désignée par l’acronyme anglais SBOM. C’est l’inventaire, lisible par machine, de tout ce que contient un logiciel : composants, versions, licences, relations de dépendance.
Son intérêt principal est la rapidité de réponse. Avec une nomenclature à jour, répondre à « sommes-nous concernés » prend quelques minutes au lieu de plusieurs jours — et cette différence détermine si vous corrigez avant ou après l’exploitation.
Deux formats se sont imposés dans les échanges entre organisations. Ce qui compte moins que le format : que la nomenclature soit générée automatiquement à chaque construction, et non rédigée à la main. Une nomenclature manuelle est périmée dès sa publication.
Point pratique : exigez la nomenclature de vos fournisseurs de logiciels. C’est de plus en plus courant dans les appels d’offres, et cela relève de la même logique que la maîtrise de la chaîne d’approvisionnement.
Les attaques propres à cette chaîne
La compromission d’un composant légitime. Un attaquant prend le contrôle du compte de publication d’une bibliothèque et diffuse une version piégée. Elle est installée automatiquement par tous ceux qui mettent à jour.
Le typosquattage. Publication d’un paquet au nom proche d’un composant populaire, en pariant sur une faute de frappe.
La confusion de dépendances. Lorsqu’un gestionnaire de paquets peut résoudre un nom depuis un dépôt interne ou un dépôt public, un attaquant publie un composant de même nom en version supérieure sur le dépôt public. L’outil, cherchant la version la plus récente, récupère la version malveillante.
La parade principale : configurer explicitement les dépôts autorisés et interdire la résolution mixte. C’est une mesure de configuration, pas un outil.
La compromission de la chaîne de construction. Plus rare et plus grave : l’attaquant modifie le processus qui produit le logiciel. Le code source reste propre, le binaire livré ne l’est pas.
Ce qu’il faut mettre en place
Verrouiller les versions
Un fichier de verrouillage fige les versions exactes, y compris transitives. Sans cela, deux constructions successives peuvent produire des logiciels différents.
Contrôler l’origine
Passer par un dépôt interne servant de miroir, avec une liste de composants autorisés. Cela règle la confusion de dépendances et donne un point de contrôle.
Analyser en continu
Confronter la nomenclature aux vulnérabilités publiées, à chaque construction et en continu ensuite — une bibliothèque saine aujourd’hui ne le sera pas éternellement.
Priorisez les résultats : une vulnérabilité dans une dépendance non atteignable depuis votre code n’a pas la même urgence qu’une faille exposée. C’est la même logique que dans la priorisation par exploitation réelle.
Surveiller la santé des composants
Date de dernière mise à jour, nombre de mainteneurs, réactivité aux signalements. Une bibliothèque critique maintenue par une seule personne inactive depuis deux ans est un risque même sans vulnérabilité connue.
Sécuriser la chaîne de construction
Les serveurs d’intégration disposent d’accès étendus et de secrets. Ils doivent être traités comme des systèmes d’administration — voir le cloisonnement par niveaux et la gestion des secrets.
Le cas des logiciels achetés
Le raisonnement s’applique aussi à ce que vous n’avez pas développé. Trois exigences à porter au contrat :
- La fourniture d’une nomenclature à chaque version livrée.
- Un engagement de correction avec des délais selon la criticité.
- Une notification lorsque l’éditeur découvre qu’un composant qu’il utilise est vulnérable.
Voir les clauses de sécurité à prévoir.
Ce que demandent les référentiels
ISO/IEC 27002:2022 traite ces sujets par les mesures 8.28 (codage sécurisé) et 8.30 (développement externalisé), toutes deux introduites ou renforcées dans la révision 2022, ainsi que 8.8 pour la gestion des vulnérabilités et 8.19 pour l’installation de logiciels.
L’article 21 de NIS 2 cite explicitement la sécurité de l’acquisition, du développement et de la maintenance des systèmes.
Le test qui ne trompe pas
Une vulnérabilité critique vient d’être publiée sur une bibliothèque très répandue. Combien de temps vous faut-il pour dire si vous l’utilisez, où, et dans quelle version ?
Si la réponse se compte en jours, la nomenclature est le chantier à ouvrir. Si elle se compte en minutes, le dispositif fonctionne.
Ce test est aussi un excellent scénario d’exercice, plus réaliste et moins spectaculaire qu’un scénario de rançongiciel.
Sources
- ISO/IEC 27002:2022, mesures 8.8, 8.19, 8.28 et 8.30
- OWASP — analyse des dépendances
- CISA — Known Exploited Vulnerabilities Catalog
- CERT-FR
Aller plus loin
L’examen de vos chaînes de construction et de vos dépendances fait partie de l’audit 360 et de nos missions de sécurité offensive sur périmètre applicatif.