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 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 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
Die Leistungsfähigkeit von OpenText Application Security + Secure Code Warrior
OpenText Application Security and Secure Code Warrior combine vulnerability detection with AI Software Governance and developer capability. Together, they help organizations reduce risk, strengthen secure coding practices, and confidently adopt AI-driven development.
Secure Code Warrior corporate overview
Secure Code Warrior is an AI Software Governance platform designed to enable organizations to safely adopt AI-driven development by bridging the gap between development velocity and enterprise security. The platform addresses the "Visibility Gap," where security teams often lack insights into shadow AI coding tools and the origins of production code.
Themen und Inhalte der Schulung zu sicherem Code
Our industry-leading content is always evolving to fit the ever changing software development landscape with your role in mind. Topics covering everything from AI to XQuery Injection, offered for a variety of roles from Architects and Engineers to Product Managers and QA. Get a sneak peek of what our content catalog has to offer by topic and role.
Cyber Resilience Act (CRA) – Angepasste Lernpfade
SCW unterstützt die Vorbereitung auf den Cyber Resilience Act (CRA) mit CRA-konformen Quests und konzeptionellen Lernsammlungen, die Entwicklungsteams dabei helfen, die CRA-Sicherheitsentwicklungsprinzipien „Secure by Design“, SDLC und sichere Codierungskompetenzen zu verinnerlichen.
Ressourcen für den Einstieg
Observe and Secure the ADLC: A Four-Point Framework for CISOs and Development Teams Using AI
While development teams look to make the most of GenAI’s undeniable benefits, we’d like to propose a four-point foundational framework that will allow security leaders to deploy AI coding tools and agents with a higher, more relevant standard of security best practices. It details exactly what enterprises can do to ensure safe, secure code development right now, and as agentic AI becomes an even bigger factor in the future.
KI kann Code schreiben und überprüfen – aber das Risiko tragen weiterhin die Menschen.
Die Einführung von Claude Code Security durch Anthropic markiert einen entscheidenden Schnittpunkt zwischen KI-gestützter Softwareentwicklung und der rasanten Weiterentwicklung unserer Herangehensweise an moderne Cybersicherheit.