Open-Source-Maintainer möchten sicher arbeiten, doch 70 % fehlt das nötige Know-how

Willkommen zum jährlichen State of Open Source Security Report 2019 von Snyk. Dieser Bericht ist in mehrere Beiträge unterteilt:

• 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, sind dafür aber nicht gut genug gerüstet

• Open-Source-Maintainer möchten sicher arbeiten, doch 70 % fehlt das nötige Know-how

• Die zehn beliebtesten Docker-Images enthalten jeweils mindestens 30 Schwachstellen

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

• 78 % der Schwachstellen stecken in indirekten Abhängigkeiten und erschweren so die Behebung

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

State of Open Source Security Report 2019 herunterladen

Sicherheitsniveau von Open-Source-Maintainern

Die meisten Entwickler und Maintainer stimmen wahrscheinlich zu, dass Sicherheit beim Erstellen von Produkten und Schreiben von Code eine wichtige Rolle spielen sollte. Für Maintainer gibt es jedoch keine festen Regeln, an die sie sich beim Aufbau von Open-Source-Projekten halten können. Daher können ihre Sicherheitsstandards erheblich variieren.

Maintainer wenden ihre Zeit und Energie unterschiedlichen Aspekten des Projekts zu, häufig funktionalen. Dadurch kann Sicherheit in ihrem Prozess eine geringere Priorität erhalten.

Seit unserem vorherigen Bericht aus dem Jahr 2017 zeichnet sich ein positiver Trend hinsichtlich des Engagements für Sicherheit und des Sicherheitsbewusstseins ab.

Open-Source-Maintainer sagen, ihr Sicherheitswissen verbessere sich, reiche aber noch nicht aus: durchschnittlich 6,6 von 10

In diesem Jahr bewertete die Mehrheit der Befragten ihr Sicherheitswissen als mittelmäßig; der Durchschnitt lag bei 6,6 von 10. Ein kleiner Teil (7 %) schätzte das eigene Wissen als gering ein. Der Anteil der Befragten mit mittelmäßigem Wissen, die Mehrheit, sank tatsächlich auf 63 % gegenüber 56 % im Vorjahr.

Die größten Veränderungen zeigen sich bei den niedrigen und hohen Einstufungen. Im vergangenen Jahr bewerteten nur 17 % ihr Sicherheitswissen als hoch, in diesem Jahr stieg der Anteil auf fast 30 %. Gleichzeitig sehen wir eine ähnliche Entwicklung beim niedrig eingestuften Sicherheitswissen: Im vergangenen Jahr lag der Anteil bei 26 %, in diesem Jahr jedoch nur bei 7 %.

70 % der Open-Source-Maintainer geben an, nicht über fundiertes Sicherheitswissen zu verfügen

Sicherheitsaudits

Ein Sicherheitsaudit kann Teil eines Code-Reviews sein, bei dem Kollegen sicherstellen, dass Best Practices für sicheren Code eingehalten werden. Es kann auch in Form verschiedener Sicherheitsaudits wie statischer oder dynamischer Anwendungssicherheitstests durchgeführt werden. Manuelle und automatisierte Audits sind entscheidend, um Schwachstellen in Ihrer Anwendung zu erkennen und zu reduzieren. Sie sollten so regelmäßig und früh in der Entwicklungsphase wie möglich durchgeführt werden, um Risiken wie Datenlecks und Datenschutzverletzungen zu einem späteren Zeitpunkt zu minimieren.

Jeder vierte Open-Source-Maintainer prüft seine Codebasis nicht

Im vergangenen Jahr gaben 44 % der Befragten an, noch nie ein Sicherheitsaudit durchgeführt zu haben. In diesem Jahr ist der Anteil deutlich niedriger: 26 % der Befragten prüfen ihren Quellcode nicht. Im Vergleich zum Bericht des Vorjahres beobachten wir in diesem Jahr bei allen Audit-Zyklen einen positiven Trend zu wiederholten Prüfungen. Im Durchschnitt prüfen 10 % mehr Befragte ihren Quellcode häufiger – sowohl vierteljährlich als auch jährlich.

Sicherheitsexperten verweisen oft auf das Shift-Left-Prinzip, um dafür zu plädieren, Sicherheitsfragen und potenzielle Probleme früher im Lebenszyklus einer Anwendung anzugehen. Dieser Ansatz kann Entwicklern durch Automatisierung viele wertvolle Erkenntnisse liefern und dem Sicherheitsteam dabei helfen, mit dem hohen Tempo moderner, kontinuierlicher Entwicklung Schritt zu halten.

Shift Left ist besonders im Bereich Sicherheit entscheidend und manchmal sogar kritisch, um die Kosten für Sicherheitsvorfälle zu senken, die erst in der Produktionsumgebung entdeckt werden. Sicherheitsprobleme früher im Prozess anzugehen und die Wahrscheinlichkeit zu erhöhen, dass Entwickler diese Praktiken übernehmen, gelingt unter anderem durch die Auswahl entwicklerfreundlicher Tools, die sich in bestehende Workflows integrieren lassen.

Wie erfahren Maintainer von Schwachstellen?

Es ist wahrscheinlicher, dass Maintainer auf ein Sicherheitsproblem aufmerksam gemacht werden, als dass sie es selbst entdecken. Eine branchenweit anerkannte Best Practice ist eine Richtlinie zur verantwortungsvollen Offenlegung, in der festgelegt wird, wie Sicherheitsforscher und andere Personen Sicherheitslücken sicher an die Projekt-Maintainer melden sollen.

Aus den Umfragedaten lässt sich schließen, dass fast die Hälfte (48 %) der Befragten über einen öffentlichen Kanal von einer Schwachstelle in ihrem Code erfahren – etwa wenn jemand ein öffentliches Issue eröffnet oder sie per E-Mail kontaktiert.

72 % der Befragten gaben an, Schwachstellen in ihrem Code bei einer persönlichen Prüfung des eigenen Codes zu entdecken. 62 % der Befragten schätzen ihr Sicherheitswissen jedoch nur als mittelmäßig ein, während nur 30 % angeben, über hohe Sicherheitsexpertise zu verfügen.

Obwohl die Mehrheit der Befragten (72 %) angibt, den eigenen Code auf Schwachstellen zu prüfen, erfahren 48 % dennoch erst davon, wenn jemand anderes ein öffentliches Issue eröffnet. Das zeigt, wie schwierig es ist, sich auf die Prüfung durch nur einen Maintainer zu verlassen – selbst wenn dieser über gute Sicherheitskenntnisse zu verfügen scheint.

Vom Einbau bis zur Offenlegung

Eine unserer Forschungsfragen lautete: Wie lange dauert es, bis eine Schwachstelle nach ihrem Einbau in die Codebasis entdeckt und offengelegt wird? Um diese Frage zu beantworten, analysierten wir einige der beliebtesten Bibliotheken im npm-Ökosystem sowie die Schwachstellen, die 2018 darin entdeckt wurden.

Da sich dieser Vorgang nur mit hohem Aufwand und schwer zuverlässig automatisieren lässt, untersuchten wir die sechs beliebtesten npm-Bibliotheken und analysierten ihre Codebasen. Dabei betrachteten wir die Zeitspanne zwischen den Commits, durch die eine Schwachstelle eingeführt und behoben wurde. Natürlich sind diese Berechnungen etwas verzerrt, da die Stichprobe so klein ist. Trotzdem sind die Größenordnung und Reihenfolge der Zahlen interessant!

Bei diesen sieben Bibliotheken betrug die kürzeste Zeitspanne von der Einführung bis zur Behebung fast ein Jahr – genau genommen 289 Tage. Die mediane Zeitspanne lag bei fast 2,5 Jahren, der längste beobachtete Fall bei 5,9 Jahren.

Im Fokus: Equifax – ein Jahr später

Ein kürzlich veröffentlichter Bericht der US-Regierung kam zu dem Schluss, dass der berüchtigte Equifax-Datendiebstahl vollständig vermeidbar gewesen wäre. Er verdeutlichte, wie wichtig es ist, Sicherheit durch die Integration in den Entwicklungs-Workflow nach links zu verlagern.

Mit einer DevSecOps-Mentalität und guten Praktiken hätte ein Entwicklungsteam die Auswirkungen der Struts-Schwachstelle verhindern können, wenn:

• Entwickler das Problem mithilfe von Tools zum Scannen von Open-Source-Abhängigkeiten entdeckt hätten, die sich über IDE-Plugins oder Code-Linter in ihren Workflow integrieren lassen.

• Jeder neue Build, der auf einem CI-Server ausgeführt wird, die Anwendungsabhängigkeiten automatisch über ein CI-Server-Plugin oder einen CLI-Aufruf als Task geprüft hätte. So wäre die neue Schwachstelle sofort erkannt, der CI-Job abgebrochen und vor der Fortsetzung eine Behebung erzwungen worden.

• Eine Monitoring-Lösung eingerichtet gewesen wäre, die Entwickler über die neue Schwachstelle in ihren Abhängigkeiten benachrichtigt hätte.

Weitergehendes Monitoring und Erkenntnisse zur Laufzeit über das Verhalten der Anwendung und die von ihr aufgerufenen anfälligen Funktionen hätten auf Schwachstellen in der Struts-Bibliothek aufmerksam machen können.

Korrekturen veröffentlichen

Ein entscheidender Bestandteil einer verantwortungsvollen Offenlegung von Sicherheitslücken ist die Geschwindigkeit, mit der eine Korrektur entwickelt und bereitgestellt wird. Es ist wichtig, die Schwachstelle so schnell wie möglich zu beheben, damit sie kürzer im Code vorhanden ist. Gleichzeitig sollte Nutzern ausreichend Zeit bleiben, auf eine korrigierte Version zu aktualisieren – möglichst bevor die Schwachstelle allgemein bekannt wird.

Da Open-Source-Communities größtenteils von der ehrenamtlichen Arbeit von Entwicklern leben (ein großes Dankeschön an all die wunderbaren Menschen, die zu Open-Source-Software beitragen – Ihre wertvolle Arbeit wird sehr geschätzt und öffentlich viel zu selten gewürdigt!), ist es interessant zu untersuchen, wie schnell Maintainer von Open-Source-Software auf eine Sicherheitslücke reagieren und eine Korrektur bereitstellen können.

Eine überwältigende Mehrheit der Befragten, insgesamt 84 %, gibt an, wahrscheinlich innerhalb von weniger als einer Woche eine Korrektur bereitzustellen. 56 % würden das Problem voraussichtlich innerhalb eines Tages beheben, während 22 % eine Sicherheitslücke binnen weniger Stunden nach ihrer Meldung beheben könnten – nicht alle Helden tragen Umhänge!

Behebungsgeschwindigkeit

Anhand der Snyk Vulnerability Database können wir feststellen, welche Pakete Versionen mit Korrekturen für Schwachstellen veröffentlicht haben. Für einige Ökosysteme ergibt sich dabei ein weniger erfreuliches Bild – wir meinen dich, JavaScript! Java und Python zeigen ein starkes Engagement für die Behebung von Sicherheitsschwachstellen. Bei JavaScript und Node.js insgesamt verfügen jedoch nur 59 % der Pakete über bekannte Korrekturen für offengelegte Schwachstellen.

Im Fokus: Verantwortungsvolle Offenlegung von Sicherheitslücken

Ein wesentlicher Vorteil einer Richtlinie zur verantwortungsvollen Offenlegung ist, dass sie Nutzer vor Schaden bewahrt. Wird eine Schwachstelle vertraulich an den Projekt-Maintainer gemeldet und von ihm bewertet, kann dieser eine Korrektur vorbereiten, bevor die Informationen öffentlich werden. Wenn Maintainer schnell handeln und eine Korrektur veröffentlichen, erhalten Nutzer ein Zeitfenster, in dem sie auf die korrigierte Version aktualisieren können. Dadurch sinkt die Zahl der Nutzer, die anfällige Versionen verwenden, erheblich.

Wir sind überzeugt, dass eine Richtlinie zur verantwortungsvollen Offenlegung auch das hohe Engagement eines Maintainers für Sicherheit vermittelt. Als Best Practice empfehlen wir ein entsprechendes Badge auf der Homepage des Projekts und eine SECURITY.MD-Richtlinie im Repository des Projekts.

Im letzten Bericht stellten wir fest, dass Maintainer mit einer öffentlich zugänglichen Richtlinie zur Offenlegung deutlich häufiger vertrauliche Meldungen von Nutzern erhalten als Maintainer ohne eine solche Richtlinie.

Etwa 21 % der Maintainer ohne öffentlich zugängliche Richtlinie zur Offenlegung wurden privat über eine Schwachstelle informiert. Bei Maintainer mit einer solchen Richtlinie waren es 73 %.

Websites sind anfällig für Web-Sicherheitsschwachstellen und profitieren von klaren Richtlinien zur Websicherheit. Ein neuer Vorschlag, der hier Abhilfe schaffen soll, ist SECURITY.TXT (RFC 5785), der bereits früh angenommen wurde. Eine solche Richtliniendatei soll Sicherheitsforschern die relevanten Kontakte, bevorzugten Sprachen, die genauen Richtlinien und Kommunikationswege vermitteln – einschließlich öffentlicher Schlüssel, um Sicherheitslücken sicher und effizient offenzulegen.

Lesen Sie weiter:

• 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, sind dafür aber nicht gut genug gerüstet

• Open-Source-Maintainer möchten sicher arbeiten, doch 70 % fehlt das nötige Know-how

• Die zehn beliebtesten Docker-Images enthalten jeweils mindestens 30 Schwachstellen

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

• 78 % der Schwachstellen stecken in indirekten Abhängigkeiten und erschweren so die Behebung