Was ist die beste Vorgehensweise beim Umgang mit PRs zur Behebung von Sicherheitslücken im öffentlichen Repo?

Wie sollte ein Open-Source-Projekt mit einem öffentlichen Repository Pull-Requests (PRs), die sicher gemeldete, aber noch nicht öffentlich gemeldete Sicherheitslücken beheben, am besten handhaben?

Ich bin an einem Open-Source-Projekt mit mehreren hundert Mitwirkenden beteiligt. Im Rahmen einer regelmäßig geplanten monatlichen Veröffentlichung veröffentlichen wir mehrmals im Jahr Sicherheitshinweise und Sicherheitslücken. Informationen zu den Sicherheitslücken werden erst veröffentlicht, wenn die gepatchte Version verfügbar ist. Wir sind in der Lage, Sicherheitsprobleme in unserem Projektmanagementsystem (JIRA) sicher zu verwalten. Wir haben jedoch keinen guten Prozess, um die PRs zu verdecken, mit denen Sicherheitslücken behoben werden, wenn sie an GitHub gesendet werden. Wir sind besorgt, dass Benutzer diese Fixes finden können, bevor sie veröffentlicht werden, und Zero-Day-Exploits erstellen.

Wir haben überlegt, private Repos zu verwenden, die das Hauptrepo bilden, aber ein Großteil unseres aktuellen Überprüfungs- und Qualitätssicherungs-Workflows findet in den PRs statt. Wenn wir den Workflow auf ein privates Repo des Sicherheitsteams verlagern würden, würde dies das Fenster verkleinern, wenn der Fix bis zu den Stunden öffentlich ist, die benötigt werden, um die Tarballs zu generieren und auf SourceForge zu veröffentlichen, was eine große Verbesserung wäre. Wir müssten wahrscheinlich auch vermeiden, die PRs in unsere öffentliche Beta zu integrieren.

Bevor ich in diese Richtung gehe, möchte ich wissen, was die beste Vorgehensweise für den Umgang mit Patches zur Fehlerbehebung vor dem Release in Open Source-Projekten mit Open Repos ist. Wenn das Problem besser gelöst werden kann, indem eine andere Plattform als GitHub verwendet wird, sollte erwähnt werden, dass die Migration auf GitLab evaluiert wird.

— Joe Murray
quelle

Ich bin nicht sicher, ob es eine bewährte Methode gibt. GitLab ist im Wesentlichen ein privater GitHub. Es ist nicht einfach, die Probleme mit Open Source- und Sicherheitsupdates in Einklang zu bringen. Wie viele Ihrer Sicherheitsupdates stammen von Personen, die nicht zu Ihrem Sicherheitsteam gehören?

— Berin Loritsch

Die meisten Probleme werden von anderen gemeldet, aber wahrscheinlich stammt weniger als ein Fünftel der Korrekturen von Personen, die nicht zum Sicherheitsteam gehören.

— Joe Murray

Meiner Meinung nach sollte ein Teil Ihres Prozesses, der privat sein soll, außerhalb von GitHub erfolgen (da GH öffentlich ist). nachdem dieser spezifische Teil erledigt ist und jeder seinen Code überprüft hat; Sie können eine PR auf GH erstellen, die so schnell wie möglich zusammengeführt wird, um zum offiziellen Prozess zurückzukehren. Sie können ein anderes Tool verwenden, um diese Ausnahmen im Prozess zu verwalten.

— Emerson Cardoso

Eine vollständige sofortige Offenlegung (dh unverzügliche Offenlegung in der Öffentlichkeit) ist absolut legitim.

— Miles Rout

Diese Frage scheint davon auszugehen, dass das Sicherheitsproblem der Welt unbekannt ist, solange es nicht vom Team offengelegt wird. Das stimmt einfach nicht; Jedes entdeckte Sicherheitsproblem sollte von jemandem mit bösen Absichten irgendwo als bekannt angesehen werden. Wenn Sie nun davon ausgehen, dass jemand anderes das Problem bereits kennt und es möglicherweise ausnutzt, können Sie die Veröffentlichung des Updates nicht mehr auf Ihre reguläre monatliche Veröffentlichung verschieben. Sie müssen ASAP freigeben. Das bedeutet, dass es kein Problem gibt, dem regulären PR-Fluss zu folgen. Nur PR gegen den neuesten Release-Zweig, Merge, Tag, Release.

— Jory Geerts

Das Protokoll hierfür besteht darin, die Risikofaktoren für das öffentliche Aufzeigen von Schwachstellen zu bestimmen. Aus Sicherheitsgründen müssen sich diese PRs in einem privaten Repo befinden, das nur Ihr Sicherheitsteam sehen kann. Dies gilt unabhängig von der Plattform, auf der Sie Pull-Requests erstellen und ausführen.

— Lloyd Moore
quelle