Eine halbe Million Sicherheitslücken beheben

Hackathons sind in Softwareentwicklungsteams dafür bekannt, Innovation und Zusammenarbeit zu fördern. Was wäre also, wenn wir dieses Modell auf die Cybersicherheit übertragen würden, um die Anwendungssicherheit eines Unternehmens zu verbessern? Für jeden CISO und jede Sicherheitsexpertin und jeden Sicherheitsexperten wäre das ein Traum – und genau das haben wir uns bei Snyk im Februar 2023 vorgenommen.

Sehen Sie sich einige der witzigsten Momente aus unseren Panels an.

Wir hatten uns zum Ziel gesetzt, 200.000 Sicherheitslücken zu beheben. So ist es ausgegangen.

Ein Security-Fix-a-thon

Damit eine Veranstaltung erfolgreich ist, müssen Entwicklerinnen und Entwickler sowie Sicherheitsexpertinnen und Sicherheitsexperten Spaß haben und gleichzeitig neue Fähigkeiten erlernen, die sie in ihren privaten oder beruflichen Projekten anwenden können. Deshalb haben wir Folgendes auf die Beine gestellt:

1. Mit kontinuierlicher Unterstützung können Hackathon-Teilnehmende ihren Kolleginnen und Kollegen in der Discord-Community von Snyk beitreten, um Sicherheitslektionen zu erhalten und Hilfe bei der Behebung von Problemen zu bekommen.

2. Ein 24-stündiger Livestream, der unser Versprechen einlöste, Wissen zu vermitteln, war ein zentrales Ereignis beim diesjährigen Big Fix. Den weltweiten 24-stündigen Livestream veranstalteten wir auf YouTube und Twitch. Mit dabei waren Speakerinnen und Speaker von Atlassian, Dynatrace, Morgan Stanley, The Linux Foundation, Sysdig, AWS, StackHawk und weiteren Unternehmen.

3. Preise: Wir wollten die Anstrengungen aller Teilnehmenden würdigen, sicherere Software zu entwickeln. Daher erhielt jede Person, die mindestens eine Sicherheitslücke behoben hatte, ein T-Shirt in limitierter Auflage von The Big Fix oder ein OpenCollective-Guthaben im Wert von 15 $, das für Spenden an Open-Source-Projekte und deren Maintainer verwendet werden konnte.

4. Rangliste: Für einen zusätzlichen Wettbewerbsanreiz veröffentlichten wir eine Rangliste der erfolgreichsten Personen. Die drei Teilnehmenden, die die meisten Sicherheitslücken behoben hatten, erhielten jeweils ein VR-Headset (1. Platz), einen kabellosen Lautsprecher (2. Platz) und ein Arduino-Starterkit (3. Platz).

Das Tolle am Hackathon war, dass Sie keine Vorkenntnisse in Anwendungssicherheit oder Cloud-Sicherheit brauchten, um teilzunehmen und in der Rangliste aufzusteigen.

Das verdanken wir Snyks Developer-First-Mentalität, dem umfassenden Integrationsökosystem und den Funktionen zur automatisierten Fehlerbehebung, mit denen Sie Sicherheitsprobleme einfach finden und beheben können. Egal, ob Sie in der Entwicklung, in DevOps, im Sicherheitsbereich oder in der Qualitätssicherung tätig sind – Snyk bietet Ihnen die nötigen Tools, um direkt loszulegen.

Jetzt ist ein idealer Zeitpunkt, um mit Snyk Code, Snyk Open Source, Snyk Container und Snyk Cloud zu starten.

Die Software der Welt schützen

Wie ist es also gelaufen? The Big Fix ist abgeschlossen – werfen wir einen Blick auf die Daten und die Ergebnisse einer Veranstaltung, die Entwicklerinnen und Entwickler dazu befähigt, Sicherheitsprobleme zu beheben.

Innerhalb eines Monats trugen die Teilnehmenden von The Big Fix 597.589 Sicherheitskorrekturen zu ihren Softwareprojekten bei – egal, ob diese geschlossen oder Open Source waren. Mehr als 1.800 Personen meldeten sich für die Veranstaltung an. Darunter waren über 120 Snyk-Mitarbeitende, mehr als 220 Kundinnen und Kunden und über 1.480 Entwicklerinnen und Entwickler aus verschiedenen Unternehmen.

Wir haben die Snyk-Datenbank genauer untersucht, um festzustellen, welche Auswirkungen die Veranstaltung auf Projekte hatte, die mit Snyk überwacht werden. Die folgenden Kennzahlen und Erkenntnisse umfassen daher sämtliche Produktanalysen zu Kontoaktivitäten, die im Rahmen der Veranstaltung erfasst wurden. Dazu zählen mehr Projekte sowie mehr gefundene und behobene Sicherheitslücken als nur die Projekte, die zum Hackathon hinzugefügt wurden.

Container-Images sind besonders anfällig für Sicherheitslücken, lassen sich aber auch besonders gut korrigieren.

Von den Millionen Sicherheitslücken, die in den mit Snyk überwachten Container-, Code- und Infrastrukturprojekten erkannt wurden, wiesen Projekte, die als Docker-Container-Projekte klassifiziert waren, eine Behebungsquote von 73,3 % auf. Ein wesentlicher Grund für diese hohe Behebungsquote ist sicherlich, dass Snyk Container automatisierte Pull-Request-Korrekturen mit Empfehlungen für Basis-Images bereitstellt und so proaktiv alternative Container-Images mit weniger Sicherheitslücken vorschlägt.

Bei Sicherheitsmaßnahmen für Code und Abhängigkeiten ist die Behebungsquote vergleichsweise niedrig. Snyk Code konnte mehr als 82.160 potenzielle Sicherheitslücken im Code finden; die Teilnehmenden behoben davon 10,2 %. Bei Snyk Open Source, das öffentlich bekannte Sicherheitslücken in Open-Source-Abhängigkeiten erkennt, lag die Behebungsquote bei 14,4 %. Da Korrekturen für Abhängigkeiten automatisiert per Pull Request vorgenommen werden und Sicherheitsprobleme im Code mithilfe der Empfehlungs-Engine von Snyk direkt in der IDE behoben werden, konnten Tausende Sicherheitslücken frühzeitig (und schnell) im Entwicklungsprozess entschärft werden.

Werfen wir einen genaueren Blick auf den Datensatz der Container-Image-Projekte. Bei den zehn führenden Docker-Container-Projekten, die Snyk überwacht hat, wurde ein bemerkenswert hoher Anteil der Sicherheitsprobleme behoben – das bestätigt die vorherige Aussage, dass sich diese Probleme viel einfacher und schneller beheben lassen. Ubuntu-Basisdistributionen und Container-Images wie ubuntu:rolling und node-Images weisen Behebungsquoten von über 90 % auf.

13–30 % aller öffentlich bekannten Sicherheitslücken werden früher und schneller behoben

Betrachten wir einzelne Sprachökosysteme genauer, können wir auch die Behebungsquoten für die jeweiligen Programmiersprachen untersuchen. Diese Werte können verzerrt sein, wenn Sicherheitslücken mit geringer Bedeutung entdeckt werden, etwa in Entwicklungskomponenten. Andere Ursachen sind möglicherweise nicht behebbare Sicherheitsprobleme in nicht mehr gepflegten Codeprojekten. Insgesamt liegt die Behebungsquote bei Sicherheitslücken in Abhängigkeiten bei etwa 13–30 %. Sie lässt sich automatisieren, damit sich Softwareentwicklerinnen und -entwickler auf die Entwicklung von Anwendungen konzentrieren können, anstatt Sicherheitsprobleme zu bearbeiten.

Go-Code ist anfällig für Fehler bei der Abwehr von Denial-of-Service-Angriffen, im Kontrollfluss und beim sicheren Umgang mit Zeigern

Die am häufigsten behobenen Sicherheitslücken in Go zeigen, dass Entwicklerinnen und Entwickler Zeit darauf verwenden, Fehler beim sicheren Umgang mit dem Programmfluss, Denial-of-Service-Angriffen und Zeigern zu beheben. Die folgenden fünf Sicherheitslücken wurden in Go-Projekten am häufigsten behoben:

• CWE-400: Unkontrollierter Ressourcenverbrauch

• CWE-266: Falsche Zuweisung von Berechtigungen

• CWE-787: Schreiben außerhalb des zulässigen Speicherbereichs

• CWE-674: Unkontrollierte Rekursion

• CWE-476: Dereferenzierung eines NULL-Zeigers

Python-Projekte sind besonders anfällig für Speicherprobleme, Fehler bei der Eingabevalidierung und Probleme im Programmfluss

Die häufigsten Arten von Sicherheitslücken in Python ähneln denen in Go-Projekten. Dazu zählen unkontrollierter Ressourcenverbrauch sowie Lese- und Schreibzugriffe außerhalb des zulässigen Speicherbereichs. Weitere häufige Sicherheitslücken in Python-Codebasen sind:

• CWE-369: Division durch null

• CWE-617: Erreichbare Assertion

• CWE-1333: Ineffiziente Komplexität regulärer Ausdrücke

Java- und JavaScript-Codebasen weisen ähnliche häufige Sicherheitslücken auf

Unter den zehn häufigsten Arten von Sicherheitslücken, die wir während The Big Fix überwacht haben, fanden wir eine Reihe von CWEs, die sowohl in Java- als auch in JavaScript-Codebasen vorkommen:

• CWE-400: Unkontrollierter Ressourcenverbrauch

• CWE-94: Unsachgemäße Kontrolle der Codegenerierung („Code Injection“)

• CWE-22: Unsachgemäße Beschränkung eines Pfadnamens auf ein eingeschränktes Verzeichnis („Path Traversal“)

• CWE-200: Offenlegung sensibler Informationen gegenüber einer nicht autorisierten Person

Ruby ist besonders anfällig für Denial-of-Service-Angriffe, Cross-Site-Scripting und HTTP-Request-Smuggling

Ruby ist vor allem für Ruby on Rails bekannt und wird hauptsächlich in der Webentwicklung eingesetzt. Daher überrascht es nicht, dass die fünf häufigsten Sicherheitslücken, die auch während der Veranstaltung behoben wurden, Risiken für Webanwendungen darstellen:

• CWE-1333: Ineffiziente Komplexität regulärer Ausdrücke

• CWE-400: Unkontrollierter Ressourcenverbrauch

• CWE-79: Unsachgemäße Neutralisierung von Eingaben bei der Generierung von Webseiten („Cross-Site-Scripting“)

• CWE-444: Uneinheitliche Interpretation von HTTP-Anfragen („HTTP Request/Response Smuggling“)

• CWE-200: Offenlegung sensibler Informationen gegenüber einer nicht autorisierten Person

Tatsächlich gehört HTTP-Request-Smuggling zu den weniger bekannten Sicherheitsproblemen, die von den Teilnehmenden am häufigsten gefunden und behoben wurden.

Die am einfachsten zu behebenden Sicherheitslücken wurden mit Static Application Testing entdeckt

Static Application Testing ist ein Ansatz, der Einblicke auf Codeebene und Codepfad-Workflows wie abstrakte Syntaxbäume nutzt, um potenzielle Sicherheitslücken und unsichere Programmierkonventionen zu erkennen. So erhalten Entwicklerinnen und Entwickler frühzeitig Feedback und können Sicherheitsbedenken bereits beim Schreiben des Codes berücksichtigen – statt erst später im Entwicklungsprozess, wenn die Funktionen bereits fertiggestellt sind.

Snyk Code stellt in die IDE integrierte Sicherheitseinblicke und Empfehlungen zur Fehlerbehebung bereit, die Entwicklerinnen und Entwickler einfach übernehmen können, indem sie die VS-Code-Erweiterung installieren (IntelliJ und andere IDEs werden ebenfalls unterstützt). Brian Clark und Nate Michalov zeigen in dieser Live-Coding-Session, wie Sie Sicherheitsprobleme finden und beheben:

Play Video: How to Get Started with Snyk Code (feat. Nate Michalov) - The Big Fix 2022 by Snyk

Von allen Sicherheitsproblemen, die das Snyk-Code-SAST-Tool erkannt hat, traten die folgenden Arten am häufigsten auf:

• CWE-94: Unsachgemäße Kontrolle der Codegenerierung („Code Injection“)

• CWE-79: Unsachgemäße Neutralisierung von Eingaben bei der Generierung von Webseiten („Cross-Site-Scripting“)

• CWE-916: Verwendung eines Passwort-Hashes mit unzureichendem Rechenaufwand

• CWE-798: Verwendung fest im Code hinterlegter Zugangsdaten

• CWE-352: Cross-Site-Request-Forgery (CSRF)

Wie geht es weiter?

Wir möchten uns bei allen bedanken, die dieses Jahr an The Big Fix teilgenommen haben. Außerdem möchten wir Sie zu einer unserer kommenden öffentlichen Veranstaltungen einladen. Dort können Sie mehr über Anwendungssicherheit erfahren und andere Fachleute aus der Cybersicherheit kennenlernen:

• CTF 101 Workshop (25. Mai 2023): In diesem praxisorientierten Workshop lernen Sie, Capture-the-Flag-Herausforderungen zu lösen!

• Ethical Hacking Workshop (21. Juni 2023): In diesem praxisorientierten Workshop lernen Sie ethisches Hacking und verantwortungsvolle Offenlegung kennen.

• DevSecCon (27. Juni 2023): Unsere wichtigste Community-Konferenz rund um DevSecOps.

Wenn Sie sich mit Gleichgesinnten aus Entwicklung und Sicherheit austauschen möchten, treten Sie dem DevSecOps Discord bei.