Selon les chiffres qui remontent du terrain, la surface d'attaque s'étend désormais à la chaîne d'approvisionnement logicielle, aux pipelines CI/CD et aux dépendances tierces intégrées à chaque étape du cycle de livraison. Pour les décideurs en cybersécurité, la question est de comprendre où se concentre le risque et comment le prioriser dans un environnement de plus en plus automatisé.
Le rapport State of DevSecOps 2026 de Datadog, fondé sur l'analyse de dizaines de milliers d'applications dans des milliers d'environnements cloud à l'échelle mondiale, établit un constat chiffré sans ambiguïté : 87 % des organisations présentent au moins une vulnérabilité exploitable connue dans leurs services déployés. Ce rapport paraît au moment où l'accélération des cycles de développement et la généralisation de l'automatisation ont profondément reconfiguré les vecteurs de risque. Les équipes DevSecOps subissent une double pression contradictoire.
Il doivent maintenir un rythme suffisant pour éviter l'accumulation de dette technique, tout en conservant le contrôle sur la qualité et l'intégrité du code introduit dans les pipelines de production. Andrew Krug, Head of Security Advocacy chez Datadog, articule ainsi cette dichotomie : « La manière dont le logiciel est développé a fondamentalement changé, mais les pratiques de sécurité n'ont pas suivi. » L'asymétrie entre vitesse de développement et maturité des pratiques de sécurité constitue le fil directeur du rapport.
L'indicateur le plus révélateur du rapport porte sur le vieillissement des dépendances logicielles. La dépendance médiane accuse désormais 278 jours de retard par rapport à sa dernière version stable, soit 63 jours de plus que l'année précédente. Ce glissement progressif traduit une réalité opérationnelle, les cycles de mise à jour sont systématiquement relégués derrière les priorités de livraison fonctionnelle. Les conséquences sont immédiates, 42 % des services s'appuient sur des bibliothèques abandonnées par leurs mainteneurs, privant ces composants de tout correctif de sécurité futur.
Corrélation entre version de langage et exposition aux failles
Le rapport établit une corrélation directe entre version de langage et exposition aux failles. Les services opérant sur des versions de langage en fin de vie présentent un taux de vulnérabilités exploitables de 50 %, contre 31 % pour les services fonctionnant sur des versions encore supportées. L'écart de 19 points matérialise le coût réel de la dette technique en termes de surface d'attaque. Les équipes Java se trouvent dans une position structurellement plus dégradée : 44 % des services Java contiennent au moins une vulnérabilité connue exploitable, avec un délai médian de correction de 62 jours pour les bibliothèques Maven, contre 19 jours pour les écosystèmes npm. Ce différentiel tient à la complexité des dépendances transitives dans les projets Java d'entreprise et à des cycles de validation plus longs dans les organisations qui maintiennent ces bases de code.
Sans cartographie continue des dépendances actives et de leur statut de support, l'évaluation objective du profil de risque applicatif est impossible. Selon le rapport, l'intégration d'outils d'analyse de composition logicielle (SCA) dans les pipelines CI/CD constitue aujourd'hui un prérequis à toute stratégie de résilience sérieuse, d'autant que les exigences NIS 2 et DORA renforcent l'obligation de traçabilité sur la chaîne logicielle.
Des modifications silencieuses de code tiers
L'automatisation des pipelines de build et de déploiement a introduit une catégorie de risque que les approches traditionnelles de la sécurité applicative ne couvrent pas — la compromission silencieuse via des actions CI/CD non épinglées. Datadog relève que seules 4 % des organisations verrouillent l'ensemble de leurs GitHub Actions publiques à une version spécifique via des commit hashes. Les 96 % restants s'exposent à un scénario documenté. Un acteur malveillant prend le contrôle du dépôt d'une action tierce, y pousse du code compromis, et toutes les organisations utilisant cette action via un tag versionné — plutôt qu'un hash de commit immuable — exécutent automatiquement le code malveillant au prochain déclenchement de pipeline.
En 2024, Datadog a identifié des milliers de bibliothèques PyPI et npm malveillantes, dont plusieurs résultaient de prises de contrôle de dépôts légitimes populaires — les cas Ultralytics, Solana web3.js et lottie-player illustrant une technique employée par des groupes étatiques comme par des cybercriminels. Le typosquatting complète cet arsenal. Créer un paquet imitant un paquet légitime, comme passports-js pour le vrai passport, exploite la difficulté structurelle pour les développeurs de valider l'intégrité des dépendances tierces dont la métadonnée et le comportement apparent semblent légitimes.
La réponse des équipes de sécurité combine plusieurs mesures complémentaires. L'épinglage systématique des actions CI/CD à des commit hashes immuables réduit mécaniquement la surface d'exposition aux prises de contrôle de dépôts tiers. L'adoption des mécanismes d'attestation de provenance disponibles sur npm et PyPI renforce la traçabilité des bibliothèques intégrées. Le déploiement d'outils d'analyse automatisée permet d'identifier le code malveillant avant installation. La mise en œuvre de ces pratiques reste marginale, créant une asymétrie exploitable à grande échelle.
Une stratégie de mise à jour accélérée
Face aux risques liés aux dépendances obsolètes, une part significative des équipes a adopté une stratégie de mise à jour accélérée. Datadog constate que 50 % des organisations intègrent les nouvelles versions de bibliothèques dans les 24 heures suivant leur publication. Cette réactivité génère un risque inverse — elle supprime le temps nécessaire à la communauté et aux équipes de sécurité pour analyser la nouvelle version avant son déploiement en production.
C'est dans cette fenêtre de quelques heures que surviennent certaines des attaques les plus efficaces sur la chaîne d'approvisionnement. Des recherches récentes montrent que des vulnérabilités critiques sont exploitées automatiquement dans les heures suivant leur divulgation publique. Pas moins de 88 % des organisations étudiées ont reçu des requêtes HTTP malveillantes non ciblées, et dans 65 % des cas d'exploitation avérée, le même attaquant avait ciblé la même URL dans plusieurs organisations simultanément. Le comportement des attaquants est massivement automatisé et opportuniste, ce qui rend la fenêtre d'exposition immédiate d'autant plus critique.
Pour les RSSI, la conclusion est inévitable : la vitesse de mise à jour seule ne constitue pas une politique de dépendances. Une politique efficace associe un délai de grâce contrôlé avant adoption des nouvelles versions, une analyse systématique de leur provenance, et une validation automatisée en environnement de pré-production avant promotion en production.
La surcharge d'alertes ralentit le traitement des menaces
Les équipes de sécurité font face à un volume croissant d'alertes classées « critiques » selon le score CVSS, indicateur de référence aveugle au contexte d'exécution de l'application concernée. Le service moyen présente désormais 13,5 vulnérabilités avec un score CVSS élevé ou critique, contre 11,9 l'année précédente. Ce volume alimente un épuisement opérationnel dans les équipes SOC, où la surcharge d'alertes ralentit le traitement des menaces.
Pour les décideurs en cybersécurité, l'écart entre criticité nominale et criticité contextuelle a des implications directes sur les ressources allouées à la remédiation. Le rapport souligne la conséquence organisationnelle de cette inflation d'alertes : « Quand presque tout est classé "critique", rien ne l'est vraiment. Les équipes reçoivent des alertes pour du bruit tandis que les menaces présentant un risque réel passent inaperçues. » L'adoption d'outils enrichissant les alertes CVSS avec du contexte d'exécution constitue un levier direct d'efficacité, au-delà des seules exigences de conformité réglementaire.
Risque pour les identifiant longue durée dans GitHub Actions
La gestion des identités dans les pipelines CI/CD constitue un quatrième vecteur de risque documenté par le rapport. Datadog relève que 37 % des organisations utilisant GitHub Actions pour déployer vers AWS s'appuient sur des IAM users, soit des identifiants de longue durée sans expiration automatique, plutôt que sur des identifiants éphémères via OpenID Connect (OIDC). La proportion utilisant OIDC progresse — 63 % en 2025 contre 58 % en 2024 — mais 58 % des organisations maintiennent simultanément des identifiants IAM de longue durée dans leurs pipelines, par inertie technique ou difficulté de migration.
Les pipelines CI/CD bénéficient fréquemment de permissions très étendues sur les environnements cloud cibles. La compromission d'un credential de longue durée dans ce contexte ouvre un accès durable à des ressources hautement sensibles. La migration vers OIDC est techniquement disponible et recommandée par les principaux fournisseurs cloud, mais elle constitue une dette organisationnelle significative pour la majorité des organisations, qui tardent à l'adresser malgré sa connaissance largement partagée dans la communauté sécurité.
Les résultats consolidés du rapport dessinent une surface d'attaque distribuée sur l'ensemble du cycle de livraison logicielle — dépendances tierces, pipelines CI/CD, gestion des identités. L'enjeu pour les équipes de sécurité porte sur la qualité des arbitrages. Réduire le bruit des alertes non contextualisées, définir des politiques de mise à jour différenciées selon le niveau de risque, et intégrer les pipelines d'automatisation dans le périmètre de sécurité au même titre que les applications elles-mêmes. Ces trois axes conditionnent la capacité des organisations à gérer un risque multidimensionnel.
