Der nächste Heartbleed kommt bestimmt

Software-Komponenten in Stücklisten festhalten und überwachen

| Autor / Redakteur: Jeff Luszcz * / Stephan Augsten

Software-Entwickler sollten genau in Stücklisten festhalten, welche Drittkomponenten sie einsetzen und ob diese aktuell sind.
Software-Entwickler sollten genau in Stücklisten festhalten, welche Drittkomponenten sie einsetzen und ob diese aktuell sind. (Bild: TeroVesalainen - Pixabay.com / CC0)

Software-Anbieter sollten wissen, auf welche Open-Source-Komponenten ihre Produkte zurückgreifen. Was sonst droht, hat die OpenSSL-Schwachstelle Heartbleed seinerzeit eindrucksvoll belegt. Wie sieht es heute mit der Transparenz bei Open Source Software aus?

Rund drei Jahre nach Bekanntwerden von Heartbleed gilt die OpenSSL-Sicherheitslücke nach wie vor als eindrückliches Beispiel der Sicherheitsrisiken von Open Source. Damals fehlte den meisten Softwareherstellern schlichtweg der Einblick, welche quelloffenen Komponenten in ihren Produkten genutzt wurden.

Noch vor zehn oder zwanzig Jahren war es für Softwareentwickler wesentlich leichter festzustellen, welche Software mit welchen Lizenzen verbunden waren. Doch das Entwicklungsmodell hat sich geändert: Statt in-House entwickelter Produkte mit wenigen kommerziellen Bibliotheken bestehen die Projekte heute zu mindesten 50 Prozent aus Open-Source-Software (OSS).

Die entsprechenden Komponenten und Module werden digital geliefert und sind in der Regel nicht eindeutig im Verzeichnisbaum dokumentiert. Wollen Entwickler wissen, ob eine kürzlich veröffentlichte Schwachstelle auch ihre Produkte betrifft, ist ein aktuelles Verzeichnis aller Abhängigkeiten oder eine Stückliste (Bill of Materials) der eingesetzten Komponenten notwendig.

In der Praxis stellt ein solches Verzeichnis jedoch viele Unternehmen vor eine echte Herausforderung. Laut Untersuchungen beträgt der Anteil der in Verzeichnissen geführten Komponenten durchschnittlich nur vier Prozent. Auf jede bekannte Komponente kommen somit 24 weitere Komponenten, die unerkannt und unverwaltet in der Software verwendet und an Kunden ausgeliefert werden.

Selbsttests durchführen

Ein Selbsttest kann schnell Aufschluss darüber geben, ob sich eine aktuelle Stückliste erstellen lässt und wann diese zuletzt aktualisiert wurde. Basiert die Liste allein auf den Einschätzungen der Entwickler, ist sie mit hoher Sicherheit nicht vollständig.

Um einen schnellen Einblick zu gewinnen empfiehlt es sich, Stichproben des Quellcodes zu nehmen und die angegebenen Versionsnummern auf ihre Aktualität hin zu überprüfen. Eine schnelle Durchsicht der Bibliotheks-Namen, eine Suche nach Copyright-Informationen, Lizenzen und kopierten Dateien sowie eine Überprüfung auf Dateiendungen vermeintlicher Drittanbieter (z. B. .JAR, .DLL) schaffen einen ersten Überblick.

Oft wird auf diese Weise schnell eine große Menge bisher unbekannter Drittsoftware sichtbar. Aufschlussreich ist auch die Suche nach dem String „OpenSSL“. Dadurch lassen sich mit hoher Wahrscheinlichkeit zahlreiche Kopien von bislang nicht bekannten Fällen von OpenSSL in Open Source und in kommerziellen Komponenten finden – sowohl in Binärprogrammen als auch in Quelldateien.

Erstellen einer Software-Stückliste

Es gibt einige wenige Hauptanwendungsfälle, bei denen sich Open-Source-Komponenten finden lassen, die möglicherweise von Schwachstellen (Vulnerabilities) betroffen sind.

  • 1. Im ersten Fall sind die Top-Level-Komponenten betroffen, oft in eindeutig bezeichneten Dateien oder Directories. Sie sind sehr leicht erkennbar, sind aber nur die Spitze des Eisbergs.
  • 2. Top-Level-Komponenten bestehen wiederum aus Teilkomponenten. Diese sind schwerer aufzudecken– selbst bekannte Vulnerabilities wie Heartbleed können übersehen werden. Versionen dieser Komponenten, die in größeren Paketen kompiliert und gelinkt werden, sind für Entwickler, die ein vollständiges Verzeichnis der Abhängigkeiten erstellen wollen, so gut wie nicht zu erkennen.
  • 3. Schließlich sollten Eigentümer der Codebasis die verbleibenden Quelldateien daraufhin überprüfen, ob es sich um „Cut and Pastes”, Refactoring oder Umstellungen von größeren Open Source Paketen handelt. Ohne eine automatisierte Lösung ist eine solche Überprüfung der Codebasis jedoch kaum möglich.

Ist eine Stückliste erstellt, folgt der Abgleich mit Komponenten, die bekannte Anfälligkeiten enthalten. Erfahrungsgemäß findet sich dabei vor allem bei einer ersten Überprüfung eine Vielzahl an gefährdeten Komponenten.

Einige dieser Vulnerabilities sind einfacher auszunutzen als andere, daher ist es gängige Praxis, Prioritäten festzulegen und eine Handlungsreihenfolge für den Ernstfall zu bestimmen. Zu den Maßnahmen der Gefahrenbehebung zählen Upgrades auf die nächste Version, Patch-Prozesse, Blockieren des Zugriffs und in manchen Fällen auch das vollständige Entfernen der Komponente und aller betroffener Produktfeatures.

Gelangen Vulnerabilities über die Software-Lieferkette in das Software-Produkt, gilt es zu überprüfen, ob die Anbieter der entsprechenden Open Source oder kommerziellen Komponenten bereits Patches zur Verfügung stellen. Häufig jedoch sind sie sich nicht einmal bewusst, dass eine Anfälligkeit vorliegt; oder sie sind nicht dazu in der Lage, das Problem zu lösen.

Defect Logging

Um eine aktive Rolle im Lifecycle-Management einer Schwachstelle zu übernehmen, sollten Unternehmen sich mit den Defect-Logging-Prozessen der Software-Komponenten vertraut zu machen. Dies gilt sowohl für Open-Source-Module als auch für kommerzielle Komponenten.

Ist eine neue Version eines Produkts verfügbar, muss die Stückliste kontinuierlich auf dem neuesten Stand gehalten und regelmäßig mit neuen Vulnerabilities abgeglichen werden – und zwar über die gesamte Entwicklung bzw. Nutzungsdauer des Software-Produkts hinweg. Diese Regelung empfiehlt sich für alle unterstützten Versionen, die bei den Anwendern im Einsatz sind, selbst wenn das Entwicklerteam bereits die neueste Version nutzt.

Jeff Luszcz
Jeff Luszcz (Bild: Roi Brooks)

Um den nächsten Heartbleed zu vermeiden, sind etablierte Prozesse und automatisierte Lösungen notwendig, mit denen Unternehmen die Open Source-Komponenten in ihren Produkten scannen, nachverfolgen und managen können. Nur so gewinnen sie einen transparenten Einblick in ihre Software und können Risiken von Vulnerabilities besser einschätzen. In Kombination mit automatisierten Systemen für das Patch-Management können Softwarehersteller so eine hohe Sicherheit ihrer Produkte gewährleisten – wovon sowohl die eigene Software-Lieferkette als auch Kunden profitieren.

* Jeff Luszcz ist Vice President of Product Management bei Flexera Software.

Kommentare werden geladen....

Kommentar zu diesem Artikel

Der Kommentar wird durch einen Redakteur geprüft und in Kürze freigeschaltet.

Anonym mitdiskutieren oder einloggen Anmelden

Avatar
Zur Wahrung unserer Interessen speichern wir zusätzlich zu den o.g. Informationen die IP-Adresse. Dies dient ausschließlich dem Zweck, dass Sie als Urheber des Kommentars identifiziert werden können. Rechtliche Grundlage ist die Wahrung berechtigter Interessen gem. Art 6 Abs 1 lit. f) DSGVO.
  1. Avatar
    Avatar
    Bearbeitet von am
    Bearbeitet von am
    1. Avatar
      Avatar
      Bearbeitet von am
      Bearbeitet von am

Kommentare werden geladen....

Kommentar melden

Melden Sie diesen Kommentar, wenn dieser nicht den Richtlinien entspricht.

Kommentar Freigeben

Der untenstehende Text wird an den Kommentator gesendet, falls dieser eine Email-hinterlegt hat.

Freigabe entfernen

Der untenstehende Text wird an den Kommentator gesendet, falls dieser eine Email-hinterlegt hat.

copyright

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Kontaktieren Sie uns über: support.vogel.de/ (ID: 44588888 / Coding & Collaboration)