Schwachstellen in Open-Source-Abhängigkeiten Security Alerts auf GitHub nutzen

GitHub bietet extrem praktische Sicherheitswarnungen für Abhängigkeiten und trägt so massiv zur Sicherheit in Open-Source-Projekten bei. Die Warnungen basieren auf öffentlich bekannten Sicherheitslücken und müssen zunächst aktiviert werden.

Anbieter zum Thema

PresseBox - unn | UNITED NEWS NETWORK GmbH

Windhoff Group

Gefährliche Abhängigkeiten

Abhängigkeiten sind bei Open-Source-Projekten ein großes Sicherheitsproblem, da viele Entwickler dazu neigen, sich zwar um den eigenen Code zu kümmern, bei genutzten Bibliotheken und anderen vorausgesetzten Tools aber auf deren Ersteller zu vertrauen. Mit den Security Alerts will GitHub gegensteuern – und das offensichtlich mit Erfolg.

Der Plattformbetreiber hat initial alle öffentlichen Repositories auf Sicherheitslücken geprüft, um einen Ausgangspunkt zu haben: GitHub spricht von vier Millionen gefundenen Lücken in 500.000 Repositories. Binnen einer Woche nach Start der Alerts wurde knapp die Hälfte dieser Anfälligkeiten behoben. Viele der übrigen Repos schienen verwaist oder nicht mehr gepflegt, da die letzten Beiträge über 90 Tage her waren.

Berücksichtigt wurden dabei allerdings nur Ruby- und Javascript-Projekte. Mittlerweile wird auch Python unterstützt, andere Sprachen sind (noch) außen vor. Projekte müssen also eine der unterstützten Sprachen nutzen, öffentlich sein und zu guter Letzt eine Liste mit Abhängigkeiten pflegen, die in bestimmten Dateien liegen dürfen. Die Alerts bauen auf dem Dependency Graph auf, der sich für private Repositories optional freischalten lässt.

Was meldet das System?

Derzeit melden die GitHub-Alarme öffentlich bekannte Sicherheitslücken, die einen CVE-Eintrag (Common Vulnerabilites and Exposures) erhalten haben. Das Programm soll noch weiterentwickelt werden, deckt mit den CVEs aber bereits einen sehr relevanten Teil ab.

Da das Alert-System auf den Dependency Graph aufgesetzt wird, finden sich die entsprechenden Alarme auch genau dort wieder. Erfreulicherweise zeigt das System aber eben nicht bloß die CVE, sondern auch eine kurze Beschreibung und die Bewertung nach dem Common Vulnerability Scoring System (CVSS), also die bekannte Einteilung in „Low, Moderate, High und Critical“, so dass Sie sofort sehen, wie ernst die Lage ist.

Richtig bequem macht GitHub die offensichtlichste aller Lösungen: Den Verweis auf eine aktuellere Version der betroffenen Abhängigkeit können Sie direkt mittels Ausschneiden und Einfügen in Ihre Abhängigkeitenliste aufnehmen. Selbstverständlich werden die CVEs auch direkt mit ihren Einträgen in der National Vulnerability Database (NVD) vom Mitre verlinkt, wo sich detaillierte Informationen finden.

Alerts aktivieren

Alerts müssen in einigen Fällen zunächst noch eingerichtet werden. Bei öffentlichen Repositories ist der Dependency Graph standardmäßig aktiviert, bei privaten Repos muss dieser zunächst freigeschaltet werden. Das erledigen Sie in dem betroffenen Repo selbst unter „Insights/Dependency Graph“.

Dann benötigen Sie eine Liste mit Abhängigkeiten, die Sie über folgende Varianten/Dateien pflegen können: Gemfile, Gemfile.lock, *.gemspec, package.json, package-lock.json, requirements.txt, pipflie.lock. Für Python wird explizit auf die „requirements.txt“ verwiesen, eine „setup.py“ könnte Probleme verursachen. Bei den Dateien handelt es sich um schlichte Textdateien, bei Ruby etwa mit Einträgen in der Art gem "my-dependency", "= 1.5.0".

Zu guter Letzt müssen Sie noch einstellen, wie und wo Sie an die Alerts kommen. Die Einstellungen finden Sie unter „Settings/Notifications“. Zum einen gibt es Optionen für die Ansicht in der GitHub-Oberfläche und zum anderen zwei E-Mail-Dienste: Die Benachrichtigung für jede gefundene Sicherheitslücke und/oder eine tägliche oder wöchentliche Zusammenfassung. Wer das volle Programm haben will, muss hier nachjustieren. Übrigens: In GitHub Desktop sind die Alerts leider nicht zu sehen.

Mit Alerts arbeiten

Die eigentliche Frage ist aber, wie man nun mit dem GitHub-System in der Praxis arbeitet. Möchte man sich das Ganze aber mal in Aktion ansehen, stellt man schnell fest, dass offenbar schon viel gesäubert wurde – ein Repo mit der richtigen Sprache und einer gefährdeten Abhängigkeit zu finden ist ohne weitere Informationen gar nicht möglich.

Am schnellsten geht es, wenn Sie schlicht selbst eine Meldung provozieren. Eröffnen Sie einfach ein leeres Repository und legen Sie eine Datei „gemfile“ mit folgendem Inhalt an: „gem "actionview", "= 4.2.5".

Um den Alert zu sehen, haben Sie, sofern alle Ansichtsoptionen aktiviert sind, mehrere Möglichkeiten, die Alarmmeldung zu sehen: Zum einen als Banner direkt oberhalb der gemfile-Datei und zum anderen in der Dependency-Graph-Ansicht; dort sowohl als Banner als auch direkt im Abhängigkeitsbaum.

Im vorangestellten Bild sehen Sie bereits die Details einer gefundenen Schwachstelle. Neben CVE-Link und CVSS-Score, hier „Moderate severity“, gibt es hier auch eine empfohlene Lösung, nämlich das Updaten der gemfile-Datei mit „gem actionview ~> 4.2.7.1“, also einer aktuelleren Version der bedingten Software. Die Angabe „~>“ steht hier für „Pessimistically Greater Than or Equal To“, sprich Ihr Projekt würde mit jeder Version ab 4.2.7.1 und unterhalb von 4.2.8.0 laufen.

Natürlich steht diese Option nicht immer zur Verfügung. Sofern es keine aktuelleren, gepatchten Versionen der benötigten Abhängigkeit gibt, empfiehlt GitHub, auf eine sichere Alternative aus dem GitHub-Universum zu wechseln – wenn das doch nur immer so einfach wäre.

Auch führt GitHub eine allgemeine Vorgehensweise zum Umgang mit den Alerts auf, diese ist im Grunde aber wenig Security-Alert-spezifisch, eher ein allgemeiner Workflow für Sicherheitsvorfälle. Kurz gesagt: CVE lesen, prüfen, wie genau die Abhängigkeit genutzt wird, Dokumentation der Abhängigkeit lesen, gegebenenfalls updaten und prüfen, ob die Schwachstellen in Ihrem Projekt dadurch behoben wurde. Anschließend folgt – natürlich – das übliche Verschmelzen und gegebenenfalls Versionieren der Änderungen.

Durchaus interessant ist jedoch die empfohlene Kommunikation, schließlich wird nicht jeder Entwickler die Alerts immer im Auge haben. Zum einen sollten Sie alle Projektbeteiligten über die Änderungen und die Schwachstelle informieren, zum anderen aber auch die Projekte, die wiederum Ihr Projekt als Abhängigkeit nutzen. Hier dürften insbesondere Informationen zu etwaigen Inkompatibilitäten benötigt werden.

Und noch eine Gruppe sollten Sie nicht vergessen: Die Forks. Gerade bei weidlich genutzten Bibliotheken können sich die Alerts nur dann auf die breite Masse der produktiv eingesetzten Implementierungen auswirken, wenn der Informationsfluss auch wirklich bis in die hinterste Ecke fließt. Sicherheit lässt sich eben nicht immer, und schon gar nicht in der Open-Source-Welt, zentral ausrollen. Hier ist durchaus jeder Entwickler aufgerufen auch über Kommunikation für Sicherheit zu sorgen.

Konzept mit Potenzial

Die Security Alerts sind definitiv eine feine Sache und es kann nur jedem Entwickler empfohlen werden, diese Funktion zu aktivieren und aktiv zu nutzen. Die Umsetzung ist erfreulich einfach und hilfreich und verursacht keinen großen Overhead. Wenn man einmal von den vielen Stunden absieht, die künftig für das Beheben oder Mitigieren von Schwachstellen drauf gehen, die man ohne die Alerts niemals bemerkt hätte.

Das Projekt ist noch recht jung, kein Jahr in der Welt, und hat noch Potenzial nach oben. Zunächst wären natürlich weitere Sprachen wünschenswert. Auch eine Aufnahme im GitHub Desktop wäre nett. Im Dependency Graph gibt es wie vorne zu sehen noch eine obskure Ordner-Endlosschleife, die nicht wirklich sinnvoll wirkt.

Eines gibt es aber nicht: Informationen für die Öffentlichkeit. Der Dependency Graph ist auch für nicht zum Repository gehörende User zu sehen, die Alerts sind es nicht. Freilich gibt es gute Gründe dafür, doch zumindest optional wäre es eine Überlegung wert; beispielsweise, um Nutzer bei Programmen zu informieren, die zwar noch laufen und genutzt, aber nicht mehr gepflegt werden.

(ID:45512242)