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 für Ihr Unternehmen da, um Ihnen zu helfen, Code während des gesamten Softwareentwicklungszyklus zu sichern und eine Kultur zu schaffen, in der Cybersicherheit an erster Stelle steht. Ganz gleich, ob Sie AppSec-Manager, Entwickler, CISO oder jemand anderes sind, der sich mit Sicherheit befasst, wir können Ihrem Unternehmen helfen, die mit unsicherem Code verbundenen Risiken zu reduzieren.
Eine Demo buchen
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/
Klicken Sie auf den untenstehenden Link und laden Sie das PDF dieser Ressource herunter.
Secure Code Warrior für Ihr Unternehmen da, um Ihnen zu helfen, Code während des gesamten Softwareentwicklungszyklus zu sichern und eine Kultur zu schaffen, in der Cybersicherheit an erster Stelle steht. Ganz gleich, ob Sie AppSec-Manager, Entwickler, CISO oder jemand anderes sind, der sich mit Sicherheit befasst, wir können Ihrem Unternehmen helfen, die mit unsicherem Code verbundenen Risiken zu reduzieren.
Bericht ansehenEine Demo buchen
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/
Inhaltsverzeichnis
Secure Code Warrior für Ihr Unternehmen da, um Ihnen zu helfen, Code während des gesamten Softwareentwicklungszyklus zu sichern und eine Kultur zu schaffen, in der Cybersicherheit an erster Stelle steht. Ganz gleich, ob Sie AppSec-Manager, Entwickler, CISO oder jemand anderes sind, der sich mit Sicherheit befasst, wir können Ihrem Unternehmen helfen, die mit unsicherem Code verbundenen Risiken zu reduzieren.
Eine Demo buchenHerunterladenRessourcen für den Einstieg
Themen und Inhalte der Securecode-Schulung
Unsere branchenführenden Inhalte werden ständig weiterentwickelt, um der sich ständig ändernden Softwareentwicklungslandschaft unter Berücksichtigung Ihrer Rolle gerecht zu werden. Themen, die alles von KI bis XQuery Injection abdecken und für eine Vielzahl von Rollen angeboten werden, von Architekten und Ingenieuren bis hin zu Produktmanagern und QA. Verschaffen Sie sich einen kleinen Einblick in das Angebot unseres Inhaltskatalogs nach Themen und Rollen.
Die Kamer van Koophandel setzt Maßstäbe für entwicklergesteuerte Sicherheit in großem Maßstab
Die Kamer van Koophandel berichtet, wie sie sicheres Codieren durch rollenbasierte Zertifizierungen, Trust Score-Benchmarking und eine Kultur der gemeinsamen Verantwortung für Sicherheit in die tägliche Entwicklungsarbeit integriert hat.
%20(1).avif)
.avif)
Bedrohungsmodellierung mit KI: So wird jeder Entwickler zum Bedrohungsmodellierer
Sie werden besser gerüstet sein, um Entwicklern dabei zu helfen, Ideen und Techniken zur Bedrohungsmodellierung mit den KI-Tools zu kombinieren, die sie bereits verwenden, um die Sicherheit zu erhöhen, die Zusammenarbeit zu verbessern und von Anfang an widerstandsfähigere Software zu entwickeln.
Ressourcen für den Einstieg
Cybermon ist zurück: Beat the Boss KI-Missionen jetzt auf Abruf verfügbar
Cybermon 2025 Beat the Boss ist jetzt das ganze Jahr über in SCW verfügbar. Setzt fortschrittliche KI/LLM-Sicherheitsanforderungen ein, um die sichere KI-Entwicklung in einem großen Maßstab zu stärken.
Cyber-Resilienz-Gesetz erklärt: Was das für die Entwicklung von Secure by Design-Software bedeutet
Erfahren Sie, was der EU Cyber Resilience Act (CRA) verlangt, für wen er gilt und wie sich Entwicklungsteams mit sicheren Methoden, der Vorbeugung von Sicherheitslücken und dem Aufbau von Fähigkeiten für Entwickler darauf vorbereiten können.
Enabler 1: Definierte und messbare Erfolgskriterien
Enabler 1 eröffnet unsere zehnteilige Reihe „Enabler of Success“ und zeigt, wie sichere Codierung mit Geschäftsergebnissen wie Risikominderung und Geschwindigkeit verbunden werden kann, um eine langfristige Programmreife zu erreichen.
