IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

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 , par Jade Emy

6PARTAGES

5  0 
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 ?

Pensez-vous que ce rapport est crédible ou pertinente ?
Quel est votre avis sur le sujet ?

Voir aussi :

DevSecOps donne des résultats significatifs, mais seules 22 % des organisations ont élaboré une stratégie formelle intégrant la sécurité dans les processus du cycle de vie du développement logiciel

73 % des décideurs informatiques admettent qu'ils pourraient faire davantage pour améliorer leurs pratiques DevSecOps, 71 % reconnaissant que la culture est le principal obstacle à leur progression

Quand DevSecOps devrait se lire SecDevOps, par Stéphane de Saint-Albin, Vice-président, Application & Cloud Security et Président, Rohde & Schwarz Cybersecurity SAS

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de OButterlin
Modérateur https://www.developpez.com
Le 27/04/2024 à 19:59
La responsabilité des ESN est très certainement à analyser dans cette histoire.
A toujours utiliser Spring + Apache (entre autres), pas étonnant qu'on ait ces résultats.
Ceci dit, il faudrait voir comment l'analyse a été faite, ce n'est pas parce qu'on a une bibliothèque tierce que l'application est vulnérable, tout dépend de l'exposition à l'extérieur.

Nous utilisons Jakarta EE 10 ou JEE8+ et nos applications ont été analysées par les équipes de cybersécurité sans rien détecter.
Même le dernier "big-problem" en date (log4j), rien... on n'utilise pas.

Bref, plutôt que d'utiliser des bibliothèques tierces avec autant de dépendances indirectes, utilisez le standard jakarta sur un serveur certifié EE
Et si vraiment l'application a besoin de bibliothèques non présentent (POI ou iText par exemple), essayez d'isoler le traitement sur un serveur dédié non accessible de l'extérieur.
2  0 
Avatar de OButterlin
Modérateur https://www.developpez.com
Le 29/04/2024 à 21:58
Citation Envoyé par kbadache Voir le message
Jakarka EE n'est plus le standard, c'est d'ailleurs pour ça que ça s'appelle Jakarta EE et non plus Java EE.
Et Jakarta EE est une usine à gaz, comme les servers d'application EE.
Quand on en sait aussi peu, on devrait se taire.
Le nom a changé parce que la gouvernance est passée de Oracle à la fondation Eclipse.
Jakarta EE reste un standard java.

Jakarta EE une usine à gaz ? Visiblement, tu ne connais pas... enfin, il te reste tes certitudes, c'est déjà ça
1  0 
Avatar de marc.collin
Membre émérite https://www.developpez.com
Le 27/04/2024 à 22:29
cela me semble des chiffres assez élevé sachant que ces failles ne sont pas exploitable avec la conf par défaut sous spring

Spring4Shell (CVE-2022-22965)
The specific exploit requires the application to run on Tomcat as a WAR deployment.
Log4Shell (CVE-2021-45046 et CVE-2021-44228)
Spring Boot services are only affected by this vulnerability if they have switched from the default logging system to log4j2
The log4j-to-slf4j and log4j-api jars that we include in spring-boot-starter-logging cannot be exploited on their own.
des failles non exploitable avec la conf par défaut et de toute façon corrigé depuis des années...
0  0 
Avatar de PhilippeGibault
Membre éprouvé https://www.developpez.com
Le 28/04/2024 à 7:24
Citation Envoyé par OButterlin Voir le message
La responsabilité des ESN est très certainement à analyser dans cette histoire.
A toujours utiliser Spring + Apache (entre autres), pas étonnant qu'on ait ces résultats.
Ceci dit, il faudrait voir comment l'analyse a été faite, ce n'est pas parce qu'on a une bibliothèque tierce que l'application est vulnérable, tout dépend de l'exposition à l'extérieur.

Nous utilisons Jakarta EE 10 ou JEE8+ et nos applications ont été analysées par les équipes de cybersécurité sans rien détecter.
Même le dernier "big-problem" en date (log4j), rien... on n'utilise pas.

Bref, plutôt que d'utiliser des bibliothèques tierces avec autant de dépendances indirectes, utilisez le standard jakarta sur un serveur certifié EE
Et si vraiment l'application a besoin de bibliothèques non présentent (POI ou iText par exemple), essayez d'isoler le traitement sur un serveur dédié non accessible de l'extérieur.
Les EJB, c'est tellement bien que Jakarta va les supprimer. Il l'ont d'ailleurs dit lors de l'un des Devoxxx.

Pour commencer, la qualité du code et sa maintenabilité sur le long terme, c'est non négociable.
Lutter contre la dette technique, c'est notre travail.

Pour ma part, il est vrai que je suis opposé aux outils de générateur de code (coucou JHipster que je déteste) et que j'ai l'habitude d'ajouter une librairie quand elle s'impose elle-même (Spring compris).

Il est vrai que l'on peut faire des choses très bien avec les EEJB et de la grosse merde avec Spring.

Néanmoins, c'est les EJB (3 pour être exact) qui ont copié Spring, et pas l'inverse.

De plus, notre métier évolue. Il évolue aussi bien techniquement que théoriquement, et la façon de concevoir une application aujourd'hui a totalement changé.

Je ne pratique plus mon métier aujourd'hui de la même façon que je le pratiquait en 2008 quand j'ai commencé.

Sur ce point, Spring a mieux évolué et s'est mieux adapté que JEE/Jakarta.

Spring s'est adapté au découplage Front/Back, à l'architecture Hexagonale, ...

Rien qu'un détail annodin, j'étais au dernier Devoxx, et je regardais du code Quarkus.
Et l'injection de dépendance était par ... Attribut, là où en Spring, elle est par constructeur.
C'est certes un détail, mais pour tester le composant, ça devient plus simple, vu que l'on est pas obligé de monter une conf complexe de test. Il suffit d'injecter simplement ... un Mock!

Par ailleurs, Spring Boot est aussi une innovation de la communauté Spring, vu que ça a permis de faire plus de Devoxx, et de simplifier le déploiement via Docker.
0  0 
Avatar de kbadache
Membre averti https://www.developpez.com
Le 29/04/2024 à 14:06
Citation Envoyé par OButterlin Voir le message
La responsabilité des ESN est très certainement à analyser dans cette histoire.
A toujours utiliser Spring + Apache (entre autres), pas étonnant qu'on ait ces résultats.
Ceci dit, il faudrait voir comment l'analyse a été faite, ce n'est pas parce qu'on a une bibliothèque tierce que l'application est vulnérable, tout dépend de l'exposition à l'extérieur.

Nous utilisons Jakarta EE 10 ou JEE8+ et nos applications ont été analysées par les équipes de cybersécurité sans rien détecter.
Même le dernier "big-problem" en date (log4j), rien... on n'utilise pas.

Bref, plutôt que d'utiliser des bibliothèques tierces avec autant de dépendances indirectes, utilisez le standard jakarta sur un serveur certifié EE
Et si vraiment l'application a besoin de bibliothèques non présentent (POI ou iText par exemple), essayez d'isoler le traitement sur un serveur dédié non accessible de l'extérieur.
Jakarka EE n'est plus le standard, c'est d'ailleurs pour ça que ça s'appelle Jakarta EE et non plus Java EE.
Et Jakarta EE est une usine à gaz, comme les servers d'application EE.
1  1 
Avatar de OButterlin
Modérateur https://www.developpez.com
Le 29/04/2024 à 22:31
Citation Envoyé par PhilippeGibault Voir le message
Les EJB, c'est tellement bien que Jakarta va les supprimer. Il l'ont d'ailleurs dit lors de l'un des Devoxxx.
Et bien en tout cas, ce ne sera pas pour la version 11 de jakarta, les EJB restent.
Mais bon, si Devoxx l'a dit, alors c'est sûr, ça va disparaître... Rappelle-moi le lien entre la fondation Eclipse et Devoxx ?

Les EJB3 ont copié Spring ? En quoi ?
La seule chose que je vois issue de Spring serait l'injection de dépendance, mais ce n'est pas lié à EJB.
A la base, c'est Spring qui l'a démocratisée (il faut rendre à Caesar ce qui appartient à Caesar), mais depuis EE8 et CDI, je dirais que l'avantage va à CDI (d'ailleurs Spring converge vers CDI).
Pour la persistence, JPA n'est pas lié à Spring, loin s'en faut, bien plus à Hibernate.
0  0 
Avatar de PhilippeGibault
Membre éprouvé https://www.developpez.com
Le 30/04/2024 à 7:52
Effectivement, pour être plus précis, c'est bien CDI (qui comme Hibernate a été spécifié dans le JCP par RedHad) qui a copié Spring.

Après, je trouve que les EJB, c'est très proche de Spring (au vu de ce qu'on a fait en TP au CNAM).

Après, à la différence de la communauté JEE/Jakarta, je trouve que la communauté Spring s'adapte mieux aux évolutions Théorique/Technique.

Chez Spring, l'injection de dépendance est par constructeur après avoir été par attribut. CDI est resté (en tout cas au vu du code que j'ai vu au Devoxx) par attribut.
Seulement, si on suit les évolution théorique de codage/TDD/Architecture Hexagoinale ..., et bien, l'injection de dépendance par constructeur, c'est mieux, et en particulier, c'est plus simple pour faire des tests (TDD).

JSF, c'est bien, mais c'est terminé, vu que pour des raisons économiques et de maintenance du code, on découple le back du front. Là aussi, je trouve que Spring s'est mieux adapté à ce changement de paradigme.

Sans compter Spring Boot qui a permis de déployer plus facilement via Docker les applications web.

...
0  0