Bedrohungen der Lieferkette

Ein Angriff auf die Software-Lieferkette kompromittiert eine Organisation nicht durch einen direkten Angriff, sondern indem etwas beschädigt wird, dem sie vertraut und das sie verwendet: eine Bibliothek, ein Build-Tool, ein Container-Basis-Image oder ein Update-Server.

Da moderne Software aus Hunderten Komponenten von Drittanbietern zusammengesetzt wird, wird eine einzige vergiftete Verbindung an alle nachgelagerten Nutzer weitergegeben. Der Angreifer investiert einmal und erreicht damit viele Opfer.

• Vertrauensumkehr — die Sicherheitsgrenze verlagert sich außerhalb Ihres eigenen Codes
• Trans Siver Schadensradius — ein schädliches Paket gelangt in Tausende Builds

Wenn Sie eine direkte Abhängigkeit hinzufügen, ziehen Sie oft Dutzende transitive Abhängigkeiten nach, die Sie nie selbst ausgewählt haben. Eine typische Node- oder Python-Anwendung deklariert eine Handvoll Pakete, löst aber Hunderte auf.

Listen Sie den vollständig aufgelösten Abhängigkeitsbaum auf, nicht nur das Manifest, um zu sehen, was Sie tatsächlich ausliefern:

Angreifer veröffentlichen bösartige Pakete mit Namen, die beliebten Paketen ähneln, und setzen auf einen folgenschweren Tippfehler.

• Typosquatting — reqeusts statt requests
• Combosquatting — python-requests ahmt den echten Namen nach
• Dependency Confusion — ein öffentliches Paket mit demselben Namen wie Ihr internes privates Paket wird veröffentlicht, sodass ein falsch konfigurierter Resolver die Version des Angreifers abruft

Schützen Sie sich, indem Sie eine vertrauenswürdige interne Registry fest vorgeben und private Pakete mit Scope oder Namespace verwenden.

Ein legitimes, weithin vertrauenswürdiges Paket kann bösartig werden, wenn das Konto seines Maintainers kompromittiert wird oder ein bösartiger Mitwirkender Veröffentlichungsrechte erhält.

Aktuelle Vorfälle aus der Praxis zeigen, dass Angreifer Zugangsdaten von Maintainer-Konten durch Phishing erbeuten und anschließend ein vergiftetes Patch-Release veröffentlichen, das während der Installation Token abgreift.

• Verlangen Sie 2FA für alle Konten, die Pakete veröffentlichen
• Bevorzugen Sie Pakete mit bereichsbezogenen Veröffentlichungstoken und geschützten Releases
• Achten Sie bei kritischen Abhängigkeiten auf unerwartete neue Maintainer

Viele Ökosysteme führen zum Installationszeitpunkt Code aus, noch bevor Ihre Anwendung überhaupt läuft. Ein npm install kann einen postinstall-Hook ausführen, der Umgebungsvariablen oder SSH-Schlüssel stiehlt.

Deaktivieren Sie beliebige Installationsskripte in CI und prüfen Sie jedes Paket, das solche Skripte benötigt:

Die Build-Umgebung selbst ist ein besonders lohnendes Ziel. Wenn ein Angreifer einen Compiler, ein CI-Runner-Image oder ein Build-Plugin vergiftet, ist jedes von ihm erzeugte Artefakt mit einer Hintertür versehen, selbst wenn Ihr Quellcode sauber ist.

Das klassische Beispiel ist ein mit einem Trojaner versehener Aktualisierungsmechanismus, der Schadsoftware mit einem legitimen Code-Signaturschlüssel signiert, sodass die Opfer sie als echt akzeptieren.

• Behandeln Sie die Build-Infrastruktur wie die Produktion und härten Sie sie umfassend
• Verwenden Sie kurzlebige, reproduzierbare Build-Runner
• Trennen Sie Signaturschlüssel vom Build-Host

Ein Lockfile legt exakte Versionen und Inhaltshashes fest, sodass eine erneute Auflösung nicht unbemerkt ein anderes Artefakt einschleusen kann. Übernehmen Sie das Lockfile immer in das Versionskontrollsystem und lassen Sie es von der CI prüfen, statt Abhängigkeiten frei neu aufzulösen.

Das Integritätsfeld enthält einen Hash. Wenn das heruntergeladene Tar-Archiv nicht übereinstimmt, schlägt die Installation fehl.

Bekannte verwundbare Versionen, die als CVEs erfasst werden, sind die häufigste Schwachstelle in der Lieferkette. Tools für Software Composition Analysis (SCA) gleichen Ihre aufgelösten Abhängigkeiten mit Schwachstellendatenbanken ab.

Führen Sie die Prüfungen in der CI aus und lassen Sie Builds bei kritischen Befunden fehlschlagen:

Flexible Versionsbereiche (^1.2.0) lassen automatisch neue Releases einfließen. Das ist praktisch, setzt Sie aber einem bösartigen Patch-Release aus.

• Pinnen Sie auf exakte Versionen und prüfen Sie Aktualisierungen bewusst
• Pinnen Sie nach Digest bei Container-Images, nicht nach veränderlichen Tags wie latest
• Vendorn Sie kritische Abhängigkeiten in Ihr eigenes Repository oder einen Mirror, damit eine Löschung im Upstream Sie weder blockieren noch gefährden kann

Die Absicherung der Lieferkette ist eine fortlaufende Aufgabe und keine einmalige Prüfung. Sie müssen wissen, was Sie ausliefern, woher es stammt und wann es verwundbar wird.

• Erstellen Sie für jedes Release eine SBOM (in der nächsten Lektion)
• Erfassen Sie die Build-Provenienz, damit Sie nachweisen können, wie ein Artefakt erzeugt wurde
• Abonnieren Sie Sicherheitshinweise, damit eine neu veröffentlichte CVE eine erneute Bewertung bereits ausgelieferter Builds auslöst

Erfassen Sie jede Phase, in der nicht vertrauenswürdige Eingaben hineingelangen: Entwicklerrechner, Quellcodeverwaltung, Paket-Registries, das Build-System, die Artefaktspeicherung und der Update-Kanal. Jede dieser Phasen kann ein möglicher Injektionspunkt sein.

Fragen Sie für jede Phase: Wer kann hier schreiben, was könnte diese Person bei einer Kompromittierung tun, und wie würde ich das erkennen? So entsteht eine priorisierte Liste von Kontrollen statt einer allgemeinen Checkliste.

Sie haben gelernt, warum Abhängigkeiten Angriffsvektoren sind und wie Sie dieses Risiko reduzieren.

• Vertrauensumkehr bedeutet, dass Ihre Sicherheit von Drittanbietern abhängt, die Sie nicht kontrollieren
• Zu den wichtigsten Bedrohungen gehören Typosquatting, Dependency Confusion, die Übernahme von Maintainer-Konten, bösartige Installationsskripte und kompromittierte Build-Werkzeuge
• Zu den wichtigsten Schutzmaßnahmen gehören Lockfiles mit Integritätshashes, SCA-Prüfungen, exaktes Pinnen nach Digest, 2FA für Paketveröffentlicher und kontinuierliche Überwachung

Als Nächstes erfassen Sie mit einer SBOM genau, was Ihre Software enthält.