VEX und CSAF: auditierbare Schwachstellennachweise

Der Hinweis um 07:40 Uhr, der eine SBOM zum Thema für das Leitungsorgan macht

An einem Dienstagmorgen Anfang 2026 sieht Anya, CISO einer schnell wachsenden FinTech-Plattform, um 07:40 Uhr, dass ein kritischer Lieferantenhinweis im CSAF-Format eingeht. In einer weit verbreiteten Open-Source-Bibliothek wurde eine Schwachstelle zur Remotecodeausführung entdeckt. Ihre Software Bill of Materials bestätigt, dass die Bibliothek in der zentralen Anwendung zur Zahlungsabwicklung, in zwei internen Services und in einer ausgelagerten Analysekomponente eingebettet ist.

Um 08:10 Uhr steht ihr Telefon nicht mehr still. Die Entwicklung will wissen, ob die verwundbare Funktion erreichbar ist. Compliance will wissen, ob ISO/IEC 27001:2022, NIS2 oder DORA betroffen sind. Die Rechtsabteilung fragt, ob der Cyber Resilience Act eine Kommunikation an Kunden oder Behörden auslösen könnte. Ein Mitglied des Leitungsorgans, gerade zu Managementverantwortung nach NIS2 geschult, stellt die Frage, die alle beschäftigt:

Sind wir betroffen?

Die erste technische Antwort aus der Entwicklung ist fachlich ehrlich: Das Paket ist vorhanden, aber die verwundbare Funktion wird in der Produktion möglicherweise nicht aufgerufen. Im Jahr 2026 reicht diese Antwort nicht aus.

Das Leitungsorgan verlangt Nachweise. Kunden erwarten eine klare Antwort. Die Beschaffung will wissen, ob der Lieferant seine vertraglichen Offenlegungspflichten erfüllt hat. Der Datenschutzbeauftragte will wissen, ob personenbezogene Daten offengelegt werden könnten. Ein ISO 27001-Auditor wird „der Entwickler hat es gesagt“ nicht als aufbewahrten Nachweis akzeptieren. Ein DORA-Auditor wird erwarten, dass die Schwachstelle mit IKT-Assets, kritischen Funktionen und Abhängigkeiten von Drittparteien verknüpft ist.

An diesem Punkt sind VEX und CSAF keine rein technischen Formate mehr, sondern Governance-Infrastruktur.

CSAF, das Common Security Advisory Framework, strukturiert Sicherheitshinweise so, dass Menschen und Maschinen betroffene Produkte, Versionen, Abhilfeanleitungen, Referenzen und Statusinformationen verarbeiten können. VEX, der Vulnerability Exploitability eXchange, liefert die Entscheidungsebene. VEX informiert Interessenträger darüber, ob eine bekannte Schwachstelle in einem bestimmten Produkt, Service oder einer bestimmten Umgebung tatsächlich ausnutzbar ist.

Die praktischen VEX-Statusergebnisse sind einfach: betroffen, nicht betroffen, behoben und in Prüfung. Die Governance dahinter ist komplex. Jeder Status benötigt Nachweise, einen Verantwortlichen, eine Begründung, eine Genehmigung und einen Auslöser für die Überprüfung.

Die Compliance-Lücke besteht nicht mehr darin, dass SBOMs fehlen. Viele Organisationen verfügen inzwischen über SBOMs. Die Lücke besteht darin nachzuweisen, wie jeder Schwachstellenhinweis triagiert wurde, wer die Statusentscheidung genehmigt hat, welche Nachweise eine Schlussfolgerung „nicht betroffen“ gestützt haben, wie die Abhilfe priorisiert wurde, wenn das Produkt „betroffen“ war, und wie die Organisation diesen Prüfpfad für Auditoren, Aufsichtsbehörden, Kunden und Management aufbewahrt hat.

Clarysec behandelt VEX und CSAF als Teil des ISMS-Betriebsmodells. In Zenith Blueprint: 30-Schritte-Roadmap für Auditoren gehört dies in die Phasen Risikomanagement, Lieferantensicherheit, technische Maßnahmen und Nachweise. In Zenith Controls: Leitfaden zur rahmenwerkübergreifenden Compliance verbindet dasselbe Thema Maßnahmen nach ISO/IEC 27001:2022 mit Sicherheit der IKT-Lieferkette, Schwachstellenmanagement, Nachweismanagement, NIS2, DORA, GDPR und NIST-Erwartungen.

Warum SBOMs Signale erzeugen, VEX aber Nachweise schafft

Eine SBOM ist eine Zutatenliste. Sie zeigt, was in einem Produkt oder Service enthalten ist. Wenn eine CVE in einer dieser Komponenten auftaucht, zeigt die SBOM, dass Sie möglicherweise betroffen sind.

Dieses Signal ist wertvoll, aber es ist keine Schlussfolgerung.

Eine ausgereifte Softwareumgebung kann Tausende von SBOM-Schwachstellentreffern erzeugen. Viele davon sind echte Risiken. Viele sind nicht ausnutzbar, weil der verwundbare Code nicht ausgeliefert, nicht importiert, nicht erreichbar, nicht konfiguriert, keiner nicht vertrauenswürdigen Eingabe ausgesetzt oder durch kompensierende Kontrollen mitigiert ist. Ohne einen formalen Prozess zur Aufzeichnung der Untersuchung verfallen Teams in der Regel in eines von zwei problematischen Mustern.

Das erste ist Triage-Erschöpfung. Entwickler verfolgen jeden Schwachstellentreffer mit derselben Dringlichkeit, selbst wenn es sich bei der Komponente um eine Build-Time-Abhängigkeit, einen inaktiven Codepfad oder eine nur intern genutzte Funktion handelt, die durch mehrschichtige Kontrollen geschützt ist.

Das zweite ist undokumentierte Risikoakzeptanz. Teams schließen Tickets mit kurzen Kommentaren wie „nicht anwendbar“ oder „False Positive“. Das mag effizient wirken, ist für Auditoren jedoch eine nicht kontrollierte Entscheidung. Für eine Aufsichtsbehörde kann es wie eine ungesteuerte Schwachstelle aussehen.

VEX und CSAF lösen dieses Problem, indem sie Schwachstellenrauschen in strukturierte, auditierbare Schwachstellennachweise umwandeln.

Ein belastbarer Governance-Prozess für VEX und CSAF beantwortet fünf Fragen:

1. Haben wir den Hinweis erhalten oder identifiziert?
2. Haben wir ihn Produkten, Assets, Lieferanten, Kunden und Datenflüssen personenbezogener Daten zugeordnet?
3. Haben wir den Schwachstellenstatus anhand definierter Kriterien bestimmt?
4. Haben wir Entscheidung, Nachweise, Verantwortlichen, Genehmigung und Auslöser für die Überprüfung dokumentiert?
5. Haben wir auf Grundlage des Risikos Abhilfe geschaffen, offengelegt, überwacht oder Nachweise aufbewahrt?

Der Unterschied zwischen „nicht betroffen“ und „ignoriert“ sind Nachweise.

Ein VEX-Status „nicht betroffen“ sollte durch eine Begründung gestützt werden, etwa dass die verwundbare Komponente nicht vorhanden ist, die verwundbare Version nicht bereitgestellt wurde, der verwundbare Codepfad nicht ausgeführt wird, die verwundbare Konfiguration deaktiviert ist oder eine kompensierende Kontrolle die Ausnutzung verhindert. „In Prüfung“ sollte eine zeitlich begrenzte Nachverfolgung haben und nicht zum Friedhof im Backlog werden. „Behoben“ sollte auf einen Patch, eine Minderung, eine Versionsaktualisierung, ein Testergebnis und einen Bereitstellungsnachweis verweisen. „Betroffen“ sollte in Risikobehandlung, Abhilfeplanung, Lieferantenbenachrichtigung, Kundenkommunikation und, soweit relevant, in Prozesse zur Bewertung von Sicherheitsvorfällen oder Datenschutzverletzungen übergehen.

Das Clarysec-Governance-Modell für VEX-Statusentscheidungen

Jeder CSAF-Hinweis und jede VEX-Erklärung sollte als kontrollierte Aufzeichnung im ISMS behandelt werden, nicht als isoliertes Engineering-Artefakt. Der Prozess kann in einer GRC-Plattform, einem Tool für Schwachstellenmanagement, einem Ticketsystem, einem Versionsverwaltungsprozess oder einer Clarysec-Nachweisarbeitsmappe liegen. Entscheidend ist, dass Status, Nachweise, Genehmigung und Risikobehandlung verknüpft bleiben.

Diese Tabelle sieht einfach aus, verändert aber das Kontrollumfeld. Eine Erklärung „nicht betroffen“ wird zu einer kleinen Risikoentscheidung für ein bestimmtes Produkt und eine bestimmte Umgebung. Ein Status „behoben“ verknüpft Schwachstellenmanagement mit Änderungsmanagement und Tests. Ein Status „betroffen“ löst Behandlung, Eskalation und mögliche Offenlegung aus. Ein Status „in Prüfung“ macht ein zeitlich begrenztes Risiko für das Management sichtbar.

Zenith Blueprint stärkt diese Denkweise in Schritt 13 zur Risikobehandlungsplanung und zur Erklärung zur Anwendbarkeit. Dort wird erläutert, dass Kontrollentscheidungen durch Risikobehandlung, gesetzliche oder vertragliche Anforderungen, Geltungsbereichsrelevanz und organisatorischen Kontext begründet werden sollten:

„Kennzeichnen Sie im SoA-Blatt jede Kontrolle als ‘Yes’ (anwendbar) oder ‘No’ (nicht anwendbar). Geben Sie eine Begründung/Notizen an.“

Für VEX folgt „nicht betroffen“ derselben Disziplin. Es ist kein beiläufiger Ticketabschluss. Es ist eine begründete Entscheidung, die einer Überprüfung standhalten muss.

Schritt 19 von Zenith Blueprint behandelt das technische Schwachstellenmanagement:

„Bleiben Sie über neue Sicherheitsfehler (über Herstellerwarnmeldungen, CVE-Feeds usw.) für Ihre Software und Hardware informiert. Bewerten Sie, welche relevant sind (nutzen wir diese Software? wie kritisch ist der Fehler?) und wenden Sie zeitnah Korrekturen oder Minderungen an.“

CSAF hilft, strukturierte Hinweise zu empfangen. SBOMs helfen, das Vorhandensein von Komponenten festzustellen. VEX hilft, Ausnutzbarkeit und Status zu dokumentieren. Das ISMS steuert die Entscheidung.

Richtliniennachweise, bevor der kritische Hinweis eingeht

Ein VEX-Programm scheitert, wenn der erste kritische Hinweis eingeht, bevor Rollen, Kriterien und Nachweisanforderungen existieren. Richtlinien müssen Schwachstelleneingang, Eskalation, Aufzeichnung, Lieferantenpflichten, Ausnahmebehandlung und Nachweisaufbewahrung bereits definieren.

Für KMU legt die Richtlinie zum Schwachstellen- und Patch-Management – KMU die Überwachungspflicht fest:

„Überwacht Systeme auf Schwachstellen und verfügbare Patches unter Verwendung von Herstellerwarnmeldungen, Bedrohungshinweisen und Benachrichtigungen des Betriebssystems“

Diese Klausel aus Rollen und Verantwortlichkeiten, Richtlinienklausel 4.2.1, gilt direkt für die CSAF-Annahme. CSAF-Hinweise sind Schwachstellenhinweise von Herstellern oder aus Ökosystemen, die überwacht, korreliert und triagiert werden müssen.

Dieselbe KMU-Richtlinie legt Erwartungen an die Fähigkeit fest, in Audits Nachweise vorzulegen:

„Führen Sie genaue Aufzeichnungen über angewendete Patches, offene Punkte und Ausnahmen, um die Auditbereitschaft sicherzustellen“

Aus Ziele, Richtlinienklausel 3.4, ergibt sich hier, dass VEX mehr ist als eine technische Datei. Wenn ein Team nicht patcht, weil ein Produkt „nicht betroffen“ ist, benötigt diese Ausnahme Nachweise, Genehmigung und Nachvollziehbarkeit.

Für Unternehmensumgebungen ist die Richtlinie zum Schwachstellen- und Patch-Management eindeutig:

„Überwachen Sie Bedrohungshinweise (z. B. CVE, CISA KEV, Herstellerbulletins) und eskalieren Sie kritische Schwachstellen.“

Aus Rollen und Verantwortlichkeiten, Richtlinienklausel 4.5.1, unterstützt diese Klausel einen strukturierten Eingangskanal für CSAF, CVE, Herstellerbulletins und Exploit-Informationen. Sie verlangt auch Eskalation, wenn ein VEX-Status für ein kritisches Produkt „betroffen“ oder „in Prüfung“ ist.

Die Unternehmensrichtlinie legt außerdem fest:

„Alle kritischen und risikoreichen Schwachstellen müssen im ISMS-Risikoregister erfasst und bis zur Behebung oder Abdeckung durch eine genehmigte Ausnahme überwacht werden.“

Diese Klausel aus Governance-Anforderungen, Richtlinienklausel 5.3, ist der Compliance-Anker. Eine VEX-Erklärung „nicht betroffen“ für eine kritische CVE ist nur belastbar, wenn sie als genehmigte Ausnahme mit Nachweisen behandelt wird. Eine VEX-Erklärung „behoben“ schließt den Kreis nur, wenn die Abhilfe verifiziert wurde.

Auch das Risiko-Scoring benötigt Kontext. Dieselbe Richtlinie verweist auf:

„Risikobeurteilung (basierend auf CVSS, Asset-Kritikalität, Bedrohungsinformationen)“

Aus Risikobehandlung und Ausnahmen, Richtlinienklausel 7.2.2, unterstützt dies ein kombiniertes Triage-Modell. CVSS allein reicht nicht aus. Eine Schwachstelle mittleren Schweregrads, die in einer kritischen Identitätskomponente aktiv ausgenutzt wird, kann dringender sein als ein kritisches CVSS-Problem in nicht erreichbarem Code.

Richtlinien zur Anwendungssicherheit und sicheren Entwicklung übertragen dieselbe Disziplin auf Entwicklung und Lieferanten. Die Richtlinie zu Anforderungen an die Anwendungssicherheit – KMU verlangt von Teams, Folgendes nachzuverfolgen:

„bekannte Schwachstellen und Abhilfestatus.“

Aus Anforderungen an die Umsetzung der Richtlinie, Richtlinienklausel 6.4.2.3, lässt sich dies sauber auf VEX-Status abbilden. Dieselbe Richtlinie verlangt, dass Vereinbarungen Folgendes festlegen:

„Pflichten zur Offenlegung von Schwachstellen, Reaktionszeiten und Patching.“

Aus Governance-Anforderungen, Richtlinienklausel 5.3.2, wird daraus eine praktische Lieferantenklausel: zeitnahe Hinweise bereitstellen, betroffene Versionen identifizieren, soweit möglich VEX-Status ausstellen, Abhilfefristen definieren und Kundenoffenlegung unterstützen.

Für sichere Entwicklung in Unternehmensumgebungen erwartet die Richtlinie für sichere Softwareentwicklung:

„Scans auf bekannte Schwachstellen (CVEs, OSS Index usw.)“

Aus Governance-Anforderungen, Richtlinienklausel 5.4.3, erhält die Entwicklung damit einen definierten Mechanismus, um Hinweise Komponenten zuzuordnen und eine VEX-Analyse auszulösen.

Wenn eine Schwachstelle zu einem Vorfall oder einer potenziellen Rechtsangelegenheit wird, wird Nachweisdisziplin wesentlich. Die Richtlinie zur Beweissicherung und Forensik – KMU stellt fest:

„Für jeden Vorfall muss ein einfaches Protokoll zur Übertragungskette (z. B. Excel-Datei oder Vorlagendokument) geführt werden.“

Aus Governance-Anforderungen, Richtlinienklausel 5.3.1, ergibt sich die Grenze zwischen routinemäßiger VEX-Triage und vorfallsbezogenem Beweismittelmanagement. Wenn Ausnutzung vermutet wird, benötigen Protokolle, Hinweisaufzeichnungen, Analysenotizen, Kommunikation und forensische Artefakte Nachvollziehbarkeit.

Abbildung von VEX und CSAF auf ISO 27001, NIS2, DORA, GDPR und CRA

Die stärksten VEX-Programme sind keine isolierten Security-Engineering-Projekte. Sie werden in das Kontrollsystem eingebettet, das die Organisation bereits nutzt.

Nach ISO/IEC 27001:2022 muss das ISMS interessierte Parteien, gesetzliche und vertragliche Verpflichtungen sowie Schnittstellen und Abhängigkeiten zu anderen Organisationen berücksichtigen. Diese Geltungsbereichslogik ist für VEX wesentlich, weil Lieferantenhinweise, Kundenzusagen, Open-Source-Komponenten und ausgelagerte Services alle Schwachstellenentscheidungen beeinflussen.

Zu den relevantesten Maßnahmen aus Anhang A gehören 5.19 Informationssicherheit in Lieferantenbeziehungen, 5.20 Berücksichtigung von Informationssicherheit in Lieferantenvereinbarungen, 5.21 Management der Informationssicherheit in der IKT-Lieferkette, 5.22 Überwachung, Überprüfung und Änderungsmanagement von Lieferantendiensten, 5.28 Erhebung von Beweismitteln und 8.8 Management technischer Schwachstellen. Maßnahmen zur sicheren Entwicklung 8.25 bis 8.29 sind ebenfalls relevant, wenn die Organisation Software oder digitale Produkte entwickelt.

NIS2 erhöht den Governance-Druck. Article 21 verlangt geeignete technische, operative und organisatorische Maßnahmen, einschließlich Risikoanalyse, Umgang mit Informationssicherheitsvorfällen, Aufrechterhaltung des Geschäftsbetriebs, Sicherheit der Lieferkette, sichere Beschaffung, Entwicklung und Wartung, Umgang mit Schwachstellen und Offenlegung, Kontrollwirksamkeit, Cyberhygiene, Kryptografie, HR-Sicherheit, Zugriffskontrolle, Asset-Management und Authentifizierung. Article 20 verlangt, dass Leitungsorgane Maßnahmen des Cybersicherheitsrisikomanagements genehmigen und überwachen. Dadurch eignen sich VEX-Kennzahlen für die Berichterstattung an das Leitungsorgan.

DORA gilt seit dem 17. Januar 2025 für Finanzunternehmen im Geltungsbereich. DORA verlangt ein Rahmenwerk für das Management von IKT-Risiken, Identifizierung und Klassifizierung von IKT-Assets, Schwachstellen, Abhängigkeiten und IKT-Drittparteidiensten, Vorfallmanagement, Resilienztests, Drittparteienrisikomanagement und Managementaufsicht. Für Finanzunternehmen sind VEX-Aufzeichnungen besonders nützlich, wenn ein Lieferantenhinweis kritischen oder wichtigen Funktionen, vertraglichen Verpflichtungen und der Vorfallklassifizierung zugeordnet werden muss.

GDPR wird relevant, wenn Ausnutzung personenbezogene Daten betreffen könnte. Eine verwundbare API, Bibliothek oder ein verwundbarer Service, die bzw. der Kundendatensätze offenlegen könnte, erfordert eine Bewertung anhand von Vertraulichkeit, Integrität, Verfügbarkeit und Meldekriterien für Datenschutzverletzungen. Eine VEX-Schlussfolgerung „nicht betroffen“ kann eine Entscheidung stützen, nicht zu melden – aber nur, wenn die Organisation zeigen kann, warum keine Verletzung des Schutzes personenbezogener Daten eingetreten ist.

Der Cyber Resilience Act ergänzt Produkt-Governance. Während CRA-Pflichten schrittweise wirksam werden, benötigen Hersteller und andere Wirtschaftsakteure wiederholbare Prozesse für den Umgang mit Schwachstellen, Sicherheitsupdates, koordinierte Offenlegung und Nachweise. CSAF kann Hinweise strukturieren. VEX kann klarstellen, welche Produkte und Versionen betroffen, behoben oder nicht betroffen sind.

Was der Clarysec-Leitfaden zur rahmenwerkübergreifenden Compliance ergänzt

Zenith Controls ist wertvoll, weil es technische Arbeit auf Audit-Erwartungen und überlappende Rahmenwerke abbildet. Für VEX und CSAF sind drei Bereiche am wichtigsten: Sicherheit der IKT-Lieferkette, technisches Schwachstellenmanagement und Erhebung von Beweismitteln.

Für die Sicherheit der IKT-Lieferkette identifiziert Zenith Controls ISO/IEC 27002:2022 Maßnahme 5.21 als „Management der Informationssicherheit in der IKT-Lieferkette“. Es erläutert, dass 5.21 die Maßnahmen zu Lieferantenbeziehungen 5.19 und 5.20 auf IKT-spezifische Risiken ausweitet, einschließlich unsicherer Softwarekomponenten sowie Drittanbieter- oder Open-Source-Bibliotheken. Es stellt Verbindungen zu sicherer Entwicklung, sicherer Programmierung, Sicherheitsprüfung, Zugriffskontrolle, Erhebung von Beweismitteln, sicherem Entwicklungslebenszyklus und ausgelagerter Entwicklung her.

Genau hier wirken CSAF und VEX. Ein Lieferantenhinweis ist nicht nur eine Nachricht eines Herstellers. Er ist ein Nachweis für die Cybersicherheitspraxis des Lieferanten. Eine VEX-Erklärung eines Lieferanten ist nicht nur eine Arbeitserleichterung. Sie kann Beschaffung, Sorgfaltspflichten, Überwachung und Kundenrisikoentscheidungen unterstützen.

Für technisches Schwachstellenmanagement identifiziert Zenith Controls Maßnahme 8.8 als „Management technischer Schwachstellen“. Die Maßnahme wird als präventiv eingeordnet, unterstützt Vertraulichkeit, Integrität und Verfügbarkeit und ist mit Bedrohungs- und Schwachstellenmanagement verbunden. Außerdem wird festgehalten, dass Schwachstellenmanagement mit Schutz vor Schadsoftware, Konfigurationsmanagement, Änderungsmanagement, Bedrohungsinformationen und Überwachung zusammenhängt.

Eine besonders nützliche Passage aus Zenith Controls für VEX-Governance lautet:

„Wirksames Schwachstellenmanagement priorisiert auf Grundlage realer Bedrohungen. Bedrohungsinformationen zeigen, welche Schwachstellen aktiv ausgenutzt werden, und steuern so die Priorisierung von Patches.“

Das ist der Unterschied zwischen reinem SBOM-Matching und risikobasierter VEX-Triage. Das bloße Vorhandensein reicht nicht aus. Ausnutzbarkeit, Asset-Kritikalität, Exponierung und Bedrohungsaktivität müssen die Entscheidung prägen.

Für Nachweise identifiziert Zenith Controls Maßnahme 5.28 „Erhebung von Beweismitteln“ als korrektiv und mit Erkennen und Reagieren verbunden. 5.28 wird mit Incident Response, Protokollierung, Überwachung und Ereignismeldung verknüpft. Außerdem wird das Beweismittelmanagement ISO/IEC 27037:2012 für Identifizierung, Erhebung, Erfassung und Aufbewahrung digitaler Beweismittel zugeordnet.

Wenn eine Schwachstelle nur theoretisch ist, können routinemäßige VEX-Aufzeichnungen ausreichen. Wenn Ausnutzung vermutet wird, muss die Organisation in vorfallsbezogenes Beweismittelmanagement wechseln. Protokolle, Lieferantenkommunikation, Kundenmitteilungen, Patch-Aufzeichnungen und forensische Artefakte benötigen Integrität, Aufbewahrung und Nachvollziehbarkeit.

Ein praktisches VEX-Nachweispaket vom Alarm bis zum Abschluss

Zurück zu Anyas FinTech-Plattform. Für eine kritische Schwachstelle in lib-common-utils, die in der SBOM des Zahlungsgateways erscheint, geht ein CSAF-Hinweis ein. Eine disziplinierte Reaktion würde ein einzelnes Nachweispaket erzeugen, nicht verstreute Slack-Nachrichten und Screenshots.

Schritt 1: Eingang des Hinweises erfassen

Eröffnen Sie einen Schwachstellenfall im ISMS-Nachweistracker. Hängen Sie den CSAF-Hinweis, die CVE-Referenz, das Lieferantenbulletin, den SBOM-Treffer und die Liste betroffener Assets an. Weisen Sie einen Schwachstellenverantwortlichen und einen fachlichen Systemverantwortlichen zu. Verknüpfen Sie den Zahlungsservice mit Kundenauswirkung, personenbezogenen Daten, Finanzverarbeitung und operativer Kritikalität.

Richtliniengrundlage: Die Richtlinie zum Schwachstellen- und Patch-Management verlangt die Überwachung von Hinweisen und die Eskalation kritischer Schwachstellen. ISO-Grundlage: Maßnahme 8.8 aus Anhang A. NIS2-Grundlage: Umgang mit Schwachstellen und sichere Wartung. DORA-Grundlage: Identifizierung von IKT-Schwachstellen und Vorfallsbereitschaft.

Schritt 2: Vorläufigen Status auf „in Prüfung“ setzen

Der anfängliche Status sollte häufig „in Prüfung“ lauten, insbesondere bei kritischen Hinweisen. Legen Sie eine Entscheidungsfrist fest, zum Beispiel 24 Stunden für extern exponierte oder kritische Services. Erfassen Sie vorläufige Kontrollen wie verstärkte Überwachung, vorübergehende Funktionsbeschränkungen oder WAF-Regeln. Dadurch wird verhindert, dass ein kritischer Hinweis in einem nicht gesteuerten Backlog verschwindet.

Schritt 3: Ausnutzbarkeitsanalyse durchführen

Die Entwicklung sollte praktische Fragen beantworten:

• Ist die verwundbare Version in der Produktion vorhanden?
• Wird die verwundbare Funktion importiert, aufgerufen oder ist sie erreichbar?
• Ist die verwundbare Konfiguration aktiviert?
• Ist die Komponente nicht vertrauenswürdiger Eingabe ausgesetzt?
• Ist Authentifizierung erforderlich, bevor der verwundbare Pfad erreicht werden kann?
• Sind kompensierende Kontrollen wirksam?
• Gibt es aktive Ausnutzung oder glaubwürdige Bedrohungsinformationen?
• Könnte eine Ausnutzung personenbezogene Daten, Finanztransaktionen oder Serviceverfügbarkeit beeinträchtigen?

In Anyas Fall bestätigt die statische Analyse, dass die Komponente vorhanden ist, die verwundbare Funktion jedoch vom Zahlungsgateway nicht aufgerufen wird. In der Produktion existiert kein Ausführungspfad. Das Team erstellt eine VEX-Erklärung „nicht betroffen“ mit unterstützenden Nachweisen.

Hätte die Analyse gezeigt, dass ein authentifizierter Admin-Job die verwundbare Funktion erreichen kann, wäre der korrekte Status „betroffen“ und nicht „nicht betroffen“. Das Team würde dann einen Risikobehandlungsplan erstellen, ein Änderungsticket eröffnen, patchen oder mitigieren und den Status erst nach Verifikation auf „behoben“ aktualisieren.

Schritt 4: Fall mit Risikoregister und Lieferantenaufzeichnung verknüpfen

Kritische und risikoreiche Fälle sollten im ISMS-Risikoregister erfasst werden, sofern sie nicht durch eine genehmigte, nachgewiesene Ausnahme geschlossen werden. Lieferantenhinweise sollten außerdem mit dem Lieferantenregister, vertraglichen Verpflichtungen und Überwachungsaufzeichnungen verknüpft werden.

Dies unterstützt Zenith Blueprint Schritt 23, der Organisationen anweist, Lieferanten zusammenzustellen, sie nach Zugriff und operativer Kontrolle zu klassifizieren, Sicherheitserwartungen in Verträge aufzunehmen und Überwachungsverfahren für Lieferantenänderungen zu definieren.

Schritt 5: Behebung validieren oder Ausnahme genehmigen

Für „behoben“ hängen Sie Patch-Version, Änderungsaufzeichnung, CI/CD-Pipeline-Ergebnis, Abhängigkeitsscan, Container-Image-Digest, Bereitstellungsnachweis und Regressionstest an. Für „nicht betroffen“ hängen Sie Codepfadanalyse, Konfigurationsnachweis, Versionsnachweis, Nachweis der kompensierenden Kontrolle und Genehmigung an.

Wenn Kunden selbst gehostete Versionen nutzen oder die Schwachstelle externe Benutzer betreffen könnte, koordinieren Sie die Kommunikation. Die Richtlinie zur koordinierten Offenlegung von Schwachstellen liefert das Modell:

„Wenn eine bestätigte Schwachstelle Kunden oder Servicenutzer betreffen könnte, erstellt das Kommunikationsteam unter Leitung des VRT einen Sicherheitshinweis. Der Hinweis enthält eine Übersicht über das Problem, ohne Exploit-Details offenzulegen, die betroffenen Produkte oder Versionen, Minderungsanleitungen oder Patch-Download-Anweisungen sowie Kontaktinformationen für Support.“

Aus Anforderungen an die Umsetzung, Richtlinienklausel 6.8, lässt sich dies direkt auf CSAF-Veröffentlichungsdisziplin abbilden.

Schritt 6: Nachweise aufbewahren, wenn Ausnutzung vermutet wird

Wenn Protokolle versuchte Ausnutzung zeigen, wechseln Sie vom Umgang mit Schwachstellen zu Incident Response und Beweissicherung. Starten Sie ein Protokoll zur Übertragungskette, bewahren Sie Protokolle auf, erfassen Sie SIEM-Abfragen, exportieren Sie relevante Ereignisse, erstellen Sie bei Bedarf Snapshots betroffener Systeme und dokumentieren Sie, wer jedes Artefakt gehandhabt hat. Verknüpfen Sie den Vorfallsfall mit der VEX-Aufzeichnung.

Was Auditoren und Aufsichtsbehörden anfordern werden

Auditoren prüfen VEX- und CSAF-Governance nicht alle auf dieselbe Weise. Ein einzelnes Nachweispaket sollte mehrere Perspektiven bedienen.

Zenith Controls enthält Leitlinien zur Auditmethodik, die zu dieser Tabelle passen. Für Sicherheit der IKT-Lieferkette prüfen Auditoren, die ISO/IEC 19011 und ISO/IEC 27007 verwenden, Beschaffungsrichtlinien, RFP-Vorlagen und Lieferantenmanagementprozesse, um IKT-spezifische Sicherheitsanforderungen zu verifizieren. Sie ziehen Stichproben aus Verträgen zu sicherer Entwicklung, Offenlegung von Schwachstellen und Softwareauthentizität.

Für technisches Schwachstellenmanagement prüfen Auditoren die Schwachstellenmanagement-Richtlinie, Scan-Frequenz, Asset-Abdeckung, risikobasierte Priorisierung, Abhilfefristen und Verantwortlichkeiten. Bei der Erhebung von Beweismitteln testen sie, ob Übertragungskette, sichere Speicherung und Aufbewahrung in realen Vorfällen eingehalten wurden.

Deshalb darf VEX-Governance nie beim Statuslabel enden. Das Label ist die Zusammenfassung. Der Prüfpfad der Nachweise ist die Kontrolle.

Managementkennzahlen, die VEX für das Leitungsorgan nutzbar machen

ISO/IEC 27001:2022 verlangt Leistungsbewertung, internes Audit und Managementbewertung. NIS2 verlangt Managementaufsicht. DORA verlangt Governance über IKT-Risiken. VEX und CSAF schaffen Kennzahlen, die Entwicklungsarbeit in Risikotransparenz für Führungskräfte übersetzen.

Nützliche Kennzahlen für die Managementbewertung sind:

• Anzahl kritischer CSAF-Hinweise, die in diesem Quartal eingegangen sind
• Prozentsatz der Hinweise mit Treffer auf SBOM-Komponenten
• Anzahl und Alter von VEX-Status nach betroffen, nicht betroffen, behoben und in Prüfung
• Überfällige Fälle mit Status „in Prüfung“
• Lieferantenhinweise ohne ausreichende Daten zu betroffenen Versionen
• Kritische Schwachstellen, die als genehmigte Ausnahmen akzeptiert wurden
• Zeit vom Eingang des Hinweises bis zur VEX-Entscheidung
• Zeit von der Entscheidung „betroffen“ bis zur Abhilfe
• Anzahl der Fälle mit potenzieller Auswirkung auf personenbezogene Daten
• Anzahl veröffentlichter Kundenhinweise

Diese Kennzahlen helfen dem Management, bessere Fragen zu stellen. Welche Lieferanten liefern keine verwertbaren Schwachstellendaten? Welche Produkte haben die längsten Abhilfezeiten? Welche Teams lassen Untersuchungen offen? Welche Schwachstellen könnten personenbezogene Daten oder kritische Funktionen betreffen?

Häufige Fehlmuster, die zu beseitigen sind

Das erste Fehlmuster ist, SBOM-Matching als Ausnutzbarkeitsanalyse zu behandeln. Ein Komponententreffer ist ein Signal, keine Schlussfolgerung.

Das zweite Fehlmuster ist die Verwendung von „nicht betroffen“ ohne Begründung. Auditoren werden fragen, warum. War der Codepfad nicht erreichbar? War die verwundbare Funktion deaktiviert? War die Version anders? Wurde die Komponente nur zur Build-Zeit genutzt? Wurde die Schlussfolgerung von der Produktsicherheit genehmigt?

Das dritte Fehlmuster besteht darin, „in Prüfung“ offen zu lassen. Dieser Status ist nur mit Verantwortlichem, Frist und vorläufigen Kontrollen sinnvoll.

Das vierte Fehlmuster ist die Trennung von Lieferanten-Governance und Schwachstellen-Governance. Lieferantenverträge sollten zeitnahe Offenlegung von Schwachstellen, Reaktionszeiten, Patch-Pflichten, Hinweisinhalte und Nachweisunterstützung verlangen.

Das fünfte Fehlmuster ist, personenbezogene Daten und Kundenkommunikation zu ignorieren. Eine Schwachstelle, die personenbezogene Daten offenlegen könnte, benötigt eine GDPR-Bewertung. Eine bestätigte Produktschwachstelle, die Kunden betreffen könnte, benötigt Disziplin bei der koordinierten Offenlegung. Eine Abhängigkeit im Finanzdienstleistungsbereich kann eine DORA-Vorfallsanalyse erfordern.

Das sechste Fehlmuster ist schwache Nachweisaufbewahrung. Zenith Blueprint warnt in Schritt 23, Maßnahme 5.28, dass Nachweise häufig übersehen werden:

„Was Sie nachweisen können, ist genauso wichtig wie das, was tatsächlich passiert ist“

Dieser Satz beschreibt die Realität 2026. Sicherheitsteams beheben nicht nur Schwachstellen. Sie weisen nach, dass Entscheidungen zeitgerecht, risikobasiert und kontrolliert getroffen wurden.

Nächste Schritte für auditierbare Schwachstellennachweise

Wenn Ihre Organisation bereits über SBOMs verfügt, ist der nächste Reifeschritt nicht eine weitere Inventartabelle. Es ist Governance über Schwachstellenstatus, Lieferantenhinweise und Offenlegungsnachweise.

Beginnen Sie mit vier Maßnahmen:

1. Nehmen Sie CSAF- und VEX-Eingang in Ihr Schwachstellenmanagementverfahren auf.
2. Definieren Sie Genehmigungskriterien für betroffen, nicht betroffen, behoben und in Prüfung.
3. Verknüpfen Sie VEX-Aufzeichnungen mit Ihrem ISMS-Risikoregister, Lieferantenregister, Asset-Inventar, SBOM-Repository und Vorfallsprozess.
4. Testen Sie den Prozess mit einem aktuellen kritischen Hinweis und erstellen Sie ein prüfungsbereites Nachweispaket.

Clarysec kann Sie dabei unterstützen, dies schnell mit Zenith Blueprint, Zenith Controls und dem relevanten Richtlinienset umzusetzen, einschließlich der Richtlinie zum Schwachstellen- und Patch-Management, Richtlinie zum Schwachstellen- und Patch-Management – KMU, Richtlinie zu Anforderungen an die Anwendungssicherheit – KMU, Richtlinie für sichere Softwareentwicklung, Richtlinie zur Beweissicherung und Forensik – KMU und Richtlinie zur koordinierten Offenlegung von Schwachstellen.

Die entscheidende Frage im Jahr 2026 lautet nicht: „Haben wir eine SBOM?“ Sie lautet: „Können wir für jeden schwerwiegenden Hinweis exakt nachweisen, wie wir den Schwachstellenstatus bestimmt, das Risiko behandelt und das Ergebnis kommuniziert haben?“

Buchen Sie ein Clarysec-Assessment oder fordern Sie das passende Richtlinien-Toolkit an, um VEX und CSAF in prüfungsbereite Schwachstellennachweise zu überführen, bevor der nächste kritische Hinweis Ihr Leitungsorgan erreicht.