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
Benchmarking von Sicherheitskompetenzen: Optimierung von Secure-by-Design im Unternehmen
Die Secure-by-Design-Bewegung ist die Zukunft der sicheren Softwareentwicklung. Erfahren Sie mehr über die wichtigsten Elemente, die Unternehmen berücksichtigen müssen, wenn sie über eine Secure-by-Design-Initiative nachdenken.
DigitalOcean verringert Sicherheitsverschuldung mit Secure Code Warrior
DigitalOceans Einsatz von Secure Code Warrior hat die Sicherheitsverschuldung deutlich reduziert, so dass sich die Teams stärker auf Innovation und Produktivität konzentrieren können. Die verbesserte Sicherheit hat die Produktqualität und den Wettbewerbsvorteil des Unternehmens gestärkt. Mit Blick auf die Zukunft wird der SCW Trust Score dem Unternehmen helfen, seine Sicherheitspraktiken weiter zu verbessern und Innovationen voranzutreiben.
Ressourcen für den Einstieg
Trust Score zeigt den Wert von Secure-by-Design-Upskilling-Initiativen
Unsere Forschung hat gezeigt, dass Schulungen für sicheren Code funktionieren. Trust Score verwendet einen Algorithmus, der auf mehr als 20 Millionen Lerndaten aus der Arbeit von mehr als 250.000 Lernenden in über 600 Organisationen basiert, und zeigt, wie effektiv die Initiative ist, um Schwachstellen zu beseitigen und wie man sie noch effektiver gestalten kann.
.png)
Reaktive versus präventive Sicherheit: Prävention ist das bessere Heilmittel
Der Gedanke, Legacy-Code und -Systeme zur gleichen Zeit wie neuere Anwendungen mit präventiver Sicherheit auszustatten, kann entmutigend erscheinen, aber ein Secure-by-Design-Ansatz, der durch die Weiterbildung von Entwicklern durchgesetzt wird, kann die besten Sicherheitsverfahren auf diese Systeme anwenden. Dies ist für viele Unternehmen die beste Chance, ihre Sicherheitslage zu verbessern.
Die Vorteile eines Benchmarking der Sicherheitskompetenzen von Entwicklern
Der zunehmende Fokus auf sicheren Code und Secure-by-Design-Prinzipien erfordert, dass Entwickler von Beginn des SDLC an in Cybersicherheit geschult werden, wobei Tools wie Secure Code Warrior's Trust Score dabei helfen, ihre Fortschritte zu messen und zu verbessern.
Wesentlicher Erfolg für Enterprise Secure-by-Design-Initiativen
Unser jüngstes Forschungspapier „Benchmarking Security Skills: Streamlining Secure-by-Design in the Enterprise“ ist das Ergebnis einer umfassenden Analyse echter Secure-by-Design-Initiativen auf Unternehmensebene und der Ableitung von Best-Practice-Ansätzen auf Grundlage datengesteuerter Erkenntnisse.
Entwicklergesteuerte Kodierung.
Sicher ist sicher.
Setzen Sie sich noch heute mit uns in Verbindung und machen Sie Softwaresicherheit zu einem festen Bestandteil Ihres Entwicklungsprozesses.
