Eine Schwachstelle, die mehrere unabhängige Hersteller gleichzeitig trifft – meist über eine gemeinsame Engine, Bibliothek oder ein gemeinsames Protokoll –, lässt sich nicht über ein gewöhnliches Vulnerability-Disclosure-Programm abwickeln. Koordinierte Offenlegung mit mehreren Parteien verlangt ein ausgehandeltes Embargo-Datum, eine abgestimmte CVE-Struktur und oft einen neutralen Koordinator, denn kein einzelner Hersteller bestimmt den Zeitplan. Nahezu jedes VDP, das heute produktiv läuft, ist für den umgekehrten Fall gebaut: ein Unternehmen, eine Meldung, eine Frist. Sehen wir uns an, was passiert, wenn diese Annahme nicht trägt, welche Frist tatsächlich maßgeblich ist und warum Ihr SLA-Dashboard ausgerechnet an dem Morgen grün zeigen kann, an dem eine gemeinsame Schwachstelle öffentlich wird. ## Ein WebKit-Fehler, jeder Proxy-Browser unter iOS Am 4. August 2026 veröffentlichten die Forscher von Mysk drei WebKit-Verhaltensweisen, die den konfigurierten Proxy eines Browsers umgehen und die echte IP-Adresse des Geräts oder dessen DNS-Resolver preisgeben. Die Mechanismen sind gewöhnliche Funktionen der Web-Plattform: ``-Hinweise, bei denen „eine Seite eindeutige, besucherspezifische Hostnamen in diese Tags einbetten und anschließend beobachten kann, wie die Anfragen am eigenen autoritativen DNS-Server eintreffen – aus dem echten Netzwerk des Besuchers statt aus dem des Proxys“; WebAuthn Related Origin Requests, bei denen der Anmeldedienst des Betriebssystems `https:///.well-known/webauthn` am Proxy vorbei abruft; und WebTransport, das HTTP/3-QUIC-Verbindungen direkt vom Gerät aus öffnet. Zum Präzedenzfall wird das nicht wegen des technischen Details, sondern wegen der Plattformregeln. Die Analyse formuliert es so: **„Da Apples App-Store-Richtlinie jedem iOS-Browser WebKit vorschreibt, ist jeder iOS-Browser betroffen, der für das Proxying auf diese API setzt – einschließlich sämtlicher Tor-Browser für iOS und Psylo.“** Eine einzige Ursache in einer einzigen API zur Proxy-Konfiguration trifft gleichzeitig Apples eigenen iCloud Private Relay und jeden davon unabhängigen Privacy-Browser, der unter iOS ausgeliefert wird. Apple ist zugleich der vorgelagerte Engine-Hersteller *und* ein nachgelagerter Produktverantwortlicher. Selbst die reflexhafte Antwort „an den Upstream eskalieren und weitermachen“ klärt also nicht, wer die Führung übernimmt. Beachten Sie, was in der Veröffentlichung fehlt. Keine CVE. Kein gemeinsames Embargo-Datum. Kontakt zu zwei der betroffenen Parteien: „Wir haben das Tor Project und die Entwickler von Onion Browser unter iOS wegen dieser Probleme angesprochen.“ Das ist kein Vorwurf an die Forscher. Es zeigt schlicht, was standardmäßig herauskommt, wenn niemand die Koordination übernimmt. Jeder betroffene Hersteller erfährt zu einem anderen Zeitpunkt und aus einer anderen Quelle davon, manche aus dem Blogbeitrag. Wer in dieser letzten Gruppe landet, [zahlt dafür einen hohen Preis](/blog/when-researchers-go-public-botched-disclosure). ## Was ist koordinierte Offenlegung mit mehreren Parteien? > Koordinierte Offenlegung mit mehreren Parteien (MPCVD) ist das Verfahren für eine Schwachstelle, die mehrere unabhängige Hersteller gleichzeitig betrifft – meist über eine gemeinsame Komponente, eine gemeinsame Engine oder ein gemeinsames Protokoll. Anders als ein VDP mit einem einzigen Hersteller verlangt sie ein ausgehandeltes Embargo-Datum, eine abgestimmte CVE-Struktur und einen Koordinator, denn keine einzelne Partei bestimmt den Zeitplan. FIRST gibt das Referenzdokument heraus, die **Multi-Party Vulnerability Coordination and Disclosure Guidelines (v1.1)**. Sie ruhen auf vier Säulen – belastbare Prozesse und Beziehungen, klare Kommunikation, Vertrauensaufbau, Begrenzung der Gefährdung – und definieren fünf Rollen: **Finder, Hersteller, Koordinator, Verteidiger sowie Nutzer und Betreiber**. Die meisten VDP haben nur für die ersten beiden überhaupt ein Vokabular. ## Warum das inzwischen der Normalfall ist, nicht die Ausnahme Die meisten Schwachstellen in einem modernen Produkt stecken in Code, den der Hersteller nicht geschrieben hat und nicht im Alleingang beheben kann. Der OSSRA-Bericht 2026 von Black Duck, der auf „der Analyse von 947 kommerziellen Codebasen aus 17 Branchen“ beruht, kommt zu diesen Zahlen: - **87 %** der geprüften Codebasen enthielten mindestens eine Schwachstelle - **78 %** enthielten hochriskante Schwachstellen, darunter **44 %** mit kritischem Risiko - Die durchschnittliche Zahl der Open-Source-Schwachstellen pro Codebasis „hat sich mehr als verdoppelt und ist um **107 %** auf durchschnittlich **581** Schwachstellen gestiegen“ - **93 %** enthalten Komponenten, an denen in den letzten zwei Jahren nicht mehr entwickelt wurde Der CERT Guide to Coordinated Vulnerability Disclosure benennt die Ursache ohne Umschweife: **„Viele Produkte werden heute nicht von einer einzigen Organisation entwickelt. Sie werden stattdessen aus Komponenten zusammengesetzt, die von anderen Organisationen stammen.“** Denken Sie diese Zahlen zu Ende. Wenn Ihre Angriffsfläche überwiegend zusammengesetzt und nicht selbst geschrieben ist, betreffen die meisten Ihrer Schwachstellen strukturell mehrere Parteien. Die Meldung, hinter der nur ein einziger Hersteller steht, ist der Sonderfall – und genau für ihn wurde Ihr Werkzeug gebaut. ## Die vier Ausgänge Ihrer Sichtungs-Warteschlange – und warum drei davon falsch sind Öffnen Sie eine beliebige VDP-Eingangswarteschlange und sehen Sie sich die Ablehnungsgründe an. Das Csirt-Modul von Kit liefert den üblichen Satz aus: `out_of_scope`, `duplicate`, `informational`, `not_reproducible`, `spam`, `other` und `ai_slop`. Jedes VDP hat irgendeine Fassung dieser Liste – und bei einer Meldung zu einer gemeinsam genutzten Abhängigkeit sind ausgerechnet die beiden naheliegendsten Ausgänge falsch. **`out_of_scope`** ist richtig für „das ist nicht unser System“. Falsch ist es für „das ist unser Produkt, nur über fremden Code“. Ihre Nutzer sind so oder so gefährdet, und wenn Sie die Meldung schließen, löschen Sie Ihre Pflicht, ohne die Gefährdung anzurühren. Es wirkt außerdem feindselig: Die Vertrauenssäule von FIRST warnt, dass juristische Eskalation „eine abschreckende Wirkung auf erwünschte Sicherheitsforschung“ entfaltet – und eine Meldung zu einer gemeinsamen Abhängigkeit stillschweigend zu schließen, liegt auf derselben Skala. Mehr zu dieser Dynamik in [Safe Harbor und juristische Drohungen](/blog/safe-harbor-legal-threats-security-researchers-vdp). **`duplicate`** steht semantisch auf dem Kopf. Heute bedeutet es „derselbe Fehler, uns bereits gemeldet“, und es schließt die Meldung. Ein Fall mit gemeinsamer Abhängigkeit behauptet das Gegenteil: dieselbe Ursache, aber im Produkt *eines anderen*. Das muss die Meldung **offen** halten – mit einem zweiten Verantwortlichen und einer zweiten Frist. **`informational`** begräbt sie. Und `not_reproducible` ist der Grund, der Sie kalt erwischt: Ein nachgelagerter Hersteller kann eine vorgelagerte Schwachstelle isoliert oft tatsächlich nicht nachstellen. Der Ausgang, den keine verbreitete Eingangs-Taxonomie kennt, ist der fünfte: **verknüpft**. Dieselbe Ursache, ein anderer Hersteller, ein abgestimmter Zeitplan – und trotzdem müssen wir dafür geradestehen. Das gewinnt an Gewicht, je mehr KI-gestützte Forschung Befunde auf Abhängigkeitsebene in die Eingangswarteschlangen spült; diese Verschiebung behandelt [KI und die Ökonomie der VDP-Sichtung](/blog/ai-cheap-vulnerability-research-vdp-triage-economics). ## Wer legt das Embargo-Datum fest? Niemand – lernen Sie also die Obergrenzen Es gibt keine Instanz, die Embargo-Daten festlegt. FIRST hält sich bewusst zurück: „Solange keine klaren Belege für eine frühere Veröffentlichung vorliegen (einschließlich aktiver Ausnutzung), sollten die Beteiligten den Herstellern eine angemessene Embargo-Frist einräumen, um die Sache zu untersuchen und Korrekturen zu entwickeln.“ Sind mehrere Koordinatoren beteiligt, „sollte ein Koordinator als federführend bestimmt werden“. Das Datum wird also ausgehandelt. Handhabbar wird diese Verhandlung aber erst, wenn Sie die harten Obergrenzen kennen, an die andere Beteiligte bereits gebunden sind. | Frist | Länge | Bindet | |---|---|---| | `distros`-Mailingliste | **maximal 14 Tage**, bevorzugt unter 7, mindestens 1 Tag | alle, die Linux-Distributionen informiert haben | | CERT/CC | **45 Tage** ab Meldung, „unabhängig davon, ob Patches oder Behelfslösungen existieren oder verfügbar sind“ | alle, die über CERT/CC gemeldet haben | | Google Project Zero | **90 Tage**, Details 30 Tage nach dem Patch; **7 Tage** bei aktiver Ausnutzung | jeden Hersteller, dem Project Zero meldet | | HackerOne (Standard) | **30 Tage** ohne Widerspruch; **180 Tage** als Rückfallgrenze für den Finder | Programme, die auf HackerOne laufen | | OpenSSL-Vorabinformation | **2 Wochen** für OS-Distributoren und abgeleitete Projekte; **1 Woche** bis zur öffentlichen Ankündigung | nachgelagerte Nutzer von OpenSSL | Aus dieser Tabelle folgt eine Regel, und sie ist die maßgebliche Regel der Offenlegung mit mehreren Parteien: **Maßgeblich ist das Embargo mit der kürzesten Frist, an die irgendein Beteiligter bereits gebunden ist.** Hat einer der Beteiligten `distros` eingeschaltet, haben Sie höchstens 14 Tage – ganz gleich, was Ihre eigene Richtlinie sagt. Ihre bevorzugten 90 Tage sind in dem Moment bedeutungslos, in dem die 14-Tage-Grenze eines anderen läuft. Der CERT Guide erklärt, warum es die Obergrenzen überhaupt gibt: **„Je mehr Parteien an einem Fall beteiligt sind und je länger die Embargo-Frist dauert, desto wahrscheinlicher wird ein Leck.“** Längere Embargos sind nicht sicherer. Sie sind nur länger. ## Eine CVE oder fünf? Die Kennungsfrage, die niemand erklärt Beide Konventionen existieren, entschieden wird von Fall zu Fall, und es ist eine Frage der Koordination, keine der Verwaltung. Das ist der am schlechtesten dokumentierte Teil der Offenlegung mit mehreren Parteien – und wer sich hier vertut, schafft Arbeit für alle, die nach ihm kommen. **Eine CVE pro Protokollfehler, viele Hersteller darunter.** Die Autoren von KRACK haben die Logik klar benannt: „Jede CVE-Kennung steht für eine bestimmte Ausprägung eines Key-Reinstallation-Angriffs. Damit beschreibt jede CVE-ID eine bestimmte Protokollschwachstelle, und deshalb **sind von jeder einzelnen CVE-ID viele Hersteller betroffen**.“ Zehn CVEs beschrieben die Schwachstelle, nicht die Produkte. **Eine CVE pro betroffenem Produkt – und das Duplikat-Chaos, das daraus folgt.** Im Fall libwebp wurde eine zweite Kennung für die Bibliothek vergeben, obwohl für den nachgelagerten Browser-Fehler bereits eine existierte. CVE-2023-5129 ist inzwischen formal tot: **„Diese CVE-ID wurde von ihrer CVE Numbering Authority zurückgewiesen oder zurückgezogen. Duplikat von CVE-2023-4863.“** An der Schwachstelle selbst hat sich nichts geändert. Geändert hat sich die Kennung – und jeder Sicherheitshinweis, jede Scanner-Regel, jeder SBOM-Eintrag und jede Ticket-Referenz, die daran hing, musste auf die andere Kennung umgestellt werden. **Gemischt, wenn sowohl das Protokoll als auch die Implementierungen fehlerhaft sind.** Terrapin brachte CVE-2023-48795 für den allgemeinen Protokollfehler zusammen mit CVE-2023-46445 und CVE-2023-46446 für AsyncSSH-spezifische Angriffe sowie CVE-2024-41909 für Apache MINA SSHD. Ist niemand offensichtlich für die Vergabe zuständig, sieht die Richtlinie von CERT/CC vor, die CVE in Fällen mit mehreren Herstellern und unklarer Zuständigkeit selbst zu vergeben. Koordination geht dort vor dem Warten auf eine Klärung unter den CNAs. Für einen nachgelagerten Hersteller ist die Folge klein und konkret: Ihr Hauptbuch muss einen *Verweis* auf eine vorgelagerte Kennung führen, die später ersetzt werden kann – keine fest eingetragene Zeichenkette in einem Beschreibungsfeld. ## So finden Sie die anderen vier Hersteller Drei Wege, nach Aufwand aufsteigend sortiert. 1. **`security.txt` (RFC 9116).** Eine Klartextdatei unter `https://example.com/.well-known/security.txt` mit den Pflichtfeldern `Contact` und `Expires` sowie den optionalen Feldern `Acknowledgments`, `Canonical`, `Encryption`, `Hiring`, `Policy` und `Preferred-Languages`. Im April 2022 als Informational RFC veröffentlicht, existiert sie, damit ein Finder Ihren Meldekanal findet, ohne zu raten. Sie ist zugleich der billigste Weg, *für einen vorgelagerten Koordinator* auffindbar zu sein – an diese Richtung denkt kaum jemand. [Ein VDP aufsetzen](/blog/how-to-set-up-vulnerability-disclosure-program) behandelt die übrige Grundlagenarbeit. 2. **Ein Koordinator.** CERT/CC betreibt VINCE (Vulnerability Information and Coordination Environment) – getragen vom Software Engineering Institute der CMU und gefördert von der CISA. Dort hinterlegen Hersteller ihre Kontakte und stimmen Fälle ab. Das ist die offizielle Antwort auf „Ich weiß nicht, wer das sonst noch ausliefert“. 3. **Manuelle Ansprache in Schüben.** Und das ist der Normalfall. Die Terrapin-Autoren haben in zwei Runden rund 29 SSH-Implementierungen angesprochen und CERT-Bund informiert. Kalibrieren Sie Ihre Erwartung an einer echten Zahl. Der KRACK-Hinweis von CERT, VU#228519, enthält eine Herstellertabelle, deren Fußzeile **„Alle 183 Hersteller anzeigen“** lautet – aufgeteilt auf betroffen, nicht betroffen und einen großen Block „unbekannt“, aus dem nie eine Rückmeldung kam. In einem echten Fall mit mehreren Parteien antwortet ein erheblicher Teil der betroffenen Hersteller überhaupt nicht. ## Terrapin: So sieht eine gut geführte Offenlegung mit mehreren Parteien aus Dieselbe Ausgangslage wie im WebKit-Fall, die gegenteilige Ausführung. Ein Protokollfehler, der rund 29 unabhängige SSH-Implementierungen trifft – und bewusst koordiniert wurde: - **17.10.2023** erster Kontakt mit OpenSSH und dem Autor von AsyncSSH - **17.11.2023** erste Herstellerrunde, 17 Implementierungen, dazu CERT-Bund - **21.11.2023** zweite Runde, 12 weitere - **11.12.2023** Meldung an `distros` - **18.12.2023** öffentliche Bekanntgabe **62 Tage, vier CVEs, ein Datum.** Achten Sie auf die letzten beiden Einträge: `distros` wurde genau 7 Tage vor der Veröffentlichung eingeschaltet – im *bevorzugten* Fenster dieser Liste, nicht knapp an ihrer 14-Tage-Grenze entlang. So sieht es aus, wenn jemand bewusst nachrechnet. Die Spannbreite echter Embargos mit mehreren Parteien ist groß. Cloudflare, Google und AWS wickelten HTTP/2 Rapid Reset unter aktiver Ausnutzung in rund 46 Tagen ab – von der Entdeckung am 25. August 2023 bis zu Googles Veröffentlichung am 10. Oktober 2023. KRACK dauerte etwa 94 Tage. Meltdown und Spectre brauchten 216: Project Zero meldete am 1. Juni 2017 an Intel, AMD und ARM und veröffentlichte am 3. Januar 2018. 46 bis 216 Tage. Kein SLA deckt diese Spanne ab, und darum geht es. **In einem Fall mit mehreren Parteien ist das Datum eine Vorgabe von außen, kein Ergebnis Ihrer Richtlinie.** ## Das Fristenproblem: warum Ihr SLA grün meldet, während Sie längst zu spät sind Dieser Fehlermodus ist nirgends aufgeschrieben, und er entsteht aus Arithmetik, nicht aus Nachlässigkeit. SLA-Fristen für Einzelfälle hängen an dem Moment, in dem die Meldung *bei Ihnen* eintraf. Kits `Csirt::Report::SlaTrackable` berechnet jede Frist ab `submitted_at`, und das ist der richtige und übliche Ansatz. Kits Standardwerte sind ebenso üblich: 72 Stunden bis zur Eingangsbestätigung, danach Zielzeiten für die Behebung von 24 Stunden bei Super-kritisch, 72 bei Kritisch, 168 bei Hoch, 336 bei Mittel und 720 bei Niedrig oder Informativ. Halten Sie diese Standardwerte nun neben die Embargo-Obergrenzen. **336 Stunden sind exakt 14 Tage** – genau das höchste Embargo, das die `distros`-Liste akzeptiert. **720 Stunden sind 30 Tage**, mehr als das Doppelte jedes Embargos, das die Linux-Distributionen einhalten. Ein Fehler in einer gemeinsam genutzten Abhängigkeit, der als Mittel oder niedriger eingestuft wurde, liegt standardmäßig noch bequem innerhalb seines eigenen SLA – und zwar an genau dem Morgen, an dem das Embargo abläuft und die Schwachstelle öffentlich wird. Das Dashboard zeigt grün. Die Meldung ist im Plan. Und der Fix ist nicht ausgeliefert, der Sicherheitshinweis nicht verfasst, und Ihre Nutzer erfahren davon aus dem Blogbeitrag eines anderen. Zwei Dinge gehen hier gleichzeitig schief. Der Ankerpunkt sitzt falsch, weil die maßgebliche Frist früher begann – als ein Finder einem anderen Hersteller meldete. Und das Enddatum stimmt nicht, weil es in Verhandlungen zwischen Parteien festgelegt wurde, denen Sie vielleicht nie begegnet sind. Das ist ein anderer Fehlermodus als die [Fairness-Probleme bei SLA](/blog/bug-bounty-payout-disputes-resolution-sla-fairness), die in bilateralen Programmen auftauchen. Dort wird gestritten, ob die Frist eingehalten wurde. Hier wird die Frist perfekt eingehalten – und man kommt trotzdem zu spät. ## Was Ihr Hauptbuch wirklich braucht: einen Datensatz für verknüpfte Offenlegungen Die Lösung ist ein einziger Datensatz, und die meisten VDP-Werkzeuge bringen alle Bausteine dafür bereits mit. Eine **verknüpfte Offenlegung** ist eine vollwertige Verbindung zwischen einer Meldung in Ihrem Hauptbuch und einer externen Offenlegung anderswo. Sie enthält: - **Eine Rolle.** `upstream`, `downstream` oder `peer`. Dieses Feld macht aus einer nicht einzuordnenden Meldung einen Fall, in dem Sie eine definierte Position haben. - **Einen externen Verweis.** Die vorgelagerte CVE oder die URL des Sicherheitshinweises sowie eine Fallreferenz des Koordinators, etwa eine VU-Nummer von CERT/CC oder einen `distros`-Thread. - **Zwei Daten, nicht eines.** `upstream_reported_at`, der tatsächliche Beginn der Frist, und `embargo_at`, das vereinbarte Veröffentlichungsdatum. - **Eine Regel.** Maßgeblich ist, was zuerst abläuft. Diese eine Zeile ist die ganze Lösung. Alles Übrige ist Wiederverwendung. Kits SLA-Stufen sprechen bereits das richtige Vokabular (`breached`, `at_risk`, `on_track`, `no_sla`); sie brauchen nur eine zweite Bedingung, die sie zusätzlich auswerten, damit eine Meldung *„Eingangsbestätigung: im Plan, Embargo: 3 Tage“* anzeigt statt eines einsamen grünen Hakens. `Csirt::TrackerIssue` pflegt bereits verwaltete, statussynchrone Verbindungen zu externen Systemen – also genau das, was ein vorgelagerter Sicherheitshinweis braucht, wenn dieser Hinweis später zurückgezogen werden kann, wie es bei CVE-2023-5129 geschah. Und `Csirt::Report::Shareable` erzeugt bereits geschwärzte, ablaufende, per E-Mail geschützte externe Freigaben. Der Kommentar im Quellcode verrät es selbst: *„Eine Ablehnung (‚außerhalb des Geltungsbereichs, das ist der Fehler des vorgelagerten Herstellers‘) ist genau der Moment, in dem ein Team die geschwärzte Kopie an eben diesen Hersteller weiterleitet.“* Der Kanal zu gleichrangigen Herstellern ist längst gebaut. Er ist nur nicht als Koordination modelliert, weshalb die Empfängerliste eine nicht nachverfolgte Weiterleitung bleibt, statt Teil der Fallakte zu werden. Der richtige Ort dafür ist die KI-gestützte Sichtung. Wenn ein Werkzeug im ersten Durchgang meldet „das sieht nach einem Fehler in einer Abhängigkeit aus, nicht nach unserem“, ist das richtige Ergebnis eine Weiterleitung, kein Abschluss. Das führt das Argument aus [dem Problem des stillen Patches](/blog/silent-patch-broken-vulnerability-disclosure-cve) weiter: Offenlegung ist eine nachverfolgte Phase, kein Endzustand. Der Fall mit mehreren Parteien fügt eine Sache hinzu. An dieser Phase hängen manchmal vier weitere Beteiligte – und Ihr Hauptbuch muss ihre Namen kennen.

Betreiben Sie ein VDP mit einem echten Hauptbuch? Das CSIRT-Modul von Kit führt Meldungen, SLA-Stufen, geschwärzte Freigaben an andere Hersteller und Verbindungen zu externen Trackern an einem Ort zusammen. So liegt die Koordinationsakte neben der Meldung statt in Ihrem Postfach.

Kostenlos testen

## Die Aufsicht wartet nicht auf das Embargo Nach dem EU Cyber Resilience Act müssen Hersteller ab dem **11. September 2026** aktiv ausgenutzte Schwachstellen über die Single Reporting Platform der ENISA melden: eine Frühwarnung binnen **24 Stunden**, eine vollständige Meldung binnen **72 Stunden** und einen Abschlussbericht binnen **14 Tagen** nach einer Korrekturmaßnahme. Diese Frist hängt an *Ihrer* Kenntnis, nicht am Embargo mit mehreren Parteien. Erfahren Sie an Tag 3 eines 90-tägigen Branchenembargos, dass die gemeinsame Schwachstelle ausgenutzt wird, läuft Ihre 24-Stunden-Pflicht sofort an. Keine Embargo-Vereinbarung entschuldigt das, und kein anderer Beteiligter kann für Sie darauf verzichten. Kits [Leitfaden zum EU Cyber Resilience Act](/blog/eu-cyber-resilience-act-mandatory-vulnerability-disclosure) behandelt die Pflicht vollständig; hier geht es nur darum, den Konflikt zu benennen. Ein Koordinationsdatensatz, der beide Daten führt, ist zugleich der Nachweis dafür, dass Sie die Frist der Aufsicht eingehalten haben, während das Branchenembargo noch lief. ## Das Vorgehen bei einer Meldung, die nicht nur Ihnen gehört Wenn aus einer Meldung hervorgeht, dass die Schwachstelle mehrere Hersteller betrifft, arbeiten Sie diese Liste ab, bevor Sie einen Ablehnungsgrund anfassen. 1. **Schließen Sie sie nicht.** Weder mit `out_of_scope` noch mit `duplicate`. Markieren Sie sie als verknüpft und halten Sie sie offen. 2. **Stellen Sie dem Finder drei Fragen.** Wen haben Sie sonst noch informiert, wann haben Sie das getan, und ist die Sache bereits an eine Mailingliste oder einen Koordinator gegangen? 3. **Ermitteln Sie die kürzeste bereits laufende Frist.** Lautet eine der Antworten `distros`, liegt Ihre Obergrenze bei 14 Tagen. Lautet sie CERT/CC, bei 45. Schreiben Sie das Datum auf. 4. **Entscheiden Sie, ob Sie führen oder folgen.** Koordiniert der vorgelagerte Hersteller, sind Sie nachgelagert und richten sich nach seinem Datum. Koordiniert niemand, wenden Sie sich an einen Koordinator, statt selbst einen zu erfinden. 5. **Einigen Sie sich früh auf die Struktur der Kennungen.** Eine CVE für die Schwachstelle oder eine pro Produkt? Fragen Sie, bevor Sicherheitshinweise verfasst werden, nicht danach. 6. **Veröffentlichen Sie eine `security.txt`.** Damit der nächste vorgelagerte Koordinator Sie ohne LinkedIn-Suche findet. 7. **Halten Sie beide Daten an der Meldung fest.** Das Eingangsdatum für Ihr SLA, das Embargo-Datum für die Wirklichkeit. Zeigen Sie beide an. 8. **Gehen Sie davon aus, dass die CRA-Frist unabhängig läuft.** Ist die Ausnutzung bestätigt, beginnt die 24-Stunden-Pflicht ungeachtet des Embargos. 9. **Verfolgen Sie die Freigabe an andere Hersteller nach.** Wenn Sie eine geschwärzte Kopie an einen anderen Hersteller weiterleiten, gehört dieser Empfänger zum Fall und ist keine Fußnote in irgendeinem Postausgang. 10. **Rechnen Sie mit Schweigen.** Ein großer Teil der angeschriebenen Hersteller meldet sich nie. Der CERT Guide rät, guten Willen zu unterstellen und weiter zu versuchen, den Kontakt wiederherzustellen. Wer selbst verstummt, landet am Ende namentlich im Offenlegungsbeitrag eines anderen Herstellers. Nichts davon verlangt ein PSIRT mit zwölf Leuten. Es verlangt ein Hauptbuch, das einen Satz ausdrücken kann, den Ihr heutiges Werkzeug vermutlich nicht kennt: **Diese Meldung ist eine von fünf.** Ergänzen Sie die Verknüpfung, ergänzen Sie die Embargo-Frist, wenden Sie die Regel der kürzesten Frist an – und aus einem Fehler, den Sie nicht einordnen können, wird ein Fall, den Sie führen können.