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.
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.
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.
[B]FAIT 3 : Seule une petite partie des vulnérabilités identifiées mérite d'être traitée en priorité[...
La fin de cet article est réservée aux abonnés. Soutenez le Club Developpez.com en prenant un abonnement pour que nous puissions continuer à vous proposer des publications.
Envoyé par kbadache
