Ein genauerer Blick auf die MVCRequestMatcher Spring-Sicherheitslücke
Am 20. März 2023 veröffentlichte Spring Security Advisories eine Blogbeitrag Verweis auf eine intern entdeckte Sicherheitslücke, CVE-2023-20860. Es wurden keine detaillierten Informationen veröffentlicht, außer dass es sich um ein Problem mit der Zugangskontrolle im Zusammenhang mit der Verwendung von handelte MVC-Matcher. Die Spring-Entwickler haben das Problem behoben, und ein Versionsupdate wird empfohlen.
Möchten Sie eine Erfahrung aus erster Hand? Probiere die Mission hier aus.
Da Sicherheit unser Hauptaugenmerk ist bei Sicherer Codekrieger, haben wir beschlossen, uns eingehender mit dieser MVCRequestMatchers-Sicherheitslücke zu befassen und herauszufinden, wo das Kernproblem liegt.
Spring stellt die RequestMatcher-Schnittstelle bereit, um festzustellen, ob eine Anfrage einem Pfadmuster entspricht. Schauen Sie sich das Code-Snippet unten an, wo MVC-Matcher Die Hilfsmethode wird verwendet, um die Endpunkte zusammen mit ihren Authentifizierungs- und Autorisierungsanforderungen zu registrieren. Wir können zum Beispiel sehen, dass nur Benutzer in der ADMIN-Rolle auf das zugreifen können /logs/audit Endpunkt.
MvcMisMatcher?
Im Frühling ** ist ein Muster, das einer beliebigen Anzahl von Verzeichnissen und Unterverzeichnissen in einer URL entspricht. Zum Beispiel/Bankkonto/** würde allen URLs entsprechen, die mit beginnen /bankkonto/, einschließlich Unterverzeichnissen wie /bankkonto/dashboard/einstellungen.
Das * Ein Muster ist ein Muster, das mit jeder URL übereinstimmt und genau eine Ebene eines Unterverzeichnisses hat. Zum Beispiel /bankkonto/ * würde passen Bankkonto/Dashboard.
Bei der Konfiguration der Matcher mit *, Spring gibt an, dass „eine Diskrepanz beim Musterabgleich zwischen Spring Security und Spring MVC“ stattgefunden hat und die Sicherheitslücke geschaffen hat.
Im Wesentlichen stimmt der Pfad aufgrund des Fehlens eines Trennzeichens vor dem doppelten Platzhalter nicht mit einer eingehenden Anfrage überein, da allen eingehenden Anfragen ein Schrägstrich vorangestellt wird. Das bedeutet, dass die Zugriffskontrollregeln nicht angewendet werden und jeder nicht authentifizierte Benutzer auf die Ressourcen zugreifen kann.
Schauen wir uns das an verpflichten das hat das Problem behoben.
Die prominenteste und wichtigste Änderung ist die Hinzufügung der Zeile 315, die das Umgehen der Autorisierungs- und Authentifizierungsregeln behebt. Es stellt sicher, dass jedem Pfadmuster, das übermittelt wird, ein Schrägstrich (/) vorangestellt wird.
404-Match wurde nicht gefunden
Beim Senden einer Webanfrage an /bankkonten/anzeigen die Spiel Die Methode analysiert und vergleicht die im Sicherheitsfilter definierten Muster mit dem angeforderten Pfad. Der Parser wandelt das angegebene Muster in einen Baum von Pfadelementen um.
Der Parser liest das erste Zeichen als SeparatorPath-Element. Dann liest es die Zeichenkettenzeichen bis zum nächsten Trennzeichen weiter und erstellt ein neues LiteralPath-Element.
Also, wo geht es schief bei der Verwendung ** als das Muster?
Es gibt zwar viele Pfadelementtypen, aber die interessantesten hier sind die Wildcard Path-Elementt und die Platzhalter für das RestPath-Element, mit ihren jeweiligen Zeichenkettendarstellungen: * und /**.
EIN Platzhalter-Path-Element entspricht null oder mehr Zeichen innerhalb eines einzelnen Pfadsegments, während ein Platzhalter für das RestPath-Element entspricht für sich genommen null oder mehr Pfadsegmente (einschließlich der Trennzeichen).
Letzteres gibt uns einen Hinweis darauf, was beim Einreichen schief geht. ** als Muster. Beim Parsen sucht es nach Mustern, aber ** beginnt nicht mit dem erwarteten Schrägstrich. Also anstatt ein zu werden Platzhalter für das RestPath-Element, es werden zwei aufeinanderfolgende Wildcard-Path-Elemente.
Als Nächstes wird das analysierte Muster verwendet, um es mit der angeforderten URL abzugleichen. Es wird erwartet, dass Pfade mit einem Schrägstrich beginnen, aber ein Platzhalter passt nicht zu den Trennzeichen.
Das bedeutet, dass anstelle eines Spielergebnis anfordern, eine Null wird zurückgegeben. Folglich werden die für diesen Matcher festgelegten Zugriffskontrollregeln nicht auf die angeforderte URL angewendet.
Spring hat das Problem behoben, indem ein Schrägstrich vorangestellt wurde. Mit anderen Worten, irgendein ** Muster wird /**, was bedeutet, dass es als analysiert werden kann Platzhalter für das RestPath-Element, und ein Spielergebnis anfordern wird zurückgegeben, da das Muster jetzt mit der angeforderten URL übereinstimmt.
Sicherheitslücke oder API-Missbrauch?
Es ist fraglich, ob dies als Sicherheitslücke betrachtet werden sollte, da der Code wie vorgesehen funktioniert. Das Problem liegt im Wesentlichen in der Tatsache, dass Frühlings-Dokumentation fehlt eine ausdrückliche Erwähnung, dass Pfade mit einem Trennzeichen beginnen sollten. Daher könnte es sich eher um einen API-Missbrauch als um einen Bug oder eine Sicherheitslücke handeln.
Am 20. März 2023 veröffentlichte Spring Security Advisories einen Blogbeitrag, in dem auf eine intern entdeckte Sicherheitslücke, CVE-2023-20860, verwiesen wurde. Es wurden keine detaillierten Informationen veröffentlicht, außer dass es sich um ein Problem mit der Zugriffskontrolle im Zusammenhang mit der Verwendung von `MVCMatchers` handelte. Die Spring-Entwickler haben das Problem behoben, und ein Versionsupdate wird empfohlen. Da Sicherheit unser Hauptaugenmerk bei Secure Code Warrior ist, haben wir uns entschlossen, uns eingehender mit dieser MVCRequestMatchers-Schwachstelle zu befassen und herauszufinden, wo das Kernproblem liegt.
Secure Code Warrior ist 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
Brysen ist Softwareentwickler bei Secure Code Warrior mit Schwerpunkt auf dem Schreiben von sicherem Code.
Am 20. März 2023 veröffentlichte Spring Security Advisories eine Blogbeitrag Verweis auf eine intern entdeckte Sicherheitslücke, CVE-2023-20860. Es wurden keine detaillierten Informationen veröffentlicht, außer dass es sich um ein Problem mit der Zugangskontrolle im Zusammenhang mit der Verwendung von handelte MVC-Matcher. Die Spring-Entwickler haben das Problem behoben, und ein Versionsupdate wird empfohlen.
Möchten Sie eine Erfahrung aus erster Hand? Probiere die Mission hier aus.
Da Sicherheit unser Hauptaugenmerk ist bei Sicherer Codekrieger, haben wir beschlossen, uns eingehender mit dieser MVCRequestMatchers-Sicherheitslücke zu befassen und herauszufinden, wo das Kernproblem liegt.
Spring stellt die RequestMatcher-Schnittstelle bereit, um festzustellen, ob eine Anfrage einem Pfadmuster entspricht. Schauen Sie sich das Code-Snippet unten an, wo MVC-Matcher Die Hilfsmethode wird verwendet, um die Endpunkte zusammen mit ihren Authentifizierungs- und Autorisierungsanforderungen zu registrieren. Wir können zum Beispiel sehen, dass nur Benutzer in der ADMIN-Rolle auf das zugreifen können /logs/audit Endpunkt.
MvcMisMatcher?
Im Frühling ** ist ein Muster, das einer beliebigen Anzahl von Verzeichnissen und Unterverzeichnissen in einer URL entspricht. Zum Beispiel/Bankkonto/** würde allen URLs entsprechen, die mit beginnen /bankkonto/, einschließlich Unterverzeichnissen wie /bankkonto/dashboard/einstellungen.
Das * Ein Muster ist ein Muster, das mit jeder URL übereinstimmt und genau eine Ebene eines Unterverzeichnisses hat. Zum Beispiel /bankkonto/ * würde passen Bankkonto/Dashboard.
Bei der Konfiguration der Matcher mit *, Spring gibt an, dass „eine Diskrepanz beim Musterabgleich zwischen Spring Security und Spring MVC“ stattgefunden hat und die Sicherheitslücke geschaffen hat.
Im Wesentlichen stimmt der Pfad aufgrund des Fehlens eines Trennzeichens vor dem doppelten Platzhalter nicht mit einer eingehenden Anfrage überein, da allen eingehenden Anfragen ein Schrägstrich vorangestellt wird. Das bedeutet, dass die Zugriffskontrollregeln nicht angewendet werden und jeder nicht authentifizierte Benutzer auf die Ressourcen zugreifen kann.
Schauen wir uns das an verpflichten das hat das Problem behoben.
Die prominenteste und wichtigste Änderung ist die Hinzufügung der Zeile 315, die das Umgehen der Autorisierungs- und Authentifizierungsregeln behebt. Es stellt sicher, dass jedem Pfadmuster, das übermittelt wird, ein Schrägstrich (/) vorangestellt wird.
404-Match wurde nicht gefunden
Beim Senden einer Webanfrage an /bankkonten/anzeigen die Spiel Die Methode analysiert und vergleicht die im Sicherheitsfilter definierten Muster mit dem angeforderten Pfad. Der Parser wandelt das angegebene Muster in einen Baum von Pfadelementen um.
Der Parser liest das erste Zeichen als SeparatorPath-Element. Dann liest es die Zeichenkettenzeichen bis zum nächsten Trennzeichen weiter und erstellt ein neues LiteralPath-Element.
Also, wo geht es schief bei der Verwendung ** als das Muster?
Es gibt zwar viele Pfadelementtypen, aber die interessantesten hier sind die Wildcard Path-Elementt und die Platzhalter für das RestPath-Element, mit ihren jeweiligen Zeichenkettendarstellungen: * und /**.
EIN Platzhalter-Path-Element entspricht null oder mehr Zeichen innerhalb eines einzelnen Pfadsegments, während ein Platzhalter für das RestPath-Element entspricht für sich genommen null oder mehr Pfadsegmente (einschließlich der Trennzeichen).
Letzteres gibt uns einen Hinweis darauf, was beim Einreichen schief geht. ** als Muster. Beim Parsen sucht es nach Mustern, aber ** beginnt nicht mit dem erwarteten Schrägstrich. Also anstatt ein zu werden Platzhalter für das RestPath-Element, es werden zwei aufeinanderfolgende Wildcard-Path-Elemente.
Als Nächstes wird das analysierte Muster verwendet, um es mit der angeforderten URL abzugleichen. Es wird erwartet, dass Pfade mit einem Schrägstrich beginnen, aber ein Platzhalter passt nicht zu den Trennzeichen.
Das bedeutet, dass anstelle eines Spielergebnis anfordern, eine Null wird zurückgegeben. Folglich werden die für diesen Matcher festgelegten Zugriffskontrollregeln nicht auf die angeforderte URL angewendet.
Spring hat das Problem behoben, indem ein Schrägstrich vorangestellt wurde. Mit anderen Worten, irgendein ** Muster wird /**, was bedeutet, dass es als analysiert werden kann Platzhalter für das RestPath-Element, und ein Spielergebnis anfordern wird zurückgegeben, da das Muster jetzt mit der angeforderten URL übereinstimmt.
Sicherheitslücke oder API-Missbrauch?
Es ist fraglich, ob dies als Sicherheitslücke betrachtet werden sollte, da der Code wie vorgesehen funktioniert. Das Problem liegt im Wesentlichen in der Tatsache, dass Frühlings-Dokumentation fehlt eine ausdrückliche Erwähnung, dass Pfade mit einem Trennzeichen beginnen sollten. Daher könnte es sich eher um einen API-Missbrauch als um einen Bug oder eine Sicherheitslücke handeln.
Am 20. März 2023 veröffentlichte Spring Security Advisories eine Blogbeitrag Verweis auf eine intern entdeckte Sicherheitslücke, CVE-2023-20860. Es wurden keine detaillierten Informationen veröffentlicht, außer dass es sich um ein Problem mit der Zugangskontrolle im Zusammenhang mit der Verwendung von handelte MVC-Matcher. Die Spring-Entwickler haben das Problem behoben, und ein Versionsupdate wird empfohlen.
Möchten Sie eine Erfahrung aus erster Hand? Probiere die Mission hier aus.
Da Sicherheit unser Hauptaugenmerk ist bei Sicherer Codekrieger, haben wir beschlossen, uns eingehender mit dieser MVCRequestMatchers-Sicherheitslücke zu befassen und herauszufinden, wo das Kernproblem liegt.
Spring stellt die RequestMatcher-Schnittstelle bereit, um festzustellen, ob eine Anfrage einem Pfadmuster entspricht. Schauen Sie sich das Code-Snippet unten an, wo MVC-Matcher Die Hilfsmethode wird verwendet, um die Endpunkte zusammen mit ihren Authentifizierungs- und Autorisierungsanforderungen zu registrieren. Wir können zum Beispiel sehen, dass nur Benutzer in der ADMIN-Rolle auf das zugreifen können /logs/audit Endpunkt.
MvcMisMatcher?
Im Frühling ** ist ein Muster, das einer beliebigen Anzahl von Verzeichnissen und Unterverzeichnissen in einer URL entspricht. Zum Beispiel/Bankkonto/** würde allen URLs entsprechen, die mit beginnen /bankkonto/, einschließlich Unterverzeichnissen wie /bankkonto/dashboard/einstellungen.
Das * Ein Muster ist ein Muster, das mit jeder URL übereinstimmt und genau eine Ebene eines Unterverzeichnisses hat. Zum Beispiel /bankkonto/ * würde passen Bankkonto/Dashboard.
Bei der Konfiguration der Matcher mit *, Spring gibt an, dass „eine Diskrepanz beim Musterabgleich zwischen Spring Security und Spring MVC“ stattgefunden hat und die Sicherheitslücke geschaffen hat.
Im Wesentlichen stimmt der Pfad aufgrund des Fehlens eines Trennzeichens vor dem doppelten Platzhalter nicht mit einer eingehenden Anfrage überein, da allen eingehenden Anfragen ein Schrägstrich vorangestellt wird. Das bedeutet, dass die Zugriffskontrollregeln nicht angewendet werden und jeder nicht authentifizierte Benutzer auf die Ressourcen zugreifen kann.
Schauen wir uns das an verpflichten das hat das Problem behoben.
Die prominenteste und wichtigste Änderung ist die Hinzufügung der Zeile 315, die das Umgehen der Autorisierungs- und Authentifizierungsregeln behebt. Es stellt sicher, dass jedem Pfadmuster, das übermittelt wird, ein Schrägstrich (/) vorangestellt wird.
404-Match wurde nicht gefunden
Beim Senden einer Webanfrage an /bankkonten/anzeigen die Spiel Die Methode analysiert und vergleicht die im Sicherheitsfilter definierten Muster mit dem angeforderten Pfad. Der Parser wandelt das angegebene Muster in einen Baum von Pfadelementen um.
Der Parser liest das erste Zeichen als SeparatorPath-Element. Dann liest es die Zeichenkettenzeichen bis zum nächsten Trennzeichen weiter und erstellt ein neues LiteralPath-Element.
Also, wo geht es schief bei der Verwendung ** als das Muster?
Es gibt zwar viele Pfadelementtypen, aber die interessantesten hier sind die Wildcard Path-Elementt und die Platzhalter für das RestPath-Element, mit ihren jeweiligen Zeichenkettendarstellungen: * und /**.
EIN Platzhalter-Path-Element entspricht null oder mehr Zeichen innerhalb eines einzelnen Pfadsegments, während ein Platzhalter für das RestPath-Element entspricht für sich genommen null oder mehr Pfadsegmente (einschließlich der Trennzeichen).
Letzteres gibt uns einen Hinweis darauf, was beim Einreichen schief geht. ** als Muster. Beim Parsen sucht es nach Mustern, aber ** beginnt nicht mit dem erwarteten Schrägstrich. Also anstatt ein zu werden Platzhalter für das RestPath-Element, es werden zwei aufeinanderfolgende Wildcard-Path-Elemente.
Als Nächstes wird das analysierte Muster verwendet, um es mit der angeforderten URL abzugleichen. Es wird erwartet, dass Pfade mit einem Schrägstrich beginnen, aber ein Platzhalter passt nicht zu den Trennzeichen.
Das bedeutet, dass anstelle eines Spielergebnis anfordern, eine Null wird zurückgegeben. Folglich werden die für diesen Matcher festgelegten Zugriffskontrollregeln nicht auf die angeforderte URL angewendet.
Spring hat das Problem behoben, indem ein Schrägstrich vorangestellt wurde. Mit anderen Worten, irgendein ** Muster wird /**, was bedeutet, dass es als analysiert werden kann Platzhalter für das RestPath-Element, und ein Spielergebnis anfordern wird zurückgegeben, da das Muster jetzt mit der angeforderten URL übereinstimmt.
Sicherheitslücke oder API-Missbrauch?
Es ist fraglich, ob dies als Sicherheitslücke betrachtet werden sollte, da der Code wie vorgesehen funktioniert. Das Problem liegt im Wesentlichen in der Tatsache, dass Frühlings-Dokumentation fehlt eine ausdrückliche Erwähnung, dass Pfade mit einem Trennzeichen beginnen sollten. Daher könnte es sich eher um einen API-Missbrauch als um einen Bug oder eine Sicherheitslücke handeln.
Klicken Sie auf den Link unten und laden Sie das PDF dieser Ressource herunter.
Secure Code Warrior ist 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
Testing our mission, experience the effects own, and learn you can avoid to make a like error.
Probiere es jetzt ausBrysen ist Softwareentwickler bei Secure Code Warrior mit Schwerpunkt auf dem Schreiben von sicherem Code.
Am 20. März 2023 veröffentlichte Spring Security Advisories eine Blogbeitrag Verweis auf eine intern entdeckte Sicherheitslücke, CVE-2023-20860. Es wurden keine detaillierten Informationen veröffentlicht, außer dass es sich um ein Problem mit der Zugangskontrolle im Zusammenhang mit der Verwendung von handelte MVC-Matcher. Die Spring-Entwickler haben das Problem behoben, und ein Versionsupdate wird empfohlen.
Möchten Sie eine Erfahrung aus erster Hand? Probiere die Mission hier aus.
Da Sicherheit unser Hauptaugenmerk ist bei Sicherer Codekrieger, haben wir beschlossen, uns eingehender mit dieser MVCRequestMatchers-Sicherheitslücke zu befassen und herauszufinden, wo das Kernproblem liegt.
Spring stellt die RequestMatcher-Schnittstelle bereit, um festzustellen, ob eine Anfrage einem Pfadmuster entspricht. Schauen Sie sich das Code-Snippet unten an, wo MVC-Matcher Die Hilfsmethode wird verwendet, um die Endpunkte zusammen mit ihren Authentifizierungs- und Autorisierungsanforderungen zu registrieren. Wir können zum Beispiel sehen, dass nur Benutzer in der ADMIN-Rolle auf das zugreifen können /logs/audit Endpunkt.
MvcMisMatcher?
Im Frühling ** ist ein Muster, das einer beliebigen Anzahl von Verzeichnissen und Unterverzeichnissen in einer URL entspricht. Zum Beispiel/Bankkonto/** würde allen URLs entsprechen, die mit beginnen /bankkonto/, einschließlich Unterverzeichnissen wie /bankkonto/dashboard/einstellungen.
Das * Ein Muster ist ein Muster, das mit jeder URL übereinstimmt und genau eine Ebene eines Unterverzeichnisses hat. Zum Beispiel /bankkonto/ * würde passen Bankkonto/Dashboard.
Bei der Konfiguration der Matcher mit *, Spring gibt an, dass „eine Diskrepanz beim Musterabgleich zwischen Spring Security und Spring MVC“ stattgefunden hat und die Sicherheitslücke geschaffen hat.
Im Wesentlichen stimmt der Pfad aufgrund des Fehlens eines Trennzeichens vor dem doppelten Platzhalter nicht mit einer eingehenden Anfrage überein, da allen eingehenden Anfragen ein Schrägstrich vorangestellt wird. Das bedeutet, dass die Zugriffskontrollregeln nicht angewendet werden und jeder nicht authentifizierte Benutzer auf die Ressourcen zugreifen kann.
Schauen wir uns das an verpflichten das hat das Problem behoben.
Die prominenteste und wichtigste Änderung ist die Hinzufügung der Zeile 315, die das Umgehen der Autorisierungs- und Authentifizierungsregeln behebt. Es stellt sicher, dass jedem Pfadmuster, das übermittelt wird, ein Schrägstrich (/) vorangestellt wird.
404-Match wurde nicht gefunden
Beim Senden einer Webanfrage an /bankkonten/anzeigen die Spiel Die Methode analysiert und vergleicht die im Sicherheitsfilter definierten Muster mit dem angeforderten Pfad. Der Parser wandelt das angegebene Muster in einen Baum von Pfadelementen um.
Der Parser liest das erste Zeichen als SeparatorPath-Element. Dann liest es die Zeichenkettenzeichen bis zum nächsten Trennzeichen weiter und erstellt ein neues LiteralPath-Element.
Also, wo geht es schief bei der Verwendung ** als das Muster?
Es gibt zwar viele Pfadelementtypen, aber die interessantesten hier sind die Wildcard Path-Elementt und die Platzhalter für das RestPath-Element, mit ihren jeweiligen Zeichenkettendarstellungen: * und /**.
EIN Platzhalter-Path-Element entspricht null oder mehr Zeichen innerhalb eines einzelnen Pfadsegments, während ein Platzhalter für das RestPath-Element entspricht für sich genommen null oder mehr Pfadsegmente (einschließlich der Trennzeichen).
Letzteres gibt uns einen Hinweis darauf, was beim Einreichen schief geht. ** als Muster. Beim Parsen sucht es nach Mustern, aber ** beginnt nicht mit dem erwarteten Schrägstrich. Also anstatt ein zu werden Platzhalter für das RestPath-Element, es werden zwei aufeinanderfolgende Wildcard-Path-Elemente.
Als Nächstes wird das analysierte Muster verwendet, um es mit der angeforderten URL abzugleichen. Es wird erwartet, dass Pfade mit einem Schrägstrich beginnen, aber ein Platzhalter passt nicht zu den Trennzeichen.
Das bedeutet, dass anstelle eines Spielergebnis anfordern, eine Null wird zurückgegeben. Folglich werden die für diesen Matcher festgelegten Zugriffskontrollregeln nicht auf die angeforderte URL angewendet.
Spring hat das Problem behoben, indem ein Schrägstrich vorangestellt wurde. Mit anderen Worten, irgendein ** Muster wird /**, was bedeutet, dass es als analysiert werden kann Platzhalter für das RestPath-Element, und ein Spielergebnis anfordern wird zurückgegeben, da das Muster jetzt mit der angeforderten URL übereinstimmt.
Sicherheitslücke oder API-Missbrauch?
Es ist fraglich, ob dies als Sicherheitslücke betrachtet werden sollte, da der Code wie vorgesehen funktioniert. Das Problem liegt im Wesentlichen in der Tatsache, dass Frühlings-Dokumentation fehlt eine ausdrückliche Erwähnung, dass Pfade mit einem Trennzeichen beginnen sollten. Daher könnte es sich eher um einen API-Missbrauch als um einen Bug oder eine Sicherheitslücke handeln.
Inhaltsverzeichniss
Secure Code Warrior ist 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.
%20(1).avif)
.avif)
Threat Modeling with AI: Turning Every Developer into a Threat Modeler
Walk away better equipped to help developers combine threat modeling ideas and techniques with the AI tools they're already using to strengthen security, improve collaboration, and build more resilient software from the start.
Ressourcen für den Einstieg
Cybermon is back: 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.
