Augen auf bei der Code-Auswahl: Risikofaktor Open Source

Autor: Gunner Winkenwerder

Moderne Entwicklungsverfahren wie das Agile Development setzen auf eng integrierte Teams. Software-Architekten, Entwickler sowie Funktionsund Security-Tester arbeiten eng
zusammen, um schneller zu verwertbaren Ergebnissen zu gelangen – und sich so von langsameren Wettbewerbern abzusetzen. Gerade die Arbeit mit lizenzfreien Komponenten und Frameworks hat dabei viele Vorzüge. Insbesondere mit Blick auf die niedrigeren Entwicklungskosten und die kürzere Time-to-Market.

Sie birgt aber auch große Risiken für die Sicherheit der Applikation. Lange Zeit kreierten interne Teams Individualsoftware streng im TopDown-Verfahren. Drittanbietercode, insbesondere Open-Source-Komponenten, galten als riskant und kamen 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 Software-Anwendungen 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 Drittanbieter-Komponenten

Eine Analyse der Software-Zusammensetzung zeigt, dass die heutigen Anwendungen 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. 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 eine große Anzahl von 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. In der Theorie funktioniert dieser Ansatz.

In der Praxis werden dagegen anfällige Open-Source-Komponenten im Entwicklungsprozess oftmals weiterhin eingesetzt. Entwickler laden sich die benötigten Komponenten einmal 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. Viele Unternehmen setzen sich mit zahlreichen unzureichend überprüften Komponenten dem Risiko aus, angegriffen zu werden. Zumal die Angreifer ganz genau wissen, dass Open-SourceKomponenten oft nicht ausreichend überwacht und gepflegt werden. Viele Unternehmen verfolgen ihre OpenSource-Nutzung entweder gar nicht oder tun dies in einer statischen, nicht immer aktuell gehaltenen 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 Managementund Orchestrierungsplattform, die Entwicklern quelloffene Bausteine in einem übersichtlichen Dashboard auflistet und ihnen tiefe Einblicke in Open-Source-Schwachstellen ihres Portfolios verschafft.

Abgleich mit der Schwachstellendatenbank

Die Open Source Security muss sich aber auch den neuen Paradigmen in der Software-Entwicklung (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. Hinzu kommt, dass Entwickler von sehr umfangreichen Software-Anwendungen in der Regel nicht die gesamte Codebasis kennen und so der Verbreitung von Sicherheitsschwachstellen Vorschub leisten. Unternehmen sind deshalb auf entsprechende 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-SecurityLösung muss aber noch mehr können. Denn Unternehmen sehen sich 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 Überprüfungsplattform sollten SecurityVerantwortliche deshalb auf folgende
Kriterien achten:

Automatisierung der Open Source Security: Schwachstellen im OpenSource-Code sollten möglichst früh im SDLC – im Idealfall bereits bei der Integration – identifiziert und behoben werden. Die Security-Plattform sollte sich über jeden Web-Browser oder direkt aus der Build-Umgebung heraus starten lassen. Die Plattform trägt die
Ergebnisse zusammen 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.

Eine Lösung für multiple Tests: Die Ergebnisse werden von Open-Source- und statischen Security-Tests automatisch korreliert, um Schwachstellen zuverlässiger zu bewerten und automatisiert zu 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.

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 die Abläufe verzögert werden.

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.

Monitoring der Lizenzierung: OpenSource-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 (z. B. 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 Security-Plattform 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 Software-Komponenten nahtlos in die integrierte Entwicklungsumgebung einzubinden und die Open-Source-Analyse als Teil ihres SDLC zu automatisieren. So erhält das Entwickler-Team Transparenz über die gesamte Codebasis, einschließlich der Open-Source-Code-Komponenten, und kann Sicherheitslücken zuverlässig schließen. Integrierte Datenbanken 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.