87 % des organisations présentent au moins une vulnérabilité exploitable, et 40 % de leurs services sont concernés. Les services Java sont les plus touchés (59 %), suivis par les services .NET (47 %) et Rust (40 %). Dès lors que des vulnérabilités sont exploitées activement, la probabilité de compromission des services exposés augmente.

La mise à jour des langages et des environnements constitue le moyen le plus efficace d’éviter les vulnérabilités exploitables dans les applications et les services, et favorise la mise à jour des dépendances. Une fois qu’une application a plusieurs versions de retard, rattraper la dernière nécessite bien plus de temps, d’argent et d’efforts. Conséquence logique, l’opération est repoussée, jusqu’à ce que l’application finisse par tourner sur une version en fin de vie (EOL).

Nous avons constaté que 10 % des services reposent sur au moins une version EOL d’un langage ou d’un environnement d’exécution. Java se situe en milieu de peloton, avec 10 % des services qui utilisent une version EOL, contre 23 % pour Go et 13 % pour PHP.

En creusant, nous avons découvert que l’agressivité de la politique de fin de vie des langages peut avoir une influence sur les vulnérabilités. Par exemple, Go adopte une politique d’EOL très agressive, ce qui explique probablement son nombre de vulnérabilités supérieur aux autres langages. La durée de support d’une version de Go est d’un an, contre quatre ans pour une version de PHP. Lorsqu’une organisation utilise une version EOL d’un langage ou d’un environnement d’exécution, 50 % des services codés dans ce langage présentent une vulnérabilité exploitable, contre 37 % lorsqu’aucune version EOL n’est utilisée.

Les applications actuelles reposent sur de nombreuses dépendances tierces, chacune avec son propre cycle de mise à jour et ses propres risques de rupture de compatibilité. D’après notre étude, la dépendance médiane est en retard de 278 jours sur la dernière version majeure disponible, alors que ce retard était de 215 jours l’année dernière. Java et Ruby dépassent cette valeur médiane, avec un retard de respectivement 492 et 357 jours.

Les dépendances des services déployés moins d’une fois par mois sont 70 % plus en retard que celles des services déployés tous les jours, avec un retard médian de respectivement 295 jours et 172 jours. Ces chiffres montrent que la fréquence de déploiement fait office à la fois de métrique de productivité et de contrôle de sécurité important. En évaluant les mises à niveau d’une bibliothèque sur la base de métriques DevOps Research and Assessment (DORA), nous avons constaté qu’une vélocité et une stabilité de développement élevées sont corrélées à une posture de sécurité plus solide que celle des services dont les métriques DORA sont plus faibles.

Comme indiqué dans le Constat 1, les services et les dépendances à jour sont moins susceptibles de présenter des vulnérabilités. Cette année, nous avons examiné l’ancienneté des dépendances par rapport au nombre de vulnérabilités et avons constaté que les bibliothèques récentes comptent moins de vulnérabilités détectées. Par service, les bibliothèques publiées en 2025 présentent en moyenne 1,3 vulnérabilité, contre 1,9 en 2024 et 3,8 en 2023. Le pic de 2023 peut en grande partie être attribué à six CVE Spring Framework et Spring Boot affectant les services Java. La prévalence des vulnérabilités Java confirme ce que nous avons observé précédemment : les dépendances Java sont généralement les plus en retard.

L’édition 2026 de notre rapport ne porte que sur les services utilisant Datadog Software Composition Analysis, mais le pourcentage de services utilisant des bibliothèques qui ne sont plus activement maintenues et contiennent des vulnérabilités connues a peu varié d’une année sur l’autre Visiblement, elles ne constituent toujours pas une priorité pour les entreprises, peut-être en raison de la vélocité de développement des fonctionnalités et de l’accumulation de vulnérabilités à traiter. Vulnérabilités de sécurité, composants obsolètes et problèmes liés à la supply chain peuvent émerger et s’accumuler rapidement, et il devient alors difficile de déterminer quelles mises à jour sont urgentes.

Les vulnérabilités des bibliothèques sont inquiétantes, car elles peuvent être détectées dans toutes les versions, à tout moment. Une mise à jour régulière des bibliothèques réduit donc souvent le risque de rupture de la compatibilité et facilite les mises à jour ultérieures. Les tests de régression sont essentiels lors de ce processus, en particulier lors du passage à une version majeure. Dans un premier temps, l’augmentation de la couverture des tests d’une application permet de s’assurer de l’absence de changements entraînant une rupture de compatibilité ou d’identifier l’origine du problème.

La mise à jour automatique des logiciels paraît être une solution simple pour éviter les retards et les risques mentionnés dans les Constats 1 et 2. Mais avec les compromissions de la supply chain, la mise à jour vers une nouvelle version dans les 24 h suivant sa publication peut en réalité dégrader la sécurité globale d’une application, car le risque d’installer un malware sans le savoir est réel.

Notre étude précise ce risque en montrant que 50 % des organisations utilisent des bibliothèques tierces moins d’un jour après leur publication, que 12 % utilisent des AMI publiques et 32 % des images Docker publiques dans ce même délai. Même si elles sont moins souvent utilisées dans les 24 h suivant leur sortie, les AMI et images Docker présentent un impact potentiel plus important en cas de compromission, car elles disposent d’un accès plus large aux systèmes que les simples bibliothèques.

Bibliothèques

L’année dernière, nous avons assisté à plusieurs attaques de la supply chain à grande échelle, notamment s1ngularity et les deux attaques Shai-Hulud. Si ces attaques ont été possibles, c’est notamment parce que les entreprises ont utilisé des versions malveillantes de leurs bibliothèques, introduites par une installation dans les 24 h suivant leur publication. Pour sécuriser les dépendances, nous recommandons de verrouiller les versions des dépendances sur un SHA de commit complet. Si cela n’est pas possible, Yarn et pnpm, deux gestionnaires de packages JavaScript, proposent une nouvelle configuration imposant une ancienneté minimale pour l’installation des nouvelles versions des packages, ce qui laisse à d’autres personnes le temps de les utiliser. GitHub Dependabot permet d’ajouter une « temporisation » pour la même raison. L’idée est de mettre à jour les packages après un certain délai pour réduire le risque d’infection par un malware. Un délai d’une semaine pourrait par exemple empêcher l’expansion d’une majorité des dépendances compromises.

Si l’on va plus loin, 54 % des organisations qui utilisent JavaScript et 55 % des organisations qui utilisent Python ont installé une nouvelle version de bibliothèque moins d’un jour après sa sortie. Nous avons également constaté que 1,6 % des organisations qui utilisent npm ont installé au moins une dépendance infectée par un malware au cours de l’année passée. C’est un chiffre important à l’échelle de npm : des dizaines de milliers d’organisations ont potentiellement exécuté du code malveillant. Les attaques de la supply chain sont bel et bien une réalité opérationnelle en l’absence de mesures de sécurité appropriées.

AMI publiques

Début 2025, Datadog a publié une étude sur une attaque par confusion de nom d’image cloud ayant affecté des AWS Amazon Machine Images (AMI). Nous avons découvert que la récupération aveugle des toutes dernières AMI créées sans spécifier de propriétaire pourrait entraîner l’utilisation d’AMI infectées. En analysant les données plus en détail, nous avons constaté que 12 % des organisations ont utilisé au minimum une AMI moins d’un jour après sa création.

En réponse à cette étude, AWS a créé une fonctionnalité « Allowed AMIs », qui peut contribuer à empêcher ces attaques. Il est recommandé de s’en servir si vous utilisez une AMI communautaire. Si vous cherchez à savoir qui, dans votre organisation, a utilisé des AMI communautaires non vérifiées, vous pouvez créer un rapport avec l’outil open source whoAMI-scanner. Investigator.cloud est une autre ressource qui sert à explorer les AMI publiques et à retracer leur lignage.

Images Docker

Les bibliothèques et les AMI ne sont pas les seuls logiciels utilisés immédiatement après leur publication. 32 % des organisations ont déjà utilisé une image Docker publique moins d’un jour après sa création, ce qui pose également un risque de sécurité. Les recherches récentes se concentrent sur les bibliothèques et les AMI, et ont quelque peu occulté le risque posé par les conteneurs Docker, qui constituent pourtant un vecteur d’attaque depuis longtemps.

Chaque fois que c’est possible, assurez-vous que les images de conteneurs viennent de sources internes de confiance, en utilisant des tags « Trusted Content » dans Docker Hub (par exemple, Docker Official Images, Verified Creators et Sponsored OSS), afin de réduire le risque d’utiliser une image infectée par un malware. Si vous ne pouvez pas utiliser une image d’une source interne de confiance, envisagez de temporiser l’installation pour vous permettre de faire votre propre analyse et de laisser aux chercheurs le temps d’investiguer. Ces solutions ne sont pas infaillibles, mais elles peuvent vous aider à réduire le risque associé à l’utilisation d’une image publique.

L’année dernière, nous avons assisté à une augmentation des attaques de la supply chain à grande échelle utilisant GitHub Actions. Ces attaques utilisent différents moyens pour accéder aux dépôts et exfiltrer des données concernant à la fois les actions personnalisées et celles de la Marketplace GitHub. Par exemple, l’action changed-files développée par tj-actions a été compromise, et les hackers ont inséré une payload malveillante qui a conduit les dépôts publics touchés à écrire leurs secrets dans des logs de workflow.

Dans ce rapport, les actions de la Marketplace sont les actions disponibles publiquement sur la Marketplace de GitHub. Alors que le nombre de vulnérabilités touchant GitHub Actions est resté relativement constant, nous avons découvert que chaque organisation qui utilise GitHub Actions se sert d’au moins une action de la Marketplace, mais que seulement 4 % verrouillent le hachage pour toutes les actions de la Marketplace. De plus, 71 % des organisations ne verrouillent le hachage pour aucune de leurs actions. C’est risqué, car GitHub indique bien que la seule manière d’empêcher les mises à jour automatiques est de verrouiller une action sur un SHA de commit complet, comme indiqué dans le Constat 3.

En allant plus loin, nous avons découvert que 80 % des organisations utilisent au moins une action de la Marketplace non gérée par GitHub et non verrouillée sur un hachage de commit. Cette statistique s’explique peut-être par une méconnaissance de cette bonne pratique et par l’effort nécessaire pour mettre à jour le fichier YAML.

2 % des organisations qui utilisent GitHub Actions exécutent au moins une action qui a été compromise précédemment et n’est pas verrouillée sur un hachage de commit. Avec la fréquence accrue des actions compromises, ce chiffre devrait augmenter d’année en année, sauf si le verrouillage des actions sur un commit s’impose.

Les vulnérabilités critiques doivent être corrigées rapidement, mais uniquement lorsqu’elles sont vraiment critiques. La gravité des vulnérabilités, généralement mesurée par le score de base CVSS, constitue un bon point de départ, mais elle peut être ajustée en prenant en compte le contexte d’exécution et le contexte des CVE. Notre étude montre que seulement 18 % des vulnérabilités critiques des dépendances restent critiques une fois que le score de gravité a été ajusté, un chiffre identique à l’année dernière. Les vulnérabilités vraiment critiques diminuent de plus de 80 %, ce qui réduit considérablement le nombre d’alertes.

Cette année, nous souhaitions examiner davantage les données pour comprendre les différences d’un langage à l’autre. Nous avons ainsi appris que 98 % des vulnérabilités des dépendances .NET perdent leur caractère critique après analyse. Leur score EPSS moyen est en effet bien plus bas que pour d’autres langages, ce qui s’explique en partie par les fonctions de sécurité natives, comme Code Access Security, qui réduisent la probabilité d’exploitation À l’autre extrémité du spectre, 49 % des vulnérabilités PHP restent critiques, sans doute en raison de la forte disponibilité d’exploits publics et de la grande facilité d’exploitation de nombreuses bibliothèques de cet écosystème.

Le score de gravité Datadog utilisé pour ajuster le score CVSS initial dépend de quatre facteurs. Deux concernent le contexte d’exécution : la présence de la vulnérabilité en production et l’existence d’une attaque active contre le service concerné. Les deux autres sont dérivés du contexte des CVE : l’existence d’un exploit et la probabilité d’exploitation d’une vulnérabilité.

La priorisation excessive de toutes les vulnérabilités critiques peut mettre en difficulté les équipes, en les noyant sous les alertes et en accaparant leur attention aux dépens de vulnérabilités qui représentent un risque réel pour l’entreprise. Une meilleure priorisation permet aux équipes de corriger ce qui importe le plus, aux développeurs de gagner du temps et, au final, de réduire les coûts.

Nous avons constaté que le nombre moyen de vulnérabilités élevées ou critiques par application comportant au moins une vulnérabilité SCA a diminué, passant de 13,5 en 2025 à 8. Si cette tendance se maintient dans les années à venir, cela signifiera que la priorisation de la sécurité s’améliore.