90% des services Java présentent un risque de vulnérabilité, les images de conteneurs légers entraînent moins de vulnérabilités et l'adoption de l'IaC est élevée

Selon le rapport DevSecOps de Datadog

Le 26 avril 2024 à 22:40, par Jade Emy

62PARTAGES

90% des services Java en production présentent un risque de vulnérabilité, selon le rapport DevSecOps de Datadog. Le rapport State of DevSecOps 2024 de Datadog détaille les vulnérabilités des services Java et le bruit des analyses de sécurité.

DevSecOps signifie développement, sécurité et opérations. Il s'agit d'une approche de la culture, de l'automatisation et de la conception des plateformes qui intègre la sécurité comme une responsabilité partagée tout au long du cycle de vie informatique.

Malgré la croissance de l'adoption de DevSecOps au cours des dernières années, il existe des lacunes importantes dans la sécurisation des déploiements cloud. Datadog a publié son rapport State of DevSecOps 2024, dévoilant des informations clés sur l'adoption des pratiques DevSecOps et les défis auxquels les organisations sont confrontées pour sécuriser les déploiements dans le cloud.

Datadog présente son rapport en déclarant :

L'envoi de code sécurisé rapidement et à grande échelle est un défi pour toute l'industrie du logiciel, comme le montrent les informations continues sur les violations de données et les vulnérabilités critiques qui font la une. Pour relever ce défi, les organisations adoptent de plus en plus DevSecOps, une pratique dans laquelle les développeurs d'applications travaillent en étroite collaboration avec les équipes d'exploitation et de sécurité tout au long du cycle de développement. DevSecOps envisage la sécurité des applications de manière globale, en reconnaissant que le code doit être sécurisé non seulement dans la manière dont il est écrit, mais aussi dans la manière dont il est déployé et exécuté 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 sécurité des applications actuelles et l'adoption des meilleures pratiques qui sont au cœur de DevSecOps - infrastructure en tant que code, déploiements cloud automatisés, pratiques de développement d'applications sécurisées et utilisation d'informations d'identification à durée de vie courte dans les pipelines CI/CD.

Nos conclusions démontrent que les pratiques DevOps modernes vont de pair avec des mesures de sécurité solides - en fait, la sécurité contribue à l'excellence opérationnelle. Notre étude montre également que si la sécurité commence par la visibilité, la sécurisation des applications n'est réaliste que lorsque les praticiens bénéficient d'un contexte et d'une hiérarchisation suffisants pour se concentrer sur ce qui compte, sans se perdre dans le bruit.

Voici les résultats de l'étude en 7 faits :

FAIT 1 : Les services Java sont les plus touchés par les vulnérabilités des tiers

En analysant le niveau de sécurité d'une série d'applications écrites dans différents langages de programmation, ils ont constaté que les services Java sont les plus touchés par les vulnérabilités des tiers : 90 % des services Java sont vulnérables à une ou plusieurs vulnérabilités critiques ou de haute sévérité introduites par une bibliothèque tierce, contre une moyenne de 47 % pour les autres technologies.

Les services Java sont également plus susceptibles d'être vulnérables à des exploits réels dont l'utilisation par les attaquants est documentée. L'Agence américaine pour la cybersécurité et la sécurité des infrastructures (CISA) tient une liste permanente des vulnérabilités exploitées dans la nature par des acteurs menaçants, le catalogue KEV (Known Exploited Vulnerabilities). Cette liste, mise à jour en permanence, est un bon moyen d'identifier les vulnérabilités les plus importantes que les attaquants exploitent activement pour compromettre les systèmes. À partir des vulnérabilités figurant dans cette liste, ils ont constaté que les services Java sont surreprésentés : 55 % des services Java sont touchés, contre 7 % de ceux qui sont conçus à l'aide d'autres langages.

Cette surreprésentation se vérifie même lorsqu'on se concentre sur des catégories spécifiques de vulnérabilités - par exemple, 23 % des services Java sont vulnérables à l'exécution de code à distance (RCE), ce qui affecte 42 % des organisations. La prévalence des vulnérabilités ayant un impact dans les bibliothèques Java les plus répandues - notamment Tomcat, Spring Framework, Apache Struts, Log4j et ActiveMQ - peut expliquer en partie ces chiffres élevés. Les vulnérabilités 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'hypothèse est renforcée lorsque l'on examine l'origine de ces vulnérabilités. En Java, 63 % des vulnérabilités importantes et critiques proviennent de dépendances indirectes, c'est-à-dire de bibliothèques tierces qui ont été indirectement intégrées à l'application. Ces vulnérabilités sont généralement plus difficiles à identifier, car les bibliothèques supplémentaires 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 dépendance complet, et pas seulement les dépendances directes, lors de l'analyse des vulnérabilités d'une application. Il est également essentiel de savoir si toute nouvelle dépendance ajoutée à une application est bien entretenue et si elle met fréquemment à jour ses propres dépendances. Des cadres tels que l'OpenSSF Scorecard sont utiles pour évaluer rapidement la santé des bibliothèques 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 dépendances de vos applications, qu'elles soient directes ou indirectes. Comment suivez-vous les vulnérabilités dans ces dépendances ? En outre, êtes-vous en mesure d'alerter rapidement en cas de compromission ? Comment limiter les dégâts ? Si la plupart des vulnérabilités ne méritent pas d'être considérées comme prioritaires, celles qui présentent un fort potentiel d'exploitation se trouvent souvent dans des applications surprivilégiées avec des informations d'identification à longue durée de vie, ce qui accroît leur gravité potentielle.

FAIT 2 : Les tentatives d'attaque des scanners de sécurité automatisés 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 différentes langues. Ils ont constaté que les attaques provenant de scanners de sécurité automatisés représentent de loin le plus grand nombre de tentatives d'exploitation. Ces scanners sont généralement des outils open source que les attaquants tentent d'utiliser à grande échelle, en scannant l'ensemble de l'internet pour identifier les systèmes vulnérables. Nuclei, ZGrab et SQLmap sont des exemples populaires de ces outils.

Ils ont constaté que la grande majorité des attaques effectuées par les scanners de sécurité automatisés sont inoffensives et ne génèrent que du bruit pour les défenseurs. Sur les dizaines de millions de requêtes malveillantes que nous avons identifiées en provenance de ces scanners, seulement 0,0065 % ont réussi à déclencher une vulnérabilité. Cela montre qu'il est essentiel de disposer d'un cadre solide pour la hiérarchisation des alertes afin de permettre aux défenseurs de surveiller efficacement les journaux bruts des serveurs web ou les alertes du pare-feu d'application web (WAF) du périmètre. L'intégration de renseignements sur les menaces et du contexte d'exécution des applications dans les détections de sécurité peut aider les organisations à filtrer les menaces les plus critiques.

FAIT 3 : Seule une petite partie des vulnérabilités identifiées mérite d'être traitée en priorité

En 2023, plus de 4 000 vulnérabilités importantes et 1 000 vulnérabilités critiques ont été identifiées et inventoriées dans le cadre du projet CVE (Common Vulnerabilities and Exposures). Les recherches de Datadog ont permis de constater qu'un service moyen est vulnérable à 19 de ces vulnérabilités. Toutefois, selon des recherches universitaires antérieures, seuls 5 % environ des vulnérabilités sont exploitées par des attaquants dans la nature.

Compte tenu de ces chiffres, il est facile de comprendre pourquoi les praticiens sont submergés par la quantité de vulnérabilités auxquelles ils sont confrontés, 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 vulnérabilités et calculé un « score ajusté » basé sur plusieurs facteurs supplémentaires afin de déterminer la probabilité et l'impact d'une exploitation réussie :

Le service vulnérable est-il exposé publiquement à l'internet ?
Est-il exécuté en production, par opposition à un environnement de développement ou de test ?
Existe-t-il un code d'exploitation disponible en ligne ou des instructions sur la manière d'exploiter la vulnérabilité ?

Ils ont également pris en compte le score du système de prédiction des exploits (Exploit Prediction Scoring System - EPSS), en accordant plus de poids aux vulnérabilités qui ont obtenu un score plus élevé pour cette mesure. Ils ont appliqué cette méthodologie à toutes les vulnérabilités afin d'évaluer combien d'entre elles resteraient critiques sur la base de leur score ajusté. Ils ont constaté qu'après l'application de notre notation ajustée, 63 % des organisations qui avaient des vulnérabilités avec une gravité CVE critique n'ont plus de vulnérabilités critiques. Par ailleurs, 30 % des organisations ont vu leur nombre de vulnérabilités critiques réduit de moitié ou plus.

Pour déterminer les vulnérabilités à traiter en priorité, les organisations doivent adopter un cadre qui leur permette d'évaluer de manière cohérente la gravité du problème. En règle générale, une vulnérabilité est plus grave si

le service concerné est exposé publiquement
la vulnérabilité est exploitée en production
Un code d'exploitation est accessible au public.

Bien que d'autres vulnérabilités puissent encore présenter un risque, elles ne devraient être traitées qu'après les problèmes qui répondent à ces trois critères.

FAIT 4 : Les images de conteneurs légers entraînent moins de vulnérabilités

En matière de développement de logiciels et de sécurité, le moins est souvent le mieux. C'est particulièrement vrai dans le contexte des dépendances tierces, telles que les images de base des conteneurs. Il existe généralement plusieurs options pour choisir une image de base, notamment :

Utiliser une image de grande taille basée sur une distribution Linux classique, telle qu'Ubuntu
Utiliser une image plus fine basée sur une distribution légère, telle que Alpine Linux ou BusyBox
L'utilisation d'une image sans distribution, qui ne contient que le temps d'exécution minimum nécessaire à l'exécution de l'application - et parfois, rien d'autre que l'application elle-même.

En analysant des milliers d'images de conteneurs, ils ont constaté que plus une image de conteneur est petite, moins elle est susceptible de présenter de vulnérabilités, probablement parce qu'elle contient moins de bibliothèques tierces. En moyenne, les images de conteneurs de moins de 100 Mo présentent 4,4 vulnérabilités élevées ou critiques, contre 42,2 pour les images de 250 à 500 Mo, et près de 80 pour les images de taille supérieure.

Cela démontre que dans les environnements conteneurisés, l'utilisation d'images légères est une pratique essentielle pour minimiser la surface d'attaque, car elle permet de réduire le nombre de bibliothèques tierces et de paquets du système d'exploitation dont dépend une application. En outre, les images légères permettent de réduire les besoins en stockage et le trafic réseau, ainsi que d'accélérer les déploiements. Enfin, les images de conteneurs légers permettent de minimiser les outils à la disposition d'un attaquant, y compris les utilitaires système tels que curl ou wget, ce qui rend l'exploitation de nombreux types de vulnérabilités plus difficile.

Jay Beale, PDG de la société de conseil InGuardians :

Lorsque je joue le rôle de l'acteur de la menace dans des environnements de conteneurs comme Kubernetes, les images de conteneurs construites sur distroless rendent ma journée plus difficile.

FAIT 5 : L'adoption de l'infrastructure en tant que code est élevée, mais varie d'un fournisseur de cloud à l'autre

Le concept d'infrastructure en tant que code (IaC) a été introduit dans les années 1990 avec des projets tels que CFEngine, Puppet et Chef. Après 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 présente des avantages considérables pour les opérations, notamment le contrôle des versions, la traçabilité et la reproductibilité entre les environnements. Sa nature déclarative aide également les équipes DevOps à comprendre l'état souhaité, plutôt que de lire d'interminables scripts bash décrivant comment y parvenir.

L'IaC est également considérée comme une pratique essentielle pour la sécurisation des environnements de production en nuage, car elle permet de garantir que :

Toutes les modifications sont examinées par des pairs
Les opérations humaines ont des permissions limitées sur les environnements de production, puisque les déploiements sont gérés par un pipeline CI/CD.
Les organisations peuvent analyser le code IaC pour détecter les configurations faibles, ce qui les aide à identifier les problèmes 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 inférieur 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 spécifiques au cloud, à savoir CloudFormation et Google Deployment Manager.

FAIT 6 : Les déploiements manuels dans le nuage sont encore très répandus

Les humains, heureusement, ne sont pas des machines, ce qui signifie qu'on est condamnés à faire des erreurs. Un élément majeur du contrôle de la qualité, et par extension de la sécurité, est l'automatisation des tâches répétitives qui peuvent être retirées des mains de l'homme.

Dans les environnements de production en nuage, un pipeline CI/CD est généralement chargé de déployer les modifications apportées à l'infrastructure et aux applications. L'automatisation qui a lieu dans ce pipeline peut être réalisée avec des outils IaC ou par des scripts utilisant des outils spécifiques aux fournisseurs de cloud.

L'automatisation garantit que les ingénieurs n'ont pas besoin d'un accès privilégié permanent à l'environnement de production, et que les déploiements sont correctement suivis et examinés par les pairs. L'opposé de cette meilleure pratique, à savoir l'exécution manuelle d'actions à partir de la console cloud, est souvent désigné sous le nom d'opérations 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 fenêtre de 14 jours précédant la rédaction de cette étude. Selon la définition de Datadog, cela signifie que ces organisations ont déployé 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 période.

FAIT 7 : L'utilisation d'identifiants à durée de vie courte dans les pipelines CI/CD est encore trop faible.

Dans les environnements cloud, les fuites d'informations d'identification à longue durée de vie sont l'une des causes les plus courantes des violations de données. Les pipelines CI/CD augmentent cette surface d'attaque car ils disposent généralement d'autorisations privilégiées et leurs informations d'identification peuvent fuir par le biais d'une journalisation excessive, de dépendances logicielles compromises ou d'artefacts de construction, comme dans le cas de la violation de Codecov. L'utilisation d'identifiants à courte durée de vie pour les pipelines CI/CD est donc l'un des aspects les plus critiques de la sécurisation 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, même dans les cas où des informations d'identification à court terme seraient à la fois plus pratiques et plus sûres. 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é » basée 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 sûre. Une fois de plus, cela montre que les bonnes pratiques opérationnelles tendent également à conduire à de meilleurs résultats en matière de sécurité.

À propos de Datadog

La plateforme SaaS de Datadog intègre et automatise la surveillance de l'infrastructure, la surveillance de la performance des applications, la gestion des journaux, la surveillance de l'utilisateur réel et de nombreuses autres capacités afin de fournir une observabilité et une sécurité unifiées et en temps réel pour l'ensemble de la pile technologique de ses clients.

Source : "State of DevSecOps 2024" (Datadog)

Et vous ?