Nach Eingang eines Schwachstellenberichts: bestätigen, bewerten, privat beheben, offenlegen

Ziel

Aus einem privaten Bericht ein behobenes Release und ein öffentliches Advisory machen, ohne dass Details durchsickern, bevor Nutzende aktualisieren können, und ohne dass der meldenden Person die Geduld ausgeht und sie zuerst veröffentlicht.

Voraussetzungen

Ein Meldekanal, der bereits veröffentlicht ist (security.txt oder eine verlinkte SECURITY-Datei); ein privater Ort, um einen Fix zu entwickeln (ein temporärer privater Fork oder ein privater Advisory-Entwurf); die Liste der Personen, die ein Release veröffentlichen dürfen; und im Idealfall ein im Voraus identifizierter Kontakt bei einer CVE Numbering Authority, wie es der OpenSSF-Leitfaden empfiehlt. Der OpenSSF-Leitfaden hält fest, dass in einem kleinen Projekt mit ein bis fünf Maintainern die Maintainer selbst das Vulnerability-Management-Team sein können.

Schritte

1. Den Eingang bestätigen, bevor irgendetwas bewertet wird. Der OpenSSF-Leitfaden verlangt dies rasch, innerhalb von ein bis zwei Tagen; GitHubs Hinweise sagen dasselbe und fügen hinzu, dass dies den Ton für den weiteren Austausch setzt.
2. Anhand der von der meldenden Person angegebenen Schritte und Versionen bewerten. Die Klassifizierung des Leitfadens: wie vorgesehen, gewöhnlicher Bug, Feature-Wunsch oder Schwachstelle, wobei eine Schwachstelle Vertraulichkeit, Integrität oder Verfügbarkeit gefährdet. Der meldenden Person das Ergebnis und die Begründung mitteilen; ein Hinweis auf eine mögliche Härtung ist keine Schwachstelle und kann als gewöhnliches Issue weitergeführt werden.
3. Eine Embargofrist vereinbaren. Der Leitfaden hält fest, dass meldende Personen üblicherweise selbst eine Frist nennen, dass 90 Tage die längste Standardfrist ist, die von den dort genannten Gruppen akzeptiert wird, und dass laufende Kommunikation entscheidend dafür ist, ob meldende Personen bereit sind, sie zu verlängern.
4. Den Fix privat entwickeln und testen; jede betroffene Version identifizieren und festlegen, welche unterstützten Versionslinien den Fix erhalten. Den Patch minimal halten, damit die Aktualisierung einfach bleibt; keine API-Änderungen mitbündeln.
5. Über die CNA eine CVE-Kennung reservieren und die Beschreibung entwerfen. Die meldende Person fragen, ob und wie sie genannt werden möchte; der Leitfaden bezeichnet es als unangemessen, die Nennung wegzulassen, ausser die meldende Person lehnt sie ab.
6. Einen Release-Tag wählen, an dem Personen während der Arbeitszeit aktualisieren können; der Leitfaden schlägt Montag bis Mittwoch vor und rät, weithin beachtete Feiertage zu meiden.
7. Veröffentlichen, dann das Advisory publizieren: betroffene Versionen, behobene Versionen, allfälliger Workaround, Nennung. GitHubs Hinweise betonen, das Release ausdrücklich als Sicherheits-Fix zu kennzeichnen, damit nachgelagerte Konsumenten es bemerken.
8. Den Zeitverlauf (Meldung, Bestätigung, Fix, Offenlegung) für die nächste Überprüfung des Prozesses festhalten.

Erwartetes Ergebnis

Die meldende Person erhält bei jedem Schritt datierte Antworten; Nutzende erfahren gleichzeitig aus dem eigenen Advisory des Projekts und einem behobenen Release von dem Problem.

Grenzen und Prüfbasis

Schritte und Zeitfenster stammen aus den zitierten Leitfäden; es wird kein Vorfall beschrieben und keine Zeit gemessen. Projekte mit Distributoren brauchen unter Umständen eine Embargoliste, was der OpenSSF-Leitfaden als optional und aufwendig einstuft.

Das Advisory zusammen mit dem Release veröffentlichen

Sobald der Fix in einen öffentlichen Branch gepusht wird, legt der Diff die Schwachstelle gegenüber jedem offen, der Commits liest, und bei einer Bibliothek ist es das veröffentlichte Advisory, das Warnungen von Dependency-Scannern in nachgelagerten Projekten auslöst. Das Advisory während der privaten Fix-Phase vollständig schreiben: betroffene Versionen, behobene Versionen, Workaround, Nennung wie mit der meldenden Person vereinbart. Dann Release und Advisory als einen Schritt veröffentlichen, höchstens Minuten auseinander, am besten aus einem einzigen Skript, das taggt, das Paket hochlädt und das Advisory publiziert. Die einzige Reihenfolge-Bedingung: Das Advisory darf keine behobene Version nennen, bevor diese installierbar ist.