Bis Ende 2025 veröffentlichte OWASP die finale Version der OWASP Top 10 2025. Auch wenn der Name eine weitere Iteration eines gut bekannten Dokuments nahelegt, handelt es sich in der Praxis um eine der reifsten und zugleich eine der „unbequemsten“ Editionen in der Geschichte des Projekts. Unbequem deshalb, weil OWASP Top 10 2025 offen zeigt, dass ein erheblicher Teil der Sicherheitsprobleme von Webanwendungen nicht aus einzelnen Codierfehlern resultiert, sondern aus Designentscheidungen, architektonischen Vereinfachungen und dem Fehlen konsistenter Sicherheitsprozesse über den gesamten Lebenszyklus der Anwendung hinweg.

Es ist zugleich eine Edition, die sehr klar trennt:

• die Arbeitsversion (RC), die der Konsultation dient (die wir in unserem früheren Beitrag besprochen haben: OWASP Top 10 2025 – Was ist neu und wie beeinflusst es die Anwendungssicherheitspolitik?),
• von der finalen Version, die den Charakter eines Referenzdokuments hat.

Im Kontext von Audits, Penetrationstests sowie regulatorischer Compliance ist ausschließlich die finale Version der OWASP Top 10 2025 relevant, die Ende 2025 veröffentlicht wurde.

OWASP Top 10 – ein Dokument, das häufig missverstanden wird.

Bevor wir zu den eigentlichen Risikokategorien übergehen, lohnt es sich, kurz innezuhalten und zu klären, was OWASP Top 10 tatsächlich ist und was es nie sein sollte.

OWASP Top 10:

• ist keine Norm,
• ist keine Zertifizierung,
• ist keine Compliance-Checkliste,
• ist kein Ersatz für Penetrationstests.

Es handelt sich um ein Modell zur Risikoklassifikation, dessen Hauptziel darin besteht, die am häufigsten auftretenden und zugleich teuersten Klassen von Sicherheitsproblemen bei Webanwendungen zu ordnen. Ein Fehler, den viele Organisationen weiterhin machen, besteht darin, OWASP Top 10 als Liste von „10 Dingen, die zu beheben sind“ zu behandeln. Dieses Dokument sollte jedoch wie eine Karte gelesen werden und nicht wie eine Montageanleitung. Eine Karte zeigt Gefahrenbereiche, ersetzt aber nicht die Kenntnis des Geländes.

Kontext der Edition 2025: Wandel der Landschaft von Webanwendungen.

OWASP Top 10 2025 spiegelt sehr deutlich wider, wie sich Webanwendungen in den letzten Jahren verändert haben. Moderne Systeme sind längst keine einzelnen Anwendungen mehr, die auf einem einzigen Server laufen, sondern komplexe Ökosysteme, die sich zusammensetzen aus:

• Frontend- und Backend-Anwendungen,
• öffentlichen und internen APIs,
• Cloud-Umgebungen,
• automatisierten CI/CD-Pipelines,
• externen Bibliotheken und Open-Source-Komponenten.

In einer solchen Umgebung ist Sicherheit kein eindimensionales Problem mehr. Eine einzelne Schwachstelle tritt selten isoliert auf. Viel häufiger ist sie Teil einer Ereigniskette, in der ein Designfehler Missbrauch ermöglicht und fehlendes Monitoring dazu führt, dass der Vorfall unentdeckt bleibt. OWASP Top 10 2025 wurde genau mit Blick auf eine solche mehrschichtige Landschaft entwickelt.

Die Struktur der OWASP Top 10 2025 als Schichtenmodell.

Eine der besten Methoden, OWASP Top 10 2025 zu interpretieren, besteht darin, es als Schichtenmodell des Risikos zu betrachten. Die einzelnen Kategorien konkurrieren nicht miteinander, sondern ergänzen sich häufig.

Auf der höchsten Ebene lassen sich vier Bereiche unterscheiden:

1. Design und Architektur.
2. Implementierung und Komponenten.
3. Konfiguration und Betrieb.
4. Prozesse, Monitoring und Reaktion.

Diese Perspektive ist entscheidend, weil sie zeigt, dass nicht alle Probleme mit denselben Werkzeugen gelöst werden können.

A01: Broken Access Control – wenn Geschäftslogik zum Angriffsvektor wird.

Broken Access Control steht seit Jahren an erster Stelle der OWASP Top 10, und die Edition 2025 bestätigt lediglich, dass dies kein Problem ist, das die Branche wirksam zu lösen gelernt hat. Wichtig ist, dass OWASP zunehmend betont, dass die Ursache solcher Schwachstellen selten ein einzelner Implementierungsfehler ist. Viel häufiger sind sie das Ergebnis einer inkonsistenten oder schlecht durchdachten Autorisierungslogik, die ohne vollständiges Bedrohungsmodell entworfen wurde.

In der Praxis tritt Broken Access Control dort auf, wo eine Anwendung beginnt, darauf zu „vertrauen“, dass Nutzer sie gemäß dem vorgesehenen Szenario verwenden. Wenn Zugriffsregeln fragmentiert sind, vom Kontext abhängen oder nur teilweise umgesetzt werden, kann ein Angreifer Schutzmechanismen nicht durch ein technisches Aushebeln umgehen, sondern durch Manipulation von Geschäftsabläufen.

Am häufigsten ist dies die Folge von:

• fehlendem konsistentem Autorisierungsmodell,
• übermäßigem Vertrauen in Client-seitige Daten,
• uneindeutigen Geschäftsregeln,
• API-Design ohne klar definierte Rollen.

OWASP Top 10 2025 zeigt, dass sich dieses Problem mit der wachsenden Zahl an APIs, Microservices und Integrationen verschärft. Jeder zusätzliche Berührungspunkt erhöht das Risiko, dass Zugriffskontrollen inkonsistent implementiert werden. Dadurch „prüft“ die Anwendung formal Berechtigungen, erlaubt in der Praxis aber Zugriff auf Ressourcen, die einem bestimmten Nutzer niemals zugänglich sein sollten.

A02: Cryptographic Failures – wenn Kryptografie nur auf dem Papier existiert.

Die Kategorie Cryptographic Failures in OWASP Top 10 2025 ist eines der stärksten Warnsignale für Organisationen, die Sicherheit mit dem bloßen Einsatz von Verschlüsselung gleichsetzen. OWASP macht unmissverständlich klar, dass falsch implementierte Kryptografie nicht nur nicht schützt, sondern häufig ein falsches Sicherheitsgefühl erzeugt.

In der Praxis resultieren diese Probleme daraus, dass Kryptografie als Infrastrukturbaustein betrachtet wird und nicht als integraler Bestandteil der Anwendungsarchitektur. Verschlüsselungsmechanismen werden oft ohne konsistente Schlüsselmanagement-Policy, ohne Kontrolle der Schlüsselrotation und ohne klare Unterscheidung zwischen schutzbedürftigen Daten und Daten geringerer Sensitivität eingeführt.

A02 umfasst unter anderem:

• fehlerhafte TLS-Konfigurationen,
• veraltete Algorithmen,
• unsachgemäßes Schlüsselmanagement,
• fehlende konsistente Verschlüsselung von Daten im Ruhezustand.

Dies ist ein besonders trügerischer Bereich, weil eine Anwendung „sicher“ wirken kann, während kritische Daten in Wirklichkeit weiterhin exponiert sind. OWASP Top 10 2025 zeigt zudem, dass Kryptografie häufig an den Schnittstellen zwischen Anwendung und anderen Systemen versagt. Daten können in einer Komponente korrekt geschützt sein und anschließend in einer anderen unverschlüsselt übertragen oder gespeichert werden. Solche Inkonsistenzen sind schwer zu erkennen und noch schwerer zu beheben, ohne die Architektur ganzheitlich zu betrachten.

A03: Injection – eine Schwachstelle, die sich an moderne Systeme angepasst hat.

Injection gehört zu den ältesten Kategorien in den OWASP Top 10, dennoch zeigt die Edition 2025 deutlich, dass das Problem nicht verschwunden ist, sondern seine Form verändert hat. Moderne Injection-Angriffe beruhen selten auf einem einfachen Einschleusen von Code in einen einzelnen Parameter. Viel häufiger sind sie Teil komplexer Interaktionen zwischen Systemkomponenten.

Stattdessen treten zunehmend auf:

• komplexe Angriffsketten,
• Missbrauch von APIs,
• Probleme, die aus der Integration vieler Systeme entstehen.

Moderne Anwendungen arbeiten auf vielen Abstraktionsebenen: ORMs, APIs, Message Broker, Queueing-Systeme. Jede dieser Ebenen interpretiert Daten auf ihre Weise. Injection wird dadurch zu einer systemischen Schwachstelle, die aus falschen Annahmen darüber entsteht, wo „Daten“ enden und „Logik“ beginnt. Dies ist ein weiteres Beispiel dafür, dass heutige Schwachstellen häufig das Ergebnis der Interaktion vieler Komponenten sind und nicht eines einzelnen Codefragments. OWASP Top 10 2025 betont, dass wirksamer Schutz vor Injection nicht ausschließlich auf Eingabevalidierung beruht. Er erfordert einen konsistenten Ansatz dafür, wie Daten im gesamten System verarbeitet, weitergegeben und interpretiert werden.

A04: Insecure Design – Sicherheit, die nie entworfen wurde.

Insecure Design ist die Kategorie, die die Philosophie der OWASP Top 10 2025 am besten widerspiegelt. Sie bezieht sich auf Situationen, in denen eine Anwendung entworfen wurde, ohne Bedrohungen realistisch zu berücksichtigen. Es geht nicht um Fehler im Code, sondern um das Fehlen defensiver Mechanismen auf der konzeptionellen Ebene des Systems.

Insecure Design betrifft Situationen, in denen:

• keine Bedrohungsanalyse durchgeführt wurde,
• keine Vertrauensgrenzen definiert wurden,
• Missbrauchsszenarien nicht berücksichtigt wurden,
• Sicherheit „auf später verschoben“ wurde.

OWASP betont klar, dass viele Anwendungen funktionale Anforderungen erfüllen, aber nie mit Blick auf Missbrauch entworfen wurden. Fehlende Abuse-Case-Analysen, mangelnde Trennung von Verantwortlichkeiten oder übermäßige Vereinfachung der Geschäftslogik führen zu Systemen, die funktional korrekt, aber strukturell verwundbar sind. Das größte Problem von Insecure Design besteht darin, dass sich solche Fehler nicht leicht „patchen“ lassen. Sie erfordern architektonische Änderungen, die in reifen Systemen oft kostspielig und schwierig umzusetzen sind. OWASP Top 10 2025 signalisiert eindeutig, dass Sicherheit entworfen werden muss und nicht am Ende hinzugefügt werden kann. Diese Probleme lassen sich nicht durch eine WAF, einen Vulnerability-Scanner oder ein Library-Update beheben. Sie erfordern architektonische Änderungen und manchmal eine Neugestaltung kritischer Systemkomponenten.

A05: Security Misconfiguration – wenn die Realität von den Annahmen abweicht.

Security Misconfiguration bleibt eine der praxisnahsten Kategorien der OWASP Top 10, weil sie die reale Umgebung betrifft, in der eine Anwendung betrieben wird. Selbst das bestentworfene System kann effektiv kompromittiert werden, wenn seine Konfiguration von den Sicherheitsannahmen abweicht. OWASP Top 10 2025 zeigt, dass die Ursachen häufig in Standardeinstellungen, inkonsistentem Hardening und Änderungen liegen, die während des Betriebs eingeführt werden. In Cloud- und Container-Umgebungen wird dieses Problem durch die Skalierung und die Komplexität der Konfiguration zusätzlich verstärkt.

Konfigurationsfehler bei:

• Servern,
• Cloud-Umgebungen,
• Containern,
• Authentifizierungsmechanismen

sind besonders gefährlich, weil sie oft keine fortgeschrittenen Angriffstechniken erfordern. Es reicht aus, wenn eine Anwendung oder Infrastruktur unbeabsichtigt exponiert wird. OWASP Top 10 2025 wertet diese Kategorie als Beleg dafür, dass Sicherheit nicht in der Entwicklungsphase endet.

A06: Vulnerable and Outdated Components – ein Risiko, das man nicht sieht.

Moderne Anwendungen bestehen zu einem großen Teil aus externen Komponenten, wodurch ein wesentlicher Anteil des Sicherheitsrisikos geerbt wird und nicht direkt vom Entwicklungsteam geschaffen ist. OWASP Top 10 2025 hebt diesen Umstand deutlich hervor und nennt die fehlende Kontrolle über den Lebenszyklus von Abhängigkeiten als eine der zentralen Bedrohungen. Fehlendes Lifecycle-Management führt dazu, dass eine Anwendung:

• Bibliotheken ohne Support nutzt,
• bekannte Schwachstellen enthält,
• Risiken aus externen Quellen übernimmt.

Dieses Problem besteht nicht nur im Einsatz verwundbarer Bibliotheken, sondern auch in der fehlenden Kenntnis darüber, welche Komponenten tatsächlich in der Anwendung enthalten sind. Ohne vollständige Transparenz über Abhängigkeiten verliert eine Organisation die Fähigkeit, Risiken zu bewerten und auf neu veröffentlichte Schwachstellen zu reagieren. OWASP Top 10 2025 zeigt, dass Komponentenmanagement nicht mehr nur technische Hygiene ist, sondern ein strategischer Bestandteil der Anwendungssicherheit.

A07: Identification and Authentication Failures – wenn Identität zum schwächsten Glied wird.

Probleme bei Identifikation und Authentifizierung gehören weiterhin zu den direktesten Wegen, die Kontrolle über eine Anwendung zu übernehmen. OWASP Top 10 2025 zeigt, dass Fehler in diesem Bereich trotz der breiten Verfügbarkeit moderner Authentifizierungsmechanismen nach wie vor häufig vorkommen. Ursache ist oft das Fehlen einer konsistenten Strategie für Identity Management. Login-, Session- und Token-Mechanismen werden häufig isoliert entworfen, ohne automatisierte Angriffsszenarien, Missbrauch und Privilegieneskalation zu berücksichtigen.

OWASP Top 10 2025 betont, dass Authentifizierung kein einmaliger Schritt ist, sondern ein kontinuierlicher Mechanismus zur Kontrolle von Vertrauen. Fehler in diesem Bereich führen schnell zu realen Schäden, weil sie Angreifern erlauben, im vollständig legitimen Nutzerkontext zu agieren.

A08: Software and Data Integrity Failures – wenn das Vertrauen in den Prozess versagt.

Kategorie A08 in OWASP Top 10 2025 ist eines der stärksten Signale dafür, dass Sicherheit von Webanwendungen nicht mehr nur ein Problem von Code ist, der in Produktion läuft. Immer häufiger liegt die Ursache von Vorfällen nicht in der Anwendung selbst, sondern im Prozess, der sie erstellt, aktualisiert und verteilt. Software and Data Integrity Failures umfasst Situationen, in denen eine Organisation die Kontrolle über die Integrität von Code, Deployment-Artefakten oder Konfigurationsdaten verliert. In der Praxis bedeutet dies eine Anfälligkeit für Angriffe auf CI/CD-Pipelines, Code-Repositories, Update-Mechanismen und Signaturprozesse. In solchen Szenarien muss ein Angreifer keine Abwehrmechanismen der Anwendung brechen. Es reicht aus, ein vertrauenswürdiges Element des Prozesses zu kompromittieren.

OWASP Top 10 2025 zeigt deutlich, dass Vertrauen in Automatisierung ohne Verifikation zu den gefährlichsten Annahmen im modernen DevOps gehört. Fehlende Integritätskontrollen, unzureichende Quellenverifikation und übermäßige Berechtigungen in Pipelines führen dazu, dass bösartiger Code in einer aus Systemperspektive vollständig legitimen Weise in Produktion gelangt. Diese Kategorie steht zudem in direktem Zusammenhang mit Datensicherheit. Unzureichend geschützte Import-, Synchronisations- oder Replikationsmechanismen können Manipulationen ermöglichen, ohne klassische Security-Alerts auszulösen. Dadurch verliert eine Organisation nicht nur Vertraulichkeit, sondern auch die Glaubwürdigkeit von Daten, was in kritischen Systemen ebenso gefährlich sein kann.

OWASP Top 10 2025 kommuniziert klar, dass die Integrität von Software und Daten als kontinuierlicher Prozess zu behandeln ist und nicht als einmaliger Deployment-Schritt.

A09: Security Logging and Monitoring Failures – wenn fehlende Sichtbarkeit zur Verletzung von NIS2-Pflichten wird.

Kategorie A09 in OWASP Top 10 2025 betrifft einen Bereich, der über Jahre hinweg als technischer Zusatz zur Anwendungssicherheit betrachtet wurde und nicht als ihr Fundament. In der Realität entscheidet jedoch gerade die Fähigkeit zu Logging, Monitoring und Reaktion häufig darüber, ob eine Organisation einen kontrollierten Vorfall erlebt oder eine Verletzung mit systemischen Auswirkungen. In der Edition 2025 signalisiert OWASP ausdrücklich, dass fehlende Sichtbarkeit an sich ein Sicherheitsrisiko ist, unabhängig von der Qualität anderer Maßnahmen.

In der Praxis beschreibt A09 Situationen, in denen Anwendungen angegriffen, missbraucht oder als Teil einer größeren Angriffskette genutzt werden können, während der Organisation Mechanismen fehlen, dies rechtzeitig zu erkennen. Logs existieren, sind aber unvollständig, inkonsistent oder auf diagnostische Zwecke beschränkt. Monitoring ist vorhanden, konzentriert sich aber auf Verfügbarkeit und nicht auf das Verhalten der Anwendung. Vorfälle bleiben unentdeckt, weil das System keine Signale erzeugt, die als Bedrohung interpretiert werden können.

Im Kontext von NIS2 erhält diese Kategorie eine völlig neue Bedeutung. Die Richtlinie erwartet keine absolute Immunität gegen Angriffe, verlangt aber die Fähigkeit zur frühen Erkennung von Vorfällen, zu ihrer Bewertung und zur fristgerechten Meldung. A09 zeigt genau den Punkt, an dem Anwendungssicherheit nicht mehr nur ein technisches Thema ist, sondern ein Compliance-Thema. Fehlendes anwendungsbezogenes Monitoring bedeutet in der Praxis, dass eine Organisation nicht feststellen kann, ob ein Vorfall stattgefunden hat, wann er begonnen hat und welchen tatsächlichen Umfang er hatte.

OWASP Top 10 2025 macht deutlich, dass es in modernen Architekturen nicht ausreicht, „Fehler“ zu loggen. Erfasst werden müssen sicherheitsrelevante Ereignisse wie ungewöhnliche Operationssequenzen, Versuche zur Privilegieneskalation, Missbrauch von Geschäftslogik sowie Anomalien im Verhalten von Nutzern und Services. Ohne diese Sichtbarkeit kann eine Organisation eine zentrale Annahme von NIS2 nicht erfüllen, nämlich Incident Management in Echtzeit statt einer Reaktion im Nachhinein. Besonders problematisch wird dies in verteilten Umgebungen mit APIs, Microservices und Cloud. OWASP Top 10 2025 zeigt, dass mit wachsender Komplexität die Korrelation von Ereignissen auf Anwendungs- und Prozessebene immer wichtiger wird. Ein einzelnes Ereignis kann harmlos wirken, erst die Korrelation offenbart einen echten Angriff. Ohne eine solche Korrelation verliert die Organisation die Fähigkeit zu beurteilen, ob ein Vorfall meldepflichtig nach NIS2 ist.

A09 berührt zudem den Bereich organisatorischer Verantwortlichkeit. Selbst wenn ein Vorfall technisch erkannt wird, führen fehlende klar definierte Reaktionsprozesse, fehlende Verantwortungszuweisung und nicht geübte Incident-Szenarien zu verzögerten oder chaotischen Reaktionen. Aus NIS2-Sicht ist dies nicht nur ein operatives Problem, sondern eine Nichterfüllung der Pflicht zur wirksamen Cybersecurity-Governance.

OWASP Top 10 2025 legt nahe, dass Anwendungssicherheit ohne wirksames Logging und Monitoring eine Illusion ist. Unter NIS2-Bedingungen bedeutet fehlende Sichtbarkeit nicht mehr nur erhöhtes technisches Risiko. Sie bedeutet regulatorisches, reputationsbezogenes und Governance-Risiko, das sich genau in dem Moment materialisiert, in dem eine Organisation die grundlegende Frage nicht beantworten kann: was ist in unserem System tatsächlich passiert?

A10: Server-Side Request Forgery (SSRF) – ein stiller Eskalationsvektor in modernen Architekturen.

Server-Side Request Forgery ist, obwohl formal an letzter Stelle der OWASP Top 10 2025, in der Praxis weiterhin einer der gefährlichsten Angriffsvektoren in Cloud- und Hybridumgebungen. A10 ist keine neue Kategorie, doch ihre Beibehaltung als eigener Punkt in der Edition 2025 ist nicht zufällig. SSRF nutzt aus, dass Server-Anwendungen immer häufiger als Vermittler zwischen Nutzern und anderen Services fungieren, sowohl internen als auch externen. Wenn eine Anwendung ohne ausreichende Einschränkungen HTTP-Requests im Namen des Nutzers ausführt, wird sie zu einem idealen Werkzeug für Missbrauch. Angreifer benötigen keinen direkten Zugriff auf interne Infrastruktur. Es genügt, die Anwendung dazu zu bringen, einen passenden Request auszuführen.

In Cloud-Umgebungen sind die Auswirkungen von SSRF besonders gravierend. Zugriff auf Instanz-Metadaten, Management-Services oder interne APIs kann zu Privilegieneskalation, Secret-Leakage und im Extremfall zur vollständigen Kompromittierung der Umgebung führen. Wichtig ist, dass SSRF-Angriffe häufig keine offensichtlichen Alarmsignale erzeugen, weil sie legitime Anwendungsfunktionen nutzen. OWASP Top 10 2025 betont, dass SSRF ein systemisches Problem ist und nicht lediglich ein Fehler der Eingabevalidierung. Die Ursache liegt im Fehlen eines klaren Vertrauensmodells, in unkontrollierten Integrationen sowie in der Annahme, dass von der Server-Anwendung generierter Traffic per Definition sicher ist.

Die Beibehaltung von A10 als eigenständige Kategorie ist ein klares Signal dafür, dass in modernen Architekturen die Grenze zwischen Anwendung und Infrastruktur zunehmend verschwimmt und Sicherheit beide Bereiche gleichzeitig umfassen muss.

OWASP Top 10 2025 im Kontext von NIS2 – von Schwachstellen zu Managementverantwortung.

Die NIS2-Richtlinie verändert die Art und Weise, wie Sicherheit von Webanwendungen in regulierten Organisationen wahrgenommen wird. Im Gegensatz zu früheren Ansätzen konzentriert sich NIS2 nicht auf einzelne technische Maßnahmen, sondern auf systemisches Risikomanagement für Cybersecurity sowie auf die Fähigkeit der Organisation, Vorfälle zu verhindern, zu erkennen und darauf zu reagieren. In diesem Kontext ist OWASP Top 10 2025 nicht mehr nur ein technisches Dokument. Es wird zu einem praktischen Modell für Applikationsrisiken, das gut zu den Anforderungen von NIS2 passt, auch wenn die Richtlinie selbst keine OWASP-Terminologie verwendet.

Die Kategorien A01-A04, die Zugriffskontrolle und Systemdesign abdecken, beziehen sich direkt auf die Verpflichtung, Risiken bereits in der Designphase wesentlicher und wichtiger Dienste zu identifizieren und zu reduzieren. NIS2 verlangt, dass Sicherheit in die Architektur von Informationssystemen integriert wird und nicht erst reaktiv nach einem Vorfall. Insecure Design und Broken Access Control zeigen sehr deutlich, wie das Fehlen eines solchen Ansatzes zu systemischen Risiken führt, für die Verantwortung nicht nur bei technischen Teams liegt, sondern auch auf Managementebene.

Die Kategorien A02 und A03, die Kryptografie und Injection betreffen, fallen in den Bereich technischer und organisatorischer Maßnahmen, die NIS2 als Schutz von Integrität, Vertraulichkeit und Verfügbarkeit von Daten versteht. Wichtig ist, dass die Richtlinie weder „einen konkreten Algorithmus“ noch „einen konkreten Mechanismus“ vorschreibt, sondern Angemessenheit der Kontrollen in Bezug auf das Risikoniveau erwartet. OWASP Top 10 2025 liefert hier eine praktische Sprache, um zu beurteilen, ob implementierte Maßnahmen tatsächlichen Applikationsbedrohungen entsprechen.

A05 und A06, also Security Misconfiguration sowie Vulnerable and Outdated Components, stehen in direktem Zusammenhang mit den NIS2-Anforderungen zur Aufrechterhaltung von Sicherheit über die Zeit. Die Richtlinie betont ausdrücklich, dass Sicherheit kein einmaliger Zustand ist, sondern ein kontinuierlicher Prozess. Konfigurationsfehler und nicht gemanagte Abhängigkeiten sind klassische Beispiele für Risiken, die nach dem Deployment entstehen, häufig durch operative Änderungen, Updates oder geschäftlichen Druck. In der Praxis gehören sie zu den häufigsten Ursachen für Vorfälle, die an CSIRTs gemeldet werden.

Besonders wichtig im Kontext von NIS2 sind die Kategorien A08, A09 und A10. Software and Data Integrity Failures zeigt, dass Sicherheit der Software-Lieferkette kein Nischenthema mehr ist, sondern eine reale organisatorische Pflicht. NIS2 verlangt ausdrücklich Kontrolle über Lieferanten, Deployment-Prozesse und Systemintegrität, was A08 zu einer der „regulatorisch relevantesten“ Kategorien der OWASP Top 10 2025 macht.

A09, Security Logging and Monitoring Failures, lässt sich nahezu direkt auf NIS2-Pflichten rund um Erkennung, Analyse und Meldung von Vorfällen abbilden. Die Richtlinie geht davon aus, dass Organisationen Vorfälle rechtzeitig bemerken müssen und nicht erst reagieren, wenn die Auswirkungen bereits sichtbar sind. Fehlendes anwendungsbezogenes Monitoring, fehlende Ereigniskorrelation und fehlende Reaktionsprozesse bedeuten in der Praxis die Unfähigkeit, zentrale NIS2-Anforderungen zu erfüllen, unabhängig davon, wie stark präventive Kontrollen sind.

SSRF in A10 erhält im Kontext von NIS2 eine zusätzliche Dimension, weil es zeigt, wie eine Webanwendung zum Einstiegspunkt in kritische Infrastruktur werden kann. In Cloud- und Hybridumgebungen ist die Grenze zwischen Anwendung und Systemen, die wesentliche Dienste unterstützen, oft extrem dünn. Ein SSRF-Angriff kann zu einer Eskalation führen, die weit über eine einzelne Anwendung hinausgeht und damit direkt in die Risikoszenarien fällt, vor denen NIS2 schützen soll.

Aus Sicht von Organisationen, die NIS2 unterliegen, ist OWASP Top 10 2025 daher keine „Liste von Schwachstellen“, sondern ein praktisches Werkzeug zur Erfüllung der Pflicht zum Cybersecurity-Risikomanagement. Es übersetzt abstrakte regulatorische Anforderungen in konkrete Bereiche von Anwendungsarchitektur und Prozessen, die kontrolliert werden können und kontrolliert werden sollten.