Points clés
- 80 à 90 % du code d'une application moderne est du code tiers (bibliothèques, frameworks, dépendances) — dont une fraction significative présente des vulnérabilités connues.
- La chaîne de dépendances (supply chain) applicative est un vecteur d'attaque croissant : compromettre une bibliothèque populaire permet d'atteindre des milliers d'applications.
- Les dépendances abandonnées (unmaintained) représentent un risque spécifique — les vulnérabilités découvertes ne seront jamais corrigées par leur mainteneur.
- Un programme de gestion des dépendances incluant inventaire, scoring de risque et processus de mise à jour est la réponse structurelle à ce risque.
La prévalence du code tiers dans les applications modernes
Une application web moderne typique repose sur des centaines de dépendances directes et transitives. Une application Node.js avec un nombre modéré de dépendances directes peut embarquer des milliers de packages npm via ses dépendances transitives. Une application Java Spring Boot inclut des dizaines de bibliothèques, elles-mêmes dépendantes d'autres bibliothèques. Cette pyramide de dépendances signifie que la surface de vulnérabilités potentielles dépasse largement ce que l'équipe de développement peut surveiller manuellement.
La base de données de vulnérabilités CVE (Common Vulnerabilities and Exposures) reçoit entre 25 000 et 30 000 nouvelles entrées par an. Une fraction significative concerne des bibliothèques de développement open source couramment utilisées. La question n'est pas si une dépendance utilisée est vulnérable, mais lesquelles le sont et avec quel niveau de risque pour le contexte spécifique de l'application.
Les attaques sur la chaîne de dépendances (supply chain)
Les attaques sur la chaîne d'approvisionnement logicielle (software supply chain attacks) ciblent le processus de distribution des bibliothèques plutôt que les applications elles-mêmes. En compromettant un package populaire — par injection de code malveillant, par typosquatting (publication d'un package avec un nom similaire), ou par prise de contrôle du compte du mainteneur — un attaquant peut atteindre simultanément des milliers d'applications qui utilisent ce package.
L'incident event-stream (2018) illustre cette technique : un attaquant a obtenu les droits de publication d'un package npm populaire et y a injecté un code malveillant ciblant les portefeuilles Bitcoin. Le package était téléchargé des millions de fois par semaine. L'attaque SolarWinds a appliqué la même logique à un niveau supérieur, en compromettant le processus de build du logiciel Orion lui-même.
Les dépendances abandonnées comme risque spécifique
Une vulnérabilité dans une bibliothèque activement maintenue sera généralement corrigée dans un délai raisonnable après sa divulgation — la question est alors la rapidité de mise à jour de l'application utilisatrice. Une vulnérabilité dans une bibliothèque abandonnée (plus de maintien actif, archives GitHub non mises à jour depuis des années) ne sera jamais corrigée par son mainteneur. L'application dépendante doit soit migrer vers une alternative maintenue, soit implémenter elle-même la correction, soit documenter le risque résiduel et mettre en place des compensations.
L'identification des dépendances abandonnées dans une codebase est réalisable via des outils SCA qui croisent l'inventaire des dépendances avec les bases de données de statut de maintenance. Cette identification doit faire partie du processus de revue annuelle des dépendances et alimenter le registre des risques applicatifs.
Le programme de gestion des dépendances
Un programme de gestion des dépendances applicatives efficace comprend : un inventaire automatisé (SBOM — Software Bill of Materials) généré et maintenu à jour pour chaque application en production ; un scoring de risque qui combine la sévérité des vulnérabilités connues, leur exploitabilité dans le contexte de l'application, et la criticité des données traitées ; un processus de mise à jour avec des SLA définis par niveau de criticité (vulnérabilité critique : patch sous 48h, haute : sous 7 jours, moyenne : sous 30 jours) ; et un mécanisme d'alerte automatique lors de la publication de nouvelles vulnérabilités dans les dépendances inventoriées.
Des outils comme Dependabot (GitHub), Renovate, Snyk ou OWASP Dependency-Track permettent d'automatiser une grande partie de ce programme, en générant automatiquement des pull requests de mise à jour et en alertant sur les nouvelles vulnérabilités. L'automatisation est indispensable à l'échelle d'un portfolio applicatif significatif.