Ein genauerer Blick auf die mvcRequestMatcher Spring-Schwachstelle
Am 20. März 2023 veröffentlichte Spring Security Advisories einen Blogbeitrag, der sich auf eine intern entdeckte Sicherheitslücke CVE-2023-20860 bezog. Es wurden keine detaillierten Informationen bekannt gegeben, außer dass es sich um ein Problem der Zugriffskontrolle bei der Verwendung von mvcMatchers handelt. Die Spring-Entwickler haben das Problem behoben, und es wird ein Versionsupdate empfohlen.
Möchten Sie eine Erfahrung aus erster Hand machen? Probieren Sie die Mission hier aus.
Da Sicherheit unser Hauptaugenmerk bei Secure Code Warriorist, haben wir uns entschlossen, diese mvcRequestMatchers-Schwachstelle genauer zu untersuchen und herauszufinden, wo das Kernproblem liegt.
Spring bietet die RequestMatcher-Schnittstelle, um festzustellen, ob eine Anfrage mit einem Pfadmuster übereinstimmt. Schauen Sie sich den folgenden Codeausschnitt an, in dem die Hilfsmethode mvcMatchers verwendet wird, um die Endpunkte zusammen mit ihren Authentifizierungs- und Autorisierungsanforderungen zu registrieren. Zum Beispiel können wir sehen, dass nur Benutzer mit der Rolle ADMIN auf den Endpunkt /logs/audit zugreifen können.

MvcMisMatchers?
In Spring ist ** ein Muster, das mit einer beliebigen Anzahl von Verzeichnissen und Unterverzeichnissen in einer URL übereinstimmt. Zum Beispiel würde /bankaccount/** allen URLs entsprechen, die mit /bankaccount/ beginnen, einschließlich Unterverzeichnissen wie /bankaccount/dashboard/settings.
Das *-Muster ist ein Muster, das mit jeder URL übereinstimmt und genau eine Ebene eines Unterverzeichnisses hat. Zum Beispiel würde /bankaccount/* auf bankaccount/dashboard passen .
Bei der Konfiguration der Matcher mit * stellt Spring fest, dass "eine Fehlanpassung beim Pattern-Matching zwischen Spring Security und Spr ing MVC" stattgefunden hat, wodurch die Schwachstelle entstand.
Da dem doppelten Platzhalter kein Trennzeichen vorangestellt ist, passt der Pfad nicht zu einer eingehenden Anfrage, da allen eingehenden Anfragen ein Schrägstrich vorangestellt wird. Dies bedeutet, dass die Zugriffskontrollregeln nicht angewendet werden und jeder nicht authentifizierte Benutzer auf die Ressourcen zugreifen kann.
Werfen wir einen Blick auf den Commit, der das Problem behoben hat.

Die auffälligste und wichtigste Änderung ist die Hinzufügung von Zeile 315, mit der die Umgehung der Autorisierungs- und Authentifizierungsregeln behoben wird. Sie stellt sicher, dass jedem Pfadmuster, das übermittelt wird, ein Schrägstrich (/) vorangestellt wird.
404 Treffer nicht gefunden

Beim Senden einer Webanforderung an /bankaccounts/view wird die Match-Methode die im Sicherheitsfilter definierten Muster analysieren und mit dem angeforderten Pfad vergleichen. Der Parser wandelt das angegebene Muster in einen Baum von Pfadelementen um.

Der Parser liest das erste Zeichen als SeparatorPathElement. Er setzt dann das Lesen der Zeichenfolgen bis zum nächsten Trennzeichen fort und erstellt ein neues LiteralPathElement.
Was läuft also schief, wenn ** als Muster verwendet wird?
Es gibt zwar eine Vielzahl von Pfadelementtypen, aber die interessantesten sind das WildcardPathElementund das WildcardTheRestPathElement mit ihren jeweiligen Zeichenkettendarstellungen: * und /**.
Ein WildcardPathElement stimmt mit null oder mehr Zeichen innerhalb eines einzelnen Pfadsegments überein, während ein WildcardTheRestPathElement mit null oder mehr Pfadsegmenten allein übereinstimmt (einschließlich der Trennzeichen).
Letzteres gibt uns einen Hinweis darauf, was falsch läuft, wenn ** als Muster eingegeben wird. Beim Parsen wird nach Mustern gesucht, aber ** beginnt nicht mit dem erwarteten Schrägstrich. Anstatt also ein WildcardTheRestPathElement zu werden, wird es zu zwei aufeinanderfolgenden WildcardPathElementen.
Anschließend wird das geparste Muster zum Abgleich mit der angeforderten URL verwendet. Es wird erwartet, dass Pfade mit einem Schrägstrich beginnen, aber ein Platzhalter passt nicht auf Trennzeichen.

Dies bedeutet, dass anstelle eines RequestMatchResult ein Nullwert zurückgegeben wird. Folglich werden die Zugriffskontrollregeln, die diesem Abgleicher zugewiesen wurden, nicht auf die angeforderte URL angewendet.
Spring hat das Problem behoben, indem ein Schrägstrich vorangestellt wurde. Mit anderen Worten: Jedes **-Muster wird zu /**, d. h. es kann als WildcardTheRestPathElement geparst werden, und es wird ein RequestMatchResult zurückgegeben, da das Muster nun mit der angeforderten URL übereinstimmt.
Schwachstelle oder API-Missbrauch?
Es ist fraglich, ob dies als Schwachstelle betrachtet werden sollte, da der Code wie vorgesehen funktioniert. Das Problem liegt im Wesentlichen darin, dass in der Spring-Dokumentation nicht ausdrücklich erwähnt wird, dass Pfade mit einem Trennzeichen beginnen sollten. Daher könnte es eher als ein Fall von API-Missbrauch und nicht als ein Fehler oder eine Schwachstelle angesehen werden.


Am 20. März 2023 veröffentlichte Spring Security Advisories einen Blogbeitrag, der sich auf eine intern entdeckte Sicherheitslücke CVE-2023-20860 bezog. Es wurden keine detaillierten Informationen bekannt gegeben, außer dass es sich um ein Problem der Zugriffskontrolle bei der Verwendung von "mvcMatchers" handelt. Die Spring-Entwickler haben das Problem behoben, und es wird ein Versions-Update empfohlen. Da Sicherheit unser Hauptaugenmerk bei Secure Code Warrior ist, haben wir uns entschlossen, diese mvcRequestMatchers-Schwachstelle genauer zu untersuchen und herauszufinden, wo das Kernproblem liegt.

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 buchenBrysen ist Softwareentwickler bei Secure Code Warrior mit Schwerpunkt auf dem Schreiben von sicherem Code.


Am 20. März 2023 veröffentlichte Spring Security Advisories einen Blogbeitrag, der sich auf eine intern entdeckte Sicherheitslücke CVE-2023-20860 bezog. Es wurden keine detaillierten Informationen bekannt gegeben, außer dass es sich um ein Problem der Zugriffskontrolle bei der Verwendung von mvcMatchers handelt. Die Spring-Entwickler haben das Problem behoben, und es wird ein Versionsupdate empfohlen.
Möchten Sie eine Erfahrung aus erster Hand machen? Probieren Sie die Mission hier aus.
Da Sicherheit unser Hauptaugenmerk bei Secure Code Warriorist, haben wir uns entschlossen, diese mvcRequestMatchers-Schwachstelle genauer zu untersuchen und herauszufinden, wo das Kernproblem liegt.
Spring bietet die RequestMatcher-Schnittstelle, um festzustellen, ob eine Anfrage mit einem Pfadmuster übereinstimmt. Schauen Sie sich den folgenden Codeausschnitt an, in dem die Hilfsmethode mvcMatchers verwendet wird, um die Endpunkte zusammen mit ihren Authentifizierungs- und Autorisierungsanforderungen zu registrieren. Zum Beispiel können wir sehen, dass nur Benutzer mit der Rolle ADMIN auf den Endpunkt /logs/audit zugreifen können.

MvcMisMatchers?
In Spring ist ** ein Muster, das mit einer beliebigen Anzahl von Verzeichnissen und Unterverzeichnissen in einer URL übereinstimmt. Zum Beispiel würde /bankaccount/** allen URLs entsprechen, die mit /bankaccount/ beginnen, einschließlich Unterverzeichnissen wie /bankaccount/dashboard/settings.
Das *-Muster ist ein Muster, das mit jeder URL übereinstimmt und genau eine Ebene eines Unterverzeichnisses hat. Zum Beispiel würde /bankaccount/* auf bankaccount/dashboard passen .
Bei der Konfiguration der Matcher mit * stellt Spring fest, dass "eine Fehlanpassung beim Pattern-Matching zwischen Spring Security und Spr ing MVC" stattgefunden hat, wodurch die Schwachstelle entstand.
Da dem doppelten Platzhalter kein Trennzeichen vorangestellt ist, passt der Pfad nicht zu einer eingehenden Anfrage, da allen eingehenden Anfragen ein Schrägstrich vorangestellt wird. Dies bedeutet, dass die Zugriffskontrollregeln nicht angewendet werden und jeder nicht authentifizierte Benutzer auf die Ressourcen zugreifen kann.
Werfen wir einen Blick auf den Commit, der das Problem behoben hat.

Die auffälligste und wichtigste Änderung ist die Hinzufügung von Zeile 315, mit der die Umgehung der Autorisierungs- und Authentifizierungsregeln behoben wird. Sie stellt sicher, dass jedem Pfadmuster, das übermittelt wird, ein Schrägstrich (/) vorangestellt wird.
404 Treffer nicht gefunden

Beim Senden einer Webanforderung an /bankaccounts/view wird die Match-Methode die im Sicherheitsfilter definierten Muster analysieren und mit dem angeforderten Pfad vergleichen. Der Parser wandelt das angegebene Muster in einen Baum von Pfadelementen um.

Der Parser liest das erste Zeichen als SeparatorPathElement. Er setzt dann das Lesen der Zeichenfolgen bis zum nächsten Trennzeichen fort und erstellt ein neues LiteralPathElement.
Was läuft also schief, wenn ** als Muster verwendet wird?
Es gibt zwar eine Vielzahl von Pfadelementtypen, aber die interessantesten sind das WildcardPathElementund das WildcardTheRestPathElement mit ihren jeweiligen Zeichenkettendarstellungen: * und /**.
Ein WildcardPathElement stimmt mit null oder mehr Zeichen innerhalb eines einzelnen Pfadsegments überein, während ein WildcardTheRestPathElement mit null oder mehr Pfadsegmenten allein übereinstimmt (einschließlich der Trennzeichen).
Letzteres gibt uns einen Hinweis darauf, was falsch läuft, wenn ** als Muster eingegeben wird. Beim Parsen wird nach Mustern gesucht, aber ** beginnt nicht mit dem erwarteten Schrägstrich. Anstatt also ein WildcardTheRestPathElement zu werden, wird es zu zwei aufeinanderfolgenden WildcardPathElementen.
Anschließend wird das geparste Muster zum Abgleich mit der angeforderten URL verwendet. Es wird erwartet, dass Pfade mit einem Schrägstrich beginnen, aber ein Platzhalter passt nicht auf Trennzeichen.

Dies bedeutet, dass anstelle eines RequestMatchResult ein Nullwert zurückgegeben wird. Folglich werden die Zugriffskontrollregeln, die diesem Abgleicher zugewiesen wurden, nicht auf die angeforderte URL angewendet.
Spring hat das Problem behoben, indem ein Schrägstrich vorangestellt wurde. Mit anderen Worten: Jedes **-Muster wird zu /**, d. h. es kann als WildcardTheRestPathElement geparst werden, und es wird ein RequestMatchResult zurückgegeben, da das Muster nun mit der angeforderten URL übereinstimmt.
Schwachstelle oder API-Missbrauch?
Es ist fraglich, ob dies als Schwachstelle betrachtet werden sollte, da der Code wie vorgesehen funktioniert. Das Problem liegt im Wesentlichen darin, dass in der Spring-Dokumentation nicht ausdrücklich erwähnt wird, dass Pfade mit einem Trennzeichen beginnen sollten. Daher könnte es eher als ein Fall von API-Missbrauch und nicht als ein Fehler oder eine Schwachstelle angesehen werden.

Am 20. März 2023 veröffentlichte Spring Security Advisories einen Blogbeitrag, der sich auf eine intern entdeckte Sicherheitslücke CVE-2023-20860 bezog. Es wurden keine detaillierten Informationen bekannt gegeben, außer dass es sich um ein Problem der Zugriffskontrolle bei der Verwendung von mvcMatchers handelt. Die Spring-Entwickler haben das Problem behoben, und es wird ein Versionsupdate empfohlen.
Möchten Sie eine Erfahrung aus erster Hand machen? Probieren Sie die Mission hier aus.
Da Sicherheit unser Hauptaugenmerk bei Secure Code Warriorist, haben wir uns entschlossen, diese mvcRequestMatchers-Schwachstelle genauer zu untersuchen und herauszufinden, wo das Kernproblem liegt.
Spring bietet die RequestMatcher-Schnittstelle, um festzustellen, ob eine Anfrage mit einem Pfadmuster übereinstimmt. Schauen Sie sich den folgenden Codeausschnitt an, in dem die Hilfsmethode mvcMatchers verwendet wird, um die Endpunkte zusammen mit ihren Authentifizierungs- und Autorisierungsanforderungen zu registrieren. Zum Beispiel können wir sehen, dass nur Benutzer mit der Rolle ADMIN auf den Endpunkt /logs/audit zugreifen können.

MvcMisMatchers?
In Spring ist ** ein Muster, das mit einer beliebigen Anzahl von Verzeichnissen und Unterverzeichnissen in einer URL übereinstimmt. Zum Beispiel würde /bankaccount/** allen URLs entsprechen, die mit /bankaccount/ beginnen, einschließlich Unterverzeichnissen wie /bankaccount/dashboard/settings.
Das *-Muster ist ein Muster, das mit jeder URL übereinstimmt und genau eine Ebene eines Unterverzeichnisses hat. Zum Beispiel würde /bankaccount/* auf bankaccount/dashboard passen .
Bei der Konfiguration der Matcher mit * stellt Spring fest, dass "eine Fehlanpassung beim Pattern-Matching zwischen Spring Security und Spr ing MVC" stattgefunden hat, wodurch die Schwachstelle entstand.
Da dem doppelten Platzhalter kein Trennzeichen vorangestellt ist, passt der Pfad nicht zu einer eingehenden Anfrage, da allen eingehenden Anfragen ein Schrägstrich vorangestellt wird. Dies bedeutet, dass die Zugriffskontrollregeln nicht angewendet werden und jeder nicht authentifizierte Benutzer auf die Ressourcen zugreifen kann.
Werfen wir einen Blick auf den Commit, der das Problem behoben hat.

Die auffälligste und wichtigste Änderung ist die Hinzufügung von Zeile 315, mit der die Umgehung der Autorisierungs- und Authentifizierungsregeln behoben wird. Sie stellt sicher, dass jedem Pfadmuster, das übermittelt wird, ein Schrägstrich (/) vorangestellt wird.
404 Treffer nicht gefunden

Beim Senden einer Webanforderung an /bankaccounts/view wird die Match-Methode die im Sicherheitsfilter definierten Muster analysieren und mit dem angeforderten Pfad vergleichen. Der Parser wandelt das angegebene Muster in einen Baum von Pfadelementen um.

Der Parser liest das erste Zeichen als SeparatorPathElement. Er setzt dann das Lesen der Zeichenfolgen bis zum nächsten Trennzeichen fort und erstellt ein neues LiteralPathElement.
Was läuft also schief, wenn ** als Muster verwendet wird?
Es gibt zwar eine Vielzahl von Pfadelementtypen, aber die interessantesten sind das WildcardPathElementund das WildcardTheRestPathElement mit ihren jeweiligen Zeichenkettendarstellungen: * und /**.
Ein WildcardPathElement stimmt mit null oder mehr Zeichen innerhalb eines einzelnen Pfadsegments überein, während ein WildcardTheRestPathElement mit null oder mehr Pfadsegmenten allein übereinstimmt (einschließlich der Trennzeichen).
Letzteres gibt uns einen Hinweis darauf, was falsch läuft, wenn ** als Muster eingegeben wird. Beim Parsen wird nach Mustern gesucht, aber ** beginnt nicht mit dem erwarteten Schrägstrich. Anstatt also ein WildcardTheRestPathElement zu werden, wird es zu zwei aufeinanderfolgenden WildcardPathElementen.
Anschließend wird das geparste Muster zum Abgleich mit der angeforderten URL verwendet. Es wird erwartet, dass Pfade mit einem Schrägstrich beginnen, aber ein Platzhalter passt nicht auf Trennzeichen.

Dies bedeutet, dass anstelle eines RequestMatchResult ein Nullwert zurückgegeben wird. Folglich werden die Zugriffskontrollregeln, die diesem Abgleicher zugewiesen wurden, nicht auf die angeforderte URL angewendet.
Spring hat das Problem behoben, indem ein Schrägstrich vorangestellt wurde. Mit anderen Worten: Jedes **-Muster wird zu /**, d. h. es kann als WildcardTheRestPathElement geparst werden, und es wird ein RequestMatchResult zurückgegeben, da das Muster nun mit der angeforderten URL übereinstimmt.
Schwachstelle oder API-Missbrauch?
Es ist fraglich, ob dies als Schwachstelle betrachtet werden sollte, da der Code wie vorgesehen funktioniert. Das Problem liegt im Wesentlichen darin, dass in der Spring-Dokumentation nicht ausdrücklich erwähnt wird, dass Pfade mit einem Trennzeichen beginnen sollten. Daher könnte es eher als ein Fall von API-Missbrauch und nicht als ein Fehler oder eine Schwachstelle angesehen werden.

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
Probieren Sie unsere Mission aus, um die Auswirkungen selbst zu erleben und zu lernen, wie Sie ähnliche Fehler vermeiden können.
Jetzt ausprobierenBrysen ist Softwareentwickler bei Secure Code Warrior mit Schwerpunkt auf dem Schreiben von sicherem Code.
Am 20. März 2023 veröffentlichte Spring Security Advisories einen Blogbeitrag, der sich auf eine intern entdeckte Sicherheitslücke CVE-2023-20860 bezog. Es wurden keine detaillierten Informationen bekannt gegeben, außer dass es sich um ein Problem der Zugriffskontrolle bei der Verwendung von mvcMatchers handelt. Die Spring-Entwickler haben das Problem behoben, und es wird ein Versionsupdate empfohlen.
Möchten Sie eine Erfahrung aus erster Hand machen? Probieren Sie die Mission hier aus.
Da Sicherheit unser Hauptaugenmerk bei Secure Code Warriorist, haben wir uns entschlossen, diese mvcRequestMatchers-Schwachstelle genauer zu untersuchen und herauszufinden, wo das Kernproblem liegt.
Spring bietet die RequestMatcher-Schnittstelle, um festzustellen, ob eine Anfrage mit einem Pfadmuster übereinstimmt. Schauen Sie sich den folgenden Codeausschnitt an, in dem die Hilfsmethode mvcMatchers verwendet wird, um die Endpunkte zusammen mit ihren Authentifizierungs- und Autorisierungsanforderungen zu registrieren. Zum Beispiel können wir sehen, dass nur Benutzer mit der Rolle ADMIN auf den Endpunkt /logs/audit zugreifen können.

MvcMisMatchers?
In Spring ist ** ein Muster, das mit einer beliebigen Anzahl von Verzeichnissen und Unterverzeichnissen in einer URL übereinstimmt. Zum Beispiel würde /bankaccount/** allen URLs entsprechen, die mit /bankaccount/ beginnen, einschließlich Unterverzeichnissen wie /bankaccount/dashboard/settings.
Das *-Muster ist ein Muster, das mit jeder URL übereinstimmt und genau eine Ebene eines Unterverzeichnisses hat. Zum Beispiel würde /bankaccount/* auf bankaccount/dashboard passen .
Bei der Konfiguration der Matcher mit * stellt Spring fest, dass "eine Fehlanpassung beim Pattern-Matching zwischen Spring Security und Spr ing MVC" stattgefunden hat, wodurch die Schwachstelle entstand.
Da dem doppelten Platzhalter kein Trennzeichen vorangestellt ist, passt der Pfad nicht zu einer eingehenden Anfrage, da allen eingehenden Anfragen ein Schrägstrich vorangestellt wird. Dies bedeutet, dass die Zugriffskontrollregeln nicht angewendet werden und jeder nicht authentifizierte Benutzer auf die Ressourcen zugreifen kann.
Werfen wir einen Blick auf den Commit, der das Problem behoben hat.

Die auffälligste und wichtigste Änderung ist die Hinzufügung von Zeile 315, mit der die Umgehung der Autorisierungs- und Authentifizierungsregeln behoben wird. Sie stellt sicher, dass jedem Pfadmuster, das übermittelt wird, ein Schrägstrich (/) vorangestellt wird.
404 Treffer nicht gefunden

Beim Senden einer Webanforderung an /bankaccounts/view wird die Match-Methode die im Sicherheitsfilter definierten Muster analysieren und mit dem angeforderten Pfad vergleichen. Der Parser wandelt das angegebene Muster in einen Baum von Pfadelementen um.

Der Parser liest das erste Zeichen als SeparatorPathElement. Er setzt dann das Lesen der Zeichenfolgen bis zum nächsten Trennzeichen fort und erstellt ein neues LiteralPathElement.
Was läuft also schief, wenn ** als Muster verwendet wird?
Es gibt zwar eine Vielzahl von Pfadelementtypen, aber die interessantesten sind das WildcardPathElementund das WildcardTheRestPathElement mit ihren jeweiligen Zeichenkettendarstellungen: * und /**.
Ein WildcardPathElement stimmt mit null oder mehr Zeichen innerhalb eines einzelnen Pfadsegments überein, während ein WildcardTheRestPathElement mit null oder mehr Pfadsegmenten allein übereinstimmt (einschließlich der Trennzeichen).
Letzteres gibt uns einen Hinweis darauf, was falsch läuft, wenn ** als Muster eingegeben wird. Beim Parsen wird nach Mustern gesucht, aber ** beginnt nicht mit dem erwarteten Schrägstrich. Anstatt also ein WildcardTheRestPathElement zu werden, wird es zu zwei aufeinanderfolgenden WildcardPathElementen.
Anschließend wird das geparste Muster zum Abgleich mit der angeforderten URL verwendet. Es wird erwartet, dass Pfade mit einem Schrägstrich beginnen, aber ein Platzhalter passt nicht auf Trennzeichen.

Dies bedeutet, dass anstelle eines RequestMatchResult ein Nullwert zurückgegeben wird. Folglich werden die Zugriffskontrollregeln, die diesem Abgleicher zugewiesen wurden, nicht auf die angeforderte URL angewendet.
Spring hat das Problem behoben, indem ein Schrägstrich vorangestellt wurde. Mit anderen Worten: Jedes **-Muster wird zu /**, d. h. es kann als WildcardTheRestPathElement geparst werden, und es wird ein RequestMatchResult zurückgegeben, da das Muster nun mit der angeforderten URL übereinstimmt.
Schwachstelle oder API-Missbrauch?
Es ist fraglich, ob dies als Schwachstelle betrachtet werden sollte, da der Code wie vorgesehen funktioniert. Das Problem liegt im Wesentlichen darin, dass in der Spring-Dokumentation nicht ausdrücklich erwähnt wird, dass Pfade mit einem Trennzeichen beginnen sollten. Daher könnte es eher als ein Fall von API-Missbrauch und nicht als ein Fehler oder eine Schwachstelle angesehen werden.
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
Auf dem Weg zu Gold: Steigende Standards für sicheren Code bei Paysafe
Sehen Sie, wie die Partnerschaft von Paysafe mit Secure Code Warrior die Produktivität der Entwickler um 45 % steigerte und die Zahl der Code-Schwachstellen erheblich reduzierte.
Die Macht der Marke in AppSec DevSec DevSecOps (Was ist in einem Acrynym!?)
Für eine dauerhafte Wirkung von AppSec-Programmen braucht es mehr als nur Technik - es braucht eine starke Marke. Eine starke Identität stellt sicher, dass Ihre Initiativen auf Resonanz stoßen und ein nachhaltiges Engagement innerhalb Ihrer Entwicklergemeinschaft fördern.
Vertrauensagent: AI von Secure Code Warrior
Dieser One-Pager stellt den SCW Trust Agent: AI vor, eine neue Reihe von Funktionen, die tiefgreifende Beobachtbarkeit und Kontrolle über KI-Codierwerkzeuge bieten. Erfahren Sie, wie unsere Lösung die Nutzung von KI-Tools mit den Fähigkeiten von Entwicklern korreliert, um Sie beim Risikomanagement zu unterstützen, Ihren SDLC zu optimieren und sicherzustellen, dass jede Zeile des von KI generierten Codes sicher ist.
Vibe Coding: Praktischer Leitfaden zur Aktualisierung Ihrer AppSec-Strategie für KI
In diesem On-Demand-Video erfahren Sie, wie AppSec-Manager durch einen praktischen Ansatz, bei dem die Schulung im Vordergrund steht, in die Lage versetzt werden, KI zu fördern, anstatt sie zu blockieren. Wir zeigen Ihnen, wie Sie Secure Code Warrior (SCW) nutzen können, um Ihre AppSec-Strategie strategisch für das Zeitalter der KI-Codierassistenten zu aktualisieren.
Ressourcen für den Einstieg
Warum sich das Bewusstsein für Cybersicherheit im Zeitalter der KI weiterentwickeln muss
CISOs können sich nicht auf das gleiche alte Awareness-Handbuch verlassen. Im Zeitalter der KI müssen sie moderne Ansätze verfolgen, um Code, Teams und Unternehmen zu schützen.
Sicheres Coding im Zeitalter der KI: Testen Sie unsere neuen interaktiven KI-Herausforderungen
KI-gestütztes Coding verändert die Entwicklung. Testen Sie unsere neuen KI-Herausforderungen im Copilot-Stil, um Code in realistischen Workflows sicher zu prüfen, zu analysieren und zu korrigieren.