Github spürt für Entwickler nun auch Sicherheitslücken auf
Die Plattform setzt damit den kürzlich mit der Einführung des Dependency Graph eingeschlagenen Weg fort. Der zeigt – bislang für Javascript und Ruby – Abhängigkeiten des eigenen Codes von anderer Software ab. Nun erhalten Entwickler Benachrichtigungen, wenn in einem dieser Programme eine Schwachstelle gefunden wurde.
Github bietet Nutzern seines vor einigen Wochen eingeführten Dependency Graph nun auch automatische Alarme zu neuen Sicherheitslücken in der von ihnen verwendeten Software. Mit dem Dependency Graph soll Entwicklern insbesondere dabei geholfen werden, den Überblick über die von ihnen verwendeten Open-Source-Komponenten zu behalten. Aktuell unterstützt die Plattform die Erkennung von integriertem Code bei Javascript und Ruby. Für Python soll das im Laufe des Jahres 2018 möglich werden.
Nach Angaben von Github bestehen bei drei Vierteln der dort laufenden Projekte Abhängigkeiten von anderem Code. Die zu kennen und berücksichtigen zu können, ist auch aber nicht nur zur korrekten Lizenzierung erforderlich, sondern auch um über mögliche Funktionsänderungen auf dem Laufenden zu bleiben. Ebenso wichtig ist es aber auch, dass über diese verwendeten Komponenten keine Sicherheitslücken in den eigenen Code eingeschleust werden oder bereits bekannte Sicherheitslücken dort nicht geschlossen werden.
Ein anschauliches Beispiel für die Bedeutung sind die im September geschlossenen Sicherheitslücken in Samba. Da Samba auch in diversen anderen Programmen verwendet wird, mussten auch zahlreiche Produkte von Red Hat sowie Ubuntu Linux, Debian Linux und Oracle Linux aktualisiert werden.
Angreifbare Komponenten als Problem
Ein weiteres Beispiel ist eine Sicherheitslücke in der vom taiwanischen Unternehmen KCodes Komponente NetUSB, die in zahllosen Router-Modellen zum Einsatz kommt. Nachdem die Entwickler auf Hinweise des Forschers, der die Lücke entdeckt hatte, nicht wirklich reagierten, veröffentlichte er sie. Das setzte nicht nur KCodes unter Druck, sondern sorgte auch bei erhebliche Aufregung bei den Router-Herstellern, deren Geräte durch eine unsichere aber nicht ohne weiteres zu ersetzende Software-Komponente als unsicher eingestuft wurden.
Auf den Punkt gebracht hat das kürzlich auch silicon.de-Blogger Julian Totzek-Hallhuber. Ihm zufolge ist Software auch deshalb anfällig für Angriffe, weil angreifbare Komponenten verwendet werden. Früher hätten Cyberkriminelle für jeden Angriff maßgeschneiderte Werkzeuge schaffen müssen. “Die Verwendung von Komponenten hat alles geändert. Wenn eine einzelne Open-Source-Komponente in tausenden Anwendungen ihren Platz findet, muss eine Attacke nicht mehr für jede einzelne Software geplant und durchgeführt werden, sondern lediglich die verwendete Komponente ins Visier genommen werden. So lassen sich tausende Anwendungen auf einen Schlag treffen”, so Totzek-Hallhuber zusammenfassend.
SAP S/4HANA trifft ECM: Was Sie für eine erfolgreiche Migrationsstrategie beachten sollten
Ceyoniq beleutet in diesem Whitepaper anhand von sechs Thesen die wichtigsten Aspekte zum Thema und gibt Tipps für eine erfolgreiche Migrationsstrategie.
GitHub verspricht Entwicklern, die den Dependency Graph aktiviert haben, zu benachrichtigen, sobald eine Schwachstelle in einem der Programme gefunden wurde, auf die sie zurückgreifen. Außerdem werden direkt GitHub-Community bekannte Fixes vorgeschlagen. Für öffentliche Repositories werden beide Funktionen automatisch aktiviert. Bei einem private Repository ist die ausdrückliche Aktivierung der Alarmfunktion für Sicherheitslücken erforderlich. Dies kann in den Einstellungen für das Repository geschehen oder auch, indem beim Dependency Graph der Zugriff erlaubt wird. Der Admin wird dann automatisch benachrichtigt, er kann aber dort auch Teams oder weitere Einzelpersonen als Empfänger angeben. Sie werden dann mit der Benachrichtigung zur Sicherheitslücke auch auf alle Komponenten hingewiesen, von derjenigen abhängen, für die ein Sicherheits-Update erforderlich ist.
Zunächst gilt das für alle Sicherheitslücken mit einer offiziellen CVE-Kennung. Die Datenbank für die Github-Sicherheitsalarme soll aber – auch in Zusammenarbeit mit den Security-Partnern im GitHub Marketplace künftig erweitert werden, um dann auch Schwachstellen ohne CVE-Kennung zu erfassen.
