Lieferkettenangriffe
Eine Software-Lieferkette besteht aus aller Software und allen Werkzeugen, die zur Erstellung und Pflege eines Softwareprodukts verwendet werden. Dazu gehört nicht nur die für das Produkt selbst entwickelte Software, sondern auch alle Software und Werkzeuge, die bei der Herstellung verwendet werden.
Bei einem Lieferkettenangriff zielt der Angreifer darauf ab, einen Teil der Lieferkette des Produkts zu kompromittieren, um das Produkt selbst zu gefährden.
Das offensichtlichste Beispiel hierfür ist eine Bibliothek eines Drittanbieters. Wenn Sie beispielsweise ein npm-Paket eines Drittanbieters verwenden, hat es die Möglichkeit, Ihre Website zu gefährden. Dies kann absichtlich geschehen, wenn es bösartig ist, oder versehentlich, wenn es unbeabsichtigte Schwachstellen enthält. Im Wesentlichen müssen Sie Ihren Drittanbieterabhängigkeiten genauso vertrauen wie Ihrem eigenen Code.
Weniger offensichtlich gilt dasselbe Prinzip für alle Werkzeuge, die Sie bei der Erstellung Ihrer Software verwenden, einschließlich Code-Editoren, Editor-Plugins, Versionskontrollsystemen, Build-Tools usw. Jedes dieser Werkzeuge könnte bösartigen oder anfälligen Code in Ihr endgültiges Softwareprodukt einfügen, im Laufe der Transformationen, die sie anwenden.
In diesem Dokument skizzieren wir Praktiken, die Sie befolgen sollten, um Ihre Software-Lieferkette zu sichern. Es ist in zwei Hauptabschnitte gegliedert:
- Sichern Ihrer Entwicklungsumgebung: Praktiken, um sicherzustellen, dass Ihr eigener Code nicht kompromittiert wird.
- Verwaltung von Drittanbieterabhängigkeiten: Praktiken, um sicherzustellen, dass Ihre Abhängigkeiten nicht kompromittiert werden.
Sichern Ihrer Entwicklungsumgebung
Ein Weg für einen Lieferkettenangriff besteht darin, dass ein Angreifer Schwachstellen oder bösartigen Code direkt in Ihr eigenes Produkt einführt. Typischerweise tut ein Angreifer dies, indem er das Konto eines Projekterhalters kompromittiert oder Schwächen in den von den Erhaltern verwendeten Entwicklerwerkzeugen ausnutzt.
Unser Leitfaden zur operativen Sicherheit beschreibt Praktiken zur Bekämpfung dieser Bedrohungen, einschließlich:
Verwaltung von Drittanbieterabhängigkeiten
Drittanbieterabhängigkeiten umfassen nicht nur Bibliotheken und Frameworks, die Ihr Code verwendet, sondern alle Drittanbieterwerkzeuge, die am Entwicklungsprozess beteiligt sind, einschließlich Editoren, IDEs, Versionskontrollsystemen, Paketmanager 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 zur Bekämpfung dieser Bedrohungen, einschließlich:
- Bewertung neuer Abhängigkeiten
- Aktualisierung bestehender Abhängigkeiten
- Pflege eines Software Bill of Materials (SBOM)
Zudem sollten Projekte Subresource Integrity verwenden für Scripts 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 die Kontrolle über die Domain cdn.example.org erlangen kann, kann er das Skript durch ein bösartiges Skript ersetzen und so Ihre Website gefährden.
Externe Skripte, wie andere Softwareabhängigkeiten, sollten Teil Ihrer SBOM sein, aber eine zusätzliche Abwehr ist das Festlegen des integrity-Attributs des Skripts:
<script
src="https://cdn.example.org/library.js"
integrity="sha256-d5f450f7ce715d827de27ca569e183f819d33c1e7601875fd61eccbc98f56c5b"></script>
Der Wert dieses Attributs enthält einen kryptografischen Hash der Skriptinhalte. Wenn das Skript von einem Angreifer modifiziert wurde, wird der Browser es ablehnen zu laden und Sie sind geschützt.
Dies erhöht jedoch den Wartungsaufwand: Jedes Mal, wenn sich die Quelle ändert (zum Beispiel, wenn eine neue Version veröffentlicht wird), müssen Sie den Wert des Attributs in Ihrem Code aktualisieren.
Das <link>-Element unterstützt ebenfalls das integrity-Attribut, sodass Sie es für CSS-Stylesheets ebenso wie für Skripte verwenden (und sollten).
Weitere Details finden Sie unter Subresource Integrity.
Verteidigungszusammenfassung-Checkliste
- Befolgen Sie Praktiken zur operativen Sicherheit, um:
- Verwenden Sie Subresource Integrity für extern referenzierte Skripte und Stylesheets.