Banner Aktuelle IT-Sicherheit Online-Schulungen Rabatt
Free

DevSecOps für mehr Supply-Chain-Sicherheit ausweiten

DevSecOps wird oft unter dem Schlagwort „shifting left“ diskutiert und hat etliche Innovationen in unterschiedlichen Bereichen hervorgebracht. Dazu zählen automatisierte Tests, Reporting und die Workflow-Integration in Tools zur Softwareentwicklung. Das sind ausgesprochen gute Voraussetzungen für die Sicherheit der Lieferkette. Die Annahme aber, dass DevSecOps nach der aktuellen Definition die Lösung für Sicherheitsprobleme innerhalb der Supply Chain liefert, ist trügerisch.

David CorletteAllgemein
Lesezeit 6 Min.

Es ist ein verbreiteter Irrglaube, dass traditionelle Sicherheitspraktiken unter dem Dach von DevSecOps, also skalierbare Sicherheit mit geringen Reibungsverlusten dank Zusammenarbeit und Automatisierung [1], die Lösung bei Sicherheitsrisiken innerhalb der Softwarelieferkette bieten. DevSecOps wird oft unter dem Schlagwort „shifting left“ diskutiert und hat etliche Innovationen in unterschiedlichen Bereichen hervorgebracht. Dazu zählen automatisierte Tests, Reporting und die Workflow-Integration in Tools und Technologien zur Softwareentwicklung. Das sind ausgesprochen gute Voraussetzungen für die Sicherheit der Lieferkette. Die Annahme aber, dass DevSecOps nach unserer aktuellen Definition die Lösung für Sicherheitsprobleme innerhalb der Supply Chain liefert, ist jedoch trügerisch.

Mehr noch führt sie eher dazu, potenziell schwerwiegende Risiken nicht ausreichend zu kontrollieren. Gerade in jüngster Zeit machten Supply-Chain-Angriffe auf deutsche Industrieunternehmen Schlagzeilen, bei denen gefälschte npm-Pakete benutzt wurden, um eine gefährliche Backdoor-Malware zu installieren. Aktuell im Juli diesen Jahres berichteten Sicherheitsforscher nach eigenen Angaben von der ersten Attacke auf die Open-Source-Software-Lieferkette, der sich speziell gegen den Bankensektor richtete – unter anderem gegen bestimmte Komponenten in den Web-Assets der betreffenden Finanzhäuser.

Man denke dabei beispielsweise auch an das Supply-Chain-Levels-for-Software-Artifacts-(SLSA) -Rahmenwerk [2], das als Reifegradmodell für die Sicherheit der Lieferkette dient. SLSA definiert die Sicherheitsprobleme innerhalb der Supply Chain als die Risiken, die entstehen, weil man die Integrität von Software-Artefakten nicht garantieren kann und „dass der Quellcode, auf den man sich verlässt, der Code ist, den man tatsächlich benutzt“ [2]. Für jede Stufe werden unterschiedliche Anforderungen definiert. Der Schwerpunkt des SLSA-Reifegradmodells liegt allerdings auf einer nachprüfbaren Software-Herkunft, vorgeschlagen werden dazu Open-Source-Tools. Wenn man sich Zeit nimmt, sich mit den verschiedenen SLSA-Stufen und den damit verbundenen Aktivitäten zum aktuellen Zeitpunkt [3] vertraut zu machen, wird man in Sachen DevSecOps im Wesentlichen eines feststellen: Nämlich, dass es äußerst schwierig ist, sie mit den Praktiken in Verbindung zu bringen, die in den letzten zehn Jahren als DevSecOps angepriesen wurden.

Die Verantwortlichen hinter den SLSA-Vorgaben sind natürlich nicht die Einzigen, die Strategien für einen geeigneten Umgang mit Supply-Chain-Risiken vorgeben. Als Reaktion auf die Executive Order 14028 des US-Präsidenten [4] verfasste das National Institute for Standards and Technology (NIST) eine eigene „Software Supply Chain Security Guidance“ [5]. Das Dokument führt mehrere Sicherheitskontrollen auf, die von Softwareanbietern und -nutzern übernommen werden sollten, darunter auch das Secure Software Development Framework (SSDF) [6]. Das SSDF umfasst eine Reihe von empfohlenen Praktiken. Ziel ist es, Unternehmen ein Rahmenwerk an die Hand zu geben, um die Vorgaben der US-Regierung für die Sicherheit der Lieferketten besser erfüllen und umsetzen zu können. Dabei geht es insbesondere um die Executive Order 14028 und das Memorandum M-22-18 und die daraus resultierenden Nachweispflichten. Zusätzlich soll das SSDF die Bewertung, das Design und die Umsetzung von Programmen zur Softwareentwicklung unterstützen. Und zwar derart, dass bei sämtlichen Prozessen, Verfahren, Werkzeugen und hinsichtlich der Lieferanten, die an der Softwarenentwicklung beteiligt sind, Sicherheitsüberlegungen und -kontrollen integriert werden. Als eine Reihe von Best Practices für die sichere Softwareentwicklung entspricht der SSDF weitgehend den branchenweit anerkannten Sicherheitspraktiken für DevSecOps.

Die „Software Supply Chain Security Guidance“ des NIST bietet jedoch noch mehr. Denn hier werden zusätzlich weitere Praktiken beschrieben, die rund um das Thema der Attestierung angewandt werden sollten, einschließlich einer Software Bill of Materials (SBOM). Eine Software-Stückliste ist ein wichtiger Bestandteil des Risikomanagements innerhalb der Software-Lieferkette (SSCRM) und für viele Branchen mittlerweile verpflichtend. Eine umfassende, genaue und den Standardspezifikationen entsprechenden SBOM zu erstellen und in übergreifende Risikomanagement-Prozesse einzubinden ist allerdings alles andere als trivial. Ein erster Schritt ist die Inventarisierung der kompletten Software, die ein Unternehmen einsetzt. Dazu gehört auch alles, was die Software enthält und zu einem potenziellen Risiko werden könnte. Viele Firmen sind inzwischen dazu übergegangen von ihren Softwareherstellern eine Software Bill of Materials einzufordern. In dieser Stückliste sind sämtliche Komponenten einer Softwareanwendung aufgelistet, ebenso wie die damit verbundenen Lizenz- und Copyright-Informationen sowie bekannte Sicherheitsprobleme für jede der betreffenden Komponenten.

Weiterhin benennt die NIST Guidance erweiterte Risikobewertungen von Anbietern. Die eher traditionellen und in der Branche akzeptierten DevSecOps-Praktiken reichen also für die Sicherheit der Lieferketten bei weitem nichts aus. Daher empfiehlt es sich, die bisherige Definition und das vorherrschende Verständnis von DevSecOps auszudehnen und solche Praktiken einzubeziehen, die eng mit der Sicherheit der Softwarelieferkette verbunden sind.

Dieses Verständnis von DevSecOps umfasst Sicherheitspraktiken, die nicht nur die Risiken innerhalb der erstellten Software betreffen, sondern auch die Art und Weise, wie die Software überhaupt erstellt wurde. Viele Unternehmen planen, diese formalisierte Praxis zu etablieren oder sind schon dabei. Etliche Firmen wissen angesichts der wachsenden Komplexität und des vergleichsweise wenig ausgereiften Bereichs allerdings nicht, wo sie am besten ansetzen sollen. Hilfreich sind besonders die folgenden sechs, von der Industrie unterstützten Sicherheitsstrategien:

  • Authentizität und Integrität von Entwicklern
  • Authentifizierung und Zugangskontrolle von Systemen zur Verwaltung des Codes
  • Eine gehärtete Build-Infrastruktur in Verbindung mit einer Software Bill of Materials (SBOM)
  • Sicherheitsüberprüfung/Tests mittels der Software Composition Analysis (SCA)
  • Attestierungsüberprüfung in einer gehärteten Bereitstellungsinfrastruktur
  • Integritätsüberprüfung vor der Verwendung der Software

Am Ende der Lieferkette braucht man Prozesse, mit denen man die Wartungsphase innerhalb des Software-Lebenszyklus schützt. Bei dem berüchtigten Angriff auf die Lieferkette von SolarWinds verschafften sich die Angreifer Zugang zu sensiblen Informationen in Tausenden von Unternehmen und etlichen US-Regierungsbehörden. Das Ergebnis eines Angriffs, bei dem es gelungen war, bösartigen Code in den Software-Patching-Prozess am Ende des Software-Lebenszyklus einzubringen.

Was die Sicherheit der Software-Lieferkette anbelangt, kommt es also vor allem auf die Authentizität und Integrität von Menschen, Prozessen und Technologien innerhalb der Anwendungsinfrastruktur an. Das Thema ist hinreichend komplex. Man kann es sich aber leichter machen, wenn man es im Kontext des Lebenszyklus der Softwareentwicklung betrachtet. Insbesondere der Entwicklungsphase, in der die Software geschrieben wird, der Erstellungsphase, in der die Software zusammengestellt wird, und schließlich der Bereitstellungsphase, in der die Software freigegeben und genutzt wird. Für jede Phase des SDLC gibt es geeignete Testmethoden, um die Integrität einer Software und der Daten zu gewährleisten. Tools allein reichen aber nicht aus. Es geht auch darum, einen entwicklerfreundlichen Sicherheitsrahmen zu schaffen. Nicht zuletzt durch geeignete Trainingsmethoden, die Diskussionen aufwerfen, wichtige Erkenntnisse zusammenfassen und im Idealfall Checklisten für grundlegende Sicherheitskontrollen bereithalten.

Sicherheitsfachleute und Entwickler kämpfen gleichermaßen mit der Komplexität des Themas und den potenziell weitreichenden Auswirkungen auf alle Bereiche der Software-Lieferkette. Angesichts dessen sollten Entwicklungsteams besser als bislang in die Lage versetzt werden, geeignete Maßnahmen zu ergreifen, um die Risiken zu jedem Zeitpunkt im Lebenszyklus der Softwareentwicklung in den Griff zu bekommen. Jede einzelne der hier genannten Strategien soll dazu beitragen, die Authentizität und Integrität von allem und jedem zu überprüfen, der an der Erstellung, Entwicklung, Bereitstellung und Nutzung von Software beteiligt ist – und so die Sicherheit der Lieferkette insgesamt verbessern.

David Corlette ist Vice President Of Product Management bei der VIPRE Security Group.

Literatur

[1] DevSecOps Manifesto: www.devsecops.org

[2] SLSA Framework: slsa.dev

[3] SLSA Levels: slsa.dev/spec/v1.0/levels

[4] EO 10428: www.federalregister.gov/documents/2021/05/17/2021-10460/improving-the-nations-cybersecurity

[5] NIST Software Supply Chain Security Guidance: www.nist.gov/itl/executive-order-14028-improving-nations-cybersecurity/software-supply-chain-security-guidance [6] NIST Secure Software Development Framework: csrc.nist.gov/Projects/ssdf