Was ist CWE?

CWE steht für Common Weakness Enumeration. Es handelt sich um eine gemeinschaftlich gepflegte Wissensbasis wiederkehrender Schwächen in Software und Hardware. Jede Schwächenart erhält eine eindeutige Kennung wie CWE-79 für Cross-Site Scripting oder CWE-89 für SQL Injection. Entwickler, Tester, Toolhersteller und Sicherheitsverantwortliche können dadurch dieselbe Fehlerklasse einheitlich benennen und Erkenntnisse über verschiedene Produkte hinweg vergleichen.

Was ist eine Weakness?

Eine Weakness ist eine Bedingung in Architektur, Design, Code oder Implementierung, die unter passenden Umständen zu einer ausnutzbaren Sicherheitslücke führen kann. Beispiele sind fehlende Autorisierungsprüfungen, unsichere Speicherzugriffe, fest einprogrammierte Zugangsdaten oder die ungefilterte Übergabe von Benutzereingaben an einen Interpreter. Die Weakness beschreibt also die Art beziehungsweise Ursache eines Fehlers – nicht automatisch einen konkreten verwundbaren Produktstand.

Mehrere konkrete Sicherheitslücken können dieselbe Ursache besitzen. Eine SQL Injection in einem Shopsystem und eine SQL Injection in einer Verwaltungssoftware können beide CWE-89 zugeordnet werden, obwohl Quellcode, Hersteller und Auswirkung verschieden sind. Genau diese Abstraktion ermöglicht es, wiederkehrende Ursachen zu erkennen und bereits während der Entwicklung zu vermeiden.

Wie ist CWE aufgebaut?

CWE ist keine einfache, flache Liste. Schwächen stehen in Beziehungen zueinander und besitzen unterschiedliche Abstraktionsebenen. Je abstrakter ein Eintrag ist, desto mehr Fälle fasst er zusammen. Je spezifischer er ist, desto konkreter werden Ursache, Technologie und mögliche Gegenmaßnahmen.

Daneben existieren Categories, Views und Compound Elements. Eine Category gruppiert verwandte Einträge, ist aber selbst keine Schwäche. Eine View stellt den Katalog für einen bestimmten Zweck dar, beispielsweise für Softwareentwicklung, Forschung oder Hardwaredesign. Composites verbinden mehrere gleichzeitig notwendige Schwächen; Chains beschreiben eine Abfolge, bei der eine Schwäche die nächste ermöglicht. Ein Beispiel ist eine fehlerhafte Ganzzahlberechnung, die anschließend zu einem Buffer Overflow führt.

Welche Informationen enthält ein CWE-Eintrag?

• Beschreibung:
  Welches fehlerhafte Verhalten die Schwäche ausmacht und wie sie von ähnlichen Einträgen abgegrenzt wird.
• Entstehungsphase:
  Ob die Schwäche typischerweise bei Anforderungen, Architektur, Design, Implementierung oder Betrieb eingeführt wird.
• Folgen:
  Welche Auswirkungen auf Vertraulichkeit, Integrität, Verfügbarkeit oder Zugriffskontrolle möglich sind.
• Erkennung:
  Welche Codeanalyse, manuellen Prüfungen oder dynamischen Tests Hinweise liefern können.
• Gegenmaßnahmen:
  Welche Design- und Implementierungsansätze die Ursache vermeiden oder begrenzen.
• Beispiele und Referenzen:
  Demonstrativer Code, beobachtete CVEs, relevante Plattformen und verwandte Angriffsmuster.
• Beziehungen:
  Über- und untergeordnete Schwächen, mögliche Chains sowie Zuordnungen zu Views und externen Taxonomien.

Nicht jeder Eintrag enthält Informationen in derselben Tiefe. Dennoch eignet sich die CWE-Detailseite häufig als Ausgangspunkt, um aus einem Finding eine Ursache, mögliche Folgen und passende Präventionsmaßnahmen abzuleiten.

Was unterscheidet CWE, CVE, CVSS und CAPEC?

Ein vereinfachtes Beispiel: Eine Anwendung setzt Benutzereingaben ungefiltert in eine SQL-Abfrage ein. Die Ursache lässt sich als CWE-89 klassifizieren. Wird dieser Fehler in einer bestimmten veröffentlichten Produktversion entdeckt, kann er eine CVE-Kennung erhalten. Ein CVSS-Vektor beschreibt technische Ausnutzbarkeit und Auswirkung dieser konkreten Lücke. Das tatsächliche Risiko für ein Unternehmen hängt zusätzlich von Exposition, verwendeter Funktion, Daten und vorhandenen Schutzmaßnahmen ab.

Wie wird die richtige CWE zugeordnet?

1. Beobachtung von Ursache trennen: Nicht nur die sichtbare Auswirkung beschreiben, sondern den Fehler bestimmen, der sie ermöglicht.
2. Passende View verwenden: Je nach Zweck beispielsweise in der Development View oder Research View navigieren.
3. So spezifisch wie belastbar zuordnen: Möglichst einen Base- oder Variant-Eintrag wählen, ohne Details zu behaupten, die nicht nachgewiesen wurden.
4. Verwandte Einträge vergleichen: Beschreibung, Abgrenzung, Beziehungen und Beispiele auf der CWE-Seite prüfen.
5. Mapping begründen: Im Bericht erklären, welches Verhalten die Zuordnung stützt.

Zu abstrakte Zuordnungen wie die allgemeine Injection-Klasse helfen Entwicklern weniger als eine belegbare Zuordnung zu SQL-, LDAP- oder Command Injection. Umgekehrt ist eine sehr spezifische Variante falsch, wenn die notwendige Technologie oder Ursache nicht geprüft wurde. Categories und Views sollten nicht als Root Cause eines konkreten Findings verwendet werden.

Wie wird CWE in der Praxis genutzt?

Softwareentwicklung

Teams können wiederkehrende CWEs aus Findings auswerten und daraus Coding Guidelines, gemeinsame Bibliotheken, Architekturvorgaben und gezielte Schulungen ableiten. Tritt CWE-862 „Missing Authorization“ regelmäßig auf, ist die richtige Reaktion nicht nur das Schließen einzelner Tickets. Sinnvoller sind zentrale Autorisierungsmechanismen, klare Ownership und automatisierte negative Tests für Berechtigungen.

Penetrationstests und Codeanalysen

Ein Penetrationstest kann Findings mit CWE-IDs versehen. Auftraggeber erhalten dadurch eine standardisierte Referenz und können Funde aus verschiedenen Berichten gruppieren. SAST-, DAST- und SCA-Werkzeuge nutzen CWE ebenfalls, ihre Mappings sollten aber überprüft werden: Ein automatischer Treffer beweist weder die Ursache noch die praktische Ausnutzbarkeit.

Kennzahlen und Beschaffung

CWE-Kategorien ermöglichen Trendanalysen: Welche Fehler kehren zurück? In welcher Phase entstehen sie? Welche Teams benötigen Unterstützung? Verträge und Sicherheitsanforderungen können relevante Schwächen referenzieren. Eine bloße Anzahl geschlossener CWEs ist jedoch keine belastbare Sicherheitskennzahl; Schweregrad, Systemkontext und wiederkehrende Ursache müssen einfließen.

Was ist die CWE Top 25?

Die CWE Top 25 ordnet besonders verbreitete und folgenreiche Software-Schwächen anhand veröffentlichter CVE-Daten. In der Ausgabe 2025 standen CWE-79 Cross-Site Scripting, CWE-89 SQL Injection, CWE-352 Cross-Site Request Forgery, CWE-862 Missing Authorization und CWE-787 Out-of-bounds Write auf den ersten fünf Plätzen. Weitere hoch platzierte Ursachen waren Path Traversal, Use After Free, Out-of-bounds Read, OS Command Injection und Code Injection.

Die Top 25 ist nützlich für Awareness und die Priorisierung allgemeiner Secure-Coding-Maßnahmen. Sie ist aber keine vollständige Prüfliste für jede Anwendung. Eine Schwäche außerhalb der Rangliste kann für ein konkretes Produkt das größte Risiko darstellen. Technologie, Architektur und Bedrohungsmodell müssen deshalb weiterhin berücksichtigt werden.

Welche Grenzen hat CWE?

Eine CWE-ID misst weder den Schweregrad noch das reale Geschäftsrisiko eines Findings. Derselbe Fehler kann in einer öffentlichen Administrationsschnittstelle kritisch und in einem isolierten Testwerkzeug nahezu bedeutungslos sein. Auch garantiert der Katalog keine vollständige oder widerspruchsfreie Zuordnung: Schwächen können sich überlappen, als Kette auftreten oder je nach Erkenntnisstand unterschiedlich präzise beschrieben werden.

CWE ist deshalb vor allem eine gemeinsame Sprache und Wissensbasis. Sie verbessert Berichte, Ursachenanalysen und Prävention, ersetzt aber weder technische Prüfung noch Risikobewertung. Der größte Nutzen entsteht, wenn Teams nicht nur IDs sammeln, sondern aus wiederkehrenden Ursachen konkrete Verbesserungen im Entwicklungsprozess ableiten.