Mit <kes>+ lesen

Praxisleitfaden zur Sicherung der Software-Lieferkette

Die Software-Lieferkette ist in den letzten Jahren zu einem attraktiven Ziel für Angreifer geworden. Ein Beispiel ist die Log4j-Sicherheitslücke von 2021, die Tausende von Systemen gefährdet hat. Vier Grundregeln sind für den Aufbau und die Aufrechterhaltung einer sicheren Software-Lieferkette unerlässlich.

Security-Management
Lesezeit 4 Min.

Bei Log4j war die Kommunikationsfunktion die Schwachstelle. Sie war anfällig und ermöglichte es Angreifern, bösartigen Code in die Logs einzuschleusen, der dann auf dem System ausgeführt werden konnte. Nach der Entdeckung dieser Schwachstelle registrierten Sicherheitsexperten Millionen von Exploit-Versuchen, von denen viele in erfolgreichen Denial-of-Service (DoS)-Angriffen endeten. Laut neuesten Forschungen von Gartner werden bis 2025 fast die Hälfte der Unternehmen Ziel eines Angriffs auf ihre Software-Lieferkette sein.

Eine Software-Lieferkette umfasst alle Codes, Personen, Systeme und Prozesse, die zur Entwicklung und Bereitstellung von Software beitragen, sowohl innerhalb als auch außerhalb einer Organisation. Die Sicherung der Lieferkette ist so herausfordernd, weil die Entwicklung moderner Anwendungen komplex und stark verteilt ist. Organisationen beschäftigen globale Teams von Entwicklern, die auf zahlreiche Open-Source-Quellen sowie auf Code-Repositories, CI/CD-Pipelines und Infrastruktur-Ressourcen angewiesen sind, um ihre Anwendungen zu erstellen und bereitzustellen.

Obwohl Sicherheit und Compliance stets oberste Priorität für Unternehmen haben, wird die Herausforderung, die Software-Lieferkette zu sichern, immer größer. Viele Unternehmen machen Fortschritte bei der Umsetzung von DevSecOps-Praktiken, doch viele stehen noch am Anfang und wissen nicht genau, wie sie vorgehen sollen.

Im Folgenden sind vier grundlegende Prinzipien skizziert, mit welchen sich die Sicherheit von Software-Lieferketten in die richtige Richtung zu lenken lässt.

1. Bei der Anwendung von Sicherheitsmaßnahmen alle Aspekte der Software-Lieferkette berücksichtigen

Da über 80 Prozent der Codebasen mindestens eine Open-Source-Schwachstelle aufweisen, liegt es nahe, dass OSS-Abhängigkeiten im Mittelpunkt der Sicherheit von Software-Lieferketten stehen. Moderne Software-Lieferketten umfassen jedoch auch andere Bereiche, deren Sicherheitsstatus entweder übersehen oder innerhalb der Organisation nicht ausreichend verstanden wird, um richtig verwaltet zu werden. Dazu gehören Code-Repositories, CI- und CD-Pipelines, Infrastruktur und Artefakt-Register, die jeweils Sicherheitskontrollen und regelmäßige Compliance-Bewertungen erfordern.

Frameworks wie OWASP Top-10 für CI/CD und CIS Software Supply Chain Security Benchmark bieten Leitlinien. Die Einhaltung dieser Frameworks erfordert detaillierte Rollenzuweisungen (RBAC), Anwendung des Prinzips der minimalen Berechtigungen, Scannen von Containern und Infrastruktur-Code auf Schwachstellen und Fehlkonfigurationen, Isolierung von Builds, Integration von Anwendungssicherheitstests und die richtige Verwaltung von Geheimnissen – um nur einige Punkte zu nennen. RBAC steht für „Role-Based Access Control“ (rollenbasierte Zugriffskontrolle). Es ist ein Konzept zur Verwaltung und Steuerung des Zugriffs auf Ressourcen in einem System, basierend auf den Rollen, die Benutzer innerhalb einer Organisation einnehmen. In einem RBAC-System werden den Benutzern Rollen zugewiesen, und jede Rolle hat bestimmte Berechtigungen, die den Zugriff auf verschiedene Ressourcen und Funktionen definieren.

2. Pflege von SBOMs als unverzichtbares Werkzeug zur Behebung von Zero-Day-Schwachstellen und anderen Komponentenproblemen

Ein Teil der Executive Order 14028, die Mitte 2021 vom Weißen Haus erlassen wurde, um die Cybersicherheit der USA zu stärken, oder auch der EU Cyber Resilience Act  verlangen von Softwareherstellern, eine Software Bill of Materials (SBOM) bereitzustellen. SBOMs sind im Wesentlichen formelle Aufzeichnungen, die Einblick in alle Komponenten geben, aus denen eine Software besteht. Sie bieten ein detailliertes, maschinenlesbares Inventar, das alle Open-Source- und Drittanbieter-Bibliotheken, Abhängigkeiten und Komponenten auflistet, die zur Erstellung der Software verwendet werden.

Unabhängig davon, ob eine Organisation dazu verpflichtet ist oder nicht, ist das Erstellen und Verwalten von SBOMs für Software-Artefakte eine wertvolle Praxis. SBOMs sind ein unverzichtbares Werkzeug zur Behebung von Komponentenproblemen oder Zero-Day-Schwachstellen. Wenn sie in einem durchsuchbaren Repository gespeichert werden, bieten SBOMs eine Übersicht darüber, wo eine bestimmte Abhängigkeit vorhanden ist, und ermöglichen es Sicherheitsteams, Schwachstellen schnell zu den betroffenen Komponenten zurückzuverfolgen.

3. Richtlinien-als-Code zur Steuerung des Softwareentwicklungs-Lebenszyklus einsetzen

In der modernen Anwendungsentwicklung sind solide Leitplanken ein unverzichtbares Werkzeug, um Fehler und absichtliche Handlungen zu vermeiden, welche die Sicherheit und Compliance gefährden. Eine ordnungsgemäße Governance entlang der gesamten Softwarelieferkette bedeutet, dass es für die Organisation einfach ist, die richtigen Dinge zu tun, und äußerst schwierig, die falschen Dinge zu tun.

Während viele Plattformen und Tools bereits vorgefertigte Richtlinien bieten, die schnell durchgesetzt werden können, ermöglicht das Konzept der Richtlinien-als-Code, basierend auf dem „Open Policy Agent“-Industriestandard, das Erstellen und Durchsetzen vollständig anpassbarer Richtlinien. Diese Richtlinien regeln alles, von den Zugriffsrechten bis hin zur Zulassung oder Ablehnung der Nutzung von OSS-Abhängigkeiten, basierend auf Kriterien wie Anbieter, Version, Paket-URL und Lizenz.

4. Vertrauen in Software-Artefakte mit SLSA sicherstellen

Wie können Nutzer und Kunden wissen, dass eine Software vertrauenswürdig ist? Um die Vertrauenswürdigkeit eines Software-Artefakts zu bestimmen, sollte man wissen, wer den Code geschrieben hat, wer ihn gebaut hat und auf welcher Entwicklungsplattform er erstellt wurde. Auch die Kenntnis der enthaltenen Komponenten ist wichtig.

Die Entscheidung, ob man einer Software vertraut, ist möglich, wenn die Herkunft – das Protokoll über die Entstehung und den Werdegang der Software – verifiziert werden kann. Dafür wurde das Supply-Chain-Levels-for-Software-Artifacts (SLSA) -Framework geschaffen. Es ermöglicht es Softwareherstellern, Informationen über jeden Aspekt der Softwarelieferkette zu erfassen, Eigenschaften von Artefakten und deren Erstellung zu überprüfen und das Risiko von Sicherheitsproblemen zu reduzieren. In der Praxis ist es für Softwarehersteller unerlässlich, die Anforderungen des SLSA-Frameworks zu übernehmen und umzusetzen, sowie ein Verfahren zur Verifizierung und Erstellung von Software-Attestierungen zu implementieren. Diese Attestierungen sind authentifizierte Aussagen (Metadaten) über Software-Artefakte entlang ihrer Lieferkette.

Angesichts des Umfangs und der Komplexität der Sicherung der modernen Softwarelieferkette, bietet dieser kurze Leitfaden nur einen kleinen Überblick. Wie alles in der Welt der modernen Anwendungsentwicklung, entwickelt sich auch diese Praxis schnell weiter. Das E-Book „How to Securely Deliver Software“ (hier gegen Registrierung kostenfrei downloadbar) liefert umfassende Best Practices, die darauf abzielen, die Sicherheitslage in Unternehmen zu stärken und das Risiko zu minimieren.

Diesen Beitrag teilen: