Neue Risikokategorie in den OWASP Top Ten: Erwarten Sie das Unerwartete
Mit der Veröffentlichung der OWASP Top Ten für das Jahr 2025 gibt es für Unternehmen einige neue Risikokategorien, denen sie besondere Aufmerksamkeit schenken sollten, darunter eine brandneue Kategorie, die ein für alle Mal beweist, dass das, was man nicht weiß, einem tatsächlich schaden kann.
Die neue Kategorie " Mishandling of Exceptional Conditions" beschreibt, was schiefgehen kann, wenn Unternehmen nicht darauf vorbereitet sind, ungewöhnliche oder unvorhersehbare Situationen zu verhindern, zu erkennen und darauf zu reagieren. Laut OWASP kann diese Schwachstelle ausgelöst werden, wenn eine Anwendung nicht verhindert, dass etwas Ungewöhnliches passiert, ein Problem nicht erkennt, wenn es auftritt und/oder schlecht oder gar nicht reagiert, wenn eine unerwartete Situation auftritt.
Der Gedanke, dass Unternehmen auf das vorbereitet sein müssen, was sie nicht kommen sahen, spiegelt die Realität der heutigen hochgradig verteilten, vernetzten Systeme wider. Und es ist nicht so, dass OWASP über Probleme spricht, die nicht bekannt sind - die Fehlbehandlung von außergewöhnlichen Umständen enthält 24 gemeinsame Schwachstellenaufzählungen (CWEs). Es ist nur so, dass diese CWEs, die eine unsachgemäße Fehlerbehandlung, das Versagen beim Öffnen von Ereignissen, logische Fehler und andere Szenarien beinhalten, unter abnormalen Bedingungen auftreten können. Dies kann z. B. durch eine unzureichende Eingabevalidierung, Fehler auf hoher Ebene in den Verarbeitungsfunktionen und eine inkonsistente (oder nicht vorhandene) Behandlung von Ausnahmen geschehen. OWASP erklärt: "Jedes Mal, wenn eine Anwendung nicht weiß, was sie als nächstes tun soll, ist eine Ausnahmebedingung falsch behandelt worden."
Diese außergewöhnlichen Umstände können dazu führen, dass Systeme in einen unvorhersehbaren Zustand geraten, der zu Systemabstürzen, unerwartetem Verhalten und lang anhaltenden Sicherheitslücken führt. Der Schlüssel zur Vermeidung dieser Art von Störungen liegt darin, mit dem Schlimmsten zu rechnen und darauf vorbereitet zu sein, wenn das Unerwartete eintritt.
Außergewöhnliche Umstände und die Entwicklung der Top Ten
Die Zusammensetzung der alle vier Jahre erscheinenden Top-Ten-Liste der schwerwiegendsten Risiken für die Sicherheit von Webanwendungen ist über die Jahre hinweg recht stabil geblieben, wobei sich einige Kategorien in der Liste verschieben und vielleicht alle vier Jahre ein oder zwei neue hinzukommen. In der Ausgabe 2025 gibt es zwei neue Einträge, darunter die falsche Handhabung außergewöhnlicher Bedingungen, die auf Platz 10 landet. Die andere Kategorie, Software Supply Chain Failures, die auf Platz 3 steht, ist eine Erweiterung einer früheren Kategorie, Vulnerable and Outdated Components (Platz 6 im Jahr 2021), die nun ein breites Spektrum an Softwarekompromittierungen umfasst. (Für diejenigen, die auf dem Laufenden bleiben wollen: Die unzureichende Zugangskontrolle ist immer noch die Nummer 1).
Die Ausnahmebedingungen, die die neueste Kategorie bilden, können eine Vielzahl von Schwachstellen hervorrufen, von Logikfehlern über Überläufe und betrügerische Transaktionen bis hin zu Problemen mit dem Speicher, dem Timing, der Authentifizierung, Autorisierung und anderen Faktoren. Diese Arten von Schwachstellen können die Vertraulichkeit, Verfügbarkeit und Integrität eines Systems oder seiner Daten beeinträchtigen. Sie ermöglichen es einem Angreifer, beispielsweise die fehlerhafte Fehlerbehandlung einer Anwendung zu manipulieren, um die Schwachstelle auszunutzen, so OWASP.
Ein Beispiel für die Unfähigkeit, unerwartete Bedingungen zu bewältigen, ist der Fall, dass eine Anwendung während des Hochladens von Dateien bei einem Denial-of-Service-Angriff Ausnahmen feststellt, die Ressourcen danach aber nicht freigibt. In diesem Fall bleiben die Ressourcen gesperrt oder sind nicht verfügbar, was zu einer Erschöpfung der Ressourcen führt. Wenn ein Angreifer in eine mehrstufige Finanztransaktion eindringt, könnte ein System, das die Transaktion nicht zurücknimmt, sobald ein Fehler entdeckt wird, dem Angreifer die Möglichkeit geben, das Konto des Benutzers zu leeren. Wenn während einer Transaktion ein Fehler entdeckt wird, ist es sehr wichtig, die gesamte Transaktion zurückzusetzen und von vorne zu beginnen. Der Versuch, eine Transaktion in der Mitte des Prozesses wiederherzustellen, kann zu nicht wiederherstellbaren Fehlern führen.
Fail Closed vs. Fail Open
Was ist also der Unterschied zwischen diesen beiden Aktionen? Das wollen wir klären:
Fail Open: Wenn ein System "offen ausfällt", arbeitet es weiter oder bleibt "offen", wenn etwas schief geht. Dies ist nützlich, wenn es sehr wichtig ist, die Dinge am Laufen zu halten, kann aber für die Sicherheit riskant sein.
Geschlossen ausfallen: Wenn ein System "geschlossen ausfällt", schaltet es sich automatisch ab oder wird gesichert, wenn ein Problem auftritt. Dies ist aus der Sicht der Sicherheit sicherer, da es dazu beiträgt, unbefugten Zugriff zu verhindern.
Umgang mit unvorhergesehenen Fehlern
Um diese Art von Risiko zu vermeiden, muss man sich auf das Unbekannte vorbereiten. Dazu gehört, dass man in der Lage ist, jeden möglichen Systemfehler zu erkennen, wenn er auftritt, und Schritte zur Lösung des Problems zu unternehmen. Sie müssen in der Lage sein, den Benutzer ordnungsgemäß zu informieren (ohne dem Angreifer kritische Informationen preiszugeben), das Ereignis zu protokollieren und gegebenenfalls eine Warnung auszugeben.
Hier ist ein Beispiel für die Offenlegung eines SQL-Abfragefehlers zusammen mit dem Installationspfad der Website, der zur Identifizierung eines Injektionspunkts verwendet werden kann:
Warning: odbc_fetch_array() erwartet, dass Parameter /1 eine Ressource ist, boolean angegeben in D:\app\index_new.php auf Zeile 188
Ein System sollte idealerweise über einen globalen Exception-Handler verfügen, der übersehene Fehler abfängt, sowie über Funktionen wie Überwachungs- oder Beobachtungswerkzeuge oder eine Funktion, die wiederholte Fehler oder Muster erkennt, die auf einen laufenden Angriff hindeuten könnten. Dies kann dazu beitragen, Angriffe abzuwehren, die darauf abzielen, Schwächen des Unternehmens bei der Fehlerbehandlung auszunutzen.
Für eine Standard-Java-Webanwendung kann beispielsweise ein globaler Error-Handler auf der Ebene des web.xml-Deployment-Deskriptors konfiguriert werden - in diesem Fall eine Konfiguration, die ab der Servlet-Spezifikation Version 2.5 und höher verwendet wird.
<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
ns="http://java.sun.com/xml/ns/javaee"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd"
version="3.0">
...
<error-page>
<exception-type>java.lang.Exception</exception-type>
<location>/error.jsp</location>
</error-page>
...
</web-app>
Dieser kleine Codeblock sagt einer Java-Webanwendung, was zu tun ist, wenn hinter den Kulissen etwas schief läuft. Anstatt dem Benutzer eine verwirrende Fehlermeldung oder einen leeren Bildschirm anzuzeigen, fängt er das Problem ab und schickt ihn zu einer benutzerdefinierten Fehlerseite. In diesem Fall wäre das die Seite error.jsp.
Da er so eingestellt ist, dass er die allgemeinen java.lang.Exception-Typen behandelt, fungiert er als Master Error Handler für die gesamte Anwendung. Das bedeutet, dass Benutzer, egal wo ein Fehler auftritt, auf dieselbe freundliche, konsistente Fehlerseite umgeleitet werden, anstatt rohe technische Details zu sehen.
Dem Unerwarteten vorbeugen
Idealerweise sollten Unternehmen darauf hinarbeiten, das Auftreten von Ausnahmesituationen so weit wie möglich zu verhindern. Die Implementierung von Ratenbegrenzungen, Ressourcenkontingenten, Drosselungen und anderen Begrenzungen kann z. B. gegen Denial-of-Service- und Brute-Force-Angriffe helfen. Möglicherweise möchten Sie identische, sich wiederholende Fehler identifizieren und sie nur als Statistik erfassen, damit sie die automatische Protokollierung und Überwachung nicht beeinträchtigen. Ein System sollte auch Folgendes umfassen:
Strenge Eingabevalidierung, um sicherzustellen, dass nur ordnungsgemäß geformte und bereinigte Daten in den Arbeitsablauf gelangen. Sie sollte zu einem frühen Zeitpunkt im Datenfluss erfolgen, idealerweise, sobald Daten empfangen werden.
Bewährte Verfahren zur Fehlerbehandlung, um Fehler genau dort zu erkennen, wo sie auftreten. Sie sollten effizient behandelt werden: Weisen Sie die Benutzer eindeutig darauf hin, dass sie ein Protokoll führen und bei Bedarf Warnungen senden müssen. Ein globaler Fehlerhandler ist ebenfalls ideal, um alles abzufangen, was übersehen wurde.
Auch die allgemeine Transaktionssicherheit ist ein Muss. Immer "fail closed": Wenn etwas schief geht, rollen Sie die gesamte Transaktion zurück. Und versuchen Sie nicht, eine Transaktion auf halbem Wege zu reparieren - das kann größere Probleme verursachen.
Zentralisierte Protokollierung, Überwachung und Alarmierung sowie ein globaler Exception Handler, der eine schnelle Untersuchung von Vorfällen und einen einheitlichen Prozess zur Behandlung von Ereignissen ermöglicht und gleichzeitig die Einhaltung von Compliance-Anforderungen erleichtert.
Modellierung von Bedrohungen und/oder Überprüfung des sicheren Entwurfs, die in der Entwurfsphase von Projekten durchgeführt werden.
Überprüfung des Codes oder statische Analyse sowie Belastungs-, Leistungs- und Penetrationstests, die am endgültigen System durchgeführt werden.
Der falsche Umgang mit außergewöhnlichen Bedingungen mag eine neue Kategorie sein, aber sie beinhaltet einige Grundprinzipien der Cybersicherheit und verdeutlicht, warum Unternehmen auf Dinge vorbereitet sein müssen, die sie nicht unbedingt voraussehen. Sie wissen vielleicht nicht, welche Form außergewöhnliche Bedingungen annehmen werden, aber Sie wissen, dass sie eintreten werden. Der Schlüssel liegt darin, darauf vorbereitet zu sein, mit allen auf die gleiche Weise umzugehen, was es einfacher macht, diese Bedingungen zu erkennen und darauf zu reagieren, wenn das Unvermeidliche eintritt.
Hinweis für SCW Trust Score™-Benutzer:
Da wir die Inhalte unserer Learning Platform aktualisieren, um sie mit dem OWASP Top 10 2025-Standard in Einklang zu bringen, werden Sie möglicherweise geringfügige Anpassungen im Trust Score für Ihre Full Stack-Entwickler feststellen. Bitte wenden Sie sich an Ihren Customer Success-Mitarbeiter, wenn Sie Fragen haben oder Unterstützung benötigen.
.avif)
Die OWASP Top 10 2025 fügt die Fehlbehandlung von Ausnahmebedingungen auf Platz 10 hinzu. Reduzieren Sie die Risiken durch eine "fail closed"-Logik, globale Fehlerbehandlungsprogramme und eine strenge Eingabevalidierung.
Secure Code Warrior schützt Ihren Code während des gesamten Softwareentwicklungszyklus und hilft Ihnen dabei, eine Kultur zu schaffen, in der Cybersicherheit oberste Priorität hat. Ganz gleich, ob Sie Anwendungs-Sicherheitsmanager, Entwickler, CISO oder Sicherheitsbeauftragter sind – wir helfen Ihnen dabei, die mit unsicherem Code verbundenen Risiken zu minimieren.
デモを予約
Mit der Veröffentlichung der OWASP Top Ten für das Jahr 2025 gibt es für Unternehmen einige neue Risikokategorien, denen sie besondere Aufmerksamkeit schenken sollten, darunter eine brandneue Kategorie, die ein für alle Mal beweist, dass das, was man nicht weiß, einem tatsächlich schaden kann.
Die neue Kategorie " Mishandling of Exceptional Conditions" beschreibt, was schiefgehen kann, wenn Unternehmen nicht darauf vorbereitet sind, ungewöhnliche oder unvorhersehbare Situationen zu verhindern, zu erkennen und darauf zu reagieren. Laut OWASP kann diese Schwachstelle ausgelöst werden, wenn eine Anwendung nicht verhindert, dass etwas Ungewöhnliches passiert, ein Problem nicht erkennt, wenn es auftritt und/oder schlecht oder gar nicht reagiert, wenn eine unerwartete Situation auftritt.
Der Gedanke, dass Unternehmen auf das vorbereitet sein müssen, was sie nicht kommen sahen, spiegelt die Realität der heutigen hochgradig verteilten, vernetzten Systeme wider. Und es ist nicht so, dass OWASP über Probleme spricht, die nicht bekannt sind - die Fehlbehandlung von außergewöhnlichen Umständen enthält 24 gemeinsame Schwachstellenaufzählungen (CWEs). Es ist nur so, dass diese CWEs, die eine unsachgemäße Fehlerbehandlung, das Versagen beim Öffnen von Ereignissen, logische Fehler und andere Szenarien beinhalten, unter abnormalen Bedingungen auftreten können. Dies kann z. B. durch eine unzureichende Eingabevalidierung, Fehler auf hoher Ebene in den Verarbeitungsfunktionen und eine inkonsistente (oder nicht vorhandene) Behandlung von Ausnahmen geschehen. OWASP erklärt: "Jedes Mal, wenn eine Anwendung nicht weiß, was sie als nächstes tun soll, ist eine Ausnahmebedingung falsch behandelt worden."
Diese außergewöhnlichen Umstände können dazu führen, dass Systeme in einen unvorhersehbaren Zustand geraten, der zu Systemabstürzen, unerwartetem Verhalten und lang anhaltenden Sicherheitslücken führt. Der Schlüssel zur Vermeidung dieser Art von Störungen liegt darin, mit dem Schlimmsten zu rechnen und darauf vorbereitet zu sein, wenn das Unerwartete eintritt.
Außergewöhnliche Umstände und die Entwicklung der Top Ten
Die Zusammensetzung der alle vier Jahre erscheinenden Top-Ten-Liste der schwerwiegendsten Risiken für die Sicherheit von Webanwendungen ist über die Jahre hinweg recht stabil geblieben, wobei sich einige Kategorien in der Liste verschieben und vielleicht alle vier Jahre ein oder zwei neue hinzukommen. In der Ausgabe 2025 gibt es zwei neue Einträge, darunter die falsche Handhabung außergewöhnlicher Bedingungen, die auf Platz 10 landet. Die andere Kategorie, Software Supply Chain Failures, die auf Platz 3 steht, ist eine Erweiterung einer früheren Kategorie, Vulnerable and Outdated Components (Platz 6 im Jahr 2021), die nun ein breites Spektrum an Softwarekompromittierungen umfasst. (Für diejenigen, die auf dem Laufenden bleiben wollen: Die unzureichende Zugangskontrolle ist immer noch die Nummer 1).
Die Ausnahmebedingungen, die die neueste Kategorie bilden, können eine Vielzahl von Schwachstellen hervorrufen, von Logikfehlern über Überläufe und betrügerische Transaktionen bis hin zu Problemen mit dem Speicher, dem Timing, der Authentifizierung, Autorisierung und anderen Faktoren. Diese Arten von Schwachstellen können die Vertraulichkeit, Verfügbarkeit und Integrität eines Systems oder seiner Daten beeinträchtigen. Sie ermöglichen es einem Angreifer, beispielsweise die fehlerhafte Fehlerbehandlung einer Anwendung zu manipulieren, um die Schwachstelle auszunutzen, so OWASP.
Ein Beispiel für die Unfähigkeit, unerwartete Bedingungen zu bewältigen, ist der Fall, dass eine Anwendung während des Hochladens von Dateien bei einem Denial-of-Service-Angriff Ausnahmen feststellt, die Ressourcen danach aber nicht freigibt. In diesem Fall bleiben die Ressourcen gesperrt oder sind nicht verfügbar, was zu einer Erschöpfung der Ressourcen führt. Wenn ein Angreifer in eine mehrstufige Finanztransaktion eindringt, könnte ein System, das die Transaktion nicht zurücknimmt, sobald ein Fehler entdeckt wird, dem Angreifer die Möglichkeit geben, das Konto des Benutzers zu leeren. Wenn während einer Transaktion ein Fehler entdeckt wird, ist es sehr wichtig, die gesamte Transaktion zurückzusetzen und von vorne zu beginnen. Der Versuch, eine Transaktion in der Mitte des Prozesses wiederherzustellen, kann zu nicht wiederherstellbaren Fehlern führen.
Fail Closed vs. Fail Open
Was ist also der Unterschied zwischen diesen beiden Aktionen? Das wollen wir klären:
Fail Open: Wenn ein System "offen ausfällt", arbeitet es weiter oder bleibt "offen", wenn etwas schief geht. Dies ist nützlich, wenn es sehr wichtig ist, die Dinge am Laufen zu halten, kann aber für die Sicherheit riskant sein.
Geschlossen ausfallen: Wenn ein System "geschlossen ausfällt", schaltet es sich automatisch ab oder wird gesichert, wenn ein Problem auftritt. Dies ist aus der Sicht der Sicherheit sicherer, da es dazu beiträgt, unbefugten Zugriff zu verhindern.
Umgang mit unvorhergesehenen Fehlern
Um diese Art von Risiko zu vermeiden, muss man sich auf das Unbekannte vorbereiten. Dazu gehört, dass man in der Lage ist, jeden möglichen Systemfehler zu erkennen, wenn er auftritt, und Schritte zur Lösung des Problems zu unternehmen. Sie müssen in der Lage sein, den Benutzer ordnungsgemäß zu informieren (ohne dem Angreifer kritische Informationen preiszugeben), das Ereignis zu protokollieren und gegebenenfalls eine Warnung auszugeben.
Hier ist ein Beispiel für die Offenlegung eines SQL-Abfragefehlers zusammen mit dem Installationspfad der Website, der zur Identifizierung eines Injektionspunkts verwendet werden kann:
Warning: odbc_fetch_array() erwartet, dass Parameter /1 eine Ressource ist, boolean angegeben in D:\app\index_new.php auf Zeile 188
Ein System sollte idealerweise über einen globalen Exception-Handler verfügen, der übersehene Fehler abfängt, sowie über Funktionen wie Überwachungs- oder Beobachtungswerkzeuge oder eine Funktion, die wiederholte Fehler oder Muster erkennt, die auf einen laufenden Angriff hindeuten könnten. Dies kann dazu beitragen, Angriffe abzuwehren, die darauf abzielen, Schwächen des Unternehmens bei der Fehlerbehandlung auszunutzen.
Für eine Standard-Java-Webanwendung kann beispielsweise ein globaler Error-Handler auf der Ebene des web.xml-Deployment-Deskriptors konfiguriert werden - in diesem Fall eine Konfiguration, die ab der Servlet-Spezifikation Version 2.5 und höher verwendet wird.
<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
ns="http://java.sun.com/xml/ns/javaee"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd"
version="3.0">
...
<error-page>
<exception-type>java.lang.Exception</exception-type>
<location>/error.jsp</location>
</error-page>
...
</web-app>
Dieser kleine Codeblock sagt einer Java-Webanwendung, was zu tun ist, wenn hinter den Kulissen etwas schief läuft. Anstatt dem Benutzer eine verwirrende Fehlermeldung oder einen leeren Bildschirm anzuzeigen, fängt er das Problem ab und schickt ihn zu einer benutzerdefinierten Fehlerseite. In diesem Fall wäre das die Seite error.jsp.
Da er so eingestellt ist, dass er die allgemeinen java.lang.Exception-Typen behandelt, fungiert er als Master Error Handler für die gesamte Anwendung. Das bedeutet, dass Benutzer, egal wo ein Fehler auftritt, auf dieselbe freundliche, konsistente Fehlerseite umgeleitet werden, anstatt rohe technische Details zu sehen.
Dem Unerwarteten vorbeugen
Idealerweise sollten Unternehmen darauf hinarbeiten, das Auftreten von Ausnahmesituationen so weit wie möglich zu verhindern. Die Implementierung von Ratenbegrenzungen, Ressourcenkontingenten, Drosselungen und anderen Begrenzungen kann z. B. gegen Denial-of-Service- und Brute-Force-Angriffe helfen. Möglicherweise möchten Sie identische, sich wiederholende Fehler identifizieren und sie nur als Statistik erfassen, damit sie die automatische Protokollierung und Überwachung nicht beeinträchtigen. Ein System sollte auch Folgendes umfassen:
Strenge Eingabevalidierung, um sicherzustellen, dass nur ordnungsgemäß geformte und bereinigte Daten in den Arbeitsablauf gelangen. Sie sollte zu einem frühen Zeitpunkt im Datenfluss erfolgen, idealerweise, sobald Daten empfangen werden.
Bewährte Verfahren zur Fehlerbehandlung, um Fehler genau dort zu erkennen, wo sie auftreten. Sie sollten effizient behandelt werden: Weisen Sie die Benutzer eindeutig darauf hin, dass sie ein Protokoll führen und bei Bedarf Warnungen senden müssen. Ein globaler Fehlerhandler ist ebenfalls ideal, um alles abzufangen, was übersehen wurde.
Auch die allgemeine Transaktionssicherheit ist ein Muss. Immer "fail closed": Wenn etwas schief geht, rollen Sie die gesamte Transaktion zurück. Und versuchen Sie nicht, eine Transaktion auf halbem Wege zu reparieren - das kann größere Probleme verursachen.
Zentralisierte Protokollierung, Überwachung und Alarmierung sowie ein globaler Exception Handler, der eine schnelle Untersuchung von Vorfällen und einen einheitlichen Prozess zur Behandlung von Ereignissen ermöglicht und gleichzeitig die Einhaltung von Compliance-Anforderungen erleichtert.
Modellierung von Bedrohungen und/oder Überprüfung des sicheren Entwurfs, die in der Entwurfsphase von Projekten durchgeführt werden.
Überprüfung des Codes oder statische Analyse sowie Belastungs-, Leistungs- und Penetrationstests, die am endgültigen System durchgeführt werden.
Der falsche Umgang mit außergewöhnlichen Bedingungen mag eine neue Kategorie sein, aber sie beinhaltet einige Grundprinzipien der Cybersicherheit und verdeutlicht, warum Unternehmen auf Dinge vorbereitet sein müssen, die sie nicht unbedingt voraussehen. Sie wissen vielleicht nicht, welche Form außergewöhnliche Bedingungen annehmen werden, aber Sie wissen, dass sie eintreten werden. Der Schlüssel liegt darin, darauf vorbereitet zu sein, mit allen auf die gleiche Weise umzugehen, was es einfacher macht, diese Bedingungen zu erkennen und darauf zu reagieren, wenn das Unvermeidliche eintritt.
Hinweis für SCW Trust Score™-Benutzer:
Da wir die Inhalte unserer Learning Platform aktualisieren, um sie mit dem OWASP Top 10 2025-Standard in Einklang zu bringen, werden Sie möglicherweise geringfügige Anpassungen im Trust Score für Ihre Full Stack-Entwickler feststellen. Bitte wenden Sie sich an Ihren Customer Success-Mitarbeiter, wenn Sie Fragen haben oder Unterstützung benötigen.
Mit der Veröffentlichung der OWASP Top Ten für das Jahr 2025 gibt es für Unternehmen einige neue Risikokategorien, denen sie besondere Aufmerksamkeit schenken sollten, darunter eine brandneue Kategorie, die ein für alle Mal beweist, dass das, was man nicht weiß, einem tatsächlich schaden kann.
Die neue Kategorie " Mishandling of Exceptional Conditions" beschreibt, was schiefgehen kann, wenn Unternehmen nicht darauf vorbereitet sind, ungewöhnliche oder unvorhersehbare Situationen zu verhindern, zu erkennen und darauf zu reagieren. Laut OWASP kann diese Schwachstelle ausgelöst werden, wenn eine Anwendung nicht verhindert, dass etwas Ungewöhnliches passiert, ein Problem nicht erkennt, wenn es auftritt und/oder schlecht oder gar nicht reagiert, wenn eine unerwartete Situation auftritt.
Der Gedanke, dass Unternehmen auf das vorbereitet sein müssen, was sie nicht kommen sahen, spiegelt die Realität der heutigen hochgradig verteilten, vernetzten Systeme wider. Und es ist nicht so, dass OWASP über Probleme spricht, die nicht bekannt sind - die Fehlbehandlung von außergewöhnlichen Umständen enthält 24 gemeinsame Schwachstellenaufzählungen (CWEs). Es ist nur so, dass diese CWEs, die eine unsachgemäße Fehlerbehandlung, das Versagen beim Öffnen von Ereignissen, logische Fehler und andere Szenarien beinhalten, unter abnormalen Bedingungen auftreten können. Dies kann z. B. durch eine unzureichende Eingabevalidierung, Fehler auf hoher Ebene in den Verarbeitungsfunktionen und eine inkonsistente (oder nicht vorhandene) Behandlung von Ausnahmen geschehen. OWASP erklärt: "Jedes Mal, wenn eine Anwendung nicht weiß, was sie als nächstes tun soll, ist eine Ausnahmebedingung falsch behandelt worden."
Diese außergewöhnlichen Umstände können dazu führen, dass Systeme in einen unvorhersehbaren Zustand geraten, der zu Systemabstürzen, unerwartetem Verhalten und lang anhaltenden Sicherheitslücken führt. Der Schlüssel zur Vermeidung dieser Art von Störungen liegt darin, mit dem Schlimmsten zu rechnen und darauf vorbereitet zu sein, wenn das Unerwartete eintritt.
Außergewöhnliche Umstände und die Entwicklung der Top Ten
Die Zusammensetzung der alle vier Jahre erscheinenden Top-Ten-Liste der schwerwiegendsten Risiken für die Sicherheit von Webanwendungen ist über die Jahre hinweg recht stabil geblieben, wobei sich einige Kategorien in der Liste verschieben und vielleicht alle vier Jahre ein oder zwei neue hinzukommen. In der Ausgabe 2025 gibt es zwei neue Einträge, darunter die falsche Handhabung außergewöhnlicher Bedingungen, die auf Platz 10 landet. Die andere Kategorie, Software Supply Chain Failures, die auf Platz 3 steht, ist eine Erweiterung einer früheren Kategorie, Vulnerable and Outdated Components (Platz 6 im Jahr 2021), die nun ein breites Spektrum an Softwarekompromittierungen umfasst. (Für diejenigen, die auf dem Laufenden bleiben wollen: Die unzureichende Zugangskontrolle ist immer noch die Nummer 1).
Die Ausnahmebedingungen, die die neueste Kategorie bilden, können eine Vielzahl von Schwachstellen hervorrufen, von Logikfehlern über Überläufe und betrügerische Transaktionen bis hin zu Problemen mit dem Speicher, dem Timing, der Authentifizierung, Autorisierung und anderen Faktoren. Diese Arten von Schwachstellen können die Vertraulichkeit, Verfügbarkeit und Integrität eines Systems oder seiner Daten beeinträchtigen. Sie ermöglichen es einem Angreifer, beispielsweise die fehlerhafte Fehlerbehandlung einer Anwendung zu manipulieren, um die Schwachstelle auszunutzen, so OWASP.
Ein Beispiel für die Unfähigkeit, unerwartete Bedingungen zu bewältigen, ist der Fall, dass eine Anwendung während des Hochladens von Dateien bei einem Denial-of-Service-Angriff Ausnahmen feststellt, die Ressourcen danach aber nicht freigibt. In diesem Fall bleiben die Ressourcen gesperrt oder sind nicht verfügbar, was zu einer Erschöpfung der Ressourcen führt. Wenn ein Angreifer in eine mehrstufige Finanztransaktion eindringt, könnte ein System, das die Transaktion nicht zurücknimmt, sobald ein Fehler entdeckt wird, dem Angreifer die Möglichkeit geben, das Konto des Benutzers zu leeren. Wenn während einer Transaktion ein Fehler entdeckt wird, ist es sehr wichtig, die gesamte Transaktion zurückzusetzen und von vorne zu beginnen. Der Versuch, eine Transaktion in der Mitte des Prozesses wiederherzustellen, kann zu nicht wiederherstellbaren Fehlern führen.
Fail Closed vs. Fail Open
Was ist also der Unterschied zwischen diesen beiden Aktionen? Das wollen wir klären:
Fail Open: Wenn ein System "offen ausfällt", arbeitet es weiter oder bleibt "offen", wenn etwas schief geht. Dies ist nützlich, wenn es sehr wichtig ist, die Dinge am Laufen zu halten, kann aber für die Sicherheit riskant sein.
Geschlossen ausfallen: Wenn ein System "geschlossen ausfällt", schaltet es sich automatisch ab oder wird gesichert, wenn ein Problem auftritt. Dies ist aus der Sicht der Sicherheit sicherer, da es dazu beiträgt, unbefugten Zugriff zu verhindern.
Umgang mit unvorhergesehenen Fehlern
Um diese Art von Risiko zu vermeiden, muss man sich auf das Unbekannte vorbereiten. Dazu gehört, dass man in der Lage ist, jeden möglichen Systemfehler zu erkennen, wenn er auftritt, und Schritte zur Lösung des Problems zu unternehmen. Sie müssen in der Lage sein, den Benutzer ordnungsgemäß zu informieren (ohne dem Angreifer kritische Informationen preiszugeben), das Ereignis zu protokollieren und gegebenenfalls eine Warnung auszugeben.
Hier ist ein Beispiel für die Offenlegung eines SQL-Abfragefehlers zusammen mit dem Installationspfad der Website, der zur Identifizierung eines Injektionspunkts verwendet werden kann:
Warning: odbc_fetch_array() erwartet, dass Parameter /1 eine Ressource ist, boolean angegeben in D:\app\index_new.php auf Zeile 188
Ein System sollte idealerweise über einen globalen Exception-Handler verfügen, der übersehene Fehler abfängt, sowie über Funktionen wie Überwachungs- oder Beobachtungswerkzeuge oder eine Funktion, die wiederholte Fehler oder Muster erkennt, die auf einen laufenden Angriff hindeuten könnten. Dies kann dazu beitragen, Angriffe abzuwehren, die darauf abzielen, Schwächen des Unternehmens bei der Fehlerbehandlung auszunutzen.
Für eine Standard-Java-Webanwendung kann beispielsweise ein globaler Error-Handler auf der Ebene des web.xml-Deployment-Deskriptors konfiguriert werden - in diesem Fall eine Konfiguration, die ab der Servlet-Spezifikation Version 2.5 und höher verwendet wird.
<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
ns="http://java.sun.com/xml/ns/javaee"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd"
version="3.0">
...
<error-page>
<exception-type>java.lang.Exception</exception-type>
<location>/error.jsp</location>
</error-page>
...
</web-app>
Dieser kleine Codeblock sagt einer Java-Webanwendung, was zu tun ist, wenn hinter den Kulissen etwas schief läuft. Anstatt dem Benutzer eine verwirrende Fehlermeldung oder einen leeren Bildschirm anzuzeigen, fängt er das Problem ab und schickt ihn zu einer benutzerdefinierten Fehlerseite. In diesem Fall wäre das die Seite error.jsp.
Da er so eingestellt ist, dass er die allgemeinen java.lang.Exception-Typen behandelt, fungiert er als Master Error Handler für die gesamte Anwendung. Das bedeutet, dass Benutzer, egal wo ein Fehler auftritt, auf dieselbe freundliche, konsistente Fehlerseite umgeleitet werden, anstatt rohe technische Details zu sehen.
Dem Unerwarteten vorbeugen
Idealerweise sollten Unternehmen darauf hinarbeiten, das Auftreten von Ausnahmesituationen so weit wie möglich zu verhindern. Die Implementierung von Ratenbegrenzungen, Ressourcenkontingenten, Drosselungen und anderen Begrenzungen kann z. B. gegen Denial-of-Service- und Brute-Force-Angriffe helfen. Möglicherweise möchten Sie identische, sich wiederholende Fehler identifizieren und sie nur als Statistik erfassen, damit sie die automatische Protokollierung und Überwachung nicht beeinträchtigen. Ein System sollte auch Folgendes umfassen:
Strenge Eingabevalidierung, um sicherzustellen, dass nur ordnungsgemäß geformte und bereinigte Daten in den Arbeitsablauf gelangen. Sie sollte zu einem frühen Zeitpunkt im Datenfluss erfolgen, idealerweise, sobald Daten empfangen werden.
Bewährte Verfahren zur Fehlerbehandlung, um Fehler genau dort zu erkennen, wo sie auftreten. Sie sollten effizient behandelt werden: Weisen Sie die Benutzer eindeutig darauf hin, dass sie ein Protokoll führen und bei Bedarf Warnungen senden müssen. Ein globaler Fehlerhandler ist ebenfalls ideal, um alles abzufangen, was übersehen wurde.
Auch die allgemeine Transaktionssicherheit ist ein Muss. Immer "fail closed": Wenn etwas schief geht, rollen Sie die gesamte Transaktion zurück. Und versuchen Sie nicht, eine Transaktion auf halbem Wege zu reparieren - das kann größere Probleme verursachen.
Zentralisierte Protokollierung, Überwachung und Alarmierung sowie ein globaler Exception Handler, der eine schnelle Untersuchung von Vorfällen und einen einheitlichen Prozess zur Behandlung von Ereignissen ermöglicht und gleichzeitig die Einhaltung von Compliance-Anforderungen erleichtert.
Modellierung von Bedrohungen und/oder Überprüfung des sicheren Entwurfs, die in der Entwurfsphase von Projekten durchgeführt werden.
Überprüfung des Codes oder statische Analyse sowie Belastungs-, Leistungs- und Penetrationstests, die am endgültigen System durchgeführt werden.
Der falsche Umgang mit außergewöhnlichen Bedingungen mag eine neue Kategorie sein, aber sie beinhaltet einige Grundprinzipien der Cybersicherheit und verdeutlicht, warum Unternehmen auf Dinge vorbereitet sein müssen, die sie nicht unbedingt voraussehen. Sie wissen vielleicht nicht, welche Form außergewöhnliche Bedingungen annehmen werden, aber Sie wissen, dass sie eintreten werden. Der Schlüssel liegt darin, darauf vorbereitet zu sein, mit allen auf die gleiche Weise umzugehen, was es einfacher macht, diese Bedingungen zu erkennen und darauf zu reagieren, wenn das Unvermeidliche eintritt.
Hinweis für SCW Trust Score™-Benutzer:
Da wir die Inhalte unserer Learning Platform aktualisieren, um sie mit dem OWASP Top 10 2025-Standard in Einklang zu bringen, werden Sie möglicherweise geringfügige Anpassungen im Trust Score für Ihre Full Stack-Entwickler feststellen. Bitte wenden Sie sich an Ihren Customer Success-Mitarbeiter, wenn Sie Fragen haben oder Unterstützung benötigen.
Klicken Sie auf den folgenden Link, um die PDF-Datei dieser Ressource herunterzuladen.
Secure Code Warrior schützt Ihren Code während des gesamten Softwareentwicklungszyklus und hilft Ihnen dabei, eine Kultur zu schaffen, in der Cybersicherheit oberste Priorität hat. Ganz gleich, ob Sie Anwendungs-Sicherheitsmanager, Entwickler, CISO oder Sicherheitsbeauftragter sind – wir helfen Ihnen dabei, die mit unsicherem Code verbundenen Risiken zu minimieren.
Bericht anzeigenデモを予約
Mit der Veröffentlichung der OWASP Top Ten für das Jahr 2025 gibt es für Unternehmen einige neue Risikokategorien, denen sie besondere Aufmerksamkeit schenken sollten, darunter eine brandneue Kategorie, die ein für alle Mal beweist, dass das, was man nicht weiß, einem tatsächlich schaden kann.
Die neue Kategorie " Mishandling of Exceptional Conditions" beschreibt, was schiefgehen kann, wenn Unternehmen nicht darauf vorbereitet sind, ungewöhnliche oder unvorhersehbare Situationen zu verhindern, zu erkennen und darauf zu reagieren. Laut OWASP kann diese Schwachstelle ausgelöst werden, wenn eine Anwendung nicht verhindert, dass etwas Ungewöhnliches passiert, ein Problem nicht erkennt, wenn es auftritt und/oder schlecht oder gar nicht reagiert, wenn eine unerwartete Situation auftritt.
Der Gedanke, dass Unternehmen auf das vorbereitet sein müssen, was sie nicht kommen sahen, spiegelt die Realität der heutigen hochgradig verteilten, vernetzten Systeme wider. Und es ist nicht so, dass OWASP über Probleme spricht, die nicht bekannt sind - die Fehlbehandlung von außergewöhnlichen Umständen enthält 24 gemeinsame Schwachstellenaufzählungen (CWEs). Es ist nur so, dass diese CWEs, die eine unsachgemäße Fehlerbehandlung, das Versagen beim Öffnen von Ereignissen, logische Fehler und andere Szenarien beinhalten, unter abnormalen Bedingungen auftreten können. Dies kann z. B. durch eine unzureichende Eingabevalidierung, Fehler auf hoher Ebene in den Verarbeitungsfunktionen und eine inkonsistente (oder nicht vorhandene) Behandlung von Ausnahmen geschehen. OWASP erklärt: "Jedes Mal, wenn eine Anwendung nicht weiß, was sie als nächstes tun soll, ist eine Ausnahmebedingung falsch behandelt worden."
Diese außergewöhnlichen Umstände können dazu führen, dass Systeme in einen unvorhersehbaren Zustand geraten, der zu Systemabstürzen, unerwartetem Verhalten und lang anhaltenden Sicherheitslücken führt. Der Schlüssel zur Vermeidung dieser Art von Störungen liegt darin, mit dem Schlimmsten zu rechnen und darauf vorbereitet zu sein, wenn das Unerwartete eintritt.
Außergewöhnliche Umstände und die Entwicklung der Top Ten
Die Zusammensetzung der alle vier Jahre erscheinenden Top-Ten-Liste der schwerwiegendsten Risiken für die Sicherheit von Webanwendungen ist über die Jahre hinweg recht stabil geblieben, wobei sich einige Kategorien in der Liste verschieben und vielleicht alle vier Jahre ein oder zwei neue hinzukommen. In der Ausgabe 2025 gibt es zwei neue Einträge, darunter die falsche Handhabung außergewöhnlicher Bedingungen, die auf Platz 10 landet. Die andere Kategorie, Software Supply Chain Failures, die auf Platz 3 steht, ist eine Erweiterung einer früheren Kategorie, Vulnerable and Outdated Components (Platz 6 im Jahr 2021), die nun ein breites Spektrum an Softwarekompromittierungen umfasst. (Für diejenigen, die auf dem Laufenden bleiben wollen: Die unzureichende Zugangskontrolle ist immer noch die Nummer 1).
Die Ausnahmebedingungen, die die neueste Kategorie bilden, können eine Vielzahl von Schwachstellen hervorrufen, von Logikfehlern über Überläufe und betrügerische Transaktionen bis hin zu Problemen mit dem Speicher, dem Timing, der Authentifizierung, Autorisierung und anderen Faktoren. Diese Arten von Schwachstellen können die Vertraulichkeit, Verfügbarkeit und Integrität eines Systems oder seiner Daten beeinträchtigen. Sie ermöglichen es einem Angreifer, beispielsweise die fehlerhafte Fehlerbehandlung einer Anwendung zu manipulieren, um die Schwachstelle auszunutzen, so OWASP.
Ein Beispiel für die Unfähigkeit, unerwartete Bedingungen zu bewältigen, ist der Fall, dass eine Anwendung während des Hochladens von Dateien bei einem Denial-of-Service-Angriff Ausnahmen feststellt, die Ressourcen danach aber nicht freigibt. In diesem Fall bleiben die Ressourcen gesperrt oder sind nicht verfügbar, was zu einer Erschöpfung der Ressourcen führt. Wenn ein Angreifer in eine mehrstufige Finanztransaktion eindringt, könnte ein System, das die Transaktion nicht zurücknimmt, sobald ein Fehler entdeckt wird, dem Angreifer die Möglichkeit geben, das Konto des Benutzers zu leeren. Wenn während einer Transaktion ein Fehler entdeckt wird, ist es sehr wichtig, die gesamte Transaktion zurückzusetzen und von vorne zu beginnen. Der Versuch, eine Transaktion in der Mitte des Prozesses wiederherzustellen, kann zu nicht wiederherstellbaren Fehlern führen.
Fail Closed vs. Fail Open
Was ist also der Unterschied zwischen diesen beiden Aktionen? Das wollen wir klären:
Fail Open: Wenn ein System "offen ausfällt", arbeitet es weiter oder bleibt "offen", wenn etwas schief geht. Dies ist nützlich, wenn es sehr wichtig ist, die Dinge am Laufen zu halten, kann aber für die Sicherheit riskant sein.
Geschlossen ausfallen: Wenn ein System "geschlossen ausfällt", schaltet es sich automatisch ab oder wird gesichert, wenn ein Problem auftritt. Dies ist aus der Sicht der Sicherheit sicherer, da es dazu beiträgt, unbefugten Zugriff zu verhindern.
Umgang mit unvorhergesehenen Fehlern
Um diese Art von Risiko zu vermeiden, muss man sich auf das Unbekannte vorbereiten. Dazu gehört, dass man in der Lage ist, jeden möglichen Systemfehler zu erkennen, wenn er auftritt, und Schritte zur Lösung des Problems zu unternehmen. Sie müssen in der Lage sein, den Benutzer ordnungsgemäß zu informieren (ohne dem Angreifer kritische Informationen preiszugeben), das Ereignis zu protokollieren und gegebenenfalls eine Warnung auszugeben.
Hier ist ein Beispiel für die Offenlegung eines SQL-Abfragefehlers zusammen mit dem Installationspfad der Website, der zur Identifizierung eines Injektionspunkts verwendet werden kann:
Warning: odbc_fetch_array() erwartet, dass Parameter /1 eine Ressource ist, boolean angegeben in D:\app\index_new.php auf Zeile 188
Ein System sollte idealerweise über einen globalen Exception-Handler verfügen, der übersehene Fehler abfängt, sowie über Funktionen wie Überwachungs- oder Beobachtungswerkzeuge oder eine Funktion, die wiederholte Fehler oder Muster erkennt, die auf einen laufenden Angriff hindeuten könnten. Dies kann dazu beitragen, Angriffe abzuwehren, die darauf abzielen, Schwächen des Unternehmens bei der Fehlerbehandlung auszunutzen.
Für eine Standard-Java-Webanwendung kann beispielsweise ein globaler Error-Handler auf der Ebene des web.xml-Deployment-Deskriptors konfiguriert werden - in diesem Fall eine Konfiguration, die ab der Servlet-Spezifikation Version 2.5 und höher verwendet wird.
<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
ns="http://java.sun.com/xml/ns/javaee"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd"
version="3.0">
...
<error-page>
<exception-type>java.lang.Exception</exception-type>
<location>/error.jsp</location>
</error-page>
...
</web-app>
Dieser kleine Codeblock sagt einer Java-Webanwendung, was zu tun ist, wenn hinter den Kulissen etwas schief läuft. Anstatt dem Benutzer eine verwirrende Fehlermeldung oder einen leeren Bildschirm anzuzeigen, fängt er das Problem ab und schickt ihn zu einer benutzerdefinierten Fehlerseite. In diesem Fall wäre das die Seite error.jsp.
Da er so eingestellt ist, dass er die allgemeinen java.lang.Exception-Typen behandelt, fungiert er als Master Error Handler für die gesamte Anwendung. Das bedeutet, dass Benutzer, egal wo ein Fehler auftritt, auf dieselbe freundliche, konsistente Fehlerseite umgeleitet werden, anstatt rohe technische Details zu sehen.
Dem Unerwarteten vorbeugen
Idealerweise sollten Unternehmen darauf hinarbeiten, das Auftreten von Ausnahmesituationen so weit wie möglich zu verhindern. Die Implementierung von Ratenbegrenzungen, Ressourcenkontingenten, Drosselungen und anderen Begrenzungen kann z. B. gegen Denial-of-Service- und Brute-Force-Angriffe helfen. Möglicherweise möchten Sie identische, sich wiederholende Fehler identifizieren und sie nur als Statistik erfassen, damit sie die automatische Protokollierung und Überwachung nicht beeinträchtigen. Ein System sollte auch Folgendes umfassen:
Strenge Eingabevalidierung, um sicherzustellen, dass nur ordnungsgemäß geformte und bereinigte Daten in den Arbeitsablauf gelangen. Sie sollte zu einem frühen Zeitpunkt im Datenfluss erfolgen, idealerweise, sobald Daten empfangen werden.
Bewährte Verfahren zur Fehlerbehandlung, um Fehler genau dort zu erkennen, wo sie auftreten. Sie sollten effizient behandelt werden: Weisen Sie die Benutzer eindeutig darauf hin, dass sie ein Protokoll führen und bei Bedarf Warnungen senden müssen. Ein globaler Fehlerhandler ist ebenfalls ideal, um alles abzufangen, was übersehen wurde.
Auch die allgemeine Transaktionssicherheit ist ein Muss. Immer "fail closed": Wenn etwas schief geht, rollen Sie die gesamte Transaktion zurück. Und versuchen Sie nicht, eine Transaktion auf halbem Wege zu reparieren - das kann größere Probleme verursachen.
Zentralisierte Protokollierung, Überwachung und Alarmierung sowie ein globaler Exception Handler, der eine schnelle Untersuchung von Vorfällen und einen einheitlichen Prozess zur Behandlung von Ereignissen ermöglicht und gleichzeitig die Einhaltung von Compliance-Anforderungen erleichtert.
Modellierung von Bedrohungen und/oder Überprüfung des sicheren Entwurfs, die in der Entwurfsphase von Projekten durchgeführt werden.
Überprüfung des Codes oder statische Analyse sowie Belastungs-, Leistungs- und Penetrationstests, die am endgültigen System durchgeführt werden.
Der falsche Umgang mit außergewöhnlichen Bedingungen mag eine neue Kategorie sein, aber sie beinhaltet einige Grundprinzipien der Cybersicherheit und verdeutlicht, warum Unternehmen auf Dinge vorbereitet sein müssen, die sie nicht unbedingt voraussehen. Sie wissen vielleicht nicht, welche Form außergewöhnliche Bedingungen annehmen werden, aber Sie wissen, dass sie eintreten werden. Der Schlüssel liegt darin, darauf vorbereitet zu sein, mit allen auf die gleiche Weise umzugehen, was es einfacher macht, diese Bedingungen zu erkennen und darauf zu reagieren, wenn das Unvermeidliche eintritt.
Hinweis für SCW Trust Score™-Benutzer:
Da wir die Inhalte unserer Learning Platform aktualisieren, um sie mit dem OWASP Top 10 2025-Standard in Einklang zu bringen, werden Sie möglicherweise geringfügige Anpassungen im Trust Score für Ihre Full Stack-Entwickler feststellen. Bitte wenden Sie sich an Ihren Customer Success-Mitarbeiter, wenn Sie Fragen haben oder Unterstützung benötigen.
目次
Secure Code Warrior schützt Ihren Code während des gesamten Softwareentwicklungszyklus und hilft Ihnen dabei, eine Kultur zu schaffen, in der Cybersicherheit oberste Priorität hat. Ganz gleich, ob Sie Anwendungs-Sicherheitsmanager, Entwickler, CISO oder Sicherheitsbeauftragter sind – wir helfen Ihnen dabei, die mit unsicherem Code verbundenen Risiken zu minimieren.
デモを予約[ダウンロード]Ressourcen für den Einstieg
Themen und Inhalte der Secure-Code-Schulung
Unsere branchenführenden Inhalte werden unter Berücksichtigung der Aufgaben unserer Kunden ständig weiterentwickelt, um mit der sich ständig verändernden Softwareentwicklungsumgebung Schritt zu halten. Sie decken alle Themen von KI bis hin zu XQuery-Injection ab und sind für verschiedene Aufgabenbereiche konzipiert, von Architekten und Ingenieuren bis hin zu Produktmanagern und Qualitätssicherungsfachleuten. Werfen Sie einen Blick auf die Inhalte unseres Content-Katalogs, sortiert nach Themen und Aufgabenbereichen.
Die Kamer van Koophandel setzt Maßstäbe für entwicklergesteuerte Sicherheit in großem Maßstab
Die Kamer van Koophandel berichtet, wie sie sicheres Codieren durch rollenbasierte Zertifizierungen, Trust Score-Benchmarking und eine Kultur der gemeinsamen Verantwortung für Sicherheit in die tägliche Entwicklungsarbeit integriert hat.
%20(1).avif)
.avif)
Bedrohungsmodellierung mit KI: So wird jeder Entwickler zum Bedrohungsmodellierer
Sie werden besser gerüstet sein, um Entwicklern dabei zu helfen, Ideen und Techniken zur Bedrohungsmodellierung mit den KI-Tools zu kombinieren, die sie bereits verwenden, um die Sicherheit zu erhöhen, die Zusammenarbeit zu verbessern und von Anfang an widerstandsfähigere Software zu entwickeln.
Ressourcen für den Einstieg
Cybermon ist zurück: Die KI-Mission zum Besiegen des Bosses ist jetzt auf Abruf verfügbar.
「Cybermon 2025 Beat the Boss」 kann nun das ganze Jahr über bei SCW gespielt werden. Führen Sie anspruchsvolle AI/LLM-Sicherheitsherausforderungen ein, um die sichere AI-Entwicklung in großem Maßstab zu stärken.
Erläuterung des Cyber-Resilience-Gesetzes: Bedeutung für die Entwicklung sicherer Software
Erfahren Sie, was das EU-Gesetz zur Cyberresilienz (CRA) verlangt, für wen es gilt und wie sich Ingenieurteams auf Secure-by-Design-Praktiken, Schwachstellenprävention und die Kompetenzentwicklung von Entwicklern vorbereiten können.
Enabler 1: Definierte und messbare Erfolgskriterien
Enabler 1 ist der erste Teil der zehnteiligen Reihe „Enablers of Success“ und zeigt, wie sichere Programmierung mit geschäftlichen Ergebnissen wie Risikominderung und Geschwindigkeit verknüpft werden kann, um Programme langfristig zu optimieren.
