Risikomanagement in der Software-Lieferkette

Risikomanagement vs. Sicherheit

Software-Lieferkettensicherheit ist die Gesamtheit der technischen Controls: SBOMs, gepinnte Abhängigkeiten, eingeschränkte Builds. Das Risikomanagement steht darüber. Es fragt, von welchen Lieferanten und Komponenten Ihr Geschäft abhängt, was passiert, wenn einer davon ausfällt, und ob Sie Ihren Aufwand an der richtigen Stelle eingesetzt haben.

Welche Risiken gibt es?

Risiko	Beispiel	Wichtigste Kontrolle
Verwundbare Komponenten	Ein Fehler in einer weit verbreiteten Bibliothek	SBOMs und kontinuierliche Überwachung
Bösartige Komponenten	Ein gekapertes Paket oder Typosquatting	Prüfung, verzögerte Übernahme, Grenzen für ausgehenden Datenverkehr
Verwaiste Projekte	Eine Abhängigkeit mit nur einem Maintainer, der sich zurückgezogen hat	Prüfung des Projektzustands und ein Ersatzplan
Lizenzrisiko	Eine Copyleft-Komponente in einem proprietären Produkt	Lizenz-Policy
Kompromittierung des Builds	Eine gekaperte GitHub Action erreicht Ihre Secrets	Pinning, Isolation, minimale Rechte
Lieferantenrisiko	Das Produkt oder Update eines Anbieters wird kompromittiert	Bewertung, Verträge, SBOMs von Lieferanten
Regulatorisches Risiko	Ein Kunde oder ein Gesetz verlangt Nachweise, die Sie nicht erbringen können	Aufzeichnungen pro Release

Ein Prozess in sechs Schritten

1. Das Inventar aufbauen. Listen Sie die Produkte auf, die Sie herstellen, und die Software, die Sie kaufen. Für das, was Sie bauen, führen Sie eine SBOM pro Release. Was Sie nicht sehen, können Sie nicht bewerten.
2. Nach Bedeutung ordnen. Eine Bibliothek in Ihrem Zahlungsdienst ist etwas anderes als eine in einem internen Tool. Bewerten Sie Produkte nach Exposition, Daten und geschäftlicher Auswirkung.
3. Die Risiken bewerten. Betrachten Sie Schwachstellen, Projektzustand, Lizenzen und den Umgang jedes Lieferanten mit Sicherheit. Gehen Sie bei der obersten Stufe in die Tiefe und bei allem anderen nur oberflächlich vor.
4. Die Risiken behandeln. Entscheiden Sie für jedes Risiko: beheben, ersetzen, eine Kontrolle ergänzen oder akzeptieren. Ein akzeptiertes Risiko braucht einen Verantwortlichen und einen Prüftermin.
5. Kontinuierlich überwachen. Risiken ändern sich, ohne dass sich bei Ihnen etwas ändert, zum Beispiel wenn ein Advisory erscheint oder ein Maintainer aufhört. Jährliche Überprüfungen übersehen das.
6. Berichten. Geben Sie der Führung einen kurzen Überblick: die größten Risiken, die Exposition im Zeitverlauf und was akzeptiert wurde. Kunden und Auditoren werden nach den Details fragen.

Lieferanten bewerten

Fragebögen allein zeigen, was ein Lieferant sagt. Fragen Sie nach Belegen dafür, was er tut:

• Eine SBOM des Produkts, mit angegebenem Format und einem Weg, Updates zu erhalten
• Wie er mit Schwachstellen umgeht und wie schnell er Kunden informiert
• Einen Sicherheitskontakt und eine Disclosure-Policy
• Wie er Releases baut und ob er zeigen kann, woher ein Release stammt
• Wie lange eine Version Sicherheitsfixes erhält
• Zertifizierungen und Auditberichte, die das Produkt abdecken, das Sie kaufen

Schreiben Sie die Erwartungen in die Verträge. Eine SBOM oder eine Meldefrist lässt sich bei Vertragsabschluss viel leichter verlangen als nach einem Vorfall.

Frameworks zur Orientierung

• NIST SP 800-161 ist die wichtigste Referenz für Cybersecurity Supply Chain Risk Management, kurz C-SCRM. Es gilt für alle Ebenen eines Unternehmens und bindet Lieferkettenrisiken in das übergreifende Risikomanagement ein.
• Das NIST SSDF behandelt Praktiken sicherer Entwicklung und ist damit eine gute Grundlage für das, was Sie von Lieferanten verlangen, und von sich selbst.
• SLSA gibt Ihnen eine gemeinsame Sprache dafür, wie vertrauenswürdig ein Build ist.
• ISO/IEC 27001:2022 enthält Controls für die IKT-Lieferkettensicherheit (Anhang A 5.21) und technische Schwachstellen (8.8). Eine SBOM verlangt die Norm nicht, aber SBOMs sind gute Nachweise für diese Controls.
• NIS2 nennt in Artikel 21(2)(d) die Sicherheit der Lieferkette als vorgeschriebene Maßnahme für betroffene Einrichtungen.

So messen Sie es

Wählen Sie einige wenige Kennzahlen, aus denen Entscheidungen folgen:

• Anteil der Produkte mit einer SBOM für das aktuelle Release
• Zeit bis zur Antwort auf „Sind wir betroffen?“ bei einer neuen kritischen Schwachstelle
• Expositionsfenster: wie lange eine verwundbare Version in Produktion war
• Anteil der im letzten Jahr bewerteten Lieferanten der obersten Stufe
• Anzahl akzeptierter Risiken, deren Prüftermin überschritten ist

Wo CRACI hilft

CRACI liefert einem Risikoprogramm die Daten, die ihm für selbst gebaute Software meist fehlen. Es zeichnet auf, was jeder GitHub-Actions-Build geladen hat, einschließlich deklarierter Lizenzen, und erzeugt daraus SBOMs, die Sie pro Release aufbewahren und als CycloneDX oder SPDX teilen können. Es überwacht das Ausgelieferte, zeigt, welche Builds ein verwundbares Paket enthielten, sodass Sie den betroffenen Zeitraum sehen, und kann Lizenz-Policies durchsetzen und Builds mit Policy-Gates blockieren. Siehe Software-Lieferkettensicherheit mit CRACI und die Tools im Vergleich.

Die Lieferantenbewertung und Ihr Risikoregister bleiben bei Ihren Governance-Tools und Ihrem Team.

Risikomanagement in der Software-Lieferkette: häufig gestellte Fragen

Was ist Risikomanagement in der Software-Lieferkette?

Es ist die Art, wie ein Unternehmen das Risiko aus Software erkennt, bewertet und senkt, die es nicht selbst geschrieben hat, darunter Open-Source-Pakete, kommerzielle Produkte, SaaS-Lieferanten und Build-Tools.

Was ist C-SCRM?

C-SCRM steht für Cybersecurity Supply Chain Risk Management, den Begriff, den NIST verwendet. NIST SP 800-161 ist die wichtigste Leitlinie dazu und beschreibt, wie sich Cyberrisiken in der gesamten Lieferkette auf allen Ebenen eines Unternehmens finden, bewerten und senken lassen.

Was sind die größten Risiken in der Software-Lieferkette?

Verwundbare und bösartige Open-Source-Komponenten, kompromittierte Build-Systeme und CI-Tools, verwaiste Projekte, Lizenzprobleme und Lieferanten, bei denen es zu Sicherheitsverletzungen kommt.

Worin unterscheidet es sich vom Third-Party-Risikomanagement?

Third-Party-Risikomanagement betrachtet Anbieter meist als Unternehmen. Risikomanagement in der Software-Lieferkette geht bis zu den Komponenten und Build-Prozessen hinunter, auch zu Open-Source-Projekten, hinter denen kein Anbieter steht.

Wer ist dafür verantwortlich?

Typischerweise gibt die Sicherheits- oder Risikoleitung das Programm vor, die Produktsicherheit ist für das zuständig, was das Unternehmen baut, und der Einkauf oder das Lieferantenmanagement für das, was es kauft. Die Entwicklungsteams beheben, was gefunden wird.