Open-Source-Sicherheit mit O’Reilly-Autor Guy Podjarny

Letzte Woche nahm Snyk-Mitgründer Guy Podjarny an einem Live-Gespräch teil, um über sein O’Reilly-Buch Securing Open Source Libraries zu sprechen. Dieser Beitrag fasst einige der interessanten Erkenntnisse aus dem Webinar zusammen. Wenn Sie noch nicht dazu gekommen sind, können Sie sich die Aufzeichnung auch hier ansehen. Snyk stellt Ihnen außerdem gerne ein Exemplar des Buchs kostenlos zur Verfügung.

Warum Open-Source-Sicherheit?

Das Gespräch begann mit einer sehr wichtigen Frage: Warum sollten wir uns mit Open-Source-Sicherheit beschäftigen? Guy ist der Ansicht, dass die mit Open-Source-Bibliotheken verbundenen Risiken auf dem Markt heute unterschätzt werden. Der weitaus größte Teil des Codes, den ein Entwicklungsteam bereitstellt, stammt nicht aus eigener Entwicklung, sondern aus Open-Source-Bibliotheken. Das ist eigentlich eine gute Nachricht, denn Teams müssen so das Rad nicht neu erfinden. Gleichzeitig übernehmen sie damit aber auch die Risiken, die in den Open-Source-Komponenten stecken.

Dieses Risiko ergibt sich zum Teil aus der Menge an Open-Source-Bibliotheken im Vergleich zum eigens entwickelten Anwendungscode. Hinzu kommt, dass Open-Source-Komponenten besonders attraktive Angriffsziele sind. Angreifer nehmen sich oft zuerst die einfachen Ziele vor. Open Source verspricht dabei eine hohe Rendite, denn eine einzige Schwachstelle kann gegen viele Opfer ausgenutzt werden.

Wie geht die Branche derzeit mit diesem Problem um?

Ein Teil der Branche geht dieses Problem derzeit gar nicht an. Manche erfahren von einem besonders schädlichen Exploit und reagieren darauf einmalig. Sie führen aber keine Stückliste ihrer Open-Source-Komponenten. Sie verfolgen nicht, welche Komponenten wo eingesetzt werden. Und sie überwachen diese Komponenten auch nicht anhand der Schwachstellendatenbank.

Andere berücksichtigen Sicherheitsaspekte bei der Entscheidung für bestimmte Open-Source-Bibliotheken. Das geschieht oft, bevor eine Bibliothek eingebunden wird. Im weiteren Verlauf wird sie jedoch nicht unbedingt überwacht. Es können neue Schwachstellen entdeckt werden, oder ein Upgrade kann neue Schwachstellen mit sich bringen. Doch es gibt keinen Prozess, um diese veränderten Risiken zu überwachen.

Schließlich investieren manche Unternehmen kontinuierlich in das Aufspüren und Beheben von Sicherheitsschwachstellen in Open-Source-Komponenten. Ein großer Teil des Buchs erklärt, wie sich das am besten umsetzen lässt. Beginnen wir also mit der Frage, was passiert, wenn eine neue Schwachstelle in einer Open-Source-Bibliothek offengelegt wird.

Ein Wettlauf gegen die Zeit

Bei jedem Projekt sollten wir davon ausgehen, dass es Fehler enthält. Wir schreiben keinen perfekten Code und entwickeln oder verwenden Code auch nicht unter optimalen Bedingungen. Das gilt ebenso für Sicherheitsfehler. Deshalb ist es sinnvoll anzunehmen, dass jedes Open-Source-Projekt, das Sie einbinden, eine Sicherheitsschwachstelle enthält. Vielleicht hat die Community sie nur noch nicht entdeckt.

Wird eine Schwachstelle entdeckt und offengelegt, beginnt ein Wettlauf. Die Community arbeitet daran, eine Fehlerbehebung bereitzustellen und dafür zu sorgen, dass sie angewendet wird. Böswillige Akteure versuchen, die Schwachstelle überall auszunutzen, wo sie können. Da sie bereits bekannt ist, müssen Angreifer sie nicht erst finden – sie müssen nur aktiv werden. Sobald die Schwachstelle offengelegt wird, steigt das damit verbundene Sicherheitsrisiko erheblich. Angreifer verlassen sich darauf, dass es an konsequenter Sicherheitshygiene mangelt. Teams sollten die Zeit zwischen der Offenlegung und der Behebung einer Schwachstelle so kurz wie möglich halten. Diese Lücke lässt sich nie ganz schließen. Trotzdem macht es einen Unterschied, ob die Behebung eine Stunde, einen Tag, eine Woche, einen Monat oder ein Jahr dauert.

Wie können Teams diese Lücke also schließen? Und welche Aufgaben haben die verschiedenen Beteiligten?

DevSecOps in der Praxis

DevSecOps ist ein erstrebenswertes Konzept, von dem wir in der Branche häufig hören. Im Kern geht es darum, disziplinübergreifend auf ein gemeinsames Ziel hinzuarbeiten: ein funktionsfähiges und sicheres Produkt. Welche Schritte einzelne Teammitglieder auf dem Weg dorthin unternehmen, hängt davon ab, ob sie in der Sicherheits- oder Entwicklungsabteilung arbeiten.

Die Aufgabe von Sicherheitsexpertinnen und -experten besteht darin, die eigene Organisation zu schützen, indem sie potenzielle Risiken bewusst und gezielt steuern. Sie sollten deshalb die aktuelle Risikolage kennen und in der Lage sein, die zu behandelnden Risiken zu priorisieren. Wird von Sicherheitsexpertinnen und -experten jedoch erwartet, dass sie die Behebung selbst übernehmen, lässt sich das nicht skalieren. Zudem kann es zu Problemen führen, denn sie kennen die Codebasis bei Weitem nicht so gut wie das Entwicklungsteam.

Sicherheitsexpertinnen und -experten verhalten sich zu DevSecOps wie Site Reliability Engineers (SREs) zu DevOps. Sie behalten den Gesamtzustand des Systems im Blick und legen Richtlinien fest. Neben ihren Aufgaben im Bereich Governance vermitteln die Mitglieder des Sicherheitsteams den Entwicklerinnen und Entwicklern, mit denen sie zusammenarbeiten, das nötige Wissen und die nötigen Fähigkeiten, damit diese Verantwortung für ihre tägliche Arbeit übernehmen können. Ihre Arbeit – von Governance bis hin zu Automatisierung – befähigt Entwicklerinnen und Entwickler, die richtigen Sicherheitsentscheidungen zu treffen und entsprechend zu handeln.

Ist der Workflow gut eingerichtet, kann ein Großteil dieser Arbeit ohne Eingreifen des Sicherheitsteams erledigt werden. Hat eine Sicherheitsexpertin oder ein Sicherheitsexperte geeignete Richtlinien festgelegt und den Entwicklerinnen und Entwicklern gute Tools sowie Schulungen bereitgestellt, kann die tägliche Arbeit mit wenig oder ganz ohne Eingreifen des Sicherheitsteams weitergehen.

Das Ziel: Schwachstellen beheben

Und welches Ziel verfolgt ein DevSecOps-Team? Schwachstellen zu beheben.

Zu wissen, dass Schwachstellen vorhanden sind und wo sie sich befinden, ist nützlich. Doch wir wollen insgesamt sicherere Systeme schaffen – und das bedeutet, Schwachstellen zu beheben. Fehlen Entwicklerinnen und Entwicklern die nötigen Tools oder die angemessene Unterstützung durch das Sicherheitsteam oder das Management, kann es passieren, dass wir Schwachstellen zwar finden, aber nicht beheben.

Wie bleiben wir also am Ball, damit wir Probleme nicht nur finden, sondern auch beheben? In vielen Organisationen werden Schwachstellen erst nach einer Triage behoben. Die Triage findet statt, bevor die Entwicklung einbezogen wird. Dabei bewerten wir Schweregrad und Risiko der Schwachstelle, aber nicht unbedingt, wie einfach sie zu beheben ist. Nach der Triage stellt das Entwicklungsteam fest, dass sich manche Probleme ganz einfach beheben lassen, während andere systemischer und schwer zu lösen sind.

Bei vielen Schwachstellen ist die Behebung einfacher als die Triage. Eine Triage ist nötig, wenn sich eine Schwachstelle nicht ohne Weiteres beheben lässt. Ist die Behebung jedoch einfach, gehen Sie direkt zur Sache und beheben Sie sie. Wenn Sie Maßnahmen ergriffen haben, um die Behebung zu erleichtern, können Sie viele dieser Schwachstellen beseitigen, ohne sie überhaupt zu triagieren.

Ein weiteres Hindernis bei der Behebung von Schwachstellen ist die Skalierung. Teams nutzen in der Regel viele Komponenten, von denen zahlreiche anfällig sind. Deshalb kann es schwierig sein, Schwachstellen in großem Umfang zu beheben. Ein guter Governance-Plan hilft dabei: Er legt fest, wann das Team alles stehen und liegen lassen und ein akutes Problem angehen muss und wann sich die Behebung in den üblichen Arbeitsplan integrieren lässt.

Guy fasst das Ziel so zusammen: Sie wollen Probleme finden und beheben, die bereits in Ihrem Projekt stecken, und künftige Probleme verhindern und auf sie reagieren. Finden. Beheben. Verhindern. Reagieren. Im Grunde sind es vier Aufgaben, die sich skalieren lassen müssen.

Begrenzen Sie den Schaden

Legen wir also los. Doch womit beginnen wir?

Der Begriff Triage wird oft mit der Notfallmedizin in Verbindung gebracht. Stellen Sie sich eine Person vor, die nach einem schweren Autounfall in die Notaufnahme gebracht wird. Sie kann verschiedene Beschwerden haben – vielleicht seit einer Woche eine Erkältung, saisonale Allergien oder sogar eine schwerwiegendere chronische Erkrankung. All das sollte ärztlich behandelt werden, aber in den ersten Momenten nach dem Unfall ist nichts davon entscheidend. Wichtig ist, die Blutung zu stoppen. Ärztinnen und Ärzte tun alles, damit sich der Zustand der Person nicht verschlechtert. Sobald sie stabil ist, können sie sich um weitere Probleme kümmern.

Wenn ein Team beginnt, sich mit Open-Source-Sicherheit zu befassen, kann das schnell überwältigend wirken. Vielleicht weist Ihr Projekt von Anfang an zahlreiche Probleme auf. Denken Sie in diesem Fall daran, zuerst das Schlimmste zu stoppen. Beheben Sie bestehende Probleme, nachdem Sie verhindert haben, dass sich die Lage weiter verschlechtert. Konzentrieren Sie sich auf die Veränderungen. Wenn Ihr Projekt sieben Schwachstellen aufweist, Sie einen PR mit neuen Änderungen öffnen und dieser anschließend acht Schwachstellen enthält, müssen Sie nur die zusätzliche Schwachstelle verhindern oder beheben, um Ihr Projekt zu stabilisieren. Beheben Sie die Sicherheitsprobleme, die sich aus den Änderungen zwischen altem und neuem Code ergeben. Sobald dieser Workflow etabliert ist, können Sie sich um die Sicherheitsprobleme kümmern, die bereits länger bestehen.

Stoppen Sie das Schlimmste – aber geben Sie sich damit nicht zufrieden. Verhindern Sie Probleme und reagieren Sie darauf. Finden und beheben Sie Schwachstellen. Gehen Sie laufende Risiken bei Open-Source-Komponenten an und sorgen Sie dafür, dass keine neuen Probleme hinzukommen. Nutzen Sie Open Source mit Zuversicht, verantwortungsvoll und sicher.

Sehen Sie sich das vollständige Interview an.

Holen Sie sich Ihr kostenloses Exemplar von Securing Open Source Libraries