Neue Sicherheitslücken in Spring-Bibliotheken: Wie Sie wissen, ob Sie gefährdet sind und was Sie tun können
Kürzlich wurden in den Spring-Bibliotheken, einer der beliebtesten Bibliotheken in der Java-Community, zwei Schwachstellen im Zusammenhang mit Remote Code Execution (RCE) bekannt. Damit Sie leichter erkennen können, ob Sie für eine der beiden Schwachstellen 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.
Sicherheitsanfälligkeit 1 - "Spring4Shell" (CVE-2022-22965)
Am 29. März 2022 entdeckte die Community eine Reihe von Tweets mit Screenshots eines Proof of Concept für einen Exploit, der auf Spring Core (SC) abzielt und Remote Code Execution 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 ist bestätigt, dass nur Anwendungen, die auf Tomcat gehostet werden, für diesen neuen Exploit anfällig sind. Auch wenn der Angriff auf den Embedded Tomcat Servlet Container oder andere, nicht von Tomcat gehostete Anwendungen noch nicht erfolgreich war, schließt dies nicht aus, dass die Bedrohung in Zukunft auch für diese Frameworks erfolgreich sein könnte.
Spring hat eine offizielle Erklärung zu der Sicherheitslücke veröffentlicht, in der klargestellt wird, dass nach dem derzeitigen Kenntnisstand der Sicherheitslücke die folgenden Bedingungen erfüllt sein müssen, um angreifbar zu sein:
- JDK 9 oder höher
- Apache Tomcat als Servlet-Container
- Verpackt als traditionelle WAR (im Gegensatz zu einem 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"-Nutzung?
Die Ausnutzung beruht auf der Verwendung von "Data Binding" (org.springframework.web.bind.WebDataBinder) in Anfragen, die in der Methodensignatur Plain Old Java Objects (POJO) verwenden:
Die Klasse Foo ist eine POJO-Klasse, die wie folgt definiert werden könnte. Beachten Sie, dass die tatsächliche Klasse nicht wichtig ist, solange sie vom Class Loader geladen wird.
Wenn eine Anfrage von einer solchen Methode bearbeitet wird, wird der Class Loader verwendet, um die Klasse aufzulösen. Der Class Loader ist für das Laden von Klassen zur Laufzeit verantwortlich, ohne vorher alle möglichen Typen in den Speicher laden zu müssen. Er findet heraus, welche .jar-Datei zu laden ist, wenn eine neue Klasse verwendet wird.
Die aktuellsten und ausführlichsten Informationen zu dieser Sicherheitslücke finden Sie direkt bei Spring in deren Blogpost, einschließlich möglicher Korrekturen oder Umgehungen.
Sicherheitsanfälligkeit 2 - Spring Cloud-Funktion (CVE-2022-22963)
Am 27. März 2022 veröffentlichte Cyber Kendra Details über eine 0-Tage-Schwachstelle für Remote Code Execution (RCE) in Spring Cloud Functions, für die es keinen Patch gab. Die Schwachstelle wurde mit der ID CVE-2022-22963 gekennzeichnet : Spring Expression Resource Access Vulnerability.
Welche Anwendungen sind gefährdet?
Die Sicherheitslücke betraf Anwendungen unter diesen Bedingungen:
- JDK 9 oder neuere Version
- Spring Cloud Functions Version 3.1.6 (oder niedriger), 3.2.2 (oder niedriger), oder eine nicht unterstützte Version
Wie funktioniert die Ausbeutung?
Spring Cloud Function bietet Entwicklern die Möglichkeit, über die Eigenschaft spring.cloud.function.routing-expression zu konfigurieren, wie das Routing gehandhabt wird, was in der Regel über die Konfiguration oder den Code erfolgt. Dies ist eine leistungsstarke Fähigkeit, die die "Spring Expression Language" (SpEL) akzeptiert. Durch diese 0-Day-Schwachstelle haben wir erfahren, dass diese Eigenschaft über die HTTP-Header einer Anfrage gesetzt werden kann, was bedeutet, dass ein Angreifer SpEL-Code direkt in seine HTTP-Anfrage an einen RoutingFunction-Endpunkt einbetten und somit beliebigen Code ausführen kann.
Welche Schritte sollten die Nutzer unternehmen, um das Risiko zu mindern?
Spring hat die Versionen 3.1.7 und 3.2.3 veröffentlicht, um dieses Problem zu beheben, indem es nicht zulässt, dass diese Eigenschaft über HTTP-Header gesetzt wird, wodurch die Sicherheitslücke entschärft wird. Nach einem Upgrade auf eine der beiden Versionen sind keine weiteren Schritte erforderlich.
Möchten Sie mehr darüber erfahren, wie wir Entwicklern helfen, sicheren Code zu schreiben? Buchen Sie eine Demo oder lesen Sie unsere kostenlosen Richtlinien für sicheren Code auf Secure 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/
Kürzlich wurden in den Spring-Bibliotheken, einer der beliebtesten Bibliotheken in der Java-Community, 2 Sicherheitslücken im Zusammenhang mit Remote Code Execution (RCE) bekannt. Wir haben die bekannten Details für "Spring4Shell" und "Spring Cloud Function" aufgeschlüsselt, damit Sie wissen, ob Sie gefährdet sind und was zu tun ist, wenn dies der Fall ist.
Secure Code Warrior ist für Ihr Unternehmen da, um Sie dabei zu unterstützen, Ihren Code über den gesamten Lebenszyklus der Softwareentwicklung hinweg zu sichern und eine Kultur zu schaffen, in der Cybersicherheit an erster Stelle steht. Ganz gleich, ob Sie AppSec-Manager, Entwickler, CISO oder ein anderer Sicherheitsverantwortlicher sind, wir können Ihrem Unternehmen helfen, die mit unsicherem Code verbundenen Risiken zu reduzieren.
Demo buchen
Kürzlich wurden in den Spring-Bibliotheken, einer der beliebtesten Bibliotheken in der Java-Community, zwei Schwachstellen im Zusammenhang mit Remote Code Execution (RCE) bekannt. Damit Sie leichter erkennen können, ob Sie für eine der beiden Schwachstellen 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.
Sicherheitsanfälligkeit 1 - "Spring4Shell" (CVE-2022-22965)
Am 29. März 2022 entdeckte die Community eine Reihe von Tweets mit Screenshots eines Proof of Concept für einen Exploit, der auf Spring Core (SC) abzielt und Remote Code Execution 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 ist bestätigt, dass nur Anwendungen, die auf Tomcat gehostet werden, für diesen neuen Exploit anfällig sind. Auch wenn der Angriff auf den Embedded Tomcat Servlet Container oder andere, nicht von Tomcat gehostete Anwendungen noch nicht erfolgreich war, schließt dies nicht aus, dass die Bedrohung in Zukunft auch für diese Frameworks erfolgreich sein könnte.
Spring hat eine offizielle Erklärung zu der Sicherheitslücke veröffentlicht, in der klargestellt wird, dass nach dem derzeitigen Kenntnisstand der Sicherheitslücke die folgenden Bedingungen erfüllt sein müssen, um angreifbar zu sein:
- JDK 9 oder höher
- Apache Tomcat als Servlet-Container
- Verpackt als traditionelle WAR (im Gegensatz zu einem 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"-Nutzung?
Die Ausnutzung beruht auf der Verwendung von "Data Binding" (org.springframework.web.bind.WebDataBinder) in Anfragen, die in der Methodensignatur Plain Old Java Objects (POJO) verwenden:
Die Klasse Foo ist eine POJO-Klasse, die wie folgt definiert werden könnte. Beachten Sie, dass die tatsächliche Klasse nicht wichtig ist, solange sie vom Class Loader geladen wird.
Wenn eine Anfrage von einer solchen Methode bearbeitet wird, wird der Class Loader verwendet, um die Klasse aufzulösen. Der Class Loader ist für das Laden von Klassen zur Laufzeit verantwortlich, ohne vorher alle möglichen Typen in den Speicher laden zu müssen. Er findet heraus, welche .jar-Datei zu laden ist, wenn eine neue Klasse verwendet wird.
Die aktuellsten und ausführlichsten Informationen zu dieser Sicherheitslücke finden Sie direkt bei Spring in deren Blogpost, einschließlich möglicher Korrekturen oder Umgehungen.
Sicherheitsanfälligkeit 2 - Spring Cloud-Funktion (CVE-2022-22963)
Am 27. März 2022 veröffentlichte Cyber Kendra Details über eine 0-Tage-Schwachstelle für Remote Code Execution (RCE) in Spring Cloud Functions, für die es keinen Patch gab. Die Schwachstelle wurde mit der ID CVE-2022-22963 gekennzeichnet : Spring Expression Resource Access Vulnerability.
Welche Anwendungen sind gefährdet?
Die Sicherheitslücke betraf Anwendungen unter diesen Bedingungen:
- JDK 9 oder neuere Version
- Spring Cloud Functions Version 3.1.6 (oder niedriger), 3.2.2 (oder niedriger), oder eine nicht unterstützte Version
Wie funktioniert die Ausbeutung?
Spring Cloud Function bietet Entwicklern die Möglichkeit, über die Eigenschaft spring.cloud.function.routing-expression zu konfigurieren, wie das Routing gehandhabt wird, was in der Regel über die Konfiguration oder den Code erfolgt. Dies ist eine leistungsstarke Fähigkeit, die die "Spring Expression Language" (SpEL) akzeptiert. Durch diese 0-Day-Schwachstelle haben wir erfahren, dass diese Eigenschaft über die HTTP-Header einer Anfrage gesetzt werden kann, was bedeutet, dass ein Angreifer SpEL-Code direkt in seine HTTP-Anfrage an einen RoutingFunction-Endpunkt einbetten und somit beliebigen Code ausführen kann.
Welche Schritte sollten die Nutzer unternehmen, um das Risiko zu mindern?
Spring hat die Versionen 3.1.7 und 3.2.3 veröffentlicht, um dieses Problem zu beheben, indem es nicht zulässt, dass diese Eigenschaft über HTTP-Header gesetzt wird, wodurch die Sicherheitslücke entschärft wird. Nach einem Upgrade auf eine der beiden Versionen sind keine weiteren Schritte erforderlich.
Möchten Sie mehr darüber erfahren, wie wir Entwicklern helfen, sicheren Code zu schreiben? Buchen Sie eine Demo oder lesen Sie unsere kostenlosen Richtlinien für sicheren Code auf Secure 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/
Kürzlich wurden in den Spring-Bibliotheken, einer der beliebtesten Bibliotheken in der Java-Community, zwei Schwachstellen im Zusammenhang mit Remote Code Execution (RCE) bekannt. Damit Sie leichter erkennen können, ob Sie für eine der beiden Schwachstellen 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.
Sicherheitsanfälligkeit 1 - "Spring4Shell" (CVE-2022-22965)
Am 29. März 2022 entdeckte die Community eine Reihe von Tweets mit Screenshots eines Proof of Concept für einen Exploit, der auf Spring Core (SC) abzielt und Remote Code Execution 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 ist bestätigt, dass nur Anwendungen, die auf Tomcat gehostet werden, für diesen neuen Exploit anfällig sind. Auch wenn der Angriff auf den Embedded Tomcat Servlet Container oder andere, nicht von Tomcat gehostete Anwendungen noch nicht erfolgreich war, schließt dies nicht aus, dass die Bedrohung in Zukunft auch für diese Frameworks erfolgreich sein könnte.
Spring hat eine offizielle Erklärung zu der Sicherheitslücke veröffentlicht, in der klargestellt wird, dass nach dem derzeitigen Kenntnisstand der Sicherheitslücke die folgenden Bedingungen erfüllt sein müssen, um angreifbar zu sein:
- JDK 9 oder höher
- Apache Tomcat als Servlet-Container
- Verpackt als traditionelle WAR (im Gegensatz zu einem 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"-Nutzung?
Die Ausnutzung beruht auf der Verwendung von "Data Binding" (org.springframework.web.bind.WebDataBinder) in Anfragen, die in der Methodensignatur Plain Old Java Objects (POJO) verwenden:
Die Klasse Foo ist eine POJO-Klasse, die wie folgt definiert werden könnte. Beachten Sie, dass die tatsächliche Klasse nicht wichtig ist, solange sie vom Class Loader geladen wird.
Wenn eine Anfrage von einer solchen Methode bearbeitet wird, wird der Class Loader verwendet, um die Klasse aufzulösen. Der Class Loader ist für das Laden von Klassen zur Laufzeit verantwortlich, ohne vorher alle möglichen Typen in den Speicher laden zu müssen. Er findet heraus, welche .jar-Datei zu laden ist, wenn eine neue Klasse verwendet wird.
Die aktuellsten und ausführlichsten Informationen zu dieser Sicherheitslücke finden Sie direkt bei Spring in deren Blogpost, einschließlich möglicher Korrekturen oder Umgehungen.
Sicherheitsanfälligkeit 2 - Spring Cloud-Funktion (CVE-2022-22963)
Am 27. März 2022 veröffentlichte Cyber Kendra Details über eine 0-Tage-Schwachstelle für Remote Code Execution (RCE) in Spring Cloud Functions, für die es keinen Patch gab. Die Schwachstelle wurde mit der ID CVE-2022-22963 gekennzeichnet : Spring Expression Resource Access Vulnerability.
Welche Anwendungen sind gefährdet?
Die Sicherheitslücke betraf Anwendungen unter diesen Bedingungen:
- JDK 9 oder neuere Version
- Spring Cloud Functions Version 3.1.6 (oder niedriger), 3.2.2 (oder niedriger), oder eine nicht unterstützte Version
Wie funktioniert die Ausbeutung?
Spring Cloud Function bietet Entwicklern die Möglichkeit, über die Eigenschaft spring.cloud.function.routing-expression zu konfigurieren, wie das Routing gehandhabt wird, was in der Regel über die Konfiguration oder den Code erfolgt. Dies ist eine leistungsstarke Fähigkeit, die die "Spring Expression Language" (SpEL) akzeptiert. Durch diese 0-Day-Schwachstelle haben wir erfahren, dass diese Eigenschaft über die HTTP-Header einer Anfrage gesetzt werden kann, was bedeutet, dass ein Angreifer SpEL-Code direkt in seine HTTP-Anfrage an einen RoutingFunction-Endpunkt einbetten und somit beliebigen Code ausführen kann.
Welche Schritte sollten die Nutzer unternehmen, um das Risiko zu mindern?
Spring hat die Versionen 3.1.7 und 3.2.3 veröffentlicht, um dieses Problem zu beheben, indem es nicht zulässt, dass diese Eigenschaft über HTTP-Header gesetzt wird, wodurch die Sicherheitslücke entschärft wird. Nach einem Upgrade auf eine der beiden Versionen sind keine weiteren Schritte erforderlich.
Möchten Sie mehr darüber erfahren, wie wir Entwicklern helfen, sicheren Code zu schreiben? Buchen Sie eine Demo oder lesen Sie unsere kostenlosen Richtlinien für sicheren Code auf Secure 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 unten stehenden Link und laden Sie die PDF-Datei dieser Ressource herunter.
Secure Code Warrior ist für Ihr Unternehmen da, um Sie dabei zu unterstützen, Ihren Code über den gesamten Lebenszyklus der Softwareentwicklung hinweg zu sichern und eine Kultur zu schaffen, in der Cybersicherheit an erster Stelle steht. Ganz gleich, ob Sie AppSec-Manager, Entwickler, CISO oder ein anderer Sicherheitsverantwortlicher sind, wir können Ihrem Unternehmen helfen, die mit unsicherem Code verbundenen Risiken zu reduzieren.
Bericht ansehenDemo buchen
Kürzlich wurden in den Spring-Bibliotheken, einer der beliebtesten Bibliotheken in der Java-Community, zwei Schwachstellen im Zusammenhang mit Remote Code Execution (RCE) bekannt. Damit Sie leichter erkennen können, ob Sie für eine der beiden Schwachstellen 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.
Sicherheitsanfälligkeit 1 - "Spring4Shell" (CVE-2022-22965)
Am 29. März 2022 entdeckte die Community eine Reihe von Tweets mit Screenshots eines Proof of Concept für einen Exploit, der auf Spring Core (SC) abzielt und Remote Code Execution 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 ist bestätigt, dass nur Anwendungen, die auf Tomcat gehostet werden, für diesen neuen Exploit anfällig sind. Auch wenn der Angriff auf den Embedded Tomcat Servlet Container oder andere, nicht von Tomcat gehostete Anwendungen noch nicht erfolgreich war, schließt dies nicht aus, dass die Bedrohung in Zukunft auch für diese Frameworks erfolgreich sein könnte.
Spring hat eine offizielle Erklärung zu der Sicherheitslücke veröffentlicht, in der klargestellt wird, dass nach dem derzeitigen Kenntnisstand der Sicherheitslücke die folgenden Bedingungen erfüllt sein müssen, um angreifbar zu sein:
- JDK 9 oder höher
- Apache Tomcat als Servlet-Container
- Verpackt als traditionelle WAR (im Gegensatz zu einem 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"-Nutzung?
Die Ausnutzung beruht auf der Verwendung von "Data Binding" (org.springframework.web.bind.WebDataBinder) in Anfragen, die in der Methodensignatur Plain Old Java Objects (POJO) verwenden:
Die Klasse Foo ist eine POJO-Klasse, die wie folgt definiert werden könnte. Beachten Sie, dass die tatsächliche Klasse nicht wichtig ist, solange sie vom Class Loader geladen wird.
Wenn eine Anfrage von einer solchen Methode bearbeitet wird, wird der Class Loader verwendet, um die Klasse aufzulösen. Der Class Loader ist für das Laden von Klassen zur Laufzeit verantwortlich, ohne vorher alle möglichen Typen in den Speicher laden zu müssen. Er findet heraus, welche .jar-Datei zu laden ist, wenn eine neue Klasse verwendet wird.
Die aktuellsten und ausführlichsten Informationen zu dieser Sicherheitslücke finden Sie direkt bei Spring in deren Blogpost, einschließlich möglicher Korrekturen oder Umgehungen.
Sicherheitsanfälligkeit 2 - Spring Cloud-Funktion (CVE-2022-22963)
Am 27. März 2022 veröffentlichte Cyber Kendra Details über eine 0-Tage-Schwachstelle für Remote Code Execution (RCE) in Spring Cloud Functions, für die es keinen Patch gab. Die Schwachstelle wurde mit der ID CVE-2022-22963 gekennzeichnet : Spring Expression Resource Access Vulnerability.
Welche Anwendungen sind gefährdet?
Die Sicherheitslücke betraf Anwendungen unter diesen Bedingungen:
- JDK 9 oder neuere Version
- Spring Cloud Functions Version 3.1.6 (oder niedriger), 3.2.2 (oder niedriger), oder eine nicht unterstützte Version
Wie funktioniert die Ausbeutung?
Spring Cloud Function bietet Entwicklern die Möglichkeit, über die Eigenschaft spring.cloud.function.routing-expression zu konfigurieren, wie das Routing gehandhabt wird, was in der Regel über die Konfiguration oder den Code erfolgt. Dies ist eine leistungsstarke Fähigkeit, die die "Spring Expression Language" (SpEL) akzeptiert. Durch diese 0-Day-Schwachstelle haben wir erfahren, dass diese Eigenschaft über die HTTP-Header einer Anfrage gesetzt werden kann, was bedeutet, dass ein Angreifer SpEL-Code direkt in seine HTTP-Anfrage an einen RoutingFunction-Endpunkt einbetten und somit beliebigen Code ausführen kann.
Welche Schritte sollten die Nutzer unternehmen, um das Risiko zu mindern?
Spring hat die Versionen 3.1.7 und 3.2.3 veröffentlicht, um dieses Problem zu beheben, indem es nicht zulässt, dass diese Eigenschaft über HTTP-Header gesetzt wird, wodurch die Sicherheitslücke entschärft wird. Nach einem Upgrade auf eine der beiden Versionen sind keine weiteren Schritte erforderlich.
Möchten Sie mehr darüber erfahren, wie wir Entwicklern helfen, sicheren Code zu schreiben? Buchen Sie eine Demo oder lesen Sie unsere kostenlosen Richtlinien für sicheren Code auf Secure 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/
Inhaltsübersicht
Secure Code Warrior ist für Ihr Unternehmen da, um Sie dabei zu unterstützen, Ihren Code über den gesamten Lebenszyklus der Softwareentwicklung hinweg zu sichern und eine Kultur zu schaffen, in der Cybersicherheit an erster Stelle steht. Ganz gleich, ob Sie AppSec-Manager, Entwickler, CISO oder ein anderer Sicherheitsverantwortlicher sind, wir können Ihrem Unternehmen helfen, die mit unsicherem Code verbundenen Risiken zu reduzieren.
Demo buchenHerunterladenRessourcen für den Einstieg
Sicher durch Design: Definition von Best Practices, Befähigung von Entwicklern und Benchmarking von präventiven Sicherheitsergebnissen
In diesem Forschungspapier werden die Mitbegründer von Secure Code Warrior , Pieter Danhieux und Dr. Matias Madou, Ph.D., zusammen mit den Experten Chris Inglis, ehemaliger US National Cyber Director (jetzt strategischer Berater der Paladin Capital Group), und Devin Lynch, Senior Director, Paladin Global Institute, die wichtigsten Erkenntnisse aus mehr als zwanzig ausführlichen Interviews mit Sicherheitsverantwortlichen in Unternehmen, darunter CISOs, ein VP of Application Security und Software-Sicherheitsexperten, offenlegen.
Benchmarking von Sicherheitskompetenzen: Optimierung von Secure-by-Design im Unternehmen
Aussagekräftige Daten über den Erfolg von Secure-by-Design-Initiativen zu finden, ist bekanntermaßen schwierig. CISOs stehen oft vor der Herausforderung, den Return on Investment (ROI) und den Geschäftswert von Sicherheitsprogrammen sowohl auf Mitarbeiter- als auch auf Unternehmensebene nachzuweisen. Ganz zu schweigen davon, dass es für Unternehmen besonders schwierig ist, Erkenntnisse darüber zu gewinnen, wie ihre Organisation im Vergleich zu aktuellen Branchenstandards abschneidet. Die Nationale Cybersicherheitsstrategie des Präsidenten forderte die Beteiligten auf, "Sicherheit und Widerstandsfähigkeit durch Design" zu erreichen. Der Schlüssel zum Erfolg von Secure-by-Design-Initiativen liegt nicht nur darin, Entwicklern die nötigen Fähigkeiten zu vermitteln, um sicheren Code zu gewährleisten, sondern auch darin, den Aufsichtsbehörden zu versichern, dass diese Fähigkeiten vorhanden sind. In dieser Präsentation stellen wir eine Vielzahl von qualitativen und quantitativen Daten vor, die aus verschiedenen Primärquellen stammen, darunter interne Daten von über 250.000 Entwicklern, datengestützte Kundeneinblicke und öffentliche Studien. Auf der Grundlage dieser gesammelten Daten wollen wir eine Vision des aktuellen Stands von Secure-by-Design-Initiativen in verschiedenen Branchen vermitteln. Der Bericht zeigt auf, warum dieser Bereich derzeit nicht ausreichend genutzt wird, welche erheblichen Auswirkungen ein erfolgreiches Schulungsprogramm auf die Minderung von Cybersecurity-Risiken haben kann und welches Potenzial zur Beseitigung von Schwachstellen in einer Codebasis besteht.
Professionelle Dienstleistungen - Beschleunigen Sie mit Fachwissen
Das PSS-Team (Program Strategy Services) von Secure Code Warriorunterstützt Sie beim Aufbau, der Verbesserung und der Optimierung Ihres Programms für sichere Codierung. Ganz gleich, ob Sie neu anfangen oder Ihren Ansatz verfeinern möchten, unsere Experten bieten Ihnen maßgeschneiderte Beratung.
Themen und Inhalte der Schulung zu sicherem Code
Unsere branchenführenden Inhalte werden ständig weiterentwickelt, um sie an die sich ständig verändernde Softwareentwicklungslandschaft anzupassen und Ihre Rolle zu berücksichtigen. Die Themen reichen von KI bis XQuery Injection und werden für eine Vielzahl von Rollen angeboten, von Architekten und Ingenieuren bis hin zu Produktmanagern und QA. Verschaffen Sie sich einen kleinen Überblick über die Inhalte, die unser Katalog nach Thema und Rolle bietet.
Ressourcen für den Einstieg
Aufgedeckt: Wie die Cyber-Industrie "Secure by Design" definiert
In unserem neuesten Whitepaper haben sich unsere Mitbegründer Pieter Danhieux und Dr. Matias Madou, Ph.D., mit über zwanzig Sicherheitsverantwortlichen in Unternehmen, darunter CISOs, AppSec-Leiter und Sicherheitsexperten, zusammengesetzt, um die wichtigsten Teile dieses Puzzles herauszufinden und die Realität hinter der Secure by Design-Bewegung aufzudecken. Die Sicherheitsteams haben ein gemeinsames Ziel, aber kein gemeinsames Regelwerk.
Wird Vibe Coding Ihre Codebasis in eine Verbindungsparty verwandeln?
Vibe Coding ist wie eine College-Verbindungsparty, und AI ist das Herzstück aller Festivitäten, das Fass. Es macht eine Menge Spaß, sich auszutoben, kreativ zu werden und zu sehen, wohin die eigene Fantasie einen führen kann, aber nach ein paar Bierfässern ist das Trinken (oder die Verwendung von KI) in Maßen zweifellos die sicherere langfristige Lösung.
Entwicklergesteuerte Kodierung.
Sicher ist sicher.
Setzen Sie sich noch heute mit uns in Verbindung und machen Sie Softwaresicherheit zu einem festen Bestandteil Ihres Entwicklungsprozesses.
