Schwachstellenmanagement CRA: 24h-Meldepflicht an ENISA

Ab dem 11. September 2026 müssen Hersteller aktiv ausgenutzte Schwachstellen innerhalb von 24 Stunden an die ENISA melden. Diese Meldepflicht ist nur die Spitze des Eisbergs: Der Cyber Resilience Act fordert ein umfassendes Schwachstellenmanagement über den gesamten Produktlebenszyklus. Dieser Artikel zeigt, welche Prozesse Unternehmen etablieren müssen und wie die praktische Umsetzung gelingt.

Schwachstellenmanagement im CRA: Die rechtlichen Anforderungen

Der Cyber Resilience Act definiert in Anhang I Teil II umfassende Anforderungen an die Behandlung von Schwachstellen. Diese gehen weit über die bekannten Meldepflichten hinaus und umfassen den gesamten Lebenszyklus einer Schwachstelle – von der Entdeckung über die Behebung bis zur Kommunikation an Nutzer.

Ob Ihr Unternehmen und Ihre Produkte unter diese CRA-Anforderungen fallen, können Sie mit unserem CRA Self-Check-Tool ermitteln. Das Tool hilft Ihnen dabei, schnell zu klären, welche Schwachstellenmanagement-Prozesse für Sie verpflichtend sind.

Die fünf Säulen des CRA-Schwachstellenmanagements

1. Identifikation und Dokumentation: Hersteller müssen Schwachstellen in ihren Produkten systematisch identifizieren und dokumentieren. Dies umfasst eigenen Code ebenso wie eingebundene Drittanbieterkomponenten.

2. Koordinierte Offenlegung (CVD): Hersteller müssen eine Richtlinie für die koordinierte Offenlegung von Schwachstellen (Coordinated Vulnerability Disclosure) veröffentlichen und einen Kommunikationskanal für Schwachstellenmeldungen bereitstellen.

3. Behebung und Patching: Schwachstellen müssen zeitnah behoben werden. Sicherheitsupdates sind kostenlos bereitzustellen und über sichere Mechanismen zu verteilen.

4. Meldepflichten: Aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle müssen innerhalb strenger Fristen an die zuständigen Behörden gemeldet werden.

5. Nutzerkommunikation: Nutzer müssen über Schwachstellen, deren Auswirkungen und verfügbare Updates informiert werden.

Die 24-Stunden-Meldepflicht im Detail

Die ab September 2026 geltende Meldepflicht ist die zeitlich kritischste CRA-Anforderung. Sie verlangt eine dreistufige Meldung:

Frühwarnung (24 Stunden): Innerhalb von 24 Stunden nach Kenntniserlangung muss eine erste Meldung an das zuständige nationale CSIRT und die ENISA erfolgen. Diese Frühwarnung muss mindestens die Art der Schwachstelle oder des Vorfalls sowie eine erste Einschätzung der Schwere enthalten.

Detaillierte Meldung (72 Stunden): Innerhalb von 72 Stunden folgt eine erweiterte Meldung mit allgemeinen Informationen über die Art der Ausnutzung, die betroffene Schwachstelle, erste Korrekturmaßnahmen sowie – falls möglich – Informationen über böswillige Akteure.

Abschlussbericht (14 Tage / 1 Monat): Spätestens nach 14 Tagen (bei schwerwiegenden Vorfällen) oder einem Monat muss ein finaler Bericht mit vollständiger Analyse, Ursachenbeschreibung und ergriffenen Maßnahmen eingereicht werden.

ENISA-Meldeplattform

Die ENISA richtet eine zentrale europäische Meldeplattform ein, über die alle CRA-Meldungen erfolgen. Die Plattform soll einen sicheren Informationsaustausch zwischen Herstellern, nationalen CSIRTs und der ENISA gewährleisten.

Parallel zur ENISA-Meldung muss auch das zuständige nationale CSIRT informiert werden. In Deutschland ist dies das BSI (Bundesamt für Sicherheit in der Informationstechnik), das als zentrale Anlaufstelle für Schwachstellenmeldungen fungiert.

Aufbau eines Product Security Incident Response Teams (PSIRT)

Die Einhaltung der Meldepflichten und die effektive Schwachstellenbehandlung erfordern dedizierte Strukturen. Ein Product Security Incident Response Team (PSIRT) ist die organisatorische Antwort auf diese Anforderung.

Aufgaben eines PSIRT

Ein PSIRT übernimmt die zentrale Koordination aller produktbezogenen Sicherheitsvorfälle und Schwachstellen. Zu den Kernaufgaben gehören die Entgegennahme und Triage von Schwachstellenmeldungen, die Koordination mit Entwicklungsteams zur Behebung, die Erstellung von Sicherheitshinweisen und Patches, die Kommunikation mit externen Sicherheitsforschern, die Erfüllung der CRA-Meldepflichten und die Pflege von Beziehungen zur Sicherheits-Community.

PSIRT-Struktur und Rollen

Ein effektives PSIRT benötigt klare Rollenverteilungen:

PSIRT-Leitung: Verantwortlich für strategische Ausrichtung, Ressourcenplanung und Eskalation. Berichtet an die Geschäftsführung und vertritt das PSIRT nach außen.

Triage-Team: Bewertet eingehende Meldungen, priorisiert nach Schweregrad und leitet an zuständige Teams weiter. Muss rund um die Uhr erreichbar sein, um die 24-Stunden-Frist einzuhalten.

Technische Analysten: Untersuchen gemeldete Schwachstellen, bewerten Ausnutzbarkeit und Auswirkungen, entwickeln Workarounds und koordinieren mit Entwicklungsteams.

Kommunikationsverantwortliche: Erstellen Sicherheitshinweise, koordinieren Veröffentlichungen und pflegen Kontakte zu Sicherheitsforschern und Behörden.

Juristische Beratung: Unterstützt bei Haftungsfragen, Vertragsthemen mit Sicherheitsforschern und regulatorischen Anforderungen.

PSIRT-Reifegradmodell

Der Aufbau eines PSIRT erfolgt typischerweise in Stufen:

Stufe 1 – Reaktiv: Grundlegende Prozesse zur Entgegennahme und Bearbeitung von Schwachstellenmeldungen. E-Mail-Postfach security@firma.de, erste Eskalationswege.

Stufe 2 – Strukturiert: Definierte Prozesse, SLAs für Reaktionszeiten, dokumentierte Triage-Kriterien, regelmäßige Berichte an Management.

Stufe 3 – Proaktiv: Aktive Schwachstellensuche durch interne Tests und Bug-Bounty-Programme, etablierte Beziehungen zur Sicherheits-Community, publizierte CVD-Policy.

Stufe 4 – Optimiert: Automatisierte Prozesse, Integration mit Entwicklungspipelines, Metriken-getriebene Optimierung, Threat Intelligence-Integration.

Für CRA-Compliance ist mindestens Stufe 2 erforderlich; zur nachhaltigen Risikominimierung empfiehlt sich Stufe 3 oder höher.

Coordinated Vulnerability Disclosure (CVD)

Der CRA fordert explizit eine Richtlinie zur koordinierten Offenlegung von Schwachstellen. CVD ist ein strukturierter Prozess, der Sicherheitsforschern einen verantwortungsvollen Weg zur Meldung von Schwachstellen bietet.

Elemente einer CVD-Policy

Eine CVD-Policy sollte folgende Informationen enthalten:

Kontaktinformationen: Klare Angabe, wie Schwachstellen gemeldet werden können (E-Mail, Webformular, PGP-Schlüssel). Die Adresse security@firma.de ist ein etablierter Standard.

Scope: Definition, welche Produkte und Systeme unter die Policy fallen. Explizite Ausschlüsse (z.B. Social Engineering, DoS-Tests) sollten benannt werden.

Erwartete Informationen: Beschreibung der gewünschten Informationen in einer Meldung (betroffenes Produkt, Version, Beschreibung, Proof of Concept, Auswirkungen).

Prozessablauf: Beschreibung des internen Prozesses nach Eingang einer Meldung, typische Bearbeitungszeiten und Kommunikationsrhythmus.

Rechtliche Zusicherungen: Klare Aussage, dass gutgläubige Sicherheitsforschung nicht rechtlich verfolgt wird (Safe Harbor). Dies ist entscheidend für die Akzeptanz in der Security-Community.

Anerkennung: Information über Anerkennung von Sicherheitsforschern (Hall of Fame, Danksagung in Advisories, ggf. Bug Bounty).

Beispiel einer CVD-Policy-Struktur

# Coordinated Vulnerability Disclosure Policy

## Scope
Diese Policy gilt für alle Produkte der Firma XYZ, die unter xyz.de/products
gelistet sind.

## Meldung von Schwachstellen
Bitte melden Sie Schwachstellen an: security@xyz.de
PGP-Schlüssel: [Link zum Public Key]

Bevorzugte Informationen:
- Betroffenes Produkt und Version
- Beschreibung der Schwachstelle
- Schritte zur Reproduktion
- Einschätzung der Auswirkungen

## Unser Prozess
- Eingangsbestätigung: innerhalb von 2 Werktagen
- Erste Bewertung: innerhalb von 7 Tagen
- Status-Update: mindestens alle 14 Tage
- Ziel-Behebungszeitraum: 90 Tage (abhängig von Schweregrad)

## Safe Harbor
Wir werden keine rechtlichen Schritte gegen Sicherheitsforscher
einleiten, die:
- In gutem Glauben handeln
- Diese Policy befolgen
- Keine Daten exfiltrieren oder Systeme beschädigen

## Anerkennung
Mit Ihrer Zustimmung nennen wir Sie in unserer Hall of Fame
und in den Security Advisories.

Bug-Bounty-Programme als Erweiterung

Bug-Bounty-Programme erweitern CVD um monetäre Anreize. Sie sind nicht CRA-verpflichtend, können aber die Effektivität der Schwachstellenfindung erheblich steigern.

Plattformen wie HackerOne, Bugcrowd oder die europäische YesWeHack bieten Infrastruktur für Bug-Bounty-Programme. Für den Einstieg kann ein privates Programm mit ausgewählten Forschern sinnvoll sein, bevor ein öffentliches Programm gestartet wird.

SBOM als Fundament des Schwachstellenmanagements

Die Software Bill of Materials (SBOM) ist unverzichtbare Grundlage für effektives Schwachstellenmanagement. Nur wenn bekannt ist, welche Komponenten in einem Produkt enthalten sind, können bei Bekanntwerden einer Schwachstelle betroffene Produkte identifiziert werden.

SBOM-basiertes Vulnerability Monitoring

Der typische Workflow sieht folgendermaßen aus:

1. SBOM-Erstellung: Bei jedem Release wird eine aktuelle SBOM generiert (CycloneDX oder SPDX-Format).
2. Kontinuierlicher Scan: Die SBOM wird automatisiert gegen Schwachstellendatenbanken (NVD, OSV, GitHub Security Advisories) geprüft.
3. Alerting: Bei neuen Schwachstellen in enthaltenen Komponenten wird das PSIRT automatisch benachrichtigt.
4. Impact Assessment: Das PSIRT bewertet, ob die Schwachstelle im Kontext des Produkts ausnutzbar ist.
5. Patching oder VEX: Entweder wird ein Patch entwickelt, oder die Nicht-Ausnutzbarkeit wird in einem VEX-Dokument dokumentiert.

Vulnerability Exploitability Exchange (VEX)

VEX-Dokumente ergänzen SBOMs um Informationen zur Ausnutzbarkeit von Schwachstellen. Sie ermöglichen die Kommunikation, dass eine bekannte Schwachstelle in einer Komponente im konkreten Produktkontext nicht ausnutzbar ist.

VEX-Status-Kategorien:

• Not Affected: Die Schwachstelle betrifft das Produkt nicht (z.B. betroffene Funktion nicht verwendet)
• Affected: Die Schwachstelle betrifft das Produkt; Patch erforderlich
• Fixed: Die Schwachstelle wurde durch ein Update behoben
• Under Investigation: Die Ausnutzbarkeit wird noch untersucht

VEX reduziert den Alert-Noise erheblich: Statt jede CVE in einer Drittanbieterkomponente als Problem zu behandeln, wird nur bei tatsächlich ausnutzbaren Schwachstellen Handlungsbedarf signalisiert.

Beispiel eines VEX-Statements (CycloneDX-Format):

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.6",
  "vulnerabilities": [
    {
      "id": "CVE-2024-12345",
      "source": {
        "name": "NVD",
        "url": "https://nvd.nist.gov/"
      },
      "analysis": {
        "state": "not_affected",
        "justification": "code_not_reachable",
        "detail": "Die betroffene Funktion parseXML() wird im Produkt nicht verwendet.",
        "response": ["will_not_fix"]
      },
      "affects": [
        {
          "ref": "pkg:npm/xml-parser@2.1.0"
        }
      ]
    }
  ]
}

Tooling für das Schwachstellenmanagement

Effektives Schwachstellenmanagement erfordert geeignete Werkzeuge für verschiedene Aufgaben.

Schwachstellen-Scanner

Trivy: Open-Source-Scanner von Aqua Security, der Container-Images, Dateisysteme und SBOMs auf bekannte Schwachstellen prüft. Ideal für CI/CD-Integration.

# SBOM scannen
trivy sbom sbom.json

# Container-Image scannen
trivy image myapp:latest --severity HIGH,CRITICAL

Grype: SBOM-basierter Schwachstellen-Scanner von Anchore. Komplementär zu Syft für SBOM-Erstellung.

# Grype auf SBOM anwenden
grype sbom:./sbom.json

Dependency-Track: Open-Source-Plattform für kontinuierliches SBOM-Management und Schwachstellen-Monitoring. Bietet Dashboard, Alerting und Reporting.

PSIRT-Plattformen

Für die Verwaltung des Schwachstellenlebenszyklus eignen sich spezialisierte Plattformen:

CERT/CC VINCE: Kostenlose Plattform des CERT Coordination Center für koordinierte Schwachstellenoffenlegung. Unterstützt Multi-Vendor-Koordination.

DefectDojo: Open-Source Application Security Management Platform. Konsolidiert Findings aus verschiedenen Scannern und ermöglicht Tracking.

Kommerzielle Lösungen: Plattformen wie Nucleus Security, Brinqa oder Kenna Security bieten umfassende Vulnerability-Management-Funktionen.

Integration mit Ticket-Systemen

Die Integration des Schwachstellenmanagements mit bestehenden Ticket-Systemen (Jira, ServiceNow, GitHub Issues) erleichtert die Nachverfolgung und Einbindung der Entwicklungsteams.

Beispiel: Automatische Jira-Ticket-Erstellung:

# GitHub Action für automatische Ticket-Erstellung bei kritischen CVEs
name: Vulnerability Alert

on:
  schedule:
    - cron: '0 6 * * *'  # Täglich um 6 Uhr

jobs:
  scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      
      - name: Generate SBOM
        run: |
          npm install -g @cyclonedx/cyclonedx-npm
          cyclonedx-npm --output-file sbom.json
      
      - name: Scan for vulnerabilities
        id: scan
        run: |
          trivy sbom sbom.json --severity CRITICAL --format json -o results.json
          echo "count=$(jq '.Results[0].Vulnerabilities | length' results.json)" >> $GITHUB_OUTPUT
      
      - name: Create Jira ticket
        if: steps.scan.outputs.count > 0
        uses: atlassian/gajira-create@v3
        with:
          project: SEC
          issuetype: Bug
          summary: "Kritische Schwachstelle in Abhängigkeit gefunden"
          description: "Details siehe Scan-Ergebnis"

Prozessintegration: Der Schwachstellen-Lebenszyklus

Ein strukturierter Prozess stellt sicher, dass Schwachstellen konsistent und nachvollziehbar behandelt werden.

Phase 1: Entdeckung

Schwachstellen werden über verschiedene Kanäle entdeckt:

• Externe Meldungen: CVD-Kontakt, Bug-Bounty-Programm
• Automatisierte Scans: SAST, DAST, SCA in CI/CD-Pipeline
• Öffentliche Quellen: CVE-Datenbanken, Security Advisories von Upstream-Projekten
• Interne Tests: Penetration Tests, Security Reviews
• Threat Intelligence: Informationen über aktive Ausnutzung

Phase 2: Triage und Bewertung

Nach Eingang einer Meldung erfolgt die initiale Bewertung:

1. Validierung: Ist die Meldung reproduzierbar? Handelt es sich um eine echte Schwachstelle?
2. Severity-Bewertung: Einordnung nach CVSS oder proprietärem Scoring
3. Impact Assessment: Welche Produkte/Versionen sind betroffen?
4. Meldepflicht-Prüfung: Liegt eine aktiv ausgenutzte Schwachstelle vor, die der 24-Stunden-Meldepflicht unterliegt?

Phase 3: Behebung

Die Behebung folgt einem priorisierten Ansatz:

Schweregrad	CVSS-Score	Ziel-Behebungszeit
Kritisch	9.0 - 10.0	7 Tage
Hoch	7.0 - 8.9	30 Tage
Mittel	4.0 - 6.9	90 Tage
Niedrig	0.1 - 3.9	Nächstes reguläres Release

Falls eine Behebung nicht sofort möglich ist, werden Workarounds oder Mitigationen dokumentiert und kommuniziert.

Phase 4: Veröffentlichung

Die Veröffentlichung umfasst das Patch-Release, den Security Advisory und die Aktualisierung der VEX-Informationen:

Security Advisory sollte enthalten:

• CVE-ID (falls vergeben)
• Betroffene Produkte und Versionen
• CVSS-Score und Severity
• Beschreibung der Schwachstelle (ohne Exploit-Details)
• Auswirkungen bei Ausnutzung
• Behobene Versionen / verfügbare Patches
• Workarounds falls kein Patch verfügbar
• Timeline (Entdeckung, Meldung, Patch-Verfügbarkeit)
• Credits an Entdecker (mit Zustimmung)

Phase 5: Post-Mortem und Lessons Learned

Nach Abschluss eines Vorfalls erfolgt eine Nachbereitung, die die Ursache analysiert (Root Cause Analysis), Prozessverbesserungen identifiziert und die Dokumentation aktualisiert. Diese Erkenntnisse fließen in die Security-by-Design-Praktiken ein, um ähnliche Schwachstellen in zukünftigen Produkten zu vermeiden.

Meldepflichten praktisch umsetzen

Die Einhaltung der 24-Stunden-Frist erfordert vorbereitete Prozesse und klare Verantwortlichkeiten.

Checkliste für die Meldepflicht-Vorbereitung

• ENISA-Meldeplattform-Zugang eingerichtet
• Kontakt zum nationalen CSIRT (BSI) etabliert
• Eskalationspfade für Wochenenden/Feiertage definiert
• Melde-Templates vorbereitet
• Schulung der PSIRT-Mitglieder durchgeführt
• Testmeldung (Dry Run) durchgeführt
• Dokumentierte Kriterien für meldepflichtige Vorfälle

Kriterien für meldepflichtige Schwachstellen

Die Meldepflicht greift bei „aktiv ausgenutzten Schwachstellen". Indikatoren hierfür sind:

• Threat Intelligence über Ausnutzung „in the wild"
• Meldungen von Kunden über Kompromittierung
• Öffentlich verfügbarer Exploit-Code in Kombination mit Hinweisen auf Nutzung
• Eintrag in CISA KEV (Known Exploited Vulnerabilities Catalog)

Eine potenzielle Schwachstelle ohne Hinweise auf aktive Ausnutzung unterliegt nicht der 24-Stunden-Frist, sollte aber dennoch zeitnah behoben werden.

Melde-Template (Frühwarnung)

FRÜHWARNUNG – AKTIV AUSGENUTZTE SCHWACHSTELLE

Datum/Uhrzeit der Kenntniserlangung: [YYYY-MM-DD HH:MM UTC]
Meldender Hersteller: [Firmenname]
Kontakt: [Name, E-Mail, Telefon]

Betroffenes Produkt: [Produktname, Version(en)]

Art der Schwachstelle: [z.B. Remote Code Execution, SQL Injection]

Erste Schwerebewertung: [Kritisch/Hoch/Mittel]

Bekannte Auswirkungen: [Kurzbeschreibung]

Hinweise auf Ausnutzung: [Quelle der Information über aktive Ausnutzung]

Erste Maßnahmen: [z.B. Advisory veröffentlicht, Patch in Entwicklung]

Nächste Meldung geplant: [Datum/Uhrzeit für 72h-Meldung]

Verknüpfung mit anderen CRA-Anforderungen

Das Schwachstellenmanagement ist eng mit anderen CRA-Bausteinen verzahnt:

SBOM: Die Software Bill of Materials ist Grundvoraussetzung für effektives Schwachstellenmanagement. Ohne Kenntnis der enthaltenen Komponenten ist keine systematische Prüfung auf bekannte Schwachstellen möglich.

Security by Design: Sichere Entwicklungspraktiken reduzieren die Anzahl der Schwachstellen von Anfang an. Schwachstellenmanagement ergänzt die präventiven Maßnahmen um reaktive Prozesse.

Update-Mechanismen: Die CRA-Anforderung an sichere Update-Fähigkeit ist Voraussetzung für die Verteilung von Sicherheitspatches. Ohne funktionierenden Update-Mechanismus ist selbst ein entdeckter und behobener Fehler nicht behebbar.

Technische Dokumentation: Prozesse zum Schwachstellenmanagement müssen dokumentiert sein und sind Teil der CRA-geforderten technischen Dokumentation.

Eine ganzheitliche Betrachtung aller Anforderungen bietet unser CRA-Leitfaden mit Umsetzungsfahrplan.

Praktischer Umsetzungsfahrplan

Die Einführung eines CRA-konformen Schwachstellenmanagements erfordert einen strukturierten Ansatz:

Phase 1: Grundlagen schaffen (Q1 2026)

• PSIRT-Struktur definieren und Rollen besetzen
• CVD-Policy erstellen und veröffentlichen
• security@-Postfach einrichten mit PGP-Verschlüsselung
• Grundlegende Eskalationspfade definieren

Phase 2: Prozesse etablieren (Q2 2026)

• Detaillierte Prozessdokumentation erstellen
• Triage-Kriterien und SLAs definieren
• Integration mit Ticket-System umsetzen
• SBOM-Generierung in CI/CD-Pipeline integrieren
• Automatisiertes Vulnerability-Scanning einrichten

Phase 3: Meldepflicht-Readiness (Q3 2026)

• ENISA-Plattform-Zugang einrichten
• BSI-Kontakt etablieren
• Melde-Templates vorbereiten
• Dry-Run-Übungen durchführen
• 24/7-Erreichbarkeit für kritische Fälle sicherstellen

Phase 4: Optimierung (ab Q4 2026)

• Metriken erheben und auswerten
• Prozesse basierend auf Erfahrungen optimieren
• Bug-Bounty-Programm evaluieren
• VEX-Integration ausbauen
• Automatisierung erweitern

Fazit: Schwachstellenmanagement als kontinuierlicher Prozess

Das CRA-konforme Schwachstellenmanagement ist keine einmalige Projektaufgabe, sondern ein dauerhafter operativer Prozess. Die 24-Stunden-Meldepflicht erfordert eine Reaktionsfähigkeit, die nur durch etablierte Strukturen, klare Verantwortlichkeiten und geübte Abläufe erreichbar ist.

Der Aufwand für den Aufbau eines PSIRT und die Implementierung strukturierter Prozesse zahlt sich mehrfach aus: durch schnellere Reaktion auf Sicherheitsvorfälle, reduzierte Haftungsrisiken, verbesserte Kundenbeziehungen und letztlich durch CRA-Compliance.

Unternehmen, die bis September 2026 keine funktionierenden Meldeprozesse etabliert haben, riskieren nicht nur Bußgelder, sondern auch Reputationsschäden bei verspäteter Reaktion auf Sicherheitsvorfälle. Der Zeitpunkt zum Handeln ist jetzt.

---

Professionelle Unterstützung

Der Aufbau eines funktionierenden Schwachstellenmanagements ist eine Kernanforderung des Cyber Resilience Act. Das Schwachstellenmanagement ist eng mit anderen CRA-Bausteinen verzahnt – insbesondere mit der Software Bill of Materials (SBOM), die Grundvoraussetzung für effektives Schwachstellenmanagement ist. Professionelle Unterstützung gewährleistet, dass Ihre Meldeprozesse rechtskonform sind und die 24-Stunden-Frist zuverlässig eingehalten werden kann.

• Cyber Resilience Act Beratung: Strukturierter Aufbau von PSIRT-Strukturen, CVD-Prozessen und ENISA-Meldeprozessen für vollständige CRA-Compliance.

---

Externe Ressourcen:

• BSI TR-03183 Technische Richtlinie
• ENISA – European Union Agency for Cybersecurity
• FIRST PSIRT Services Framework
• OWASP Vulnerability Disclosure Cheat Sheet
• CycloneDX VEX Specification