Integrated Risk Management for Software Products: From SBOM Data to Board-Level Insight

Von lars-henriksen | Thema: Risk Management

Risikomanagement für Softwareprodukte steckt in einem Dilemma: Die Bedrohungslandschaft ist hochdynamisch, die Softwarearchitekturen sind komplex – aber die eingesetzten Methoden stammen oft aus einer anderen Ära. Wer heute noch primär auf Excel-Tabellen und jährliche Audits setzt, verliert den Anschluss. Dieser Artikel zeigt, wie strukturierte SBOM-Daten kombiniert mit Threat-Modeling-Methoden eine belastbare Risikobasis schaffen – von der Engineering-Ebene bis in den Boardroom.

1. The Maturity Gap: Warum klassisches Risikomanagement an seine Grenzen stößt

Traditionelle Risikomanagement-Frameworks wurden für eine Welt entworfen, in der Softwareprodukte überschaubar, monolithisch und intern entwickelt waren. Heute sieht die Realität anders aus: Ein modernes Produkt besteht zu 70–90 % aus Open-Source-Komponenten, wird über CI/CD-Pipelines mehrfach täglich deployed und bezieht Abhängigkeiten aus dutzenden indirekten Quellen.

Spreadsheet-basierte Ansätze versagen hier strukturell. Sie sind statisch in einer dynamischen Umgebung, schwer zu automatisieren und liefern keine maschinenlesbare Datenbasis für systematische Analysen. Vor allem aber scheitern sie am zentralen Problem moderner Softwarerisiken: der Supply-Chain-Komplexität. Log4Shell hat exemplarisch gezeigt, dass eine einzelne transitive Abhängigkeit globale Auswirkungen haben kann – und die meisten Unternehmen wussten schlicht nicht, welche ihrer Produkte betroffen waren. Das ist kein Prozessversagen, das ist ein Datenproblem.

2. Das SBOM als Risikofundament: Von der Komponentenliste zur strukturierten Datenbasis

Ein Software Bill of Materials (SBOM) ist mehr als ein Inventarverzeichnis. In maschinenlesbaren Formaten wie CycloneDX oder SPDX liefert ein SBOM eine strukturierte, versionierte Beschreibung aller Softwarekomponenten – direkte und transitive Abhängigkeiten inklusive.

Der eigentliche Wert entsteht durch Anreicherung: Wenn SBOM-Daten mit Schwachstellendatenbanken wie der NVD verknüpft werden, lässt sich für jede Komponente feststellen, welche CVEs bekannt sind, wie schwerwiegend diese laut CVSS eingestuft werden und – entscheidend – ob die Schwachstelle im konkreten Deployment-Kontext überhaupt ausnutzbar ist. Hier kommt das VEX-Format (Vulnerability Exploitability eXchange) ins Spiel: Es erlaubt Herstellern, maschinenlesbare Aussagen darüber zu machen, ob ein CVE für ihr Produkt tatsächlich relevant ist.

Das Ergebnis ist eine dynamische, automatisierbar pflegbare Risikodatenbasis – kein statisches Dokument, sondern ein lebendiger Datenbestand, der bei jedem Build-Zyklus aktualisiert werden kann.

3. Threat Modeling als analytische Schicht: Von Komponenten zu Angriffsszenarien

SBOM-Daten zeigen, was verwundbar ist. Threat Modeling beantwortet die Frage, wie diese Verwundbarkeit in einem konkreten Angriffskontext ausgenutzt werden kann. Beide Perspektiven sind notwendig – keine reicht allein aus.

Methoden wie STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) oder PASTA (Process for Attack Simulation and Threat Analysis) bieten strukturierte Rahmen, um für ein gegebenes Softwareprodukt systematisch Bedrohungsszenarien zu entwickeln. Attack Trees ermöglichen es, Angriffspfade zu modellieren und dabei SBOM-Komponenten als konkrete Angriffspunkte zu verankern.

Der Mehrwert dieser Kombination: Eine Bibliotheksschwachstelle mit CVSS 9.8 ist ohne Kontext wenig aussagekräftig. Erst wenn klar ist, dass diese Komponente in einem internet-exponierten Service ohne Authentifizierung läuft und Nutzerdaten verarbeitet, wird aus einer abstrakten Zahl ein konkretes Risiko. Threat Modeling liefert genau diesen Kontext – und ermöglicht eine Priorisierung, die Engineering-Teams tatsächlich handlungsleitend unterstützt.

4. Eine einheitliche Risk Posture: Aggregation, Priorisierung und Scoring

Die Kombination aus SBOM-Schwachstellendaten und Threat-Modeling-Ergebnissen schafft die Grundlage für ein kohärentes Risk Scoring. Entscheidend ist dabei, nicht einfach CVSS-Scores zu addieren, sondern mehrere Dimensionen zu berücksichtigen:

Exploitability: Existiert ein öffentlicher Exploit? Wird die Schwachstelle aktiv ausgenutzt?
Exposure: Ist die betroffene Komponente öffentlich erreichbar oder nur intern?
Business Impact: Welche Geschäftsprozesse oder Daten sind betroffen?
EPSS-Score: Der Exploit Prediction Scoring System-Score gibt eine datengetriebene Wahrscheinlichkeit an, dass eine Schwachstelle in den nächsten 30 Tagen aktiv ausgenutzt wird.

Ein praxistaugliches Scoring-Modell kombiniert diese Faktoren zu einem gewichteten Risikowert – und definiert klare Schwellenwerte für sofortigen Handlungsbedarf, geplagte Remediation und akzeptiertes Residualrisiko. Damit werden Engineering-Teams nicht mit Tausenden von Low-Priority-Findings überflutet, sondern erhalten eine fokussierte, priorisierte Arbeitsliste. Die Reduktion von False Positives ist kein nettes Feature – sie ist die Voraussetzung dafür, dass das System überhaupt gelebt wird.

5. Die Kommunikationslücke schließen: Technisches Risiko für den Vorstand übersetzen

Der vielleicht unterschätzteste Schritt im gesamten Prozess ist die Übersetzung technischer Risikodaten in Board-relevante Informationen. CISOs und Security-Teams kämpfen regelmäßig damit, dass ihre Berichte entweder zu technisch sind, um Entscheidungen auszulösen, oder so stark abstrahiert wurden, dass sie jeden Handlungsanreiz verloren haben.

Effektive Board-Level-Kommunikation erfordert:

Ein gemeinsames Risikovokabular: Risikotoleranz muss explizit definiert sein – welche Risikokategorien sind inakzeptabel, welche können akzeptiert werden, welche müssen transferiert werden?
Geschäftsrelevante KPIs statt CVE-Zählungen: “Wir haben 847 offene CVEs” ist keine Entscheidungsgrundlage. “3 kritische Schwachstellen in produktiv genutzten Systemen gefährden Compliance mit NIS2 und könnten zu Betriebsunterbrechungen führen” schon.
Visualisierungsansätze: Risikoheatmaps, Trend-Dashboards und “Risk Appetite vs. Current Exposure”-Darstellungen ermöglichen Entscheidungsträgern eine intuitive Einschätzung der Lage.
Klare Handlungsoptionen: Jeder Board-Report sollte mit konkreten Entscheidungsoptionen enden – inklusive Ressourcenbedarf und erwarteter Risikoreduzierung.

Das Ziel ist nicht, den Vorstand technisch zu schulen, sondern ihm die Informationen zu geben, die er benötigt, um informierte Governance-Entscheidungen zu treffen.

6. Den Feedback-Loop operationalisieren: Von Insight zu kontinuierlicher Risikoreduzierung

Ein Risikomanagement-Framework ist nur dann wertvoll, wenn es in den Entwicklungsalltag integriert ist – nicht als jährliches Audit, sondern als kontinuierlicher Prozess. Die Integration in DevSecOps-Workflows ist dafür entscheidend.

Praktische Ansätze:

Automatisierte SBOM-Generierung bei jedem Build – etwa über Syft oder Trivy – stellt sicher, dass die Risikobasisdaten immer aktuell sind.
Policy-as-Code ermöglicht es, Risikoentscheidungen als maschinenprüfbare Regeln zu formulieren: “Kein Deployment, wenn kritische CVEs mit EPSS > 0,8 ungepacht sind.”
Definierte Eskalationspfade sorgen dafür, dass kritische Findings nicht im Backlog verschwinden, sondern strukturiert eskaliert und priorisiert werden.
Regelmäßige Threat-Model-Reviews – idealerweise bei jeder signifikanten Architekturänderung – halten das analytische Modell valide.

Der entscheidende Kulturwandel: Risikomanagement wird zur Shared Responsibility zwischen Security, Engineering und Product Management – nicht zur alleinigen Aufgabe eines Compliance-Teams.

7. Tooling, Standards und Ausblick: Wohin das Ökosystem sich entwickelt

Das Ökosystem rund um softwareorientiertes Risikomanagement reift sichtbar. Auf der Standards-Seite setzen NIST SP 800-161 (Supply Chain Risk Management) und der EU Cyber Resilience Act zunehmend verbindliche Rahmenbedingungen – insbesondere für Hersteller, die in der EU tätig sind. Die Pflicht zur SBOM-Erstellung wird in regulierten Märkten zur Normalität.

Auf der Tooling-Seite hat sich ein funktionsfähiges Open-Source-Ökosystem entwickelt:

Dependency-Track bietet eine umfassende SBOM-Management- und Vulnerability-Tracking-Plattform.
Grype liefert schnelle, containerbasierte Schwachstellenscans.
OpenSSF Scorecard bewertet die Security-Gesundheit von Open-Source-Projekten – ein wichtiger Input für Supply-Chain-Risikoentscheidungen.

Der Ausblick ist klar: Die Richtung geht hin zu automatisierter, risikobasierter Software-Governance – mit AI-gestützter Priorisierung, kontinuierlichem Compliance-Monitoring und standardisierten Risikoformaten, die über Organisationsgrenzen hinweg ausgetauscht werden können. Wer heute die Dateninfrastruktur aufbaut, positioniert sich für diesen nächsten Reifegrad.

Fazit

Drei Kernergebnisse aus diesem Framework:

SBOM-Daten sind das Fundament – aber erst durch Anreicherung mit Schwachstelleninformationen und kontextuellem Threat Modeling entsteht eine handlungsrelevante Risikobasis.
Priorisierung schlägt Vollständigkeit – ein Score-Modell, das Exploitability, Exposure und Business Impact kombiniert, reduziert Noise und erhöht die Akzeptanz bei Engineering-Teams dramatisch.
Die Übersetzungsarbeit ist strategisch – wer technische Risikodaten nicht in Board-relevante Entscheidungsvorlagen überführen kann, verliert den internen Rückhalt für nachhaltige Investitionen in Software-Sicherheit.