Im Zuge der Digitalisierung entwickelt sich Open-Source-Software auch in Deutschland, Österreich und der Schweiz zu einem wichtigen Baustein agiler Entwicklungsumgebungen. Der quelloffene Code ermöglicht es Unternehmen, wirtschaftlicher zu agieren und ihre Anwendungen schneller zur Marktreife zu führen – doch er birgt auch Risiken. Mittelständler, Konzerne und Regierungseinrichtungen sind daher gut beraten, passgenaue Strategien für eine sichere Open-Source-Nutzung zu entwickeln.

Lange Zeit kreierten interne Teams Individualsoftware streng im Top-down-Verfahren. Drittanbietercode, insbesondere Open-Source-Komponenten, galt als riskant und kam mit Blick auf die unbekannte Herkunft und die undurchsichtigen Lizenzierungsmodelle nur selten zum Einsatz. Mittlerweile ist die Open Source Community und damit auch die Akzeptanz von Open-Source-Projekten wie Linux und OpenSSL sowie von Frameworks wie Apache Struts gewachsen. Heute bestehen Softwareanwendungen typischerweise aus benutzerdefiniertem, eigenentwickeltem Code und Drittanbietercode, wobei Open Source sowohl bei Inhouse-Projekten als auch bei kommerziell entwickelter Software oft den Löwenanteil des verwendeten Codes ausmacht.

Durchbruch von Drittanbieterkomponenten. Eine Analyse der Softwarezusammensetzung zeigt, dass heutige Anwendungen oft zu mehr als 80 Prozent aus Open Source bestehen. Die hohe Akzeptanz von quelloffenen Komponenten in nahezu allen Branchen hat zu einem Anstieg der Open-Source-Entwicklung geführt. Viele namhafte Unternehmen bieten mittlerweile Open-Source-Projekte an, die Entwickler nutzen und ergänzen können. Der Durchbruch von quelloffenen Komponenten hat aber auch die Art der Anwendungsentwicklung verändert: Anstatt die gesamte Software von Grund auf neu zu entwickeln, verwenden Unternehmen Open Source, um gängige oder sich wiederholende Funktionen bereitzustellen. Und das Vertrauen in Open Source ist seit der Einführung von Linux als Betriebssystem in professionellen Umgebungen, Java als primäre Entwicklungssprache und Apache Struts als MVC-Framework gestiegen. Eigenentwickelter Code wird daher meist nur noch für proprietäre Features verwendet. Entwickler können ihre Zeit so anwendungsspezifischen Schlüsselfunktionen widmen, anstatt gängige Features aufwendig nachzubauen.

Mangelnde Überwachung von Open Source. Open-Source-Software ist trotz aller Vorteile aber auch anfällig für Security-Schwachstellen. Jedes Jahr legt die Community zahlreiche Sicherheitslücken in Open-Source-Software offen. Hersteller melden diese Sicherheitslücken in der Regel verantwortungsbewusst und liefern ein passendes Patch oder eine aktualisierte Version, die die Schwachstelle beseitigt und gefährdete Komponenten behebt, gleich mit. Theoretisch müssten die Entwickler dann einfach nur zur jeweils aktuellsten Version der Open-Source-Komponenten greifen, um auf der sicheren Seite zu sein.

In der Praxis werden auch aber bekanntermaßen an-fällige Open-Source-Komponenten oftmals weiterhin eingesetzt. Entwickler laden sich die benötigten Komponenten herunter und behalten sie oft jahrelang in ihrem Workspace. Mit zunehmendem Alter dieser Bausteine steigt die Wahrscheinlichkeit, dass ihre Schwachstellen bereits bekannt und im Darknet entsprechende Exploits verfügbar sind – und damit natürlich auch das Risiko eines Angriffs.

Dies gilt umso mehr, als die Angreifer ganz genau wissen, dass Open-Source-Komponenten oft nicht systematisch überwacht und gepflegt werden. Viele Unternehmen verfolgen ihre Open-Source-Nutzung entweder gar nicht oder lediglich mithilfe einer statischen, oft veralteten Tabelle.

Der erste Schritt für Security-Verantwortliche, die die Weichen für eine sichere Open-Source-Nutzung stellen wollen, ist daher, sich einen Überblick darüber zu verschaffen, wo Open Source verwendet wird. Die optimale Lösung ist eine umfassende Management- und Orchestrierungsplattform, die Entwicklern quelloffene Bausteine in einem übersichtlichen Dashboard auflistet und ihnen tiefe Einblicke in Open-Source-Schwachstellen ihres Portfolios verschafft.

Abgleich mit Schwachstellendatenbanken. Die Open-Source-Security muss sich aber auch den neuen Paradigmen in der Softwareentwicklung wie DevOps anpassen. Die in vielen Unternehmen eingesetzten statischen Analysetools sind oftmals nicht in der Lage, Schwachstellen von Open-Source-Code zu erkennen – nicht einmal dann, wenn diese bereits bekannt und dokumentiert sind. Hinzukommt, dass die Entwickler gerade im Falle sehr umfangreicher Softwareanwendungen in der Regel nicht die gesamte Codebasis kennen und so der Verbreitung von Sicherheitsschwachstellen Vorschub leisten. Unternehmen sind deshalb auf dedizierte Lösungen angewiesen, die die Software auf enthaltenen quelloffenen Code scannen und diesen dann mit hinterlegten Schwachstellendatenbanken abgleichen.

Auswahlkriterien einer Komplettlösung. Eine umfassende Software-Security-Lösung muss aber noch mehr können. Denn Unternehmen sehen im Hinblick auf Open Source mit drei wesentlichen Herausforderungen konfrontiert: die Sicherheit ihrer Anwendungen, mögliche Lizenzkonflikte und die Wartung ihrer Systeme und Bibliotheken. Bei der Auswahl der Plattform sollten Security-Verantwortliche deshalb auf folgende Kriterien achten:

1. Implementierung einer Software-Composition-Analysis-Lösung (SCA):
Open-Source- und Drittanbieter-Komponenten sowie eigenentwickelter Code sind in moderner Software eng miteinander verzahnt. Eine nahtlos integrierte SCA-Lösung untersucht die Software entlang der gesamten CI/CD-Pipeline auf Open-Source-Komponenten im Quellcode und detektiert Security-Schwachstellen in quelloffener Software. In Kombination mit einem statischen Analysetool zeigt die SCA-Lösung auf, für welche Angriffe die Anwendung anfällig ist und wie Entwickler die Sicherheitslücken zuverlässig beheben.

2. Automatisierung der Open-Source-Security:
Schwachstellen im Open-Source-Code müssen möglichst früh im SDLC, im Idealfall bereits bei der Integration, identifiziert und behoben werden. Die Security-Plattform sollte sich daher über jeden Web-Browser oder direkt aus der Build-Umgebung heraus starten lassen. Die Lösung aggregiert die Ergebnisse und stellt diese den Entwicklern anschließend in Echtzeit in der Web-Oberfläche bereit oder teilt sie direkt in der Projektübersicht des Build-Managers.

3. Eine Lösung für multiple Tests:
Wenn die Ergebnisse der Open-Source-Analyse und der statischen Security-Tests automatisch korreliert werden, lassen sich Schwachstellen zuverlässiger bewerten und automatisiert priorisieren. Auf diese Weise können Entwickler Schwachstellen in ihrem eigenen Code und Open-Source-Schwachstellen über eine einheitliche Konsole managen, statische und SCA-Analysen gleichzeitig anstoßen und sofort erkennen, ob von einer Open-Source-Schwachstelle in ihrer App Gefahr ausgeht.

4. Fundierte Security-Analysen:
Bei der Auswertung gilt es darauf zu achten, dass ein Überblick über Tausende von Open-Source-Schwachstellen, Security-Warnhinweisen und Bugs hinterlegt ist. Entwickler identifizieren Code-Schwachstellen zuverlässig und beheben diese dank handlungsrelevanter Hinweise, ohne dass Abläufe dadurch verzögert werden.

5. Open-Source-Code durchgängig prüfen:
Voraussetzung für eine erfolgreiche Open-Source-Integration ist, dass die verwendeten quelloffenen Code-Bestandteile auch nach Abschluss der eigentlichen Entwicklung auf potenzielle Sicherheitslücken hin analysiert werden. Einige der gefährlichsten Open-Source-Schwachstellen, etwa ShellShock (CVE-2014-6271), wurden erst Jahrzehnte nach der Veröffentlichung des Codes identifiziert. Ohne volle Transparenz über den Open-Source-Code, dessen Historie und dessen Rolle im Gesamt-Code ist es nahezu unmöglich, diese Art von Sicherheitslücken zu finden und zu schließen.

6. Monitoring der Lizenzierung:
Open-Source-Lizenzen sind komplex, und bei Verstößen gegen die Vorgaben drohen hohe Bußgelder oder der Verlust von geistigem Eigentum. Die Security-Lösung sollte Unternehmen auf potenzielle Lizenzierungsrisiken hinweisen und mit aussagekräftigen Bewertungen verhindern, dass Mitarbeiter Komponenten verwenden, die nicht mit den technologischen oder geschäftlichen Rahmenbedingungen des Projekts vereinbar sind.

Mit einer umfassenden Security-Plattform lassen sich Policies für eine sichere und Compliance-konforme Einbindung von Open-Source-Code erstellen und durchsetzen. So definieren Unternehmen Kriterien für die Verwendung und etablieren interne Freigabeprozesse anhand von Metadaten und Projektdetails. Versucht ein Entwickler, nicht-konforme Komponenten zu nutzen, schickt das System eine Benachrichtigung und stößt einen vorgegebenen Workflow (etwa Build-Abbruch) an. Ein Browser-Plugin vereinfacht zudem die Auswahl von Open-Source-Komponenten. Die Entwickler können online aus verfügbaren Open-Source-Komponenten wählen und anhand unterschiedlicher Risikobewertungen (Sicherheit, Qualität, Compliance) prüfen, ob deren Verwendung zulässig ist – und das bevor sie sie im Projekt einbinden.

Die Sicherheitslösung sollte daher so konfiguriert werden, dass sie insbesondere auf häufige Schwachstellen oder Fehler achtet, die etwa in den OWASP Top 10 oder SANS Top 25 aufgeführt sind. Natürlich sind das nicht die einzigen Schwachstellen, um die Entwickler sich Gedanken machen müssen. In allen Fällen ist es deshalb sinnvoll umfangreichere Tests durchzuführen – auch über die Entwicklungsphase hinaus.

Fazit. Angesichts der steigenden Beliebtheit von Open Source kommen Unternehmen heute nicht umhin, die Analyse der Softwarekomponenten nahtlos in die IDE ihrer Entwickler zu integrieren und die Open-Source-Analyse als Teil ihres SDLC zu automatisieren. So erhält das Entwickler-Team Transparenz über die gesamte Code-Basis, einschließlich der Open-Source-Code-Komponenten, und kann Sicherheitslücken zuverlässig schließen. Integrierte Schwachstellendatenbanken stellen zudem sicher, dass neu entdeckte Schwachstellen schnell beseitigt werden, bevor sie zu einem Sicherheitsproblem für die Anwendung und zum Compliance-Risiko für das Unternehmen werden.

Dr. Christopher Brennan,
Regional Director DACH
bei Checkmarx

Illustration: © Botond1977 /shutterstock.com