Software Supply Chain Risks: From SBOM to Actionable Risk Decisions

The Illusion of Visibility: Why an SBOM Alone Is Not Risk Management

A Software Bill of Materials creates transparency – but transparency is not protection. Those who create an SBOM know which components are in their software. Knowing which components are inside is far from knowing which of them represent a real business risk. Between these two points lies a structural gap that is underestimated in many security programmes.

The SBOM is a necessary foundation – but on its own it does not answer a single risk decision. It does not tell you whether a vulnerable library is running in a productive, externally exposed service or in an internal development tool with no network access. It does not distinguish between a theoretically exploitable code path and one that is actually reachable. And it cannot assess which vulnerability will be actively exploited within the next 30 days.

Effective supply chain risk management begins where the SBOM ends: with the linkage of component data to vulnerability intelligence, business context and actionable logic.

Anatomy of a Software Supply Chain Risk

The attack surface along the software supply chain is multi-layered. Direct dependencies – that is, libraries a development team explicitly includes – are still relatively controllable. More dangerous are transitive dependencies: libraries used by other libraries, often several levels deep, and that nobody consciously selected.

Beyond that, the supply chain also encompasses compilers, build tools, container base images and distribution mechanisms. The SolarWinds attack demonstrated that the build pipeline itself is an attack vector. Log4Shell showed how far a single transitive dependency can reach into the infrastructure.

Typical attack patterns include:

• Dependency Confusion: An attacker publishes a package with the same name as an internal package in a public registry – with a higher version number. Package managers then automatically select the malicious version.
• Typosquatting: Packages with deliberately misspelled names (e.g. reqeusts instead of requests) trick developers into unintentionally installing malware.
• Compromised Maintainer Accounts: Legitimate packages are injected with malicious code via compromised developer accounts.

An SBOM documents these dependencies – but only a systematic risk analysis turns this documentation into a basis for decisions.

Vulnerability Feeds, CVSS and the Limits of Generic Scoring Systems

Most organisations rely on the NVD (National Vulnerability Database) as their primary source. Alongside it, OSV (Open Source Vulnerabilities) and VEX (Vulnerability Exploitability eXchange) are gaining importance. VEX usefully complements the SBOM concept: vendors can declare whether a known vulnerability is actually exploitable in their specific implementation at all.

The problem with the CVSS score is not that it is wrong – it is that it is context-free. A CVSS of 9.8 sounds alarming. But this score describes the worst-case scenario under optimal attack conditions, not the real threat situation for a specific environment. If a component is not reachable over the network, the affected code path is never executed, or no public exploit exists, the actual risk drops drastically.

Two supplementary signals significantly improve decision quality:

• EPSS (Exploit Prediction Scoring System): A machine learning model that predicts the probability that a vulnerability will be exploited in the wild within 30 days. A CVE with CVSS 7.5 and EPSS 0.02% is in practice far less urgent than one with CVSS 6.8 and EPSS 12%.
• CISA KEV (Known Exploited Vulnerabilities Catalog): Vulnerabilities on this list are being actively exploited – by definition they have priority, regardless of CVSS score.

Tip: A detailed discussion of the individual scores can also be found in episode 8 of the EACG ProdSec-Talks podcast, see https://www.eacg.de/en/podcast/s08-borrowed-severity/.

Those who prioritise vulnerabilities solely by CVSS systematically produce misprioritisations: too much effort on theoretically critical but practically harmless gaps – and too little attention on actively exploited vulnerabilities with mid-range scores.

To counteract such misjudgements, TrustSource, for example, has created the ability to define the environmental properties of a module and thus automatically calculate the Environmental Score instead of the simple CVSS Base Score – an adaptation to the situation at deployment. In addition, the EPSS/CVSS matrix offers a simple way of risk-oriented prioritisation.

A Risk-Based Assessment Framework: From Raw Data to a Prioritised Risk Statement

A practical framework combines four dimensions into a weighted risk statement:

1. Vulnerability severity: CVSS as baseline, supplemented by Environmental Score, EPSS and KEV status.
2. Exploitability: Is an exploit publicly available? Is the vulnerable function actually called? Is the code path reachable?
3. Asset criticality: What is the protection need of the affected system? Does it process personal data, payment information or critical infrastructure?
4. Degree of exposure: Is the service internal or externally exposed? Do compensating controls such as WAF, network segmentation or mTLS exist?

The result is not a single score but a categorised risk statement: Critical / High / Medium / Accepted – with a justified prioritisation recommendation. What matters is that this statement enables a security team to act operationally: who has to do what by when?

A practical tip: prioritisation decisions should be documented and dated. What is accepted risk today can become an immediate action tomorrow due to a new exploit.

Integration into Existing Security and Development Processes

Supply chain risk management only delivers value when it is embedded in existing processes – not when it runs as a separate initiative alongside them.

CI/CD integration: SBOMs should be generated automatically with every build and checked against current vulnerability feeds. Tools such as Grype or Trivy can be integrated directly into pipelines. Policy-as-code approaches (e.g. with OPA) allow defined risk acceptance limits to be enforced automatically – and builds with critical, non-accepted vulnerabilities to be stopped.

SIEM/SOAR workflows: New CVEs relating to inventoried components should automatically create tickets, be enriched against asset criticality and routed to the right teams. SOAR playbooks can take over the initial triage and contextualisation.

Third-party risk programmes: Supplier SBOMs should become part of vendor assessment. VEX documents can be contractually required. The question “Which open source components are in your software?” is now a legitimate part of security questionnaires.

On the governance side, clear responsibilities are needed: who owns an asset, who decides on risk acceptance, and who escalates when SLAs are breached? Without this structure, even the best framework remains ineffective.

Metrics, Reporting and Communication at CISO Level

CISOs do not need raw data – they need a basis for decisions. The following KPIs have proven useful for supply chain risk reporting:

• Mean Time to Remediate (MTTR): How long does it take on average to close a critical vulnerability? Broken down by criticality levels.
• Exposure Window: How long was a system exposed with a known, exploitable vulnerability?
• Risk Debt: How many accepted risks accumulate over time – and how is this figure developing?
• SBOM Coverage Rate: What share of productive software is covered by up-to-date SBOMs?

For auditors and regulators, traceability is decisive: when was a vulnerability disclosed, when detected, when assessed, when remediated – and who made which decision? This audit trail capability is not a nice-to-have but a prerequisite for compliance evidence under NIS2, DORA and similar regulations.

Tooling Landscape and Strategic Recommendations for Action

The tooling landscape has grown and remains fragmented. Some established tools:

• Dependency-Track (OWASP): Platform for continuous SBOM analysis with vulnerability feed integration and policy engine.
• Grype / Syft (Anchore): Leaner CLI tools for SBOM generation (Syft) and vulnerability scanning (Grype), well suited for CI/CD integration.
• OpenSSF Scorecard: Rates open source projects by security hygiene criteria – useful when selecting dependencies.
• GUAC (Graph for Understanding Artifact Composition): Experimental, but promising for graph-based analysis of supply chain relationships.
• TrustSource: With the TrustSource Community Edition – the all-in-one solution that, as of this month, helps to bring together the tasks of SBOM generation, vulnerability enrichment, asset context and workflow automation as comprehensively as possible – or with the Managed Service, one of the few tools that addresses the complete process.

---

Conclusion: Three Key Takeaways

1. An SBOM is a starting point, not a solution. Only its linkage with vulnerability intelligence, exploitability signals and business context turns component data into genuine risk decisions.

2. CVSS alone leads to misprioritisation. EPSS and the CISA KEV Catalog are indispensable additions for focusing limited remediation capacity on actually relevant risks.

3. Supply chain risk management must be anchored in processes. CI/CD integration, clear governance and controllable metrics are the prerequisites for translating visibility into protective impact.