Software Supply Chain Risks: From SBOM to Actionable Risk Decisions

Die Illusion der Sichtbarkeit: Warum ein SBOM allein kein Risikomanagement ist

Ein Software Bill of Materials schafft Transparenz – aber Transparenz ist kein Schutz. Wer ein SBOM erstellt, weiß, welche Komponenten in seiner Software stecken. Wer weiß, welche Komponenten drin stecken, weiß noch lange nicht, welche davon ein reales Geschäftsrisiko darstellen. Zwischen diesen beiden Punkten liegt eine strukturelle Lücke, die in vielen Sicherheitsprogrammen unterschätzt wird.

Das SBOM ist eine notwendige Grundlage – aber es beantwortet keine einzige Risikoentscheidung von allein. Es sagt nicht, ob eine verwundbare Bibliothek in einem produktiven, nach außen exponierten Service läuft oder in einem internen Entwicklungswerkzeug ohne Netzwerkzugang. Es unterscheidet nicht zwischen einem theoretisch angreifbaren Code-Pfad und einem, der tatsächlich erreichbar ist. Und es kann nicht einschätzen, welche Schwachstelle in den nächsten 30 Tagen aktiv ausgenutzt wird.

Effektives Supply-Chain-Risikomanagement beginnt dort, wo das SBOM aufhört: bei der Verknüpfung von Komponentendaten mit Vulnerability-Intelligence, Geschäftskontext und Handlungslogik.

Anatomie eines Software-Supply-Chain-Risikos

Die Angriffsfläche entlang der Software-Lieferkette ist mehrschichtig. Direkte Dependencies – also Bibliotheken, die ein Entwicklerteam explizit einbindet – sind noch verhältnismäßig gut kontrollierbar. Gefährlicher sind transitive Abhängigkeiten: Bibliotheken, die von Bibliotheken verwendet werden, oft mehrere Ebenen tief, und die niemand bewusst ausgewählt hat.

Darüber hinaus umfasst die Supply Chain auch Compiler, Build-Tools, Container-Base-Images und Distributionsmechanismen. Der SolarWinds-Angriff hat gezeigt, dass die Build-Pipeline selbst ein Angriffsvektor ist. Log4Shell hat demonstriert, wie weit eine einzelne transitive Abhängigkeit in die Infrastruktur reichen kann.

Typische Angriffsmuster sind:

• Dependency Confusion: Ein Angreifer veröffentlicht ein Paket mit demselben Namen wie ein internes Paket in einem öffentlichen Registry – mit höherer Versionsnummer. Paketmanager wählen dann automatisch die bösartige Version.
• Typosquatting: Pakete mit absichtlich fehlergeschriebenen Namen (z. B. reqeusts statt requests) verleiten Entwickler zur unbeabsichtigten Installation von Schadsoftware.
• Compromised Maintainer Accounts: Legitime Pakete werden über kompromittierte Entwicklerkonten mit schadhaftem Code versehen.

Ein SBOM dokumentiert diese Abhängigkeiten – aber erst eine systematische Risikoanalyse macht aus dieser Dokumentation eine Entscheidungsgrundlage.

Vulnerability Feeds, CVSS und die Grenzen generischer Scoring-Systeme

Die meisten Organisationen greifen auf die NVD (National Vulnerability Database) als primäre Quelle zurück. Daneben gewinnen OSV (Open Source Vulnerabilities) und VEX (Vulnerability Exploitability eXchange) an Bedeutung. VEX ergänzt das SBOM-Konzept sinnvoll: Hersteller können darin erklären, ob eine bekannte Schwachstelle in ihrer spezifischen Implementierung überhaupt ausnutzbar ist.

Das Problem mit dem CVSS-Score ist nicht, dass er falsch ist – es ist, dass er kontextlos ist. Ein CVSS von 9.8 klingt alarmierend. Aber dieser Score beschreibt das worst-case-Szenario unter optimalen Angriffsbedingungen, nicht die reale Bedrohungslage für eine konkrete Umgebung. Wenn eine Komponente nicht über das Netzwerk erreichbar ist, der betroffene Code-Pfad nie ausgeführt wird oder kein öffentlicher Exploit existiert, sinkt das tatsächliche Risiko drastisch.

Zwei Ergänzungssignale verbessern die Entscheidungsqualität erheblich:

• EPSS (Exploit Prediction Scoring System): Ein Machine-Learning-Modell, das die Wahrscheinlichkeit vorhersagt, dass eine Schwachstelle innerhalb von 30 Tagen in der freien Wildbahn ausgenutzt wird. Ein CVE mit CVSS 7.5 und EPSS 0.02 % ist in der Praxis weit weniger dringlich als eines mit CVSS 6.8 und EPSS 12 %.
• CISA KEV (Known Exploited Vulnerabilities Catalog): Schwachstellen auf dieser Liste werden aktiv ausgenutzt – sie haben per Definition Priorität, unabhängig vom CVSS-Score.

Tipp: Eine ausführliche Diskussion der einzelnen Scores findet sich auch in Episode 8 des EACG ProdSec-Talks Podcast, s. https://www.eacg.de/en/podcast/s08-borrowed-severity/.

Wer Vulnerabilities nur nach CVSS priorisiert, erzeugt systematisch Fehlpriorisierungen: zu viel Aufwand für theoretisch kritische, aber praktisch harmlose Lücken – und zu wenig Aufmerksamkeit für aktiv ausgenutzte Schwachstellen mit mittlerem Score-Bereich.

Um solchen Fehleinschätzungen entgegen zu wirken, hat TrustSource beispielsweise die Möglichkeit geschaffen, die Umgebungseigenschaften eines Moduls zu definieren und somit anstelle des einfachen CVSS Base Scores automatisch den Environmental Score zu berechnen, eine Adaption auf die Situation im Deploymment. Zudem bietet die EPSS/CVSS Matrix eine einfache Möglichkeit der Risiko-orientierten Priorisierung.

Ein risikobasierter Bewertungsrahmen: Von Rohdaten zur priorisierten Risikoaussage

Ein praxistaugliches Framework kombiniert vier Dimensionen zu einer gewichteten Risikoaussage:

1. Schwachstellenschwere: CVSS als Baseline, ergänzt durch Environmental Score, EPSS und KEV-Status.
2. Ausnutzbarkeit: Ist ein Exploit öffentlich verfügbar? Wird die verwundbare Funktion tatsächlich aufgerufen? Ist der Code-Pfad erreichbar?
3. Asset-Kritikalität: Welchen Schutzbedarf hat das betroffene System? Verarbeitet es personenbezogene Daten, Zahlungsinformationen oder kritische Infrastruktur?
4. Expositionsgrad: Ist der Service intern oder nach außen exponiert? Existieren kompensierende Kontrollen wie WAF, Network Segmentation oder mTLS?

Das Ergebnis ist kein einzelner Score, sondern eine kategorisierte Risikoaussage: Kritisch / Hoch / Mittel / Akzeptiert – mit begründeter Priorisierungsempfehlung. Entscheidend ist, dass diese Aussage für ein Sicherheitsteam operativ handlungsfähig macht: Wer muss bis wann was tun?

Ein praktischer Tipp: Priorisierungsentscheidungen sollten dokumentiert und mit einem Datum versehen werden. Was heute akzeptiertes Risiko ist, kann morgen durch einen neuen Exploit zur Sofortmaßnahme werden.

Integration in bestehende Sicherheits- und Entwicklungsprozesse

Supply-Chain-Risikomanagement entfaltet seinen Wert nur, wenn es in bestehende Prozesse eingebettet ist – nicht als separate Initiative daneben läuft.

CI/CD-Integration: SBOMs sollten automatisch bei jedem Build erzeugt und gegen aktuelle Vulnerability-Feeds geprüft werden. Tools wie Grype oder Trivy lassen sich direkt in Pipelines integrieren. Policy-as-Code-Ansätze (z. B. mit OPA) erlauben es, definierte Risikoakzeptanzgrenzen automatisch durchzusetzen – und Builds mit kritischen, nicht-akzeptierten Vulnerabilities zu stoppen.

SIEM/SOAR-Workflows: Neue CVEs mit Bezug zu inventarisierten Komponenten sollten automatisch Tickets erzeugen, gegen Asset-Kritikalität angereichert und an die richtigen Teams geroutet werden. SOAR-Playbooks können dabei die initiale Triage und Kontextualisierung übernehmen.

Third-Party-Risk-Programme: SBOMs von Lieferanten sollten Teil des Vendor-Assessments werden. VEX-Dokumente können vertraglich eingefordert werden. Die Frage „Welche Open-Source-Komponenten stecken in Ihrer Software?” ist inzwischen legitimer Bestandteil von Sicherheitsfragebögen.

Governance-seitig braucht es klare Verantwortlichkeiten: Wer ist Owner eines Assets, wer entscheidet über Risikoakzeptanz, und wer eskaliert bei überschrittenen SLAs? Ohne diese Struktur bleibt auch das beste Framework wirkungslos.

Metriken, Reporting und Kommunikation auf CISO-Ebene

CISOs brauchen keine Rohdaten – sie brauchen Entscheidungsgrundlagen. Die folgenden KPIs haben sich für das Supply-Chain-Risikoreporting bewährt:

• Mean Time to Remediate (MTTR): Wie lange dauert es im Durchschnitt, eine kritische Schwachstelle zu schließen? Getrennt nach Kritikalitätsstufen.
• Exposure Window: Wie lange war ein System mit einer bekannten, ausnutzbaren Schwachstelle exponiert?
• Risk Debt: Wie viele akzeptierte Risiken akkumulieren sich über Zeit – und wie entwickelt sich diese Zahl?
• SBOM Coverage Rate: Welcher Anteil der produktiven Software ist durch aktuelle SBOMs abgedeckt?

Für Auditoren und Regulatoren ist Nachvollziehbarkeit entscheidend: Wann wurde eine Schwachstelle bekannt, wann erkannt, wann bewertet, wann behoben – und wer hat welche Entscheidung getroffen? Diese Audit-Trail-Fähigkeit ist kein Nice-to-have, sondern Voraussetzung für Compliance-Nachweise unter NIS2, DORA und ähnlichen Regelwerken.

Tooling-Landschaft und strategische Handlungsempfehlungen

Die Tool-Landschaft ist gewachsen und weiterhin fragmentiert. Einige etablierte Werkzeuge:

• Dependency-Track (OWASP): Plattform zur kontinuierlichen SBOM-Analyse mit Vulnerability-Feed-Integration und Policy-Engine.
• Grype / Syft (Anchore): Schlankere CLI-Tools zur SBOM-Generierung (Syft) und Vulnerability-Scanning (Grype), gut für CI/CD-Integration.
• OpenSSF Scorecard: Bewertet Open-Source-Projekte nach Sicherheitshygiene-Kriterien – nützlich bei der Auswahl von Abhängigkeiten.
• GUAC (Graph for Understanding Artifact Composition): Experimentell, aber vielversprechend für die graph-basierte Analyse von Supply-Chain-Beziehungen.
• TrustSource : Mit der Community Edition von TrustSource, die all-in-one-Lösung, die seit diesem Monat dabei unterstützt möglichst übergreifend die Aufgaben SBOM-Generierung, Vulnerability-Enrichment, Asset-Kontext und Workflow-Automatisierung zusammenzuführen oder dem Managed Service, eines der wenigen Werkzeuge, das den kompletten Prozess adressiert.

---

Fazit: Drei Kernergebnisse

1. Ein SBOM ist ein Startpunkt, keine Lösung. Erst die Verknüpfung mit Vulnerability-Intelligence, Exploitability-Signalen und Geschäftskontext macht aus Komponentendaten echte Risikoentscheidungen.

2. CVSS allein führt zu Fehlpriorisierungen. EPSS und der CISA KEV Catalog sind unverzichtbare Ergänzungen, um begrenzte Remediation-Kapazitäten auf tatsächlich relevante Risiken zu konzentrieren.

3. Supply-Chain-Risikomanagement muss prozessual verankert sein. CI/CD-Integration, klare Governance und steuerbare Metriken sind die Voraussetzung dafür, dass Sichtbarkeit in Schutzwirkung übersetzt wird.