Schwachstellen-Offenlegung im Open-Source-Umfeld Wie Entwickler und Sicherheitsforscher interagieren

Wie arbeiten Open-Source-Entwickler und Sicherheitsforscher bei der Vulnerability Disclosure, also der Offenlegung von Sicherheitslücken zusammen? GitHub hat aus Eigennutz genau diese Frage gestellt, teilt die Ergebnisse nun aber mit der Allgemeinheit.

Anbieter zum Thema

Insider Research

Confluent Germany GmbH

Um die Prozesse in den GitHub Security Labs zu verbessern, hat GitHub zwischen November 2020 und März 2021 zahlreiche Remote-Interviews mit Open-Source-Betreuern geführt. Kernfrage war, wie die beiden Gruppen bei der Offenlegung von Schwachstellen interagieren.

Die Mehrheit der Projektbetreuer erklärte dabei, dass sie wenig bis gar keinen Kontakt zur Community der Sicherheitsforscher hätten. Etliche Teilnehmer bezeichneten sich hinsichtlich ihres Security-Engagements als passiv oder als reine Informationsempfänger. Fernab der Schwachstellenberichte gibt es aber zumindest einige Maintainer, die sich über Twitter, Slack, Discord und im persönlichen Gespräch mit Security-Spezialisten austauschen.

Auf die Frage hin, welche Ressourcen die Security-Teams bereitstellen sollten, wünschten sich die Teilnehmer grundlegende Informationen oder Einsteiger-Inhalte. Die Schwerpunkte lagen dabei auf gängigen Schwachstellen, Problemen und Anfälligkeitsmustern, Leitfäden für Sicherheitsforscher und Informationen über Arbeitsabläufe, die Funktionsweise von Security-Prozessen und das Auffinden von Bugs.

Im Allgemeinen empfanden die Open-Source-Betreuer ihre Interaktion mit Sicherheitsforschern als positiv oder angenehm waren. Doch das war nicht immer der Fall. Je nach Forscher beklagten einige die Kommunikation als „sehr undurchsichtig“ oder sprachen von „sehr unterschiedlichen“, also eher durchwachsenen Erfahrungen.

Der Umgang mit Schwachstellen-Meldungen

Die meisten Projektbetreuer bevorzugen es, dass ihnen Schwachstellenberichte privat übermittelt werden. Die Mehrheit der Maintainer stellt deshalb auch einen eindeutigen Sicherheitskontakt per E-Mail bereit. Die meisten haben jedoch noch keinen Sicherheitsleitfaden etabliert und wollen entweder einen einführen oder arbeiten gerade aktiv daran.

Bei einem eingehenden Bericht schauen viele Entwickler erst einmal, ob die Sicherheitslücke eine Remote Code Execution ermöglicht, da eine solche einen hohen Schweregrad impliziert. Darüber hinaus sehen sich die Maintainer Codeausschnitte und reproduzierbare Schritte an. Zwingend erwarten würden sie Abhilfemaßnahmen von den Sicherheitsforschern zwar nicht, in Ermangelung an Zeit empfinden sie diese aber als äußerst hilfreich.

Mit Blick auf übliche 90-tägige Frist bis zur Fehler-Veröffentlichung meinten die meisten Betreuer, dass sie dies für eine vernünftige, gute oder faire Zeitspanne hielten. Jedoch wünschen sich viele Betreuer auch mehr zeitliche Flexibilität und einen kooperativeren Prozess bei der Festlegung des Zeitrahmens.

Weitere Informationen zur Developer-Sicherheitsforscher-Interaktion im GitHub-Blog.

(ID:47643631)