Koordinierte Offenlegung von Schwachstellen: So betreiben Sie ein Programm

Was ist die koordinierte Offenlegung von Schwachstellen?

Die koordinierte Offenlegung von Schwachstellen (Coordinated Vulnerability Disclosure, CVD) ist die Praxis, eine neu gefundene Schwachstelle vertraulich zwischen Finder und Hersteller zu behandeln, bis ein Fix oder eine Abhilfemaßnahme verfügbar ist, und sie dann zu veröffentlichen. Der CERT Guide to Coordinated Vulnerability Disclosure beschreibt sie als das Sammeln von Informationen bei den Findern von Schwachstellen, das Koordinieren des Austauschs dieser Informationen zwischen den relevanten Beteiligten und das Offenlegen der Schwachstelle und ihrer Abhilfemaßnahmen, auch gegenüber der Öffentlichkeit.

Für einen Produkthersteller hat CVD zwei Hälften. Die nach außen gerichtete Hälfte, Meldungen empfangen und Advisories veröffentlichen, behandelt diese Seite. Die nach innen gerichtete Hälfte, Verifizieren, Beheben und Veröffentlichen, ist der Lebenszyklus des Schwachstellenmanagements. Beide betreibt meist ein PSIRT.

CVD, Full Disclosure und Bug Bounty im Vergleich

	Koordinierte Offenlegung	Full Disclosure	Bug Bounty
Was es ist	Vertrauliche Meldung, Fix, dann Veröffentlichung zu einem vereinbarten Zeitpunkt	Der Finder veröffentlicht Details sofort, mit oder ohne Information an den Hersteller	Ein Programm, das für gültige Befunde bezahlt
Wer den Zeitpunkt bestimmt	Hersteller und Finder gemeinsam, manchmal mit einem Koordinator	Der Finder	Die Bedingungen des Programms, meist nach CVD
Risiko für Nutzer	Am niedrigsten: Details werden öffentlich, sobald ein Fix existiert oder eine Frist abläuft	Am höchsten: Angreifer erfahren davon zeitgleich mit den Verteidigern	Wie bei CVD
Kosten	Personalzeit für Triage und Reaktion	Ungeplante Notfallarbeit	Personalzeit plus Prämien und oft Plattformgebühren

Ein Bug Bounty ist keine Alternative zu einem Vulnerability Disclosure Program (VDP). Es ist ein Anreiz, der auf einem solchen aufsetzt. Jeder Hersteller braucht einen Weg, über den jeder eine Schwachstelle melden kann; ein Bounty entscheidet nur, ob manche Meldungen bezahlt werden.

Was in eine Richtlinie zur Offenlegung von Schwachstellen gehört

Eine Richtlinie zur Offenlegung von Schwachstellen ist das öffentliche Dokument, das die Bedingungen Ihres Programms festlegt. ISO/IEC 29147, der internationale Standard für die Offenlegung von Schwachstellen, schreibt ein Element vor, einen bevorzugten Kontaktweg, und empfiehlt mehrere weitere. Eine vollständige Richtlinie deckt ab:

• Wie gemeldet wird. Eine eigene Adresse oder ein Webformular und ein Weg, sensible Details sicher zu übermitteln, etwa ein veröffentlichter Verschlüsselungsschlüssel.
• Was enthalten sein sollte. Betroffenes Produkt und Version, Schritte zur Reproduktion, Auswirkung und wie der Meldende erreichbar ist.
• Geltungsbereich. Welche Produkte, Versionen und Dienste abgedeckt sind und welche Testmethoden ausgeschlossen sind, etwa Denial of Service oder der Zugriff auf Daten anderer Nutzer.
• Safe Harbor. Die Zusage, keine rechtlichen Schritte gegen Forschung in gutem Glauben einzuleiten, die der Richtlinie folgt.
• Was Meldende erwarten können. Wann Sie die Meldung bestätigen, wie Sie sie auf dem Laufenden halten und Ihre Zielzeit bis zum Fix.
• Zeitplan der Offenlegung. Wann Details öffentlich werden und was geschieht, wenn ein Fix länger dauert.
• Veröffentlichung. Wo Advisories erscheinen und ob Sie CVE-IDs vergeben.
• Anerkennung. Ob und wie Sie Meldende nennen und ob Sie Bounties zahlen.

Halten Sie die Richtlinie kurz und konkret. Meldende lesen sie, um zu entscheiden, ob eine Meldung an Sie sicher ist und sich lohnt.

security.txt: Machen Sie Ihren Kontakt leicht auffindbar

Eine Richtlinie funktioniert nur, wenn Forschende sie finden. RFC 9116, veröffentlicht im April 2022, definiert security.txt, eine kleine Textdatei, die unter /.well-known/security.txt über HTTPS bereitgestellt wird.

Contact: mailto:[email protected]
Expires: 2027-09-30T23:00:00.000Z
Encryption: https://example.com/pgp-key.txt
Policy: https://example.com/security/disclosure-policy
Acknowledgments: https://example.com/security/thanks
Preferred-Languages: en
Canonical: https://example.com/.well-known/security.txt

• Pflicht: Contact und Expires. RFC 9116 empfiehlt ein Ablaufdatum weniger als ein Jahr in der Zukunft, damit die Datei nicht veraltet.
• Optional: Policy, Encryption, Acknowledgments, Preferred-Languages, Canonical und Hiring.
• Signatur: Der RFC empfiehlt eine OpenPGP-Cleartext-Signatur, mit gesetztem Canonical.

Legen Sie sich vor dem Expires-Datum eine Erinnerung in den Kalender. Eine abgelaufene Datei signalisiert Forschenden, dass niemand mitliest.

Embargos und Offenlegungsfristen

Das Embargo ist der Zeitraum zwischen Meldung und Veröffentlichung. Die meistzitierte Norm ist die Richtlinie von Google Project Zero: Hersteller haben 90 Tage, um einen Patch bereitzustellen, und Details werden 30 Tage nach Auslieferung des Patches veröffentlicht. Ein Hersteller, der etwas mehr Zeit braucht, kann eine Nachfrist beantragen, auf höchstens 104 Tage insgesamt. Wird eine Schwachstelle bereits in freier Wildbahn ausgenutzt, sinkt die Frist auf 7 Tage.

Ihre eigene Richtlinie kann andere Bedingungen festlegen, und viele Meldende akzeptieren das. Wichtig ist, dass der Zeitplan schriftlich festgehalten ist, dass Sie Meldende informiert halten und dass Sie eine Verlängerung vor Ablauf der Frist beantragen, nicht danach. Ein pünktlich veröffentlichtes Advisory mit einer Abhilfemaßnahme ist besser als Schweigen.

CVE-IDs und CNAs

Die meisten Advisories tragen eine CVE-ID, damit Kunden und Tools sie zuordnen können. IDs vergeben CVE Numbering Authorities (CNAs), Organisationen, die befugt sind, innerhalb eines vereinbarten Bereichs IDs zu vergeben. Viele Softwarehersteller sind CNAs für ihre eigenen Produkte und können so die ID vergeben und den Eintrag nach eigenem Zeitplan veröffentlichen. Sind Sie keine, vergibt sie eine CNA, deren Bereich Ihr Produkt abdeckt, oder eine CNA of Last Resort.

Koordination mehrerer Parteien

Manche Schwachstellen betreffen viele Hersteller zugleich: ein Fehler in einer weit verbreiteten Bibliothek, einem Protokoll oder einem Chip. Dann hilft ein Koordinator, jeden betroffenen Hersteller zu erreichen und einen gemeinsamen Veröffentlichungstermin zu vereinbaren.

• CERT/CC am Software Engineering Institute der Carnegie Mellon University koordiniert Fälle mit mehreren Herstellern und veröffentlicht den CERT-CVD-Leitfaden.
• Nationale CSIRTs in der EU. Nach NIS2 benennt jeder Mitgliedstaat ein CSIRT als CVD-Koordinator. Es agiert als vertrauenswürdiger Vermittler zwischen Meldenden und Herstellern, handelt Offenlegungsfristen aus, behandelt Schwachstellen, die mehrere Einrichtungen betreffen, und nimmt anonyme Meldungen an.
• Die European Vulnerability Database (EUVD) der ENISA, eingerichtet nach NIS2, ist seit Mai 2025 in Betrieb und veröffentlicht Informationen zu öffentlich bekannten Schwachstellen, auch zu EU-weit koordinierten.

ISO/IEC 29147 behandelt auch den Fall, dass Sie beides sind: ein Hersteller, dessen Produkt die verwundbare Komponente eines anderen Herstellers enthält und der upstream melden und zugleich die eigenen Kunden informieren muss.

Nach Eingang einer Meldung

1. Bestätigen Sie innerhalb der Zeit, die Ihre Richtlinie zusagt, und geben Sie dem Meldenden eine Tracking-ID.
2. Verifizieren Sie die Meldung und bewerten Sie ihren Schweregrad.
3. Ermitteln Sie, was betroffen ist: jedes Produkt, Release und jeden unterstützten Branch, der den verwundbaren Code oder die Komponente enthält.
4. Beheben und veröffentlichen Sie für jeden betroffenen Branch und halten Sie den Meldenden auf dem Laufenden.
5. Veröffentlichen Sie das Advisory mit CVE-ID, betroffenen Versionen, Behebung und Nennung des Meldenden. Maschinenlesbare Advisories nutzen CSAF, und VEX sagt Kunden, welche Produkte nicht betroffen sind.

Den vollständigen Prozess mit Rollen, Fristen und Kennzahlen beschreibt der Lebenszyklus des Schwachstellenmanagements.

Regulierung macht CVD-Richtlinien zur Pflicht

Der EU Cyber Resilience Act verlangt von Herstellern, eine Richtlinie zur koordinierten Offenlegung von Schwachstellen festzulegen und durchzusetzen und eine Kontaktadresse für die Meldung von Schwachstellen bereitzustellen, auch für solche in Komponenten von Dritten (Anhang I Teil II). Diese Pflichten gelten ab dem 11. Dezember 2027; siehe was der CRA verlangt. NIS2 Artikel 21 Absatz 2 Buchstabe e nennt die Behandlung und Offenlegung von Schwachstellen unter den Sicherheitsmaßnahmen, die wesentliche und wichtige Einrichtungen ergreifen müssen. In den USA ordnete die Executive Order 14028 Leitlinien zur Software-Lieferkette an, die die Teilnahme an einem Vulnerability Disclosure Program einschließen.

Eine Meldung ist nur so nützlich wie Ihre Aufzeichnung des Ausgelieferten

Jede Meldung wirft dieselbe erste Frage auf: Welche unserer Releases enthalten das? CRACI führt Ihre GitHub-Actions-Builds auf seinen eigenen Runnern aus und zeichnet die Pakete auf, die jeder Job tatsächlich geladen hat, einschließlich transitiver Abhängigkeiten, aus CI-Caches wiederhergestellter Pakete und Abhängigkeiten, die kein Lockfile auflistet. Die Build-Historie zeigt, welche früheren Builds eine verwundbare Abhängigkeit enthielten, sodass Sie den Zeitraum der Betroffenheit kennen, und die Inventaransicht zeigt, welche Softwareversionen auf welchen Produkten installiert sind.

CRACI führt SBOMs über Builds und Repositories hinweg zusammen und bewertet überwachte SBOMs laufend neu, sodass Sie, sobald eine Schwachstelle in einer Open-Source-Komponente veröffentlicht ist, jede Stelle sehen, an der sie vorkommt. Sicherheitsteams sichten Befunde und leiten sie an die Teams weiter, die für die Behebung zuständig sind, CRACI unterstützt VEX, und Policy-Gates können Builds blockieren, die eine bestimmte CVE enthalten, sobald sie behoben ist. Siehe Schwachstellenverfolgung.

Koordinierte Offenlegung von Schwachstellen: häufig gestellte Fragen

Was ist die koordinierte Offenlegung von Schwachstellen?

Die koordinierte Offenlegung von Schwachstellen (Coordinated Vulnerability Disclosure, CVD) ist der Prozess, bei dem die Person, die eine Schwachstelle findet, sie vertraulich dem Hersteller meldet, der Hersteller sie behebt und die Details veröffentlicht werden, sobald Nutzer sich schützen können, meist zu einem vereinbarten Termin. Koordinatoren wie CERT/CC oder ein nationales CSIRT greifen ein, wenn ein Hersteller nicht erreichbar ist oder mehrere Hersteller betroffen sind.

Was ist der Unterschied zwischen einem VDP und einem Bug Bounty?

Ein Vulnerability Disclosure Program (VDP) sagt jedem, wie eine Schwachstelle zu melden ist und was zu erwarten ist, ohne für Befunde zu bezahlen. Ein Bug Bounty bezahlt Forschende für gültige Befunde, meist innerhalb eines definierten Bereichs und oft über eine Bounty-Plattform. Die meisten Organisationen beginnen mit einem VDP; ein Bounty ist eine optionale Ergänzung dazu, kein Ersatz.

Was sollte eine Richtlinie zur Offenlegung von Schwachstellen enthalten?

Mindestens, wie gemeldet wird: eine Kontaktadresse oder ein Formular. ISO/IEC 29147 empfiehlt außerdem anzugeben, was eine Meldung enthalten sollte, wie sicher kommuniziert wird, was Meldende wann erwarten können, was im Geltungsbereich liegt, wie Sie Advisories veröffentlichen und wie Sie Meldende nennen. Die meisten Richtlinien ergänzen eine Safe-Harbor-Erklärung und einen Zeitplan der Offenlegung.

Was ist security.txt?

security.txt ist eine einfache Textdatei, die in RFC 9116 definiert ist und unter /.well-known/security.txt bereitgestellt wird. Sie sagt Forschenden, wo sie Schwachstellen melden können. Sie muss ein Contact- und ein Expires-Feld enthalten und kann auf Ihre Richtlinie, Ihren Verschlüsselungsschlüssel und Ihre Danksagungsseite verlinken.

Wie lang ist eine typische Offenlegungsfrist?

90 Tage sind die meistzitierte Norm. Google Project Zero gibt Herstellern 90 Tage, um einen Patch bereitzustellen, und veröffentlicht Details 30 Tage nach dem Patch, mit einer Frist von 7 Tagen, wenn eine Schwachstelle bereits in freier Wildbahn ausgenutzt wird. Ihre eigene Richtlinie kann andere Bedingungen festlegen, und Koordinatoren verhandeln von Fall zu Fall.

Ist eine Richtlinie zur koordinierten Offenlegung von Schwachstellen Pflicht?

Zunehmend ja. Der EU Cyber Resilience Act verlangt von Herstellern von Produkten mit digitalen Elementen, eine CVD-Richtlinie festzulegen und durchzusetzen und eine Kontaktadresse für Meldungen bereitzustellen, und NIS2 nennt die Behandlung und Offenlegung von Schwachstellen unter den erforderlichen Sicherheitsmaßnahmen. Anderswo verlangen Kunden und Beschaffungsregeln oft eine solche Richtlinie.

Muss ich CNA sein, um eine CVE-ID zu erhalten?

Nein. Eine CVE Numbering Authority (CNA) vergibt CVE-IDs innerhalb ihres eigenen Bereichs, und viele Hersteller werden CNAs für ihre eigenen Produkte. Wenn Sie keine sind, kann eine CNA, deren Bereich Ihr Produkt abdeckt, oder eine CNA of Last Resort die ID vergeben.