Richtlinie zur Offenlegung von Schwachstellen

Auf einen Blick

Diese Seite beschreibt NextPDFs Richtlinie zur koordinierten Offenlegung von Schwachstellen. Sie erklärt meldenden Personen, wie sie die Maintainer privat erreichen, mit welchem Reaktionszeitplan sie rechnen können und wie das Embargo funktioniert.

Abgrenzung. Eine Offenlegungsrichtlinie ist eine Prozesszusage, keine Garantie für Zeitplan oder Ergebnis. Die unten genannten Zielwerte sind die nach bestem Wissen gegebenen Zusagen der Maintainer gegenüber meldenden Personen; sie beschreiben den Prozess, dem das Projekt folgt, nicht ein vertragliches Versprechen, dass eine bestimmte Meldung bestätigt, triagiert, behoben oder bis zu einem bestimmten Datum offengelegt wird. Der Zeitpunkt der koordinierten Offenlegung wird ausgehandelt, nicht einseitig garantiert.

Installation

Nicht zutreffend. Um eine Schwachstelle zu melden, müssen Sie nichts installieren. Die maschinenlesbare Kontaktfläche ist unter /.well-known/security.txt (RFC 9116) veröffentlicht. Die maßgebliche menschenlesbare Richtlinie ist die SECURITY.md des Repositorys.

Konzeptioneller Überblick

Die Richtlinie setzt die koordinierte Offenlegung von Schwachstellen im Sinne von ISO/IEC 29147 um, ergänzt um den Behandlungsprozess aus ISO/IEC 30111 (iso_iec_30111#x9.x43.p2): ein privater Eingang, eine Triage mit Schweregradbewertung, eine Behebungsphase unter Embargo und eine gemeinsame öffentliche Offenlegung. Betrifft eine Schwachstelle mehrere Anbieter, wird der Veröffentlichungszeitpunkt zwischen den betroffenen Parteien abgestimmt und nicht einseitig festgelegt (iso_iec_29147#x3.x110.p13).

Der Prozess ist außerdem auf die Pflichten von Herstellern zur Schwachstellenbehandlung aus dem EU Cyber Resilience Act (eu_cra#x1.p191) sowie auf die Praxis „auf Schwachstellen reagieren“ des NIST Secure Software Development Framework (nist_sp_800_218#x15) abgestimmt. Beide fassen diese Pflichten als wiederholbare Prozesspflichten auf — nicht als Gewährleistung eines garantierten Einzelergebnisses.

API-Oberfläche

Nicht zutreffend. Die Offenlegung ist ein Prozess, keine API. Die maschinenlesbare Discovery-Fläche ist die Datei security.txt gemäß RFC 9116; Werkzeuge parsen ihre Felder Contact: und Expires:. Diese Seite gibt den Inhalt dieser Datei über die unten genannten Kanäle hinaus nicht nochmals wieder.

Codebeispiel — Schnellstart

Nicht zutreffend. Es gibt keinen Code, den Sie ausführen müssen, um eine Schwachstelle zu melden. Nutzen Sie einen privaten Kanal:

• GitHub Security Advisories (bevorzugt — im Ruhezustand verschlüsselt, mit Audit-Log): Erstellen Sie im GitHub-Security-Tab des Projekts einen Advisory-Entwurf.
• E-Mail: [email protected] mit [SECURITY] im Betreff. Wenn Sie Ende-zu-Ende-Verschlüsselung benötigen und in security.txt noch kein veröffentlichter OpenPGP-Schlüssel aufgeführt ist, verwenden Sie stattdessen den GitHub-Security-Advisory-Kanal.

Melden Sie Schwachstellen nicht über öffentliche Issues, öffentliche Mailinglisten, Social Media oder Chat. Eine öffentliche Offenlegung vor einem Fix gefährdet Nutzer ungepatchter Versionen.

Codebeispiel — Produktion

Nicht zutreffend.

Randfälle & Stolperfallen

• Zielwerte sind Zusagen, keine SLAs. Der unten stehende Zeitplan gibt an, was das Projekt anstrebt. Ein komplexes Problem, das mehrere Komponenten betrifft oder eine Upstream-Koordination erfordert, kann länger dauern; die meldende Person wird auf dem Laufenden gehalten.
• Die Embargo-Dauer ist verhandelbar, mit einer Obergrenze. Das Standard-Embargo läuft von der Triage bis zur Veröffentlichung des Fixes. Eine meldende Person, die mehr Zeit benötigt, muss dies beim Erstellen des Advisorys ausdrücklich anfragen. Nach Überschreiten des Maximums veröffentlicht das Projekt das Advisory unabhängig davon, ob ein Fix verfügbar ist, im Einklang mit den branchenüblichen Normen zur koordinierten Offenlegung — so werden Nutzer vor einem unbegrenzt zurückgehaltenen Advisory geschützt.
• Der Schweregrad bestimmt den Zeitplan. Ein kritisches, aktiv ausgenutztes Problem wird in einem verkürzten Zeitplan behandelt; ein Härtungsvorschlag mit niedrigem Schweregrad dagegen nicht. Der Schweregrad wird im Rahmen der Triage bewertet und kann angepasst werden.
• Die CVE-Vergabe ist Teil der Triage. Der Maintainer beantragt eine CVE über die GitHub-Security-Advisory-CNA-Registrierung des Projekts im Rahmen der Triage; die meldende Person muss keine separate CVE beantragen.

Performance

Nicht zutreffend.

Sicherheitshinweise

Die Zielwerte für den Reaktionszeitplan sind Zusagen an meldende Personen und bilden die Basis für die Schwachstellenbehandlung des Projekts. Es sind Zielwerte, keine Garantien:

Phase	Zielwert
Empfang bestätigen	innerhalb von 1–2 Werktagen
Erste Triage + Schweregradbewertung	innerhalb von ~5 Werktagen / 7 Kalendertagen
Patchentwicklung + private Prüfung	typischerweise 14 Werktage; 30–90 Tage für komplexe bestätigte CVEs, je nach Schweregrad
CVE-Zuweisung (falls angenommen)	parallel zum Patch, über den GitHub-CNA-Kanal
Koordinierte öffentliche Offenlegung	bei der Veröffentlichung des Patches, an einem gemeinsam mit der meldenden Person festgelegten Datum
Embargo (von der Triage bis zur Veröffentlichung)	standardmäßig ~90 Tage, bei aktiver Ausnutzung verkürzt, auf ausdrückliche Anfrage bis zu einem festen Maximum verlängerbar

Prüfbare Prozessregeln:

1. Privat zuerst. Kein öffentlicher Kanal ist ein akzeptierter Eingangskanal. Die einzigen akzeptierten Kanäle sind das GitHub Security Advisory und die Sicherheits-E-Mail.
2. Koordiniert, nicht einseitig. Der Zeitpunkt der Offenlegung wird mit der meldenden Person und allen mitbetroffenen Anbietern ausgehandelt (iso_iec_29147#x3.x110.p13).
3. Begrenztes Embargo. Das Embargo hat einen Standardwert und eine harte Obergrenze; ein Advisory wird nicht unbegrenzt zurückgehalten.
4. Nennung auf Wunsch. Forschende werden genannt, sobald das Embargo endet, es sei denn, sie wünschen Anonymität.

Diese Aussagen beschreiben den Prozess, zu dessen Einhaltung sich das Projekt verpflichtet. Sie garantieren nicht, dass eine bestimmte Meldung bis zu einem bestimmten Datum zu einem Fix, einer CVE oder einer Offenlegung führt.

Konformität

Kein Konformitätsprofil. Die Richtlinie ist auf ISO/IEC 29147 und ISO/IEC 30111 sowie die oben zitierten CRA/SSDF-Prozesspflichten abgestimmt; „abgestimmt auf“ ist eine bewusst gewählte Formulierung — das Projekt behauptet keine Zertifizierung nach einem dieser Schemata. Sie definieren, wie ein robuster Prozess aussieht; diese Seite dokumentiert die Zusage des Projekts, einen solchen zu betreiben.

Siehe auch

• Trust-Center
• Bedrohungsmodell der Engine
• Sicherheitsmodell für Signatur und Verschlüsselung
• Repository SECURITY.md und /.well-known/security.txt (RFC 9116)