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

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

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

• 88 % mehr Sicherheitslücken in Anwendungbibliotheken innerhalb von zwei Jahren

• 81 % glauben, 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 das nötige Know-how

• Die zehn beliebtesten Docker-Images enthalten jeweils mindestens 30 Sicherheitslücken

• ReDoS-Sicherheitslücken in npm steigen um 143 %, XSS nimmt weiter zu

• 78 % der Sicherheitslücken finden sich in indirekten Abhängigkeiten, was die Behebung komplex macht

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

Bericht „State of Open Source Security 2019“ herunterladen

Verantwortung für Open-Source-Sicherheit

Wir wollten herausfinden, wer in der Praxis heute für die Sicherheit einer Anwendung oder Bibliothek verantwortlich ist und wem Nutzer diese Verantwortung zuschreiben.

81 % der Befragten sind der Meinung, dass Entwickler für die Sicherheit des Anwendungscodes verantwortlich sein sollten. Das ist ein deutliches Signal dafür, wie stark Entwickler eingebunden sein und sich engagieren sollen, und unterstützt die starke DevSecOps-Bewegung, der sich heute viele anschließen.

Ein sinnvoller Ansatz, um Sicherheit als Teil des SDLC zu etablieren, besteht darin, sie über den gesamten Entwicklungszyklus hinweg zu integrieren – vom Entwurf bis zur Produktion. Das unterscheidet sich deutlich von der traditionelleren, einmaligen Sicherheitsprüfungsphase, die in regelmäßigen Abständen stattfindet und nicht zum modernen, schnellen Modell der Softwarebereitstellung passt. Prozesse und Richtlinien allein reichen jedoch möglicherweise nicht aus. Schulungen, benutzerfreundliche Tools und die Einbindung von F&E-Teams und Stakeholdern sind ebenso wichtig, damit Sicherheitspraktiken in einem Unternehmen erfolgreich etabliert werden.

Sicherheitslücken entdecken

Um den eigenen Code sorgfältig auf potenzielle Sicherheitslücken zu überprüfen, braucht es viel Fachwissen und Erfahrung sowie einen scharfen Blick. Da dies keine einfache Aufgabe ist, legt sie – sofern sie überhaupt durchgeführt wird – nahe, dass anfälliger Code lange unentdeckt bleiben kann, bis ihn jemand aufspürt.

37 % der Nutzer führen während der CI keine Sicherheitstests durch

Teams, die DevOps praktizieren oder über eine ausgereifte CI/CD-Pipeline verfügen, können Sicherheitstests möglicherweise leichter in ihre Build-Automatisierung integrieren. Dennoch stellen wir fest, dass fast 40 % der Nutzer bei ihren CI-Läufen keinerlei Sicherheitstests durchführen. Erfreulich ist jedoch, dass mehr als die Hälfte von ihnen zumindest ihre Open-Source-Abhängigkeiten auf Sicherheitslücken prüft.

Eine weitere Erkenntnis unserer Untersuchung: Teams, die Sicherheit in ihre Arbeit integrieren, schneiden auch bei der kontinuierlichen Bereitstellung besser ab. Ein wesentlicher Faktor dabei ist, dass Informationssicherheitsteams vorab genehmigte, leicht nutzbare Bibliotheken, Pakete, Toolchains und Prozesse bereitstellen, die Entwickler und IT-Betriebsteams bei ihrer Arbeit einsetzen können.

Nicole Forsgren, Accelerate

Von Sicherheitslücken erfahren

Aus Sicht der Nutzer ist es interessant zu erfahren, wie sie von Sicherheitslücken in den Abhängigkeiten ihrer Anwendungen erfahren, damit sie auf potenzielle Bedrohungen reagieren können, sobald diese entdeckt werden.

Besorgniserregende 27 % der Befragten gaben an, dass sie keine proaktive oder automatische Möglichkeit haben, von neu entdeckten Sicherheitslücken in ihren Anwendungen zu erfahren. Nur 36 % der Nutzer bestätigten, dass sie ein Abhängigkeitsmanagement- oder Scan-Tool einsetzen, um Sicherheitslücken aufzuspüren.

Snyk-Zahlen

• Allein im zweiten Halbjahr 2018 eröffnete Snyk für seine Nutzer mehr als 70.000 Pull Requests in den Maven-, RubyGems- und npm-Ökosystemen, um Sicherheitslücken in ihren Projekten zu beheben.

• Bei 60 % aller Abhängigkeiten in einem gescannten Java-Projekt stellte Snyk einen Behebungspfad für die gefundenen Sicherheitslücken bereit. Behebungspfade lassen sich nicht immer bereitstellen, wenn eine direkte Abhängigkeit nicht mit einer korrigierten Version einer indirekten Abhängigkeit kompatibel ist. In einigen solchen Fällen kann das Snyk-Sicherheitsteam individuelle Patches bereitstellen.

Wie schnell werden Sicherheitskorrekturen übernommen?

Wie lange dauert es, bis Nutzer neue Releases mit Sicherheitskorrekturen für bekannte Sicherheitslücken übernehmen? Als Beispiel haben wir uns die PyPI-Registry von Python und das Paket websockets angesehen, um herauszufinden, wie beliebt anfällige Releases auch nach der Veröffentlichung einer Sicherheitskorrektur noch waren.

Das websockets-Projekt ist ein recht beliebtes und gut gepflegtes Paket. Es besteht seit 2013 und wird bis heute regelmäßig aktualisiert.

Im August 2018 wurde der Community eine Denial-of-Service-Sicherheitslücke gemeldet, die die Paketversionen 4.0 und 4.0.1 betraf. Zum Zeitpunkt der Offenlegung waren bereits neuere Versionen mit der Sicherheitskorrektur in der Registry verfügbar. Die Downloadzahlen der anfälligen Versionen zeigen jedoch, dass Nutzer websockets noch lange Zeit in anfälligen Versionen heruntergeladen haben.

Im Dezember 2018 verzeichneten wir immer noch 11.000 Downloads des Pakets websockets mit der Sicherheitslücke, obwohl mit Version 5.0 ein korrigiertes Major-Upgrade verfügbar war.

 Lesen Sie weiter:

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

• 88 % mehr Sicherheitslücken in Anwendungbibliotheken innerhalb von zwei Jahren

• 81 % glauben, 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 das nötige Know-how

• Die zehn beliebtesten Docker-Images enthalten jeweils mindestens 30 Sicherheitslücken

• ReDoS-Sicherheitslücken in npm steigen um 143 %, XSS nimmt weiter zu

• 78 % der Sicherheitslücken finden sich in indirekten Abhängigkeiten, was die Behebung komplex macht