Mit <kes>+ lesen

OSS: Mehr als einsehbar : Mehr Sicherheit durch eine starke Gemeinschaft und Automationsunterstützung

Neben der Möglichkeit zur Prüfung von Quelltexten bieten Open-Source-Software-(OSS)-Projekte noch weitere Vorteile, die auch der Sicherheit zugute kommen, meint unser Autor– nicht zuletzt können dabei Automatismen der OSS-Plattformen unterstützen.

Lesezeit 7 Min.

Von Johannes Nicolai, Potsdam

Open-Source-Software (OSS) ist aus der Arbeit vieler Entwickler längst nicht mehr wegzudenken: Sie bildet die Grundlage für eine Vielzahl von Programmiersprachen, Frameworks und Applikationen, mit denen Entwickler weltweit Tag für Tag arbeiten. Kommerzielle Software-Projekte weisen heute typischerweise mehr als 60 % Abhängigkeiten zu Open-Source-Komponenten auf. Bis zu 96 % der in Unternehmen genutzten Anwendungen enthalten OSS. Etwa die Hälfte des gesamten Codes solcher Anwendungen ist selbst Open Source – und zwar über alle Branchen hinweg. Bei neu entwickelten Apps liegt diese Quote zumeist schon bei 80–90 %.

Open Source hat klar die Art und Weise verändert, wie Software entwickelt wird – kein Wunder also, dass nicht zuletzt in puncto Komplexität und Sicherheit Fragen aufkommen: Birgt die größte Stärke von Open Source – die globale Zusammenarbeit vieler Menschen – womöglich auch die größte Gefahr, wenn niemand mehr den Überblick behält? Wie lässt sich in einem solchen Umfeld Sicherheit garantieren? Welche Mechanismen und Prozesse haben sich hier bewährt?

Im Mittelpunkt des Open-Source-Gedankens steht, dass der Quellcode einer Software offen und somit für jeden frei zugänglich ist. Dadurch kann er von jedermann kostenfrei eingesehen, geändert und auch genutzt werden. Oft tauschen sich so hunderte (oder gar tausende) von Menschen aus verschiedensten Regionen mit unterschiedlichen kulturellen Hintergründen, Ideen und Fähigkeiten miteinander aus und entwickeln gemeinsam ihren Code beziehungsweise ihr Projekt weiter. Das Bündeln dieses breiten Spektrums an Ideen und Fähigkeiten bildet den Kern der Innovationskraft und damit der Bedeutung von OSS.

Eigene Software „Open Source“ zu stellen und dann damit zu rechnen, dass sich sofort Heerscharen freiwilliger Programmierer beteiligen, um für das Unternehmen kostenlos neue Funktionalität zu produzieren, ist eine häufige Fehl-Erwartung. Externe Entwickler werden nur Freude daran haben, mitzuarbeiten, wo eine gesunde Open-Source-Community-Kultur etabliert ist – Ideen hierzu liefern beispielsweise die „Open Source Guides“ von Github (https://opensource.guide).

OSS in Unternehmen

Um zu lernen, wie Open-Source-Communities ticken und wie der Contribution-Prozess funktioniert, empfiehlt es sich, zunächst einmal auf GitHub nach einer existierenden Community zu suchen und dort auch aktiv mitzuarbeiten. Unter https://github.com/collections/choosing-projects sind etwa Projekte gelistet, die besonders freundlich mit „Neuankömmlingen“ umgehen und gerade nach Hilfe fragen. Sobald man in der Interaktion geübt ist, kann man dann auch eigene Projekte angehen.

Zeit und Mühe in eine eigene Open-Source-Kultur zu investieren, kann sich auf vielfältige Weise lohnen: So schauen etwa viele engagierte Entwickler, die auf der Suche nach einem neuen Arbeitgeber sind, gezielt nach, ob und wie sich Unternehmen an Open-Source-Projekten beteiligen. Viele Programmierer sind heute von dem Umstand demotiviert, zwar an interessanten Projekten zu arbeiten, ihre Beiträge und Fähigkeiten aber außerhalb der Firma niemals zeigen zu können – damit wird ein öffentliches Portfolio (ähnlich einer Künstlermappe) zu etwas, das sie nur in ihrer Freizeit weiterentwickeln können. Unternehmen, die selbst in Open-Source-Entwicklung investieren, sind daher als potenzielle Arbeitgeber wesentlich attraktiver.

Neben einem besseren Zugang zu Talenten verheißt ein OSS-Engagement aber auch Einflussmöglichkeiten und Investitionsschutz bei innovativer Technologie – wer mitmacht, kann auch die Richtung solcher Entwicklungen durch die eigenen Open-Source-Kontributoren gezielt beeinflussen. Einen weiteren nicht unerheblichen Faktor stellt die Kosteneffizienz da: Entwickler brauchen keine Applikationen von Grund auf neu zu bauen, deren Elemente bereits zuvor hundertfach für andere Projekte entwickelt wurden, sondern können die Open-Source-Komponenten, die sie benötigen, kostenfrei einbinden und nach ihren Wünschen konfigurieren oder anpassen.

Die „Reichweite“ großer Communities ist dabei nicht zu unterschätzen: GitHub umfasst als wohl bekannteste Entwicklungsplattform beispielsweise mehr als 50 Millionen Developer und 100 Millionen Open-Source- und kommerzielle Software-Projekte. Zu den Top-100-Open-Source-Projekten tragen indirekt mehr als 74 000 Software-Entwickler bei – weit mehr als Microsoft, Facebook oder Google stellen könnten.

Abbildung 1

Abbildung 1: Automatische Code-Analysen können auf OSS-Plattformen dabei helfen, typische Fehler zu vermeiden.

OSS-Vorteile

  • Die Quelltexte von OpenSource-Software sind offen und somit für jeden frei zugänglich – jeder kann den Code kostenfrei einsehen, ändern und für sich nutzen.
  • So arbeiten oft hunderte (manchmal tausende) Menschen gemeinsam an einem Projekt – die unterschiedlichen Hintergründe der Contributor steigern die Innovationskraft.
  • Mehr Augenpaare finden mehr Fehler – das erhöht die Sicherheit und auch die Qualität der Software insgesamt.
  • Auf einschlägigen Plattformen können Monitoringlösungen und automatisierte Codeprüfungen Fehler finden oder vermeiden helfen sowie bei Code-Abhängigkeiten Updates anstoßen.
  • OSS bedeutet Kosteneffizienz durch Zeit- und Ressourcenersparnis.
  • Talente werden angezogen und können mit den Tools arbeiten, die sie gewohnt sind.
  • Die Denkweise einer OpenSource-Kultur ist nicht nur für die Entwicklung sabteilung, sondern für das ganze Unternehmen förderlich.

Security-Chancen

Bei aktiven Open-Source-Projekten werden 98 % der von GitHub übermittelten Sicherheitslücken innerhalb von zwei Wochen adressiert. Im Gegensatz dazu bleiben über 70 % aller bekannten Sicherheitslücken in kommerzieller Software mehr als einen Monat unbehoben – über 50 % werden sogar erst nach mehr als einem Jahr oder nie adressiert (Quelle: www.veracode.com/state-of-software-security-report).

Sicherheit ist im Open-Source-Kontext eine Gemeinschaftsaufgabe: Die globale Zusammenarbeit von Entwicklern mit unterschiedlichsten Expertisen und somit auch unzähligen Augenpaaren, die den Code durchforsten, Verbesserungsvorschläge einbringen, Fehler entdecken, auf diese hinweisen und sie sogleich korrigieren, bieten teilnehmenden Organisationen die Möglichkeit, innovativen und sicheren Code einzusetzen.

Das Befolgen sicherer Coding-Praktiken und die sofortige sorgfältige sowie konsequente Behebung von Schwachstellen direkt nach ihrer Entdeckung tragen in der Open-Source-Community dazu bei, Angriffspunkte und anfällige Stellen auf ein Minimum zu reduzieren.

Eine sichere und aktive Open-Source-Gemeinschaft ist jedoch nicht nur für OSS an sich förderlich, sondern kommt auch den Millionen – teils kritischen – Technologien und Infrastrukturen zugute, die davon abhängen.

Automatische Hilfen für OS-Code/-Bibliotheken

Plattformen wie GitHub zeigen sowohl für kommerzielle als auch für OSS-Projekte genau an, welche Komponenten sie einbinden (konsumieren), welche Lizenzen und Bedingungen damit einhergehen und welche offene Sicherheitslücken dafür bekannt sind – sofern möglich stellt das System auch automatisierte, erprobte Sicherheits-Fixes zur Verfügung (siehe auch https://github.com/features/security).

Ein durchschnittliches kommerzielles Javascript-/Typescript-Projekt konsumiert heute beispielsweise mehr als 700 Open-Source-Komponenten – in der kommerziellen Java- und .NET-Welt sind es immer noch mehr als 200 direkte und indirekte Abhängigkeiten. Auf automatisierte Unterstützung kann man bei einer derart starken Verflechtung nicht sinnvoll verzichten.

GitHub bietet hier mit Dependabot ein Werkzeug an, das Probleme in den konsumierten Abhängigkeiten zu Open-Source-Bibliotheken (Bausteinen) aufzeigen und beheben kann.

Seit Anfang Mai ist jetzt auch eine statische Code-Analyse nativ in GitHub eingebunden: Bei aktiviertem Code-Scanning wird jeder Git-Push auf neue potenzielle Sicherheitslücken geprüft und die Ergebnisse werden direkt im Pull-Request angezeigt. Dafür wird CodeQL eingesetzt, ein fortschrittliches semantisches Analysewerkzeug, das eine verhältnismäßig hohe Zahl an Sicherheitslücken finden kann (weitere Infos siehe https://lgtm.com, https://securitylab.github.com/tools/codeql). Um die Sicherheit globaler Software zu unterstützen, stellt Github Code-Scanning für Open-Source- und Forschungs-Projekte kostenlos zur Verfügung und ermöglicht allen öffentlichen Projekten die Anmeldung zur aktuellen Beta.

Mittels auf CodeQL basierter statischer Analysen wurden allein dieses Jahr (Stand April 2020) über 50 „Common Vulnerabilities and Exposures“ (CVEs) gefunden und mehr als 100 000 Pull-Requests analysiert, sodass gefundene Sicherheitslücken gar nicht erst Eingang in ein Release fanden – hier zeigt sich auch einmal ganz praktisch, was der DevSecOps-Gedanke im Kern beschreibt.

Jedes Mal, wenn eine Sicherheitslücke gefunden wird, versucht die CodeQL-Community das Problem an sich so zu erfassen, dass das System auch andere Varianten dieser Lücke finden kann. Auf diese Weise sind bereits über 1700 CodeQL-Community-Queries zusammengekommen – die Tendenz ist rapide steigend. Jeder, der sich gerne am Schreiben solcher Queries beteiligen möchte, kann über https://securitylab.github.com/ mitmachen – und sich dabei unter anderem Google, HackerOne, Microsoft und OWASP anschließen.

Während CodeQL potenzielle Sicherheitslücken im eigenen Quellcode als Teil des DevSecOps-Lifecycle automatisch aufzeigt, sorgt sich der bereits kurz angesprochene Dependabot darum, bereits bekannte Sicherheitslücken in benutzten Bausteinen (Abhängigkeiten) automatisch zu beheben, indem Pull-Requests zum Update auf neuere, sichere Versionen der benutzten Bibliotheken erzeugt werden. Github-Analysen zeigen, dass mit der Bereitstellung eines automatisierten Fixes die Wahrscheinlichkeit der schnellen Behebung einer Sicherheitslücke in den ersten 48 Stunden auf mehr als das Doppelte steigt (vgl. Abb. 2).

Doch auch Versions-Upgrades funktionieren nicht immer ohne Weiteres – manchmal haben sich neue Fehler eingeschlichen oder Management und Wissen Open-Source-Software Interfaces geändert. Deswegen überprüft Dependabot in mehr als 6 Mio. Open-Source-Repositories, ob die von ihm generierten Pull-Requests auch erfolgreich „gemerged“ wurden oder ob Testfälle oder andere automatisierte Checks fehlschlugen. Aus dem Community-Feedback ermittelt Dependabot zudem den sogenannten „Community Compatibility Score“, der auch kommerziellen Kunden eine gute Indikation liefert, ob ein automatisches Sicherheitsupdate problemlos „mergebar“ ist.

Als weitere Neuigkeit von der – dieses Jahr nur virtuellen – Github-Satellite-Konferenz von Anfang Mai (https://githubsatellite. com) ist übrigens die Funktion „Secret Scanning“ zur automatischen Suche nach Geheimnissen nun auch für interne Repositories im Enterprise-Plan verfügbar. Diese Funktion (früher Token-Scanning genannt) kann bereits seit 2018 öffentliche Repositories überprüfen. Da in den letzten Jahren hierüber mehr als zehn Millionen potenziell unternehmensinterne Informationen identifiziert wurden, haben viele Github-Kunden darum gebeten, die gleiche Möglichkeit auch für „privaten“ Code nutzen zu können.

Johannes Nicolai ist langjähriger Open-Source-Enthusiast und Contributor sowie Principal Solutions Engineer bei GitHub.

Abbildung 2

Abbildung 2: Bei Vorliegen eines „Automated Security-Updates“ (ASU) werden Sicherheitsprobleme deutlich schneller behoben.

Abbildung 3

Abbildung 3: Dependabot prüft bei Pull-Requests auf Github automatisch, ob Abhängigkeiten bekannte Sicherheitsprobleme aufweisen.

Diesen Beitrag teilen: