Supply-Chain-Angriffe
Eine Software-Supply-Chain umfasst alle Software und Tools, die zur Erstellung und Wartung eines Softwareprodukts verwendet werden. Dies beinhaltet nicht nur die Software, die für das Produkt selbst entwickelt wurde, sondern auch alle Software und Tools, die in der Produktion verwendet werden.
Bei einem Supply-Chain-Angriff zielt der Angreifer auf einen Teil der Lieferkette des Produkts ab, um das Produkt selbst zu kompromittieren.
Das offensichtlichste Beispiel hier ist eine Drittanbieter-Bibliothek. Wenn Sie beispielsweise ein npm-Paket verwenden, das von einem Drittanbieter entwickelt wurde, hat dieses die Möglichkeit, Ihre Seite zu kompromittieren. Dies kann absichtlich geschehen, wenn es bösartig ist, oder versehentlich, wenn es eigene unbeabsichtigte Schwachstellen enthält. Im Wesentlichen müssen Sie Ihren Drittanbieter-Abhängigkeiten genauso vertrauen wie Ihrem eigenen Code.
Weniger offensichtlich ist, dass dasselbe Prinzip für alle Tools gilt, die Sie bei der Erstellung Ihrer Software verwenden, einschließlich Code-Editoren, Editor-Plugins, Versionskontrollsystemen, Build-Tools und so weiter. Jedes dieser Tools könnte im Laufe der Transformationen, die es anwendet, bösartigen oder anfälligen Code in Ihr endgültiges Softwareprodukt einfügen.
In diesem Dokument skizzieren wir Praktiken, die befolgt werden sollten, um Ihre Software-Supply-Chain abzusichern. Es ist in zwei Hauptabschnitte gegliedert:
- Absicherung Ihrer Entwicklungsumgebung: Praktiken, um sicherzustellen, dass Ihr eigener Code nicht kompromittiert wird.
- Verwaltung von Drittanbieter-Abhängigkeiten: Praktiken, um sicherzustellen, dass Ihre Abhängigkeiten nicht kompromittiert werden.
Absicherung Ihrer Entwicklungsumgebung
Ein Weg für einen Supply-Chain-Angriff besteht darin, dass ein Angreifer Schwachstellen oder bösartigen Code direkt in Ihr eigenes Produkt einbringt. Typischerweise geschieht dies, indem der Angreifer das Konto eines Projektbetreuers kompromittiert oder Schwächen in den von den Betreuern verwendeten Entwickler-Tools ausnutzt.
Unser Leitfaden zur operativen Sicherheit beschreibt Praktiken, um diesen Bedrohungen entgegenzuwirken, einschließlich:
Verwaltung von Drittanbieter-Abhängigkeiten
Drittanbieter-Abhängigkeiten beinhalten nicht nur Bibliotheken und Frameworks, die Ihr Code verwendet, sondern alle Drittanbieter-Tools, die im Entwicklungsprozess involviert sind, einschließlich Editoren, IDEs, Versionskontrollsystemen, Paketmanagern und Build-Tools.
Angreifer können Ihr Projekt kompromittieren, indem sie Schwächen in diesen Abhängigkeiten ausnutzen. Unser Leitfaden zur operativen Sicherheit beschreibt Praktiken, um diesen Bedrohungen entgegenzuwirken, einschließlich:
- Bewertung neuer Abhängigkeiten
- Aktualisierung bestehender Abhängigkeiten
- Pflege einer Software-Stückliste (SBOM)
Zusätzlich sollten Projekte Subresource Integrity verwenden für Skripte und Stylesheets, die von einer Drittanbieter-Website gehostet werden.
Verwendung von Subresource Integrity
Viele Websites beinhalten extern gehostete Skripte: am bemerkenswertesten, aber nicht ausschließlich, Skripte, die von einem Content Delivery Network (CDN) bereitgestellt werden:
<script src="https://cdn.example.org/library.js"></script>
Dies stellt ein Risiko für Ihre Lieferkette dar: Wenn ein Angreifer Kontrolle über die Domain cdn.example.org erlangt, kann er das Skript durch ein bösartiges Skript ersetzen und so Ihre Seite kompromittieren.
Externe Skripte sollten, wie andere Software-Abhängigkeiten auch, Teil Ihrer SBOM sein, aber eine zusätzliche Verteidigung besteht darin, das integrity-Attribut des Skripts festzulegen:
<script
src="https://cdn.example.org/library.js"
integrity="sha256-d5f450f7ce715d827de27ca569e183f819d33c1e7601875fd61eccbc98f56c5b"></script>
Der Wert dieses Attributs enthält einen kryptografischen Hash des Skriptinhalts. Wenn das Skript von einem Angreifer verändert wurde, dann wird der Browser es ablehnen zu laden und Sie werden geschützt.
Dies fügt jedoch eine zusätzliche Wartungsbelastung hinzu: Jedes Mal, wenn sich die Quelle ändert (zum Beispiel jedes Mal, wenn eine neue Version freigegeben wird), müssen Sie den Wert des Attributs in Ihrem Code aktualisieren.
Das <link>-Element unterstützt ebenfalls das integrity-Attribut, sodass Sie es sowohl für CSS-Stylesheets als auch für Skripte verwenden können (und sollten).
Siehe Subresource Integrity für weitere Details.
Verteidigungs-Checkliste
- Befolgen Sie Praktiken der operativen Sicherheit:
- Verwenden Sie Subresource Integrity für extern referenzierte Skripte und Stylesheets.