Begriffe in der Cybersicherheit: Was ist eigentlich eine Schwachstelle?

Was genau ist eigentlich eine Schwachstelle? Und was unterscheidet sie von einer technischen Schwäche, einer Bedrohung oder einem Risiko? Diese Begriffe tauchen in Normen, Tools, Gesetzen und Audits immer wieder auf, werden aber oft unterschiedlich verwendet. In diesem Artikel erklären wir die wichtigsten Begriffe der IT-Sicherheit klar, praxisnah und mit Bezug zur Cyber-Resilience-Verordnung (CRA).

Warum lohnt es sich, die Begriffe sauber zu trennen?

In Sicherheitsprozessen, ob in der Entwicklung, bei der Konformität mit der CRA oder bei internen Audits, ist es wichtig, präzise zu sprechen:

• Ist etwas ein genereller Programmierfehler oder schon eine ausnutzbare Lücke?
• Ist die Gefahr theoretisch oder gibt es ein reales Angriffsszenario?
• Und wie bewerten wir das Risiko, das sich daraus ergibt?

Denn Security-Standards, Tools und Gesetze unterscheiden sehr genau zwischen diesen Begriffen:

• ISO/IEC 27005 nutzt den Begriff „Risk“ als zentrales Steuerungsinstrument für Sicherheitsentscheidungen.
• Das CVE-System beschreibt konkrete Schwachstellen (Vulnerabilities) in Produkten und Komponenten.
• Der CWE-Katalog klassifiziert technische Fehlerarten (Weaknesses), die zu solchen Schwachstellen führen können.
• NIST und die CRA sprechen gezielt über Threats (Bedrohungen), also darüber, wie Risiken durch Angreifer entstehen und Schwachstellen ausgenutzt werden.

Technische Schwächen: die Weakness

Der Begriff Weakness (auf Deutsch: technische Schwäche) beschreibt ein grundsätzliches, wiederkehrendes Problem in der Architektur, dem Design oder dem Code eines Systems.

Dabei handelt es sich nicht um eine konkrete Schwachstelle in einem bestimmten Produkt – sondern um ein generisches Fehlermuster, das in vielen Systemen auftreten kann und potenziell die Sicherheit beeinträchtigt.

Eine Weakness ist sozusagen die Ursache – die Schwachstelle (Vulnerability) ist das Symptom.

Wann spricht man von einer Weakness?

Eine Weakness liegt zum Beispiel vor, wenn:

• Entwickler Eingaben nicht validieren, bevor sie verarbeitet werden
• Passwörter hart im Code gespeichert werden
• Fehlende Zugriffskontrollen auf API-Ebene bestehen
• Speicherbereiche ohne Begrenzung beschrieben werden (Buffer Overflow)
• oder Fehler in der Session-Verwaltung auftreten

Diese Muster sind technisch bekannt, in Katalogen dokumentiert – und die Ursache vieler realer Angriffe.

Standardreferenz: CWE – Common Weakness Enumeration

Die CWE-Liste (Common Weakness Enumeration) des MITRE-Konsortiums klassifiziert über 900 bekannte Schwächen nach Kategorien wie „Input Validation“, „Authentication“, „Cryptographic Issues“ oder „Concurrency Flaws“.

Ziel ist es, Entwicklern, Architekten und Security-Teams eine gemeinsame Sprache zu geben, um über technische Risiken zu sprechen – unabhängig von konkreten Produkten.

Beispiel aus der Praxis

Ein Webformular überträgt Nutzereingaben direkt in eine Datenbankabfrage, ohne die Eingaben zu prüfen. Ein Angreifer kann dadurch JavaScript oder SQL-Code einschleusen.

Diese Schwäche ist allgemein bekannt als:

CWE-20: Improper Input Validation

Ob diese Schwäche in einem Produkt tatsächlich zu einer Vulnerability wird, hängt von vielen Faktoren ab, beispielsweise ob zusätzliche Filter oder Sicherheitsmechanismen greifen.

Ausnutzbare Schwachstellen: die Vulnerability

Eine Vulnerability (auf Deutsch: ausnutzbare Schwachstelle) ist eine konkrete Sicherheitslücke, die in einem bestimmten Produkt, System oder einer Softwarekomponente identifiziert wurde.

Im Gegensatz zur allgemeinen Weakness, die als Fehlerquelle theoretisch überall vorkommen kann, beschreibt eine Vulnerability eine greifbare und überprüfbare Schwachstelle, die sich unter bestimmten Bedingungen technisch ausnutzen lässt.

Wann spricht man von einer Vulnerability?

Eine Vulnerability liegt vor, wenn:

• sich eine technische Schwäche (z. B. ungeprüfte Eingaben) in einem konkreten Release oder Produkt manifestiert
• ein Angreifer sie aus der Ferne oder lokal ausnutzen kann
• daraus ein Verlust an Vertraulichkeit, Integrität oder Verfügbarkeit entstehen kann
• die Schwachstelle öffentlich oder intern dokumentiert und reproduzierbar ist

Nicht jede Weakness wird zu einer Vulnerability – aber jede Vulnerability basiert auf mindestens einer Weakness.

Standardreferenz: CVE, ISO/IEC 27005, NIST SP 800-30

Die bekannteste Datenbank für dokumentierte Schwachstellen ist das CVE-System (Common Vulnerabilities and Exposures), betrieben von MITRE. Jede erfasste Lücke erhält eine eindeutige Kennung, z. B. CVE-2024-12345, und wird mit Informationen zu betroffenen Produkten, Versionen, Auswirkung und Schweregrad (z. B. CVSS-Score) veröffentlicht.

Parallel dazu definieren ISO/IEC 27005 und NIST SP 800-30 Vulnerabilities als zentrale Elemente im Risikomanagement.

Beispiel aus der Praxis

Ein Online-Shop verwendet eine veraltete Version eines Web-Frameworks, in dem eine SQL-Injection-Schwachstelle entdeckt wurde. Angreifer können durch manipulierte URLs beliebige Datenbankbefehle ausführen.

Diese konkrete Lücke wird wie folgt dokumentiert:

CVE-2024-12345 – SQL Injection in XYZ Framework 2.3.1

Die Schwachstelle ist nun nachvollziehbar, ausnutzbar und muss vom Hersteller behoben werden – z. B. durch ein Sicherheitsupdate.

Bedrohungen: die Threat

Eine Threat (auf Deutsch: Bedrohung) bezeichnet eine potenzielle Ursache für Schaden, die sich gegen ein System, eine Organisation oder ein Produkt richten kann, insbesondere, wenn dort Schwachstellen vorhanden sind.

Im Unterschied zu einer Vulnerability ist ein Threat kein technischer Fehler, sondern ein externes oder internes Ereignis, das eine vorhandene Schwachstelle aktiv ausnutzen könnte.

Wann spricht man von einer Threat?

Eine Bedrohung kann viele Formen annehmen, zum Beispiel:

• Personen mit böswilliger Absicht (z. B. Hacker, Insider, Cybercrime-Gruppen)
• automatisierte Tools oder Bots, die gezielt nach Schwachstellen suchen
• technische Ereignisse wie Stromausfälle, Hardwaredefekte oder Softwareabstürze
• menschliches Fehlverhalten wie Fehlkonfigurationen oder Social Engineering
• natürliche Einflüsse wie Wasser, Feuer oder extreme Temperaturen

Die Bedrohung ist noch kein Angriff, aber sie beschreibt ein realistisches Risiko­szenario.

Standardreferenz: ISO/IEC 27000, NIST SP 800-30, NIST Glossary

• ISO/IEC 27000:2022 (Abschnitt 3.70):

  „A potential cause of an unwanted incident, which may result in harm to a system or organization.“

• NIST SP 800-30 Rev. 1:

  „The potential for a particular threat source to successfully exploit a particular vulnerability.“

In beiden Definitionen geht es darum, dass etwas oder jemand eine vorhandene Schwachstelle nutzen könnte, um Schaden zu verursachen, aber noch nicht zwangsläufig aktiv geworden ist.

Beispiel aus der Praxis

Ein Botnetz durchsucht automatisiert tausende Webserver im Internet nach einer bekannten Schwachstelle (CVE).

Es ist dabei nicht auf ein bestimmtes Unternehmen ausgerichtet – sondern nutzt eine skalierte Angriffsmethode, bei der jede nicht gepatchte Instanz zum Ziel werden kann.

Fazit: Das Botnetz ist die Threat, die ungepatchte Schwachstelle auf dem Server ist die Vulnerability und der Schaden (z. B. Datenabfluss) wäre das Risiko, wenn es zur Ausnutzung kommt.

Das Ergebnis: das Risiko

Ein Risiko entsteht dann, wenn eine Bedrohung (Threat) auf eine Schwachstelle (Vulnerability) trifft und daraus ein realer Schaden entstehen kann.

Es ist also das Produkt aus Möglichkeit und Wirkung oder einfacher gesagt:

Was kann passieren? Wie wahrscheinlich ist es? Und wie schlimm wäre es?

Risiko ist in der Cybersicherheit nicht gleich Bedrohung, sondern die Kombination mehrerer Faktoren, die in Summe über das Sicherheitsniveau eines Produkts oder Systems entscheiden.

Standardreferenz: ISO/IEC 27005 & ISO/IEC 31000

• ISO/IEC 31000:2018 (Kap. 3.1):

  „Risk is the effect of uncertainty on objectives.“

• ISO/IEC 27005:2018 (Kap. 8):

  „Risk results from the combination of the probability of an event and its consequences.“

Diese Definitionen betonen: Risiko ist nicht nur Technik, sondern immer auch eine Frage von Unternehmenszielen, Werten, Auswirkungen und Unsicherheiten.

Beispiel aus der Praxis

Ein Unternehmen betreibt einen VPN-Server mit einer bekannten Schwachstelle (CVE-2024-56789). Ein automatisiertes Angriffsskript (Threat) wird darauf angesetzt – und kompromittiert den Zugang.

Die Folge:

• Zugriff auf interne Systeme
• Verlust sensibler Kundendaten
• Datenschutzverletzung
• Reputations- und Vertrauensverlust

In diesem Fall ergibt sich das Risiko aus:

• der existierenden Schwachstelle (Vulnerability)
• eine aktive Bedrohung (Threat)
• dem Schaden, der daraus entsteht

Risiko = Eintrittswahrscheinlichkeit × Schadensausmaß

Im Risikomanagement, etwa nach ISO/IEC 27005 oder im CRA-Kontext, wird das Risiko oft qualitativ oder quantitativ bewertet. Dabei geht es nicht nur um technische Aspekte, sondern auch um:

• finanzielle Auswirkungen
• rechtliche Folgen
• Betriebsunterbrechungen
• Auswirkungen auf Vertrauen und Marktposition
• Verstöße gegen das Gesetz

Typische Methoden zur Bewertung:

• Risikomatrix (Low / Medium / High / Critical)
• CVSS (für technische Schweregrade)
• Risikoportfolios mit Eintrittswahrscheinlichkeit und Schadenshöhe

So hängen die Begriffe zusammen

Die vier Begriffe Weakness, Vulnerability, Threat und Risk sind keine Synonyme, sondern beschreiben aufeinander aufbauende Stufen innerhalb eines Sicherheitskontexts.

Man kann sie sich wie eine Kette vorstellen, jede Stufe führt zur nächsten:

Weakness – die potenzielle Ursache

Am Anfang steht die Weakness, also ein technisches oder konzeptionelles Fehlermuster. Das kann eine fehlerhafte Eingabeprüfung, unsicherer Umgang mit Rechten oder mangelnde Authentifizierung sein.

Sie ist noch keine akute Gefahr, aber sie schafft die Voraussetzungen für spätere Probleme.

Vulnerability – die konkrete Schwachstelle

Wird eine Weakness im Code oder Design nicht behoben, kann sie sich im konkreten Produkt als Vulnerability manifestieren, also eine tatsächlich existierende, überprüfbare Schwachstelle, die unter bestimmten Bedingungen ausnutzbar ist.

Jetzt gibt es eine reale Lücke, mit direktem Bezug zu einem bestimmten System oder einer Softwareversion.

Threat – die Bedrohung

Eine Threat beschreibt die potenzielle Ausnutzung dieser Lücke etwa durch einen Angreifer, Malware, menschliches Versagen oder äußere Umstände.

Solange die Vulnerability nicht bekannt ist oder niemand sie ausnutzt, bleibt sie theoretisch. Doch sobald eine Threat aktiv wird, wird sie zur Auslöserin eines Risikos.

Risk – das resultierende Risiko

Wenn die Threat erfolgreich ist, also die Schwachstelle ausgenutzt wird, kann daraus ein realer Schaden entstehen: Datenverlust, Systemausfall, Reputationsschaden oder ein rechtlicher Verstoß.

Das Risiko beschreibt die Kombination aus Wahrscheinlichkeit und Schadensausmaß und ist die zentrale Bewertungsgröße für Management, Audits und Security-Maßnahmen.

Zusammenfassung als Kette:

    [ Weakness ]       
        ↓
    [ Vulnerability ]  
        ↓
    [ Threat ]         
        ↓
    [ Risiko ]

Oder als kurzer Satz:

Eine Weakness kann zu einer Vulnerability führen. Eine Threat kann diese Schwachstelle ausnutzen. Und daraus entsteht ein Risiko, das Schaden verursacht.

CWE und CVE: Zwei Seiten derselben Medaille

Die Begriffe CWE und CVE begegnen uns häufig im Sicherheitskontext insbesondere, wenn es um automatisierte Tools, SBOMs oder Schwachstellenberichte geht. Doch obwohl sie ähnlich klingen, erfüllen sie komplementäre Aufgaben im Security-Ökosystem.

Man kann sagen: CWE beschreibt das Problem – CVE beschreibt den konkreten Vorfall.

Was ist CWE?

CWE (Common Weakness Enumeration) ist ein internationaler Standardkatalog, der typische technische Schwächen (Weaknesses) systematisch klassifiziert.

CWE ist präventiv: Sie hilft, Fehler zu vermeiden, bevor sie zur Schwachstelle werden.

Was ist CVE?

CVE (Common Vulnerabilities and Exposures) ist ein globales System zur Identifikation konkreter Sicherheitslücken in Produkten, Systemen oder Komponenten.

CVE ist reaktiv: Sie zeigt auf, wo ein Fehler passiert ist – und welche Maßnahmen jetzt nötig sind.

CWE vs. CVE im Überblick

Relevanz für die CRA

Auch die Cyber-Resilience-Verordnung arbeitet mit diesen Begriffen (direkt oder indirekt):

Beispiel: Wer eine Schwachstelle (Vulnerability) nicht behebt, obwohl sie bekannt ist, verstößt gegen Art. 13 CRA. Wer eine „wesentliche Änderung“ macht, ohne Risikoanalyse, riskiert eine neue Konformitätsbewertung (Art. 14 CRA).

Fazit

Die Begriffe Weakness, Vulnerability, Threat und Risk klingen im Alltag oft austauschbar, sind es aber nicht. In der professionellen IT-Sicherheit haben sie klar definierte Bedeutungen, eigene Kontexte, Normreferenzen und ganz unterschiedliche Funktionen im Sicherheitslebenszyklus.

Wer diese Begriffe richtig versteht und gezielt einsetzt, kann:

Sicherheitsprozesse strukturieren Schwachstellenmanagement beginnt mit der Erkennung technischer Fehlerquellen (CWE), der Identifikation konkreter Lücken (CVE) und der Bewertung realer Bedrohungsszenarien (Threat Modeling). Nur mit diesem Wissen lässt sich das Risiko richtig einschätzen und zielgerichtet mindern.

Audits und technische Dokumentation sauber vorbereiten Unklare Risikobeschreibungen oder vermischte Begriffe führen zu Rückfragen durch Auditor:innen und Behörden. Wer Threats, Schwachstellen und Risiken sauber dokumentiert, etwa nach ISO 27005 oder Anhang VII der CRA wirkt professionell, vorbereitet und vertrauenswürdig.

Normen und gesetzliche Anforderungen korrekt umsetzen Ob ISO/IEC 27001, 27005, 31000, NIST oder die Cyber-Resilience-Verordnung (EU) 2024/2847, sie alle setzen voraus, dass Unternehmen wissen, wovon sie sprechen. Die CRA unterscheidet z. B. klar zwischen Risiken, Schwachstellen, Bedrohungen und Designfehlern. Wer hier präzise bleibt, erfüllt nicht nur die gesetzlichen Pflichten, sondern verbessert auch seine Sicherheitskultur nachhaltig.