78 % der Schwachstellen stecken in indirekten Abhängigkeiten – das erschwert die Behebung

Willkommen zum jährlichen Bericht „State of Open Source Security 2019“ von Snyk. Dieser Bericht besteht aus mehreren Beiträgen:

• Maven-Central-Pakete verdoppelt; eine Viertelmillion neue Pakete in npm indexiert

• 88 % mehr Schwachstellen in Anwendungsbibliotheken innerhalb von zwei Jahren

• 81 % finden, dass Entwickler für Sicherheit verantwortlich sein sollten, diese dafür aber nicht ausreichend gerüstet sind

• Open-Source-Maintainer wollen für Sicherheit sorgen, doch 70 % fehlt es an den nötigen Fähigkeiten

• Jedes der zehn beliebtesten Docker-Images enthält mindestens 30 Schwachstellen

• ReDoS-Schwachstellen in npm steigen um 143 %, und XSS nimmt weiter zu

• 78 % der Schwachstellen stecken in indirekten Abhängigkeiten – das erschwert die Behebung

Oder laden Sie unseren liebevoll gestalteten PDF-Bericht herunter, der all diese Informationen und noch mehr an einem Ort bündelt.

Bericht „State of Open Source Security 2019“ herunterladen

Indirekte Abhängigkeiten

Es ist kaum vorstellbar, Software ohne Open-Source-Abhängigkeiten zu schreiben. Abhängigkeiten eines Projekts zu verwalten, ist eine wichtige Aufgabe und erfordert die nötige Sorgfalt, damit Sie den Überblick über die verwendeten Bibliotheken behalten. Schließlich umfasst die bereitgestellte Anwendung sowohl Ihren Code als auch Ihre Abhängigkeiten.

Die meisten Abhängigkeiten in npm, Maven und Ruby sind indirekte Abhängigkeiten, die von den wenigen explizit definierten Bibliotheken angefordert werden. Schwachstellen in indirekten Abhängigkeiten machen 78 % aller Schwachstellen aus.

Snyk hat über eine Million Projekt-Snapshots gescannt und festgestellt, dass Schwachstellen in indirekten Abhängigkeiten 78 % aller Schwachstellen ausmachen. Das unterstreicht den dringenden Bedarf an einem klaren Einblick in den Abhängigkeitsbaum und daran, die Besonderheiten eines anfälligen Pfads genau hervorzuheben, um diese Schwachstellen zu beheben.

Schwachstellen in einer Abhängigkeit zu finden, ist natürlich nur der erste Schritt. Komplexer ist es, alle Pfade im Abhängigkeitsbaum genau zu ermitteln, über die sich die anfällige Abhängigkeit erreichen lässt.

Noch anspruchsvoller und interessanter ist es, Maßnahmen vorzuschlagen, mit denen sich die Schwachstelle beseitigen lässt, ohne die Kompatibilität zwischen den Abhängigkeiten zu beeinträchtigen.

Risiken und Auswirkungen

Nur jeder dritte Entwickler kann eine Schwachstelle mit hohem oder kritischem Schweregrad innerhalb eines Tages oder weniger beheben.

Es dürfte die meisten nicht überraschen, dass Sicherheit im diesjährigen Bericht „State of the Octoverse“ von GitHub die beliebteste Kategorie für Projektintegrations-Apps ist – mit mehr als einer Integration für Entwickler. Hier ein Zitat des Branchenanalysten Gartner aus einem aktuellen Bericht zur Anwendungssicherheit, in dem es um die Notwendigkeit geht, Sicherheit so früh wie möglich im Anwendungslebenszyklus zu testen.

Fast die Hälfte (43 %) der Befragten hat mindestens 20 direkte Abhängigkeiten. Das verstärkt den Bedarf, Open-Source-Schwachstellen zu überwachen, die über diese Bibliotheken eingeführt werden.

Je mehr wir Open-Source-Software nutzen, desto größer wird das Risiko: Wir binden Code von anderen ein, der bereits jetzt oder künftig Schwachstellen enthalten kann. Darüber hinaus geht es beim Risiko nicht nur darum, wie sicher der Code ist, sondern auch um die Lizenzkonformität des übernommenen Codes und darum, ob dieser Code gegen seine Lizenz verstößt.

Werden Sie aktiv

Die Zusammensetzung von Anwendungen ist komplex. Als Maintainer und Entwickler von Open-Source-Software können Sie Maßnahmen ergreifen, um die Sicherheit der Projekte zu verbessern, die Ihnen gehören oder zu denen Sie beitragen.

Open-Source-Maintainer

Als Open-Source-Maintainer sollten Sie sichere Versionen Ihres Codes bereitstellen und eine Kommunikationsstrategie für dessen Nutzer entwickeln. So können Sie andere Projekte und Anwendungen positiv beeinflussen – und wahrscheinlich auch Ihren eigenen Projekten zugutekommen.

• Führen Sie nach Möglichkeit gemeinsam mit Ihren Kollegen sichere Code-Reviews durch und halten Sie sich an Best Practices für sicheren Code. Nehmen Sie Sicherheitsaspekte in Ihre Code-Review-Checkliste auf und schulen Sie die Reviewer, damit sie wissen, worauf sie achten müssen.

• Prüfen Sie Ihre Codebasis regelmäßig auf Schwachstellen, zum Beispiel mithilfe statischer und dynamischer Codeanalysen. Diese lassen sich in Ihren Entwicklungs-Workflow integrieren und automatisieren, damit Sie Schwachstellen leichter erkennen, bevor sie öffentlich werden.

• Legen Sie einen einfachen, klaren Prozess für die Kommunikation verantwortungsvoller Offenlegungen fest – mit einer eigenen Richtlinie oder durch Weiterleitung an ein bestehendes Programm. Um Ihr Sicherheitsbewusstsein zu vermitteln, können Sie eine SECURITY.MD-Richtlinie und ein Projekt-Badge einführen, das den Sicherheitsstatus des Projekts widerspiegelt.

• Setzen Sie eine Shift-Left-Sicherheitsstrategie um, die Ihrem Team während der Entwicklung, in CI und sogar beim Erstellen von Pull Requests Einblick in Sicherheitsprobleme gibt. So verhindern Sie, dass anfälliger Code in Ihre Projekte gelangt.

Open-Source-Entwickler

Wenn Sie Open-Source-Komponenten verwenden, müssen Sie die direkten und indirekten Abhängigkeiten Ihrer Projekte genau kennen – einschließlich möglicher Sicherheitslücken im Abhängigkeitsbaum. Beachten Sie die folgenden Sicherheitsrichtlinien:

• Prüfen Sie Ihre Codebasis regelmäßig mit einem Tool, das Schwachstellen in Drittanbieter-Abhängigkeiten automatisch erkennt, Ihrem Team Empfehlungen zur Behebung gibt und die Abhängigkeiten eines Projekts auch nach dessen Bereitstellung überwacht.

• Halten Sie sich bei der Meldung einer Sicherheitslücke an die Richtlinien für verantwortungsvolle Offenlegung, damit Sie Nutzer nicht gefährden. Wenn Sie nicht wissen, wie Sie dabei vorgehen sollen, wenden Sie sich an ein Sicherheitsunternehmen, das Sie durch den Offenlegungsprozess begleitet, etwa an das Programm für verantwortungsvolle Offenlegung von Snyk.

• Abonnieren Sie die Sicherheitskanäle Ihrer Open-Source-Abhängigkeiten, sofern vorhanden. So erfahren Sie von möglichen Schwachstellen, sobald diese gemeldet werden.

Lesen Sie weiter in unseren Beiträgen mit den wichtigsten Erkenntnissen:

• Maven-Central-Pakete verdoppelt; eine Viertelmillion neue Pakete in npm indexiert

• 88 % mehr Schwachstellen in Anwendungsbibliotheken innerhalb von zwei Jahren

• 81 % finden, dass Entwickler für Sicherheit verantwortlich sein sollten, diese dafür aber nicht ausreichend gerüstet sind

• Open-Source-Maintainer wollen für Sicherheit sorgen, doch 70 % fehlt es an den nötigen Fähigkeiten

• Jedes der zehn beliebtesten Docker-Images enthält mindestens 30 Schwachstellen

• ReDoS-Schwachstellen in npm steigen um 143 %, und XSS nimmt weiter zu

• 78 % der Schwachstellen stecken in indirekten Abhängigkeiten – das erschwert die Behebung