Neues O’Reilly-Buch: Open-Source-Bibliotheken absichern – von Guy Podjarny

Snyk hat sich mit O’Reilly zusammengetan, um ein neues Buch anzubieten: Open-Source-Bibliotheken absichern: Schwachstellen in Open-Source-Codepaketen verwalten.  In diesem Buch behandelt Snyk-CEO und -Gründer Guy Podjarny eine Reihe von Themen, die Ihnen dabei helfen, das Risiko durch anfällige Open-Source-Bibliotheken zu bewältigen, die heute von Ihren Anwendungen genutzt werden. 

Anfällige Abhängigkeiten sind der wahrscheinlichste Teil Ihrer Anwendung, den Angreifer ausnutzen. Das Buch behandelt einige der wichtigsten Best Practices und Tools, mit denen Sie Ihre Anwendungen im großen Maßstab schützen können.

Laden Sie jetzt Ihr kostenloses Buch herunter!

Guy erklärt zunächst, was eine bekannte Schwachstelle ist und wie sie öffentlich dokumentiert wird, etwa in den CVE- und NVD-Datenbanken. Außerdem erläutert er, warum es nicht ausreicht, sich allein darauf zu verlassen. Darüber hinaus geht Guy auf verantwortungsvolle Offenlegung ein und zeigt, welche Schritte Sie bei Schwachstellen unternehmen können, die Sie entdecken.

In Kapitel 2 geht Guy auf den Kern des Buches ein und zeigt, wie Schwachstellen über mehrere Pfade in Ihre Anwendung gelangen können. Dazu kommt es, wenn eine anfällige Bibliothek mehrfach in Ihrem Abhängigkeitsbaum vorkommt.

Nehmen Sie eine App, die zwei Pakete, A und B, verwendet, wobei A ebenfalls B (in derselben Version) nutzt. Daraus ergibt sich folgender Abhängigkeitsbaum:

Nehmen wir nun an, B@1.0.0 weist eine bekannte Denial-of-Service-Schwachstelle (DoS) auf. Wie viele Schwachstellen sollten wir melden, wenn wir die App testen? Einerseits weist die App nur eine bekannte Schwachstelle auf: DoS in B@1.0.0. Andererseits gibt es zwei Instanzen dieser Schwachstelle. Was sollten wir melden: eine oder zwei?

Ein weiteres wichtiges Thema ist die Frage, wann getestet werden sollte. Das Buch beleuchtet die Vorteile von Tests auf Quelltextebene ebenso wie die von Tests an erstellten Anwendungen. Tests des Quelltexts liefern jedoch nur Näherungswerte, während Tests einer erstellten Anwendung präzisere Ergebnisse liefern. Die beste Lösung: beides nutzen!

Um beides zu kombinieren, testen bestimmte Tools _erstellte_Apps, suchen aber auch nach Paketmanifestdateien, erstellen einen logischen Baum und versuchen, die gefundenen Bibliotheken darin einzuordnen. So profitieren Sie von der Testabdeckung für erstellte Apps und – soweit möglich – von der quellcodebasierten Analysetiefe.

Alternativ können Sie beide Ansätze in unterschiedlichen Phasen Ihrer Entwicklung einsetzen. So können Sie beispielsweise das Scannen des Quellcodes in Ihren GitHub-/GitLab-/BitBucket-Workflow integrieren und Tests erstellter Apps während des Build-Prozesses oder als Deployment-Gate durchführen. In den meisten Fällen liefern beide Ansätze dieselben Ergebnisse und ergänzen sich. Wenn nicht, stellen die Tests der erstellten App sicher, dass Sie keine anfällige Anwendung bereitstellen. 

Das Kapitel behandelt, wie Sie bekannte Schwachstellen in Ihrem SCM, über die Befehlszeile, in Container-Registries und im Browser finden können. Das ist jedoch nur die halbe Geschichte. Spannender wird es, wenn Sie auf die gefundenen Daten reagieren müssen. Guy erklärt, wie Sie direkte und indirekte Abhängigkeiten aktualisieren und Patches anwenden, wenn es keine Upgrade-Pfade gibt. In einigen Programmiersprachen kann es trotzdem zu Konflikten kommen:

Viele Programmiersprachen, etwa Ruby und Python, erfordern globale Abhängigkeiten. Clients wie Rubys bundler und Pythons pip bestimmen, welche Bibliotheksversionen gleichzeitig verwendet werden können. Daher kann das Aktualisieren einer Bibliothek Konflikte mit einer anderen auslösen. Entwicklerinnen und Entwickler können solche Konflikte zwar meist bewältigen, manchmal lassen sich diese Probleme jedoch einfach nicht lösen.

Neben Schwachstellen in Anwendungen geht das Buch auch darauf ein, wie Sie Schwachstellen in Ihren Container-Images beheben können. Guy erklärt, dass es für Schwachstellen im Betriebssystem im Gegensatz zu Anwendungsschwachstellen seltener eine korrigierte Version gibt, auf die Sie einfach aktualisieren können. Deshalb kommt es umso mehr auf eine gute Priorisierung an. 

Kapitel 4 behandelt ein besonders wichtiges Thema in der schnelllebigen, modernen Entwicklungswelt von heute: Sicherheitstests in bestehende Pipelines integrieren, damit Änderungen während ihrer Weiterleitung in die Produktion getestet werden. Dies wird häufig als DevSecOps-Pipeline bezeichnet.

Laden Sie das vollständige Buch herunter!

Schnelle Behebung vorbereiten

Ein wichtiger Teil des gesamten Prozesses ist die Frage, wie Ihre Teams auf neu entdeckte Schwachstellen reagieren – sei es aufgrund einer Codeänderung oder weil eine neue Schwachstelle offengelegt wurde. An wen sollten Sie sich wenden, wenn eine neue Sicherheitsbenachrichtigung eingeht? An das Sicherheitsteam? An die Entwickler? An die Geschäftsleitung? Wie schnell sollten Sie auf Probleme unterschiedlicher Art und Schwere reagieren? Sollten Sie Builds wegen neuer Schwachstellen abbrechen? Sind Sie durch Aktualisierungen in der Abhängigkeitskette gefährdet? Laden Sie jetzt das Buch herunter, um praktische Anleitungen und weitere Tipps für den Einstieg in die Absicherung Ihrer Open-Source-Bibliotheken zu erhalten.