1. Wie man nachweisen kann, dass industrielle Produkte „keine Schwachstellen haben“
Fangen wir mit der unangenehmen Wahrheit an: Man kann praktisch nie beweisen, dass ein Produkt gar keine Schwachstellen hat.
Was man sehr wohl nachweisen kann (und was Auditoren, Kunden und der CRA de facto wollen), ist etwas viel Konkreteres:
Zum Zeitpunkt X gibt es keine bekannten und relevanten Schwachstellen in den eingesetzten Komponenten, oder sie sind bewertet, mitigiert und dokumentiert.
Das ist ein belastbarer, überprüfbarer Nachweis. Und genau darum geht es hier.
2. Ausgangspunkt: CVEs als gemeinsame „Sprache“ für Schwachstellen
2.1 Was ist eine CVE?
Eine CVE (Common Vulnerabilities and Exposures) ist eine standardisierte Kennung für eine bekannte Schwachstelle, z. B. CVE-2024-12345. Damit kann jeder (Hersteller, Kunde, CERT, Behörde) eindeutig über dieselbe Schwachstelle sprechen.
Wichtig: Eine CVE sagt noch nicht automatisch:
- ob dein Produkt betroffen ist,
- ob die Schwachstelle ausnutzbar ist,
- wie wahrscheinlich ein Angriff ist.
Eine CVE ist erst mal „ein Eintrag“. Die Bewertung kommt danach.
2.2 Was du brauchst, bevor du überhaupt über CVEs reden kannst
Um CVEs sinnvoll zu prüfen, brauchst du eine saubere Inventarisierung deiner Produktbestandteile. In der Praxis sind das:
- SBOM (Software Bill of Materials): Bibliotheken, Pakete, Versionen, Abhängigkeiten
- HBOM (Hardware Bill of Materials): Hardware-Komponenten, Module, Firmwarestände
Ohne diese Liste kannst du nicht sauber belegen, dass du „geprüft“ hast. Dann hast du bestenfalls Hoffnung.
3. Schritt-für-Schritt-Ansatz für einen nachvollziehbaren Nachweis
Der Nachweis wird robust, wenn du ihn wie eine Pipeline aufbaust: identifizieren → verifizieren → priorisieren → dokumentieren.
3.1 Schritt 1: CVE-Matching (bin ich betroffen?)
Ziel: Zu jeder Komponente aus SBOM/HBOM prüfen, ob es dazu bekannte CVEs gibt.
Ergebnis dieses Schrittes ist nicht „sicher“, sondern eine Liste:
- CVE gefunden, aber unklar ob betroffen
- CVE gefunden und betroffen
- keine CVE gefunden (für diese Komponente)
Wichtig für den Nachweis: Du dokumentierst deine Datenbasis (BOM/SBOM), den Zeitpunkt und die Quellen, aus denen du CVEs gezogen hast.
3.2 Schritt 2: „Ist das Ding wirklich brisant?“ – CISA KEV und ExploitDB prüfen
Wenn du aus CVEs eine Liste gemacht hast, kommt der entscheidende Filter: Was ist realistisch ausnutzbar bzw. wird aktiv ausgenutzt?
a) CISA KEV (Known Exploited Vulnerabilities)
Die CISA KEV-Liste ist im Grunde die Kurzform von: „Diese Schwachstellen werden in freier Wildbahn wirklich ausgenutzt.“
Wenn eine CVE dort auftaucht, ist das ein starkes Signal für hohe Dringlichkeit.
b) ExploitDB
ExploitDB ist eine Sammlung öffentlich verfügbarer Exploit-Beispiele.
Wenn es dort einen Exploit gibt, steigt das Risiko deutlich, weil ein Angriff weniger „theoretisch“ ist.
Pragmatische Regel:
- CVE in CISA KEV: höchste Priorität
- ExploitDB Exploit vorhanden: sehr hohe Priorität
- beides nicht vorhanden: dann brauchst du eine probabilistische Einschätzung (nächster Schritt)
(Observer nutzt genau solche Quellen als Grundlage, u. a. CVE, ExploitDB und CISA KEV.) :contentReference[oaicite:0]{index=0}
3.3 Schritt 3: Wenn kein „harter Beweis“ vorliegt – EPSS (FIRST) als Risikoschätzung
Nicht jede Schwachstelle steht in KEV. Nicht jede hat einen Exploit auf ExploitDB. Trotzdem kann sie relevant sein.
Hier kommt EPSS ins Spiel: der Exploit Prediction Scoring System der FIRST-Organisation.
Was EPSS macht (verständlich erklärt)
EPSS liefert eine Wahrscheinlichkeitsschätzung, wie wahrscheinlich es ist, dass eine Schwachstelle in naher Zukunft tatsächlich ausgenutzt wird.
Das ist kein Orakel, aber ein sehr praktischer Priorisierungshebel.
Wichtig: EPSS ersetzt nicht Fachbewertung. Es hilft dir, aus „tausend CVEs“ eine Reihenfolge zu machen, die man im Alltag auch abarbeiten kann.
4. Der entscheidende Trick: Ein eigener Threshold (Schwellwert) für „relevant“ definieren
Wenn du „Nachweis“ sagst, brauchst du eine klare, nachvollziehbare Regel, nach der du entscheidest. Sonst ist es Willkür.
4.1 Warum ein Threshold?
Ohne Schwellwert passiert typischerweise eines von zwei Dingen:
- Man behandelt jede CVE gleich und erstickt an Arbeit.
- Man ignoriert zu viel und hat keine belastbare Argumentation.
Ein Threshold ist die Mitte: klare Regel, reproduzierbar, auditierbar.
4.2 Beispiel für eine pragmatische Policy
Du kannst dir intern z. B. folgende Logik definieren:
A. Immer kritisch behandeln (unabhängig von EPSS):
- CVE ist in CISA KEV gelistet
- CVE hat einen Exploit in ExploitDB
- CVE betrifft direkt exponierte Komponenten (z. B. Remote Interfaces, Auth, Netzwerkdienste)
B. Sonst EPSS-basiert:
- Definiere einen EPSS-Schwellwert, ab dem du eine CVE als „priorisiert“ behandelst.
- Alles darunter wird dokumentiert, aber nicht zwingend sofort gefixt, sofern Kompensationsmaßnahmen bestehen.
Wichtig ist nicht, welcher konkrete Wert „richtig“ ist. Wichtig ist:
- Der Wert ist dokumentiert
- Er ist konsequent angewendet
- Er ist begründet (z. B. Ressourcen, Exposition, Produkttyp, Kundenanforderungen)
4.3 Wie der Nachweis dann aussieht
Dein Nachweis besteht am Ende aus:
- Produktinventar (SBOM/HBOM, Versionen, Zeitstempel)
- Liste gefundener CVEs inkl. Quellencheck (KEV/ExploitDB/EPSS)
- Entscheidung pro CVE (betroffen/nicht betroffen, fix/mitigation/akzeptiert)
- Maßnahmen und Status (Patch, Konfig, Workaround, Update-Plan)
- Freigabe/Review (wer hat entschieden, wann, warum)
Das ist das, was „kein Schwachstellenproblem“ in der Praxis bedeutet: kein ungeklärtes, unbeherrschtes Risiko oberhalb deiner Policy.
5. Typische Stolperfallen (damit du nicht in die üblichen Löcher fällst)
-
„Keine CVE gefunden“ heißt nicht „sicher“.
Es heißt nur: in deiner Datenbasis ist nichts bekannt. -
Versionen sind oft das Problem.
SBOMs sind nur so gut wie die Versionstreue. Bei industriellen Produkten sind Versionen, Forks, Backports und OEM-Varianten typisch. -
Betroffenheit ist nicht binär.
„CVE vorhanden“ ist nicht gleich „ausnutzbar“. Exposition (Netzwerk), Konfiguration und Nutzung entscheiden. -
Nachweis ohne Prozess ist ein Einmal-Foto.
Auditoren und Kunden wollen sehen, dass du das regelmäßig machst, nicht nur einmal vor dem Termin.
6. Wie der Observer dabei unterstützt
Der oben beschriebene Prozess klingt logisch, ist aber manuell brutal: Daten sammeln, abgleichen, konsolidieren, priorisieren, dokumentieren. Genau dafür gibt es den Observer.
6.1 Was der Observer im Kern macht
Observer liefert eine strukturierte, konsolidierte Sicht auf Schwachstellen und Risiken über deine Produkte hinweg und macht daraus einen workflow-fähigen Prozess. :contentReference[oaicite:1]{index=1}
Konkret orientiert sich das Vorgehen an einem klaren Ablauf:
- BOMs importieren (Software und Hardware, inklusive relevanter Identifikatoren)
- Vulnerabilities erkennen und konsolidieren
- Priorisieren, was wirklich wichtig ist
- Remediation und Nachweisführung (Entscheidungen, Status, Evidenz) :contentReference[oaicite:2]{index=2}
6.2 Welche Quellen Observer für die Einordnung nutzt
Observer baut auf etablierten Datenquellen und Standards auf, unter anderem:
- CVE als Identifier-System
- ExploitDB als Exploit-Signal
- CISA KEV als „aktiv ausgenutzt“-Signal
- weitere relevante Datenquellen und Formate für Advisory- und Vulnerability-Informationen :contentReference[oaicite:3]{index=3}
Damit bekommst du genau die Signale, die du für deinen Nachweis brauchst: nicht nur „da ist eine CVE“, sondern auch „ist sie realistisch ausnutzbar und priorisiert?“.
6.3 Was das für den Nachweis bedeutet
Mit Observer wird aus „irgendwer hat mal gegoogelt“ ein belastbarer, wiederholbarer Nachweis:
- Inventar + Schwachstellenlage sind verknüpft
- Priorisierung kann auf klaren Signalen basieren (KEV/Exploit/EPSS-Policy)
- Entscheidungen und Maßnahmen werden nachvollziehbar dokumentiert
- das Ganze ist wiederholbar über den Produktlebenszyklus
Das ist exakt der Unterschied zwischen einer Behauptung und einem Nachweis.