01Schwachstellen-Landkarte: die CWE Top 25 (Ausgabe 2025)
Die CWE Top 25 von MITRE ranken die gefährlichsten Software-Schwachstellenklassen; die Ausgabe 2025 basiert auf 39.080 CVE-Einträgen aus dem Zeitraum Juni 2024 bis Juni 2025, gewichtet nach Häufigkeit und durchschnittlichem CVSS-Schweregrad. An der Spitze stehen Cross-Site Scripting (CWE-79), SQL-Injection (CWE-89) und Cross-Site Request Forgery (CWE-352) – seit Jahrzehnten bekannte Muster, die dennoch die häufigsten Ursachen realer CVEs bleiben. Auffällig sind daneben zwei Blöcke: Speicherfehler wie Out-of-bounds Write/Read und Use After Free (vor allem in C/C++-Codebasen) sowie gleich vier Autorisierungs-Schwächen (CWE-862, CWE-863, CWE-284, CWE-639). Für Secure Coding heißt das: Die meisten Schwachstellen folgen bekannten, vermeidbaren Mustern – und lassen sich gezielt adressieren.
02OWASP Top 10:2025 – Risikokategorien für Webanwendungen
Die OWASP Top 10 bündeln einzelne Schwächen zu Risikokategorien; die Ausgabe 2025 ist die aktuelle veröffentlichte Version und stützt sich auf Testdaten von rund 2,8 Millionen Anwendungen. Broken Access Control bleibt auf Platz 1 und umfasst nun auch Server-Side Request Forgery; neu sind A03 „Software Supply Chain Failures“ als Erweiterung der früheren „Vulnerable and Outdated Components“ sowie A10 „Mishandling of Exceptional Conditions“. Injection (A05), Security Misconfiguration (A02) und Cryptographic Failures (A04) bleiben prominent vertreten. Die Top 10 eignen sich gut für Awareness und Priorisierung – einen vollständigen Anforderungskatalog für die Entwicklung ersetzen sie nicht.
03OWASP ASVS 5.0 als Anforderungsrahmen
Der OWASP Application Security Verification Standard übersetzt Secure Coding in prüfbare Anforderungen. Version 5.0.0 (veröffentlicht im Mai 2025) umfasst rund 350 Anforderungen in 17 Kapiteln – von Encoding und Sanitization über Autorisierung, Session-Management und Kryptografie bis zu Secure Coding and Architecture. Die drei Level sind gegenüber 4.x neu geschnitten und nach Priorität geordnet: L1 enthält als Einstieg rund 20 Prozent der Anforderungen (kritische Erstverteidigung), L2 als Zielniveau für die meisten Anwendungen weitere rund 50 Prozent, L3 die verbleibenden Defense-in-Depth-Maßnahmen. In der Praxis dient der ASVS als Anforderungsrahmen für Entwicklung und Beschaffung ebenso wie als Prüfmaßstab für Code Reviews und Penetrationstests.
04Kern-Praktiken: Validierung, Encoding, Autorisierung, Secrets
Vier Praktiken decken einen Großteil der Schwachstellen-Landkarte ab. Erstens Input-Validierung: alle Eingaben serverseitig gegen Positivlisten (Typ, Länge, Wertebereich, erlaubte Syntax) prüfen – das reduziert die Angriffsfläche, ersetzt aber kein Encoding. Zweitens kontextspezifisches Output-Encoding und parametrisierte Abfragen: Sie neutralisieren Injection-Klassen wie XSS und SQL-Injection an der Wurzel. Drittens Autorisierung nach dem Muster „deny by default“: jede Objekt- und Funktionszugriffsprüfung serverseitig und zentral (Policy bzw. Middleware) statt verstreuter Einzelprüfungen – genau gegen die im CWE-Ranking prominenten Klassen CWE-862 und CWE-639. Viertens Secrets-Handling: keine Zugangsdaten oder Schlüssel im Quellcode oder in Repositories, sondern zentrale Secrets-Speicher mit Rotation und minimalen Berechtigungen, ergänzt um Secret-Scanning in der Pipeline.
05Verankerung im SDLC: Code Review, SAST und DAST
Secure Coding wirkt nur, wenn es im Entwicklungsprozess verankert ist. SAST analysiert den Quellcode bereits im Pull Request und findet Muster wie Injection-Senken oder hartkodierte Secrets; DAST testet die laufende Anwendung und erkennt Konfigurations- und Laufzeitprobleme – beide ergänzen sich, ersetzen einander aber nicht. Manuelle Security-Code-Reviews bleiben für Logik-Schwächen wie fehlende Autorisierung unverzichtbar, weil automatisierte Werkzeuge solche Fehler kaum erkennen. Den organisatorischen Rahmen liefert das NIST Secure Software Development Framework (SP 800-218, Version 1.1) mit vier Praxisgruppen von der Vorbereitung der Organisation bis zur Reaktion auf Schwachstellen; ASVS-Level und CWE-Klassen liefern die inhaltliche Messlatte für Quality Gates und Metriken.
06Entwickler-Enablement: Training, Champions, „Paved Road“
Standards und Werkzeuge scheitern ohne Entwicklerinnen und Entwickler, die sie anwenden können. Wirksames Enablement ist rollen- und stackspezifisch: Trainings entlang der im eigenen Code tatsächlich gefundenen Schwachstellenklassen statt generischer Jahresschulungen, ergänzt um Security Champions in den Teams als erste Anlaufstelle. Ebenso wichtig ist der „Paved Road“-Gedanke: geprüfte Bibliotheken, sichere Framework-Defaults und Vorlagen, die die sichere Variante zur einfachsten machen – die OWASP Top 10 Proactive Controls 2024 (C1–C10) bieten dafür eine kompakte, entwicklernahe Prioritätenliste. Messbar wird das Programm über Größen wie die Wiederauftretensrate einzelner Schwachstellenklassen und die Zeit bis zur Behebung.
