Die CNCF veröffentlichte am 7. September 2026 eine Leitkarte mit dem Titel „Umgang mit Schwachstellenmeldungen“ (Handling vulnerability reports: Recipe card). Sie richtet sich an kleine und mittlere Open-Source-Projekte, deren Schwerpunkt nicht hauptsächlich auf Sicherheit liegt. Erstellt wurde das Material von Marina Moore von Edera, der Co-Vorsitzenden von TAG Security, und Sherine Khoury von Red Hat, einer Leiterin von TAG Security.
Die zentrale Idee des Leitfadens besteht darin, den zusätzlichen Aufwand für Maintainer und Nutzer zu verringern und zugleich zu verhindern, dass eine Sicherheitsmeldung zu einer öffentlichen Diskussion wird, bevor die Behebung bereitsteht. Die CNCF erklärt, dass eine Sicherheitslücke ein Fehler ist, der ausgenutzt werden kann, um die Vertraulichkeit, Integrität oder Verfügbarkeit eines Systems zu beeinträchtigen. Nicht jeder Softwarefehler ist jedoch ausnutzbar oder wird als Schwachstelle eingestuft.
Mit einem klaren und privaten Meldekanal beginnen
Die Leitlinien empfehlen, in der Datei README.md einen klaren und leicht auffindbaren Sicherheitsbereich einzurichten und die Anweisungen entweder direkt in dieser Datei bereitzustellen oder auf eine Datei SECURITY.md im Stammverzeichnis des Repositorys zu verweisen. Ziel ist es, Forschende zu einem privaten Prozess zu führen, anstatt die Problemdetails in einem öffentlichen Issue zu veröffentlichen, das jeder lesen kann.
Die Meldeanweisungen sollten mehrere Elemente erläutern, darunter das Bedrohungsmodell oder die Mindestanforderungen dafür, dass eine Meldung als Schwachstelle gilt, den Übermittlungsort, das Format der Meldung, die voraussichtliche Dauer bis zur Prüfung und den ungefähren Zeitraum bis zur Offenlegung. Dafür kann der private Schwachstellenmeldeprozess von GitHub oder eine private Mailingliste verwendet werden. Ein Bug-Bounty-Programm ist für kleine und mittlere Projekte nicht verpflichtend, wenn sie nicht über die Kapazitäten verfügen, ein solches zu betreiben.
Die Art der Meldung prüfen, bevor sie als Schwachstelle behandelt wird
Nach Eingang der Meldung sollte zunächst festgestellt werden, ob sie tatsächlich auf eine ausnutzbare Schwachstelle hinweist oder auf einen nicht ausnutzbaren Fehler, ein Missverständnis des erwarteten Verhaltens oder einen Dokumentationsfehler. Die CNCF schlägt vor, die Meldung mit ihrem Verfasser und den geeigneten Experten des Projekts zu besprechen. Dabei sollte die Zahl der Beteiligten begrenzt bleiben und sich alle bis zur Veröffentlichung der Meldung zur Vertraulichkeit verpflichten.
Zu den praktischen Fragen, die gestellt werden können, gehören: Gibt es eine für die Nutzer verfügbare Abhilfemaßnahme? Kann der Fehler zu einem Einbruch, einem Datenleck oder einer anderen schädlichen Aktivität führen? Liegt das Problem ausschließlich in der Dokumentation? Wenn sich herausstellt, dass die Meldung keine Schwachstelle betrifft, kann ihr Verfasser dazu aufgefordert werden, ein öffentliches Issue zu erstellen. Bei Bedarf sollten geeignete Veröffentlichungsverfahren eingesetzt werden, um die Nutzer zu informieren.
Im Fall von Unsicherheit weisen die Leitlinien auf die Möglichkeit hin, bei TAG Security and Compliance oder CNCF-Mitarbeitern um Orientierung zu bitten, wobei die Einzelheiten der Meldung außerhalb öffentlicher Kanäle bleiben müssen. Außerdem sollten die Teilnehmer der vertraulichen Sperrfrist sorgfältig ausgewählt werden. Es sollten nur Personen einbezogen werden, die tatsächlich Unterstützung bei der Lösung benötigen, damit die Information nicht vor der Bereitstellung der Korrektur an Angreifer durchsickert.
Die Behebung entwickeln und abseits der Öffentlichkeit testen
Die CNCF warnt davor, den Patch in einem öffentlichen Pull Request zu veröffentlichen oder zu diskutieren, da dadurch die Art der Schwachstelle offengelegt werden könnte, bevor die Nutzer Gelegenheit zur Aktualisierung haben. Wird der private Meldeprozess von GitHub verwendet, kann ausgehend von der Meldung ein privater Branch erstellt werden. Andernfalls kann die Korrektur über einen privaten Kanal entwickelt und geprüft werden.
Die Korrektur muss getestet werden, selbst wenn die übliche Continuous-Integration-Umgebung mit privaten Branches nicht funktioniert. In diesem Fall können die Tests nach Einschätzung der Maintainer und abhängig vom Umfang der Änderung lokal durchgeführt werden. Nachdem sichergestellt wurde, dass die Korrektur das Problem behebt und die Tests ausreichend sind, empfehlen die Leitlinien, sie schnell zu integrieren und genügend Maintainer an ihrer Erstellung und Prüfung zu beteiligen. Vor der öffentlichen Veröffentlichung sollte der Code erneut geprüft und bestätigt werden, dass die Schwachstelle tatsächlich geschlossen wurde.
Die Veröffentlichung mit der CVE-Offenlegung koordinieren
Nach Abschluss der Korrektur betrachtet die CNCF eine Offenlegung innerhalb von 90 Tagen nach Eingang der Meldung als gängige Praxis. Wenn die Ressourcen des Projekts dies erlauben, kann es eine private Liste von Nutzern vorab informieren. Die Pflege einer aktuellen Kontaktliste stellt jedoch eine Belastung dar, die die meisten kleinen Projekte nicht tragen können.
Daher schlägt die Leitkarte einen einfacheren Ansatz vor: Die Veröffentlichung mit der Korrektur und die Bekanntgabe der Schwachstelle sollen gleichzeitig erfolgen, damit die Nutzer die Behebung erhalten, sobald das Problem angekündigt wird. Dafür muss unmittelbar nach der Einbringung der Korrektur eine neue Version erstellt und anschließend eine CVE veröffentlicht werden. Wird der private GitHub-Mechanismus verwendet, kann dies über die GitHub-Oberfläche erfolgen.
Eine CVE-Nummer muss von einer CNA, also einer CVE-Nummerierungsstelle, vergeben werden. GitHub ist eine dieser Stellen und kann den Vorgang durchführen. Das Projekt und der Forschende können außerdem direkt mit einer der aufgeführten CNA-Stellen Kontakt aufnehmen. Der Schweregrad der CVE wird anhand einer Reihe von Fragen bestimmt. Das Projekt sollte mit dem Forschenden zusammenarbeiten, um die Richtigkeit der Antworten sicherzustellen und sich auf den zugewiesenen Schweregrad zu einigen.
Warum sind diese Leitlinien wichtig?
In der Praxis verlagert die Leitkarte die Verantwortung für die Verwaltung einer Schwachstelle von einer zufälligen Reaktion auf einen umsetzbaren Ablauf: ein privater Kanal, eine begrenzte Prüfung, eine nicht öffentliche Korrektur und anschließend eine koordinierte Veröffentlichung und Offenlegung. Nach der Veröffentlichung der CVE erscheinen die Informationen in OSV und anderen Schwachstellendatenbanken. Dadurch können die Prüfwerkzeuge der Nutzer erkennen, dass eine Aktualisierung erforderlich ist.
Der Geltungsbereich des Rezepts ist jedoch klar begrenzt: Es richtet sich an kleine und mittlere Projekte, die nicht auf Sicherheit spezialisiert sind, und ist kein Ersatz für ein komplexeres Programm für Projekte mit hohem Risiko oder besonderer Sicherheitsrelevanz. Die CNCF empfiehlt außerdem, darüber nachzudenken, einige Zeit nach der Bereitstellung der Korrektur einen Proof of Concept zu veröffentlichen, um den Nutzern eine zusätzliche Gelegenheit zur Aktualisierung zu geben. Zugleich wird eingeräumt, dass dies bei Verwendung des privaten Meldeprozesses schwierig sein kann.