Une application moderne est rarement construite uniquement avec le code produit par son équipe.
Elle dépend de bibliothèques open source, de frameworks, d’images Docker, de services cloud, d’API externes, de registres de packages et parfois de prestataires tiers.
Cette architecture accélère considérablement le développement, mais elle crée également un problème systémique : une vulnérabilité située en dehors du périmètre direct de l’organisation peut affecter toute son infrastructure.
L’ENISA souligne précisément cette évolution dans son Threat Landscape. Son analyse 2026 insiste sur le fait que les dépendances numériques élargissent la surface d'attaque. L'agence relève également que plus de 48 000 vulnérabilités ont reçu un identifiant CVE en 2025.
Le problème du « transitive dependency »
Prenons un projet qui dépend directement de dix bibliothèques.
Ces bibliothèques peuvent elles-mêmes dépendre de dizaines d'autres composants.
L'équipe ne gère donc pas réellement dix dépendances, mais potentiellement plusieurs centaines de composants indirects.
C'est pourquoi les pratiques modernes de sécurité logicielle utilisent notamment :
- Software Bill of Materials (SBOM) ;
- analyse SCA ;
- signature des artefacts ;
- provenance des packages ;
- verrouillage des versions ;
- scans automatisés ;
- surveillance des CVE ;
- politiques de mise à jour.
Le sujet dépasse largement le développeur.
Il concerne l'architecture, le CI/CD, la gouvernance et la gestion des fournisseurs.
Une question particulièrement importante pour l’Afrique
Dans des écosystèmes numériques où les ressources techniques peuvent être limitées, la réutilisation de composants open source est particulièrement importante.
Mais plus la dépendance à l'écosystème logiciel mondial augmente, plus il devient nécessaire de disposer de compétences locales capables d'auditer, maintenir et sécuriser ces composants.
La cybersécurité devient ainsi également une question de capacité technique.
Cybersécurité