Neue Sicherheitslücken in Spring-Bibliotheken: Wie Sie feststellen können, ob Sie gefährdet sind und was zu tun ist
Vor Kurzem haben Spring-Bibliotheken, eine der beliebtesten Bibliotheken in der Java-Community, zwei Sicherheitslücken im Zusammenhang mit Remote Code Execution (RCE) aufgedeckt. Um Ihnen das Verständnis zu erleichtern, ob Sie durch eine der Sicherheitslücken gefährdet sind und welche Maßnahmen Sie ergreifen müssen, haben wir die bekannten Details für „Spring4Shell“ und „Spring Cloud Function“ aufgeschlüsselt.
Sicherheitslücke 1 — „Spring4Shell“ (CVE-2022-22965)
Am 29. März 2022 entdeckte die Community eine Reihe von Tweets, die Screenshots eines Machbarkeitsnachweises eines Exploits gegen Spring Core (SC) enthielten, der die Remote-Code-Ausführung für alle Versionen von Spring Core ermöglicht, einschließlich der zuletzt veröffentlichten Version 5.3.17.
Welche Anwendungen sind gefährdet?
Derzeit wurde bestätigt, dass nur Anwendungen, die auf Tomcat gehostet werden, von diesem neuen Exploit bedroht sind. Es wurde zwar nicht nachgewiesen, dass der Exploit gegen den Embedded Tomcat Servlet Container oder andere Anwendungen, die nicht von Tomcat gehostet werden, erfolgreich ist, aber das schließt nicht aus, dass sich die Bedrohung dieser Frameworks in Zukunft als erfolgreich erweisen könnte.
Spring hat einen offiziellen veröffentlicht Aussage über die Sicherheitsanfälligkeit, in der klargestellt wird, dass die folgenden Bedingungen erfüllt sein müssen, um nach derzeitigem Verständnis der Sicherheitsanfälligkeit gefährdet zu sein:
- JDK 9 oder höher
- Apache Tomcat als Servlet-Container
- Als traditionelles WAR verpackt (im Gegensatz zu einer ausführbaren Spring Boot-Jar)
- Spring-Webmvc- oder Spring-Webflux-Abhängigkeit
- Spring Framework-Versionen 5.3.0 bis 5.3.17, 5.2.0 bis 5.2.19 und ältere Versionen
Wie funktioniert die „Spring4Shell“ -Ausbeutung?
Die Ausnutzung basiert auf der Verwendung von „Data Binding“ (org.springframework.web.bind.WebDataBinder) in Anfragen, die Plain Old Java Objects (POJO) in der Methodensignatur verwenden:
Wobei die Foo-Klasse eine POJO-Klasse ist, die wie folgt definiert werden könnte. Beachten Sie, dass die eigentliche Klasse nicht wichtig ist, solange sie vom Class Loader geladen wird.
Wenn eine Anfrage mit einer solchen Methode bearbeitet wird, wird der Class Loader verwendet, um die Klasse aufzulösen. Der Class Loader ist dafür verantwortlich, Klassen zur Laufzeit zu laden, ohne dass zuerst alle möglichen Typen in den Speicher geladen werden müssen. Er findet heraus, welche JAR-Datei geladen werden muss, wenn eine neue Klasse verwendet wird.
Die aktuellsten und detailliertesten Informationen zu dieser Sicherheitsanfälligkeit finden Sie direkt von Spring auf ihrer Blogbeitrag, einschließlich möglicher Korrekturen oder Problemumgehungen.
Sicherheitslücke 2 — Spring Cloud-Funktion (CVE-2022-22963)
Am 27. März 2022 veröffentlichte Cyber Kendra Details zu einer 0-tägigen Remote Code Execution (RCE) -Sicherheitslücke in Spring Cloud Functions, für die es keinen Patch gab. Der Sicherheitslücke wurde die ID zugewiesen CVE-2022-22963: Sicherheitslücke beim Zugriff auf Spring Expression-Ressourcen.
Welche Anwendungen sind gefährdet?
Die Sicherheitsanfälligkeit betraf Anwendungen unter den folgenden Bedingungen:
- JDK 9 oder neuer
- Spring Cloud Functions Version 3.1.6 (oder niedriger), 3.2.2 (oder niedriger) oder jede nicht unterstützte Version
Wie funktioniert die Ausbeutung?
Spring Cloud Function bietet Entwicklern die Möglichkeit, zu konfigurieren, wie das Routing über die Eigenschaft spring.cloud.function.routing-expression gehandhabt wird, was normalerweise über Konfiguration oder Code erfolgt. Dies ist eine leistungsstarke Funktion, die die „Spring Expression Language“ (SPel) akzeptiert. Durch diese 0-Day-Sicherheitslücke haben wir herausgefunden, dass diese Eigenschaft über die HTTP-Header einer Anfrage gesetzt werden kann. Dies bedeutete, dass ein Angreifer SPel-Code direkt in seine HTTP-Anfrage an einen RoutingFunction-Endpunkt einbetten und so beliebigen Code ausführen konnte.
Welche Maßnahmen sollten Benutzer ergreifen, um das Risiko zu mindern?
Der Frühling hat veröffentlicht Versionen 3.1.7 und 3.2.3, um dieses Problem zu beheben, indem sie nicht zulassen, dass diese Eigenschaft über HTTP-Header gesetzt wird, wodurch die Sicherheitsanfälligkeit gemindert wird. Nach dem Upgrade auf eine der Versionen sind keine weiteren Schritte erforderlich.
Möchten Sie mehr darüber erfahren, wie wir Entwicklern helfen, sichereren Code zu schreiben? Eine Demo buchen oder lesen Sie unsere kostenlosen Richtlinien zur sicheren Codierung unter sicherer Code-Coach.
Quellen
- https://www.lunasec.io/docs/blog/spring-rce-vulnerabilities/
- https://www.rapid7.com/blog/post/2022/03/30/spring4shell-zero-day-vulnerability-in-spring-framework/
Vor Kurzem haben Spring-Bibliotheken, eine der beliebtesten Bibliotheken in der Java-Community, zwei Sicherheitslücken im Zusammenhang mit Remote Code Execution (RCE) aufgedeckt. Wir haben die bekannten Details für „Spring4Shell“ und „Spring Cloud Function“ aufgeschlüsselt, um Ihnen zu helfen, zu verstehen, ob Sie gefährdet sind und was Sie tun müssen, wenn Sie gefährdet sind.
Secure Code Warrior là pour aider votre entreprise à sécuriser le code tout au long du cycle de développement logiciel et à créer une culture où la cybersécurité est une priorité. Que vous soyez responsable de la sécurité des applications, développeur, responsable de la sécurité des systèmes d'information ou toute autre personne impliquée dans la sécurité, nous pouvons aider votre entreprise à réduire les risques liés à un code non sécurisé.
Réserver une démonstration
Vor Kurzem haben Spring-Bibliotheken, eine der beliebtesten Bibliotheken in der Java-Community, zwei Sicherheitslücken im Zusammenhang mit Remote Code Execution (RCE) aufgedeckt. Um Ihnen das Verständnis zu erleichtern, ob Sie durch eine der Sicherheitslücken gefährdet sind und welche Maßnahmen Sie ergreifen müssen, haben wir die bekannten Details für „Spring4Shell“ und „Spring Cloud Function“ aufgeschlüsselt.
Sicherheitslücke 1 — „Spring4Shell“ (CVE-2022-22965)
Am 29. März 2022 entdeckte die Community eine Reihe von Tweets, die Screenshots eines Machbarkeitsnachweises eines Exploits gegen Spring Core (SC) enthielten, der die Remote-Code-Ausführung für alle Versionen von Spring Core ermöglicht, einschließlich der zuletzt veröffentlichten Version 5.3.17.
Welche Anwendungen sind gefährdet?
Derzeit wurde bestätigt, dass nur Anwendungen, die auf Tomcat gehostet werden, von diesem neuen Exploit bedroht sind. Es wurde zwar nicht nachgewiesen, dass der Exploit gegen den Embedded Tomcat Servlet Container oder andere Anwendungen, die nicht von Tomcat gehostet werden, erfolgreich ist, aber das schließt nicht aus, dass sich die Bedrohung dieser Frameworks in Zukunft als erfolgreich erweisen könnte.
Spring hat einen offiziellen veröffentlicht Aussage über die Sicherheitsanfälligkeit, in der klargestellt wird, dass die folgenden Bedingungen erfüllt sein müssen, um nach derzeitigem Verständnis der Sicherheitsanfälligkeit gefährdet zu sein:
- JDK 9 oder höher
- Apache Tomcat als Servlet-Container
- Als traditionelles WAR verpackt (im Gegensatz zu einer ausführbaren Spring Boot-Jar)
- Spring-Webmvc- oder Spring-Webflux-Abhängigkeit
- Spring Framework-Versionen 5.3.0 bis 5.3.17, 5.2.0 bis 5.2.19 und ältere Versionen
Wie funktioniert die „Spring4Shell“ -Ausbeutung?
Die Ausnutzung basiert auf der Verwendung von „Data Binding“ (org.springframework.web.bind.WebDataBinder) in Anfragen, die Plain Old Java Objects (POJO) in der Methodensignatur verwenden:
Wobei die Foo-Klasse eine POJO-Klasse ist, die wie folgt definiert werden könnte. Beachten Sie, dass die eigentliche Klasse nicht wichtig ist, solange sie vom Class Loader geladen wird.
Wenn eine Anfrage mit einer solchen Methode bearbeitet wird, wird der Class Loader verwendet, um die Klasse aufzulösen. Der Class Loader ist dafür verantwortlich, Klassen zur Laufzeit zu laden, ohne dass zuerst alle möglichen Typen in den Speicher geladen werden müssen. Er findet heraus, welche JAR-Datei geladen werden muss, wenn eine neue Klasse verwendet wird.
Die aktuellsten und detailliertesten Informationen zu dieser Sicherheitsanfälligkeit finden Sie direkt von Spring auf ihrer Blogbeitrag, einschließlich möglicher Korrekturen oder Problemumgehungen.
Sicherheitslücke 2 — Spring Cloud-Funktion (CVE-2022-22963)
Am 27. März 2022 veröffentlichte Cyber Kendra Details zu einer 0-tägigen Remote Code Execution (RCE) -Sicherheitslücke in Spring Cloud Functions, für die es keinen Patch gab. Der Sicherheitslücke wurde die ID zugewiesen CVE-2022-22963: Sicherheitslücke beim Zugriff auf Spring Expression-Ressourcen.
Welche Anwendungen sind gefährdet?
Die Sicherheitsanfälligkeit betraf Anwendungen unter den folgenden Bedingungen:
- JDK 9 oder neuer
- Spring Cloud Functions Version 3.1.6 (oder niedriger), 3.2.2 (oder niedriger) oder jede nicht unterstützte Version
Wie funktioniert die Ausbeutung?
Spring Cloud Function bietet Entwicklern die Möglichkeit, zu konfigurieren, wie das Routing über die Eigenschaft spring.cloud.function.routing-expression gehandhabt wird, was normalerweise über Konfiguration oder Code erfolgt. Dies ist eine leistungsstarke Funktion, die die „Spring Expression Language“ (SPel) akzeptiert. Durch diese 0-Day-Sicherheitslücke haben wir herausgefunden, dass diese Eigenschaft über die HTTP-Header einer Anfrage gesetzt werden kann. Dies bedeutete, dass ein Angreifer SPel-Code direkt in seine HTTP-Anfrage an einen RoutingFunction-Endpunkt einbetten und so beliebigen Code ausführen konnte.
Welche Maßnahmen sollten Benutzer ergreifen, um das Risiko zu mindern?
Der Frühling hat veröffentlicht Versionen 3.1.7 und 3.2.3, um dieses Problem zu beheben, indem sie nicht zulassen, dass diese Eigenschaft über HTTP-Header gesetzt wird, wodurch die Sicherheitsanfälligkeit gemindert wird. Nach dem Upgrade auf eine der Versionen sind keine weiteren Schritte erforderlich.
Möchten Sie mehr darüber erfahren, wie wir Entwicklern helfen, sichereren Code zu schreiben? Eine Demo buchen oder lesen Sie unsere kostenlosen Richtlinien zur sicheren Codierung unter sicherer Code-Coach.
Quellen
- https://www.lunasec.io/docs/blog/spring-rce-vulnerabilities/
- https://www.rapid7.com/blog/post/2022/03/30/spring4shell-zero-day-vulnerability-in-spring-framework/
Vor Kurzem haben Spring-Bibliotheken, eine der beliebtesten Bibliotheken in der Java-Community, zwei Sicherheitslücken im Zusammenhang mit Remote Code Execution (RCE) aufgedeckt. Um Ihnen das Verständnis zu erleichtern, ob Sie durch eine der Sicherheitslücken gefährdet sind und welche Maßnahmen Sie ergreifen müssen, haben wir die bekannten Details für „Spring4Shell“ und „Spring Cloud Function“ aufgeschlüsselt.
Sicherheitslücke 1 — „Spring4Shell“ (CVE-2022-22965)
Am 29. März 2022 entdeckte die Community eine Reihe von Tweets, die Screenshots eines Machbarkeitsnachweises eines Exploits gegen Spring Core (SC) enthielten, der die Remote-Code-Ausführung für alle Versionen von Spring Core ermöglicht, einschließlich der zuletzt veröffentlichten Version 5.3.17.
Welche Anwendungen sind gefährdet?
Derzeit wurde bestätigt, dass nur Anwendungen, die auf Tomcat gehostet werden, von diesem neuen Exploit bedroht sind. Es wurde zwar nicht nachgewiesen, dass der Exploit gegen den Embedded Tomcat Servlet Container oder andere Anwendungen, die nicht von Tomcat gehostet werden, erfolgreich ist, aber das schließt nicht aus, dass sich die Bedrohung dieser Frameworks in Zukunft als erfolgreich erweisen könnte.
Spring hat einen offiziellen veröffentlicht Aussage über die Sicherheitsanfälligkeit, in der klargestellt wird, dass die folgenden Bedingungen erfüllt sein müssen, um nach derzeitigem Verständnis der Sicherheitsanfälligkeit gefährdet zu sein:
- JDK 9 oder höher
- Apache Tomcat als Servlet-Container
- Als traditionelles WAR verpackt (im Gegensatz zu einer ausführbaren Spring Boot-Jar)
- Spring-Webmvc- oder Spring-Webflux-Abhängigkeit
- Spring Framework-Versionen 5.3.0 bis 5.3.17, 5.2.0 bis 5.2.19 und ältere Versionen
Wie funktioniert die „Spring4Shell“ -Ausbeutung?
Die Ausnutzung basiert auf der Verwendung von „Data Binding“ (org.springframework.web.bind.WebDataBinder) in Anfragen, die Plain Old Java Objects (POJO) in der Methodensignatur verwenden:
Wobei die Foo-Klasse eine POJO-Klasse ist, die wie folgt definiert werden könnte. Beachten Sie, dass die eigentliche Klasse nicht wichtig ist, solange sie vom Class Loader geladen wird.
Wenn eine Anfrage mit einer solchen Methode bearbeitet wird, wird der Class Loader verwendet, um die Klasse aufzulösen. Der Class Loader ist dafür verantwortlich, Klassen zur Laufzeit zu laden, ohne dass zuerst alle möglichen Typen in den Speicher geladen werden müssen. Er findet heraus, welche JAR-Datei geladen werden muss, wenn eine neue Klasse verwendet wird.
Die aktuellsten und detailliertesten Informationen zu dieser Sicherheitsanfälligkeit finden Sie direkt von Spring auf ihrer Blogbeitrag, einschließlich möglicher Korrekturen oder Problemumgehungen.
Sicherheitslücke 2 — Spring Cloud-Funktion (CVE-2022-22963)
Am 27. März 2022 veröffentlichte Cyber Kendra Details zu einer 0-tägigen Remote Code Execution (RCE) -Sicherheitslücke in Spring Cloud Functions, für die es keinen Patch gab. Der Sicherheitslücke wurde die ID zugewiesen CVE-2022-22963: Sicherheitslücke beim Zugriff auf Spring Expression-Ressourcen.
Welche Anwendungen sind gefährdet?
Die Sicherheitsanfälligkeit betraf Anwendungen unter den folgenden Bedingungen:
- JDK 9 oder neuer
- Spring Cloud Functions Version 3.1.6 (oder niedriger), 3.2.2 (oder niedriger) oder jede nicht unterstützte Version
Wie funktioniert die Ausbeutung?
Spring Cloud Function bietet Entwicklern die Möglichkeit, zu konfigurieren, wie das Routing über die Eigenschaft spring.cloud.function.routing-expression gehandhabt wird, was normalerweise über Konfiguration oder Code erfolgt. Dies ist eine leistungsstarke Funktion, die die „Spring Expression Language“ (SPel) akzeptiert. Durch diese 0-Day-Sicherheitslücke haben wir herausgefunden, dass diese Eigenschaft über die HTTP-Header einer Anfrage gesetzt werden kann. Dies bedeutete, dass ein Angreifer SPel-Code direkt in seine HTTP-Anfrage an einen RoutingFunction-Endpunkt einbetten und so beliebigen Code ausführen konnte.
Welche Maßnahmen sollten Benutzer ergreifen, um das Risiko zu mindern?
Der Frühling hat veröffentlicht Versionen 3.1.7 und 3.2.3, um dieses Problem zu beheben, indem sie nicht zulassen, dass diese Eigenschaft über HTTP-Header gesetzt wird, wodurch die Sicherheitsanfälligkeit gemindert wird. Nach dem Upgrade auf eine der Versionen sind keine weiteren Schritte erforderlich.
Möchten Sie mehr darüber erfahren, wie wir Entwicklern helfen, sichereren Code zu schreiben? Eine Demo buchen oder lesen Sie unsere kostenlosen Richtlinien zur sicheren Codierung unter sicherer Code-Coach.
Quellen
- https://www.lunasec.io/docs/blog/spring-rce-vulnerabilities/
- https://www.rapid7.com/blog/post/2022/03/30/spring4shell-zero-day-vulnerability-in-spring-framework/
Veuillez cliquer sur le lien ci-dessous et télécharger le PDF de cette ressource.
Secure Code Warrior là pour aider votre entreprise à sécuriser le code tout au long du cycle de développement logiciel et à créer une culture où la cybersécurité est une priorité. Que vous soyez responsable de la sécurité des applications, développeur, responsable de la sécurité des systèmes d'information ou toute autre personne impliquée dans la sécurité, nous pouvons aider votre entreprise à réduire les risques liés à un code non sécurisé.
Consulter le rapportRéserver une démonstration
Vor Kurzem haben Spring-Bibliotheken, eine der beliebtesten Bibliotheken in der Java-Community, zwei Sicherheitslücken im Zusammenhang mit Remote Code Execution (RCE) aufgedeckt. Um Ihnen das Verständnis zu erleichtern, ob Sie durch eine der Sicherheitslücken gefährdet sind und welche Maßnahmen Sie ergreifen müssen, haben wir die bekannten Details für „Spring4Shell“ und „Spring Cloud Function“ aufgeschlüsselt.
Sicherheitslücke 1 — „Spring4Shell“ (CVE-2022-22965)
Am 29. März 2022 entdeckte die Community eine Reihe von Tweets, die Screenshots eines Machbarkeitsnachweises eines Exploits gegen Spring Core (SC) enthielten, der die Remote-Code-Ausführung für alle Versionen von Spring Core ermöglicht, einschließlich der zuletzt veröffentlichten Version 5.3.17.
Welche Anwendungen sind gefährdet?
Derzeit wurde bestätigt, dass nur Anwendungen, die auf Tomcat gehostet werden, von diesem neuen Exploit bedroht sind. Es wurde zwar nicht nachgewiesen, dass der Exploit gegen den Embedded Tomcat Servlet Container oder andere Anwendungen, die nicht von Tomcat gehostet werden, erfolgreich ist, aber das schließt nicht aus, dass sich die Bedrohung dieser Frameworks in Zukunft als erfolgreich erweisen könnte.
Spring hat einen offiziellen veröffentlicht Aussage über die Sicherheitsanfälligkeit, in der klargestellt wird, dass die folgenden Bedingungen erfüllt sein müssen, um nach derzeitigem Verständnis der Sicherheitsanfälligkeit gefährdet zu sein:
- JDK 9 oder höher
- Apache Tomcat als Servlet-Container
- Als traditionelles WAR verpackt (im Gegensatz zu einer ausführbaren Spring Boot-Jar)
- Spring-Webmvc- oder Spring-Webflux-Abhängigkeit
- Spring Framework-Versionen 5.3.0 bis 5.3.17, 5.2.0 bis 5.2.19 und ältere Versionen
Wie funktioniert die „Spring4Shell“ -Ausbeutung?
Die Ausnutzung basiert auf der Verwendung von „Data Binding“ (org.springframework.web.bind.WebDataBinder) in Anfragen, die Plain Old Java Objects (POJO) in der Methodensignatur verwenden:
Wobei die Foo-Klasse eine POJO-Klasse ist, die wie folgt definiert werden könnte. Beachten Sie, dass die eigentliche Klasse nicht wichtig ist, solange sie vom Class Loader geladen wird.
Wenn eine Anfrage mit einer solchen Methode bearbeitet wird, wird der Class Loader verwendet, um die Klasse aufzulösen. Der Class Loader ist dafür verantwortlich, Klassen zur Laufzeit zu laden, ohne dass zuerst alle möglichen Typen in den Speicher geladen werden müssen. Er findet heraus, welche JAR-Datei geladen werden muss, wenn eine neue Klasse verwendet wird.
Die aktuellsten und detailliertesten Informationen zu dieser Sicherheitsanfälligkeit finden Sie direkt von Spring auf ihrer Blogbeitrag, einschließlich möglicher Korrekturen oder Problemumgehungen.
Sicherheitslücke 2 — Spring Cloud-Funktion (CVE-2022-22963)
Am 27. März 2022 veröffentlichte Cyber Kendra Details zu einer 0-tägigen Remote Code Execution (RCE) -Sicherheitslücke in Spring Cloud Functions, für die es keinen Patch gab. Der Sicherheitslücke wurde die ID zugewiesen CVE-2022-22963: Sicherheitslücke beim Zugriff auf Spring Expression-Ressourcen.
Welche Anwendungen sind gefährdet?
Die Sicherheitsanfälligkeit betraf Anwendungen unter den folgenden Bedingungen:
- JDK 9 oder neuer
- Spring Cloud Functions Version 3.1.6 (oder niedriger), 3.2.2 (oder niedriger) oder jede nicht unterstützte Version
Wie funktioniert die Ausbeutung?
Spring Cloud Function bietet Entwicklern die Möglichkeit, zu konfigurieren, wie das Routing über die Eigenschaft spring.cloud.function.routing-expression gehandhabt wird, was normalerweise über Konfiguration oder Code erfolgt. Dies ist eine leistungsstarke Funktion, die die „Spring Expression Language“ (SPel) akzeptiert. Durch diese 0-Day-Sicherheitslücke haben wir herausgefunden, dass diese Eigenschaft über die HTTP-Header einer Anfrage gesetzt werden kann. Dies bedeutete, dass ein Angreifer SPel-Code direkt in seine HTTP-Anfrage an einen RoutingFunction-Endpunkt einbetten und so beliebigen Code ausführen konnte.
Welche Maßnahmen sollten Benutzer ergreifen, um das Risiko zu mindern?
Der Frühling hat veröffentlicht Versionen 3.1.7 und 3.2.3, um dieses Problem zu beheben, indem sie nicht zulassen, dass diese Eigenschaft über HTTP-Header gesetzt wird, wodurch die Sicherheitsanfälligkeit gemindert wird. Nach dem Upgrade auf eine der Versionen sind keine weiteren Schritte erforderlich.
Möchten Sie mehr darüber erfahren, wie wir Entwicklern helfen, sichereren Code zu schreiben? Eine Demo buchen oder lesen Sie unsere kostenlosen Richtlinien zur sicheren Codierung unter sicherer Code-Coach.
Quellen
- https://www.lunasec.io/docs/blog/spring-rce-vulnerabilities/
- https://www.rapid7.com/blog/post/2022/03/30/spring4shell-zero-day-vulnerability-in-spring-framework/
Table des matières
Secure Code Warrior là pour aider votre entreprise à sécuriser le code tout au long du cycle de développement logiciel et à créer une culture où la cybersécurité est une priorité. Que vous soyez responsable de la sécurité des applications, développeur, responsable de la sécurité des systèmes d'information ou toute autre personne impliquée dans la sécurité, nous pouvons aider votre entreprise à réduire les risques liés à un code non sécurisé.
Réserver une démonstrationTéléchargerRessources pour débuter
Trust Agent:AI - Secure and scale AI-Drive development
AI is writing code. Who’s governing it? With up to 50% of AI-generated code containing security weaknesses, managing AI risk is critical. Discover how SCW's Trust Agent: AI provides the real-time visibility, proactive governance, and targeted upskilling needed to scale AI-driven development securely.
La puissance de la sécurité des applications OpenText + Secure Code Warrior
OpenText Application Security and Secure Code Warrior combine vulnerability detection with AI Software Governance and developer capability. Together, they help organizations reduce risk, strengthen secure coding practices, and confidently adopt AI-driven development.
Secure Code Warrior corporate overview
Secure Code Warrior is an AI Software Governance platform designed to enable organizations to safely adopt AI-driven development by bridging the gap between development velocity and enterprise security. The platform addresses the "Visibility Gap," where security teams often lack insights into shadow AI coding tools and the origins of production code.
Thèmes et contenus de la formation Securecode
Nos contenus de pointe sont constamment développés afin de s'adapter à l'évolution constante du paysage du développement logiciel, en tenant compte de votre rôle. Les thèmes abordés couvrent tous les domaines, de l'IA à l'injection XQuery, et sont proposés pour une multitude de rôles, des architectes et ingénieurs aux chefs de produit et responsables assurance qualité. Nous vous invitons à découvrir un aperçu de notre catalogue de contenus classés par thème et par rôle.
Ressources pour débuter
Cybermon est de retour : les missions KI « Beat the Boss » sont désormais disponibles sur demande.
Cybermon 2025 Beat the Boss est désormais disponible toute l'année dans SCW. Il utilise des exigences de sécurité IA/LLM avancées pour 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 la conception
Découvrez les exigences de la loi européenne sur la cyber-résilience (CRA), à qui elle s'applique et comment les équipes de développement peuvent s'y préparer en adoptant des méthodes sécurisées, en prévenant les failles de sécurité et en renforçant les compétences des développeurs.
Facteur 1 : Critères de réussite définis et mesurables
Le catalyseur n° 1 inaugure notre série en dix parties intitulée « Les catalyseurs de la réussite » et démontre comment un codage sécurisé peut être associé à des résultats commerciaux tels que la réduction des risques et la rapidité afin d'atteindre une maturité programmatique à long terme.