90% des services Java en production prsentent un risque de vulnrabilit, selon le rapport DevSecOps de Datadog. Le rapport State of DevSecOps 2024 de Datadog dtaille les vulnrabilits des services Java et le bruit des analyses de scurit.
DevSecOps signifie dveloppement, scurit et oprations. Il s’agit d’une approche de la culture, de l’automatisation et de la conception des plateformes qui intgre la scurit comme une responsabilit partage tout au long du cycle de vie informatique.
Malgr la croissance de l’adoption de DevSecOps au cours des dernires annes, il existe des lacunes importantes dans la scurisation des dploiements cloud. Datadog a publi son rapport State of DevSecOps 2024, dvoilant des informations cls sur l’adoption des pratiques DevSecOps et les dfis auxquels les organisations sont confrontes pour scuriser les dploiements dans le cloud.
Datadog prsente son rapport en dclarant :
L’envoi de code scuris rapidement et grande chelle est un dfi pour toute l’industrie du logiciel, comme le montrent les informations continues sur les violations de donnes et les vulnrabilits critiques qui font la une. Pour relever ce dfi, les organisations adoptent de plus en plus DevSecOps, une pratique dans laquelle les dveloppeurs d’applications travaillent en troite collaboration avec les quipes d’exploitation et de scurit tout au long du cycle de dveloppement. DevSecOps envisage la scurit des applications de manire globale, en reconnaissant que le code doit tre scuris non seulement dans la manire dont il est crit, mais aussi dans la manire dont il est dploy et excut en production.
Nous avons analys des dizaines de milliers d’applications et d’images de conteneurs, ainsi que des milliers d’environnements cloud, afin d’valuer le niveau de scurit des applications actuelles et l’adoption des meilleures pratiques qui sont au cur de DevSecOps – infrastructure en tant que code, dploiements cloud automatiss, pratiques de dveloppement d’applications scurises et utilisation d’informations d’identification dure de vie courte dans les pipelines CI/CD.
Nos conclusions dmontrent que les pratiques DevOps modernes vont de pair avec des mesures de scurit solides – en fait, la scurit contribue l’excellence oprationnelle. Notre tude montre galement que si la scurit commence par la visibilit, la scurisation des applications n’est raliste que lorsque les praticiens bnficient d’un contexte et d’une hirarchisation suffisants pour se concentrer sur ce qui compte, sans se perdre dans le bruit.
Voici les rsultats de l’tude en 7 faits :
FAIT 1 : Les services Java sont les plus touchs par les vulnrabilits des tiers
En analysant le niveau de scurit d’une srie d’applications crites dans diffrents langages de programmation, ils ont constat que les services Java sont les plus touchs par les vulnrabilits des tiers : 90 % des services Java sont vulnrables une ou plusieurs vulnrabilits critiques ou de haute svrit introduites par une bibliothque tierce, contre une moyenne de 47 % pour les autres technologies.
Les services Java sont galement plus susceptibles d’tre vulnrables des exploits rels dont l’utilisation par les attaquants est documente. L’Agence amricaine pour la cyberscurit et la scurit des infrastructures (CISA) tient une liste permanente des vulnrabilits exploites dans la nature par des acteurs menaants, le catalogue KEV (Known Exploited Vulnerabilities). Cette liste, mise jour en permanence, est un bon moyen d’identifier les vulnrabilits les plus importantes que les attaquants exploitent activement pour compromettre les systmes. partir des vulnrabilits figurant dans cette liste, ils ont constat que les services Java sont surreprsents : 55 % des services Java sont touchs, contre 7 % de ceux qui sont conus l’aide d’autres langages.
Cette surreprsentation se vrifie mme lorsqu’on se concentre sur des catgories spcifiques de vulnrabilits – par exemple, 23 % des services Java sont vulnrables l’excution de code distance (RCE), ce qui affecte 42 % des organisations. La prvalence des vulnrabilits ayant un impact dans les bibliothques Java les plus rpandues – notamment Tomcat, Spring Framework, Apache Struts, Log4j et ActiveMQ – peut expliquer en partie ces chiffres levs. Les vulnrabilits les plus courantes sont les suivantes
- Spring4Shell (CVE-2022-22965)
- Log4Shell (CVE-2021-45046 et CVE-2021-44228)
- Un RCE dans Apache ActiveMQ (CVE-2023-46604)
L’hypothse est renforce lorsque l’on examine l’origine de ces vulnrabilits. En Java, 63 % des vulnrabilits importantes et critiques proviennent de dpendances indirectes, c’est–dire de bibliothques tierces qui ont t indirectement intgres l’application. Ces vulnrabilits sont gnralement plus difficiles identifier, car les bibliothques supplmentaires dans lesquelles elles apparaissent sont souvent introduites dans une application sans qu’on le sache.
Il est donc essentiel de prendre en compte l’arbre de dpendance complet, et pas seulement les dpendances directes, lors de l’analyse des vulnrabilits d’une application. Il est galement essentiel de savoir si toute nouvelle dpendance ajoute une application est bien entretenue et si elle met frquemment jour ses propres dpendances. Des cadres tels que l’OpenSSF Scorecard sont utiles pour valuer rapidement la sant des bibliothques open source.
Jeff McJunkin, Fondateur de Rogue Valley Information Security et instructeur SANS :
La surface d’attaque de votre organisation ne se limite pas au code public que vous avez crit, elle englobe galement les dpendances de vos applications, qu’elles soient directes ou indirectes. Comment suivez-vous les vulnrabilits dans ces dpendances ? En outre, tes-vous en mesure d’alerter rapidement en cas de compromission ? Comment limiter les dgts ? Si la plupart des vulnrabilits ne mritent pas d’tre considres comme prioritaires, celles qui prsentent un fort potentiel d’exploitation se trouvent souvent dans des applications surprivilgies avec des informations d’identification longue dure de vie, ce qui accrot leur gravit potentielle.
FAIT 2 : Les tentatives d’attaque des scanners de scurit automatiss sont pour la plupart des bruits qui ne peuvent pas tre pris en compte.
Ils ont analys un grand nombre de tentatives d’exploitation contre des applications dans diffrentes langues. Ils ont constat que les attaques provenant de scanners de scurit automatiss reprsentent de loin le plus grand nombre de tentatives d’exploitation. Ces scanners sont gnralement des outils open source que les attaquants tentent d’utiliser grande chelle, en scannant l’ensemble de l’internet pour identifier les systmes vulnrables. Nuclei, ZGrab et SQLmap sont des exemples populaires de ces outils.
Ils ont constat que la grande majorit des attaques effectues par les scanners de scurit automatiss sont inoffensives et ne gnrent que du bruit pour les dfenseurs. Sur les dizaines de millions de requtes malveillantes que nous avons identifies en provenance de ces scanners, seulement 0,0065 % ont russi dclencher une vulnrabilit. Cela montre qu’il est essentiel de disposer d’un cadre solide pour la hirarchisation des alertes afin de permettre aux dfenseurs de surveiller efficacement les journaux bruts des serveurs web ou les alertes du pare-feu d’application web (WAF) du primtre. L’intgration de renseignements sur les menaces et du contexte d’excution des applications dans les dtections de scurit peut aider les organisations filtrer les menaces les plus critiques.
FAIT 3 : Seule une petite partie des vulnrabilits identifies mrite d’tre traite en priorit
En 2023, plus de 4 000 vulnrabilits importantes et 1 000 vulnrabilits critiques ont t identifies et inventories dans le cadre du projet CVE (Common Vulnerabilities and Exposures). Les recherches de Datadog ont permis de constater qu’un service moyen est vulnrable 19 de ces vulnrabilits. Toutefois, selon des recherches universitaires antrieures, seuls 5 % environ des vulnrabilits sont exploites par des attaquants dans la nature.
Compte tenu de ces chiffres, il est facile de comprendre pourquoi les praticiens sont submergs par la quantit de vulnrabilits auxquelles ils sont confronts, et pourquoi ils ont besoin de cadres de priorisation pour les aider se concentrer sur ce qui est important. Ils ont analys un grand nombre de vulnrabilits et calcul un score ajust bas sur plusieurs facteurs supplmentaires afin de dterminer la probabilit et l’impact d’une exploitation russie :
- Le service vulnrable est-il expos publiquement l’internet ?
- Est-il excut en production, par opposition un environnement de dveloppement ou de test ?
- Existe-t-il un code d’exploitation disponible en ligne ou des instructions sur la manire d’exploiter la vulnrabilit ?
Ils ont galement pris en compte le score du systme de prdiction des exploits (Exploit Prediction Scoring System – EPSS), en accordant plus de poids aux vulnrabilits qui ont obtenu un score plus lev pour cette mesure. Ils ont appliqu cette mthodologie toutes les vulnrabilits afin d’valuer combien d’entre elles resteraient critiques sur la base de leur score ajust. Ils ont constat qu’aprs l’application de notre notation ajuste, 63 % des organisations qui avaient des vulnrabilits avec une gravit CVE critique n’ont plus de vulnrabilits critiques. Par ailleurs, 30 % des organisations ont vu leur nombre de vulnrabilits critiques rduit de moiti ou plus.
Pour dterminer les vulnrabilits traiter en priorit, les organisations doivent adopter un cadre qui leur permette d’valuer de manire cohrente la gravit du problme. En rgle gnrale, une vulnrabilit est plus grave si
- le service concern est expos publiquement
- la vulnrabilit est exploite en production
- Un code d’exploitation est accessible au public.
Bien que d’autres vulnrabilits puissent encore prsenter un risque, elles ne devraient tre traites qu’aprs les problmes qui rpondent ces trois critres.
FAIT 4 : Les images de conteneurs lgers entranent moins de vulnrabilits
En matire de dveloppement de logiciels et de scurit, le moins est souvent le mieux. C’est particulirement vrai dans le contexte des dpendances tierces, telles que les images de base des conteneurs. Il existe gnralement plusieurs options pour choisir une image de base, notamment :
- Utiliser une image de grande taille base sur une distribution Linux classique, telle qu’Ubuntu
- Utiliser une image plus fine base sur une distribution lgre, telle que Alpine Linux ou BusyBox
- L’utilisation d’une image sans distribution, qui ne contient que le temps d’excution minimum ncessaire l’excution de l’application – et parfois, rien d’autre que l’application elle-mme.
En analysant des milliers d’images de conteneurs, ils ont constat que plus une image de conteneur est petite, moins elle est susceptible de prsenter de vulnrabilits, probablement parce qu’elle contient moins de bibliothques tierces. En moyenne, les images de conteneurs de moins de 100 Mo prsentent 4,4 vulnrabilits leves ou critiques, contre 42,2 pour les images de 250 500 Mo, et prs de 80 pour les images de taille suprieure.
Cela dmontre que dans les environnements conteneuriss, l’utilisation d’images lgres est une pratique essentielle pour minimiser la surface d’attaque, car elle permet de rduire le nombre de bibliothques tierces et de paquets du systme d’exploitation dont dpend une application. En outre, les images lgres permettent de rduire les besoins en stockage et le trafic rseau, ainsi que d’acclrer les dploiements. Enfin, les images de conteneurs lgers permettent de minimiser les outils la disposition d’un attaquant, y compris les utilitaires systme tels que curl ou wget, ce qui rend l’exploitation de nombreux types de vulnrabilits plus difficile.
Jay Beale, PDG de la socit de conseil InGuardians :
Lorsque je joue le rle de l’acteur de la menace dans des environnements de conteneurs comme Kubernetes, les images de conteneurs construites sur distroless rendent ma journe plus difficile.
FAIT 5 : L’adoption de l’infrastructure en tant que code est leve, mais varie d’un fournisseur de cloud l’autre
Le concept d’infrastructure en tant que code (IaC) a t introduit dans les annes 1990 avec des projets tels que CFEngine, Puppet et Chef. Aprs que l’informatique en nuage ait gagn en popularit, l’IaC est rapidement devenue une norme de facto pour l’approvisionnement des environnements en nuage. L’IaC prsente des avantages considrables pour les oprations, notamment le contrle des versions, la traabilit et la reproductibilit entre les environnements. Sa nature dclarative aide galement les quipes DevOps comprendre l’tat souhait, plutt que de lire d’interminables scripts bash dcrivant comment y parvenir.
L’IaC est galement considre comme une pratique essentielle pour la scurisation des environnements de production en nuage, car elle permet de garantir que :
- Toutes les modifications sont examines par des pairs
- Les oprations humaines ont des permissions limites sur les environnements de production, puisque les dploiements sont grs par un pipeline CI/CD.
- Les organisations peuvent analyser le code IaC pour dtecter les configurations faibles, ce qui les aide identifier les problmes avant qu’ils n’atteignent la production.
Ils ont constat que sur AWS, plus de 71 % des organisations utilisent l’IaC par le biais d’au moins une technologie IaC populaire telle que Terraform, CloudFormation ou Pulumi. Ce chiffre est infrieur dans Google Cloud, avec 55 %.
Il est noter qu’ils n’ont pas pu faire de rapport sur Azure, car les journaux d’activit Azure ne consignent pas les agents utilisateurs HTTP.
Sur AWS et Google Cloud, Terraform est la technologie la plus populaire, juste avant les outils IaC spcifiques au cloud, savoir CloudFormation et Google Deployment Manager.
FAIT 6 : Les dploiements manuels dans le nuage sont encore trs rpandus
Les humains, heureusement, ne sont pas des machines, ce qui signifie qu’on est condamns faire des erreurs. Un lment majeur du contrle de la qualit, et par extension de la scurit, est l’automatisation des tches rptitives qui peuvent tre retires des mains de l’homme.
Dans les environnements de production en nuage, un pipeline CI/CD est gnralement charg de dployer les modifications apportes l’infrastructure et aux applications. L’automatisation qui a lieu dans ce pipeline peut tre ralise avec des outils IaC ou par des scripts utilisant des outils spcifiques aux fournisseurs de cloud.
L’automatisation garantit que les ingnieurs n’ont pas besoin d’un accs privilgi permanent l’environnement de production, et que les dploiements sont correctement suivis et examins par les pairs. L’oppos de cette meilleure pratique, savoir l’excution manuelle d’actions partir de la console cloud, est souvent dsign sous le nom d’oprations par clics ou ClickOps.
En analysant les journaux CloudTrail, ils ont identifi qu’au moins 38 % des organisations dans AWS avaient utilis ClickOps dans tous leurs comptes AWS dans une fentre de 14 jours prcdant la rdaction de cette tude. Selon la dfinition de Datadog, cela signifie que ces organisations ont dploy des charges de travail ou pris des mesures sensibles manuellement via la console de gestion AWS – y compris dans leurs environnements de production – au cours de cette priode.
FAIT 7 : L’utilisation d’identifiants dure de vie courte dans les pipelines CI/CD est encore trop faible.
Dans les environnements cloud, les fuites d’informations d’identification longue dure de vie sont l’une des causes les plus courantes des violations de donnes. Les pipelines CI/CD augmentent cette surface d’attaque car ils disposent gnralement d’autorisations privilgies et leurs informations d’identification peuvent fuir par le biais d’une journalisation excessive, de dpendances logicielles compromises ou d’artefacts de construction, comme dans le cas de la violation de Codecov. L’utilisation d’identifiants courte dure de vie pour les pipelines CI/CD est donc l’un des aspects les plus critiques de la scurisation d’un environnement en nuage.
Cependant, ils ont constat qu’un nombre important d’organisations continuent utiliser des informations d’identification long terme dans leurs environnements AWS, mme dans les cas o des informations d’identification court terme seraient la fois plus pratiques et plus sres. Parmi les organisations utilisant les actions GitHub, soit plus de 31 % des organisations fonctionnant sur AWS, nous avons constat que seulement 37 % utilisent exclusivement une authentification sans cl base sur des informations d’identification court terme et OpenID Connect (OIDC). Par ailleurs, 63 % ont utilis au moins une fois des utilisateurs IAM (une forme d’authentification long terme) pour authentifier les pipelines GitHub Actions, tandis que 42 % ont utilis exclusivement des utilisateurs IAM.
L’utilisation de l’authentification sans cl dans les pipelines CI/CD est plus facile mettre en place et plus sre. Une fois de plus, cela montre que les bonnes pratiques oprationnelles tendent galement conduire de meilleurs rsultats en matire de scurit.
propos de Datadog
La plateforme SaaS de Datadog intgre et automatise la surveillance de l’infrastructure, la surveillance de la performance des applications, la gestion des journaux, la surveillance de l’utilisateur rel et de nombreuses autres capacits afin de fournir une observabilit et une scurit unifies et en temps rel pour l’ensemble de la pile technologique de ses clients.
Source : « State of DevSecOps 2024 » (Datadog)
Et vous ?
Pensez-vous que ce rapport est crdible ou pertinente ?
Quel est votre avis sur le sujet ?
Voir aussi :