Skip to main content

Informationen zur koordinierten Offenlegung von Sicherheitsrisiken

Die Offenlegung von Sicherheitsrisiken ist eine koordinierte Anstrengung zwischen den Erstellern von Sicherheitsberichten und Maintainern des Repositorys.

Informationen zur Offenlegung von Sicherheitsrisiken in der Branche

Die Aufdeckung von Sicherheitsrisiken ist ein Bereich, in dem die Zusammenarbeit zwischen denjenigen, die Sicherheitsrisiken melden, z. B. Sicherheitsforscher, und den Projektbetreuern sehr wichtig ist. Beide Parteien müssen zusammenarbeiten, und zwar von dem Moment an, in dem eine potenziell gefährliche Sicherheitslücke gefunden wird, bis zu dem Zeitpunkt, an dem die Schwachstelle öffentlich gemacht wird, idealerweise mit einem entsprechenden Patch. Wenn ein Projektbetreuer privat über ein Sicherheitsrisiko informiert wird, entwickelt er in der Regel einen Fix, prüft ihn und benachrichtigt die Benutzer des Projekts oder Pakets.

Der erste Bericht eines Sicherheitsrisikos wird privat erstellt. Die vollständigen Details werden erst veröffentlicht, nachdem der oder die Maintainer*in das Problem bestätigt und idealerweise Korrekturen oder einen Patch verfügbar gemacht hat. Diese Veröffentlichung erfolgt in manchen Fällen mit Verzögerung, um mehr Zeit für die Installation der Patches einzuräumen. Weitere Informationen findest du auf der Website der OWASP Cheat Sheet Series im Abschnitt zur Offenlegung von Sicherheitsrisiken.

Bewährte Methoden für Melder*innen von Sicherheitsrisiken

Es empfiehlt sich, Sicherheitsrisiken privat an Maintainerinnen zu melden. Als Melderin eines Sicherheitsrisikos solltest du nach Möglichkeit Folgendes vermeiden:

  • Öffentliche Offenlegung des Sicherheitsrisikos, ohne Maintainer*innen eine Möglichkeit zur Behebung einzuräumen
  • Umgehen der Maintainer*innen
  • Offenlegung des Sicherheitsrisikos, bevor eine korrigierte Codeversion verfügbar ist
  • Erwarten einer Vergütung für das Melden eines Problems, für das es kein öffentliches Bounty-Programm gibt

Melderinnen von Sicherheitsrisiken dürfen Sicherheitsrisiken nach einer bestimmten Zeit offenlegen, wenn sie versucht haben, die Maintainerinnen zu kontaktieren und keine Antwort erhalten haben oder wenn sie sie kontaktiert haben und gebeten wurden, mit der Offenlegung zu lange zu warten.

Melderinnen von Sicherheitsrisiken wird empfohlen, die Bedingungen der Offenlegung bei der Berichterstattung klar anzugeben. Selbst wenn Melderinnen sich nicht an eine strenge Vorgehensweise halten, sollte der zeitliche Horizont einer geplanten Offenlegung der Sicherheitsrisiken Maintainer*innen klar vermittelt werden. Ein Beispiel für eine Offenlegungsstrategie findest du auf der Website von GitHub Security Lab unter Offenlegungsstrategie von Security Lab.

Bewährte Methoden für Maintainer*innen

Als Maintainerin solltest du klar angeben, wie und wo du Berichte zu Sicherheitsrisiken erhalten möchtest. Wenn diese Informationen nicht klar verfügbar sind, wissen Melderinnen von Sicherheitsrisiken nicht, wie sie dich kontaktieren können, und extrahieren möglicherweise die E-Mail-Adressen von Entwickler*innen aus Git-Commitverläufen, um auf diese Weise eine geeignete Kontaktperson zu finden. Dies kann zu Spannungen, verlorenen Berichten oder zur Veröffentlichung ungelöster Berichte führen.

Maintainer*innen sollten Sicherheitsrisiken rechtzeitig offenlegen. Wenn dein Repository ein Sicherheitsrisiko aufweist, wird Folgendes empfohlen:

  • Behandle das Sicherheitsrisiko in deiner Antwort und Offenlegung nicht nur wie einen einfachen Fehler, sondern wie ein Sicherheitsproblem. Du musst z. B. explizit in den Versionshinweisen erwähnen, dass es sich bei dem Problem um ein Sicherheitsrisiko handelt.
  • Bestätige den Empfang des Sicherheitsberichts so schnell wie möglich, auch wenn unmittelbar keine Ressourcen für eine Untersuchung verfügbar sind. Dies sendet die Botschaft, dass du schnell reagierst und handelst, und es schafft eine positive Grundlage für die weitere Interaktion zwischen dir und dem oder der Melder*in des Sicherheitsrisikos.
  • Binde Melderinnen von Sicherheitsrisiken ein, wenn du die Auswirkungen und die Richtigkeit des Berichts überprüfst. Die Melderinnen haben das Sicherheitsrisiko wahrscheinlich bereits in verschiedenen Szenarios eingehender untersucht, von denen du einige möglicherweise noch nicht berücksichtigt hast.
  • Behebe das Problem so, wie du es für passend erachtest, und berücksichtige sorgfältig dabei alle Hinweise und Ratschläge der Melderinnen. Häufig kennen Melderinnen bestimmte Ausnahmefälle und Korrekturumgehungen, die ohne Sicherheitsforschungen leicht zu übersehen sind.
  • Würdige immer die Melder*innen von Sicherheitsrisiken in der Danksagung einer Entdeckung.
  • Versuche, Fixes so schnell wie möglich zu veröffentlichen.
  • Stelle sicher, dass du das weitläufigere Ökosystem auf das Problem und seine Behebung aufmerksam machst, wenn du das Sicherheitsrisiko offenlegst. Es kommt nicht selten vor, dass ein erkanntes Sicherheitsproblem im aktuellen Entwicklungsbranch eines Projekts behoben wird, während der Commit oder das nachfolgende Release nicht explizit als Sicherheitsfix oder Release markiert wird. Dies kann bei späteren Benutzer*innen zu Problemen führen.

Die Details eines Sicherheitsrisikos zu veröffentlichen, wirft kein schlechtes Licht auf Maintainerinnen. Sicherheitsrisiken gibt es in jeder Software, und Benutzerinnen vertrauen Maintainer*innen, die eine klare Vorgehensweise für die Offenlegung von Sicherheitsrisiken in ihrem Code etabliert haben.

Informationen zum Melden und Offenlegen von Sicherheitsrisiken in Projekten auf GitHub

Für GitHub stehen zwei Prozesse zur Verfügung:

  • Der Standardprozess: Melder von Sicherheitsrisiken setzen sich mit den Repositoryverwaltern in Verbindung, indem sie Kontaktinformationen verwenden, die sich in der Sicherheitsrichtlinie für das Repository befinden. Die Repositoryverwalter erstellen dann bei Bedarf eine Empfehlung für den Repositoryentwurf.
  • Privater Bericht zu Sicherheitsrisiken: Melder von Sicherheitsrisiken legen den Repositoryverwaltern direkt und privat Details zu Sicherheitsrisiken offen, indem sie eine Empfehlung für den Repositoryentwurf vorschlagen und Details zu ihren Ergebnissen bereitstellen.

Standardprozess

Der Prozess zum Melden und Offenlegen von Sicherheitsrisiken in Projekte auf GitHub lautet wie folgt:

Wenn du Sicherheitsexpertin bist (z. B. Sicherheitsforscherin) und ein Sicherheitsrisiko melden möchtest, überprüfe zunächst, ob für das entsprechende Repository eine Sicherheitsrichtlinie vorliegt. Weitere Informationen findest du unter Hinzufügen einer Sicherheitsrichtlinie für dein Repository. Ist eine Strategie vorhanden, befolge sie, um den Prozess zu verstehen, bevor du dich an das Sicherheitsteam für dieses Repository wendest.

Wenn keine Sicherheitsrichtlinie vorliegt, kann ein privater Kontakt zu Maintainerinnen am effizientesten hergestellt werden, indem du ein Issue erstellst und nach einem bevorzugten Sicherheitskontakt fragst. Dabei solltest du beachten, dass das Issue umgehend öffentlich sichtbar ist. Daher sollte es keine Informationen über den Fehler enthalten. Sobald der Kontakt hergestellt wurde, kannst du den Maintainerinnen vorschlagen, eine für die Zukunft Sicherheitsrichtlinie zu definieren.

Note

Nur für npm: Wenn uns Schadsoftware in einem npm-Paket gemeldet wird, versuchen wir, dich privat zu kontaktieren. Wenn du das Problem nicht rechtzeitig behebst, werden wir es offenlegen. Weitere Informationen findest du in der npm-Dokumentation unter Melden von Schadsoftware in einem npm-Paket.

Wenn Sie ein Sicherheitsrisiko in GitHub gefunden haben, melden Sie es über unseren koordinierten Offenlegungsprozess. Weitere Informationen findest du auf der Website Bug-Bounty-Programm von GitHub Security.

Wenn du Maintainerin bist, kannst du den Pipelineprozess von Anfang an gestalten und eine Sicherheitsrichtlinie für dein Repository einrichten oder andere Anweisungen für das Melden von Sicherheitsrisiken klar verfügbar machen, z. B. in der README-Datei deines Projekts. Informationen zum Hinzufügen einer Sicherheitsrichtlinie findest du unter Hinzufügen einer Sicherheitsrichtlinie für dein Repository. Wenn keine Sicherheitsrichtlinie vorliegt, werden Melderinnen wahrscheinlich versuchen, dich per E-Mail oder auf anderem Wege privat zu kontaktieren. Stattdessen können Melder*innen auch ein (öffentliches) Issue mit Details eines Sicherheitsproblems öffnen.

Um ein Sicherheitsrisiko in deinem Code offenzulegen, musst du als Maintainerin zunächst eine Sicherheitswarnung im Paketrepository in GitHub erstellen. Mithilfe von Sicherheitsempfehlungen für Repositorys können Verwalterinnen von öffentlichen Repositorys ein Sicherheitsrisiko in einem Projekt privat besprechen und beheben. Nach der Zusammenarbeit an einer Lösung können Repositoryverwalter die Sicherheitsempfehlung veröffentlichen, um das Sicherheitsrisiko öffentlich für die Community des Projekts offenzulegen. Durch die Veröffentlichung von Sicherheitsempfehlungen erleichtern Repositoryverwalter ihrer Community das Aktualisieren von Paketabhängigkeiten und das Untersuchen der Auswirkungen von Sicherheitsrisiken. Weitere Informationen findest du unter Informationen zu Sicherheitsempfehlungen für Repositorys.

Weitere Informationen zu den ersten Schritten findest du unter Erstellen einer Sicherheitsempfehlung für ein Repository.

Privater Bericht zu Sicherheitsrisiken

Besitzer und Administratoren öffentlicher Repositorys können das private Melden von Sicherheitsrisiken für ihre Repositorys aktivieren. Weitere Informationen findest du unter Konfigurieren der Meldung privater Sicherheitsrisiken für ein Repository.

Die private Berichterstattung zu Sicherheitsrisiken bietet eine einfache Möglichkeit für Sicherheitsrisikoberichterstatter, Sicherheitsrisiken für Repositoryverwalter innerhalb von GitHub privat offenzulegen, und zwar auf eine Weise, die die Repositoryverwalter sofort über das Issue benachrichtigt. Weitere Informationen für Sicherheitsforscher und Repositoryverwalter findest du unter Privates Melden eines Sicherheitsrisikos bzw. Verwalten privat gemeldeter Sicherheitsrisiken.

Note

Wenn für das Repository, das das Sicherheitsrisiko enthält, keine private Sicherheitsrisikoberichterstattung aktiviert ist, müssen sowohl Sicherheitsforscher als auch Repositoryverwalter die im Abschnitt Standardprozess oben beschriebenen Anweisungen befolgen.