Software supply chain security needs risk-based prioritization

At a glance

What this is: ArmorCode frames software supply chain security as an operational governance problem, with SBOMs, VEX and business-risk prioritisation needed to move beyond raw SCA alerts.

Why it matters: This matters because IAM, NHI and build-pipeline governance all depend on knowing which third-party dependencies, credentials and delivery paths are actually reachable before remediation capacity is overwhelmed.

By the numbers:

• Third-party involvement in breaches doubled from 15% to 30% in a single year, according to Verizon’s 2025 Data Breach Investigations Report cited by ArmorCode.

Context

Software supply chain security is the discipline of controlling the third-party code, build systems and delivery paths that ship software into production. The core governance gap is that traditional application security tools were built to inspect first-party code, while most operational exposure now comes from dependencies, containers and CI/CD infrastructure that change faster than manual review can follow.

In this article, ArmorCode argues that SBOMs, VEX and contextual prioritisation are the practical answer to that gap because they connect inventory to exploitability and business impact. The identity intersection is real: build pipelines, third-party access and machine credentials turn supply chain management into a governance issue for both NHI and application delivery.

Key questions

Q: What breaks when supply chain teams rely on scanner severity alone?

A: They get a backlog of high-volume findings with no reliable way to tell what is reachable, exploitable or business-critical. Severity scores describe technical weakness in isolation, but they do not account for exposure, ownership or reachability, so teams spend time on dead ends while real risk waits for attention.

Q: Why do SBOMs need VEX and asset context to be useful?

A: Because an SBOM is only an inventory. VEX and context tell you whether a flagged component is actually affected, whether the vulnerable code path is reachable and whether the asset matters enough to prioritise. Without that layer, an inventory becomes compliance paperwork instead of a remediation tool.

Technical breakdown

Why SCA creates scale without context

Software composition analysis lists components and known vulnerabilities, but it does not tell teams whether a vulnerability is reachable, whether the affected code path is used, or whether the asset matters to the business. That limitation becomes severe when organisations run multiple scanners across teams and each one scores the same component differently. The result is operational noise, not clear risk. In practice, SCA is necessary for visibility, but it is not enough for decision-making because it lacks exploitability and asset context.

Practical implication: treat SCA as an intake signal and push findings into a context layer before deciding remediation priority.

How SBOMs and VEX change supply chain governance

An SBOM is a structured inventory of software components, while VEX adds exploitability status for a specific vulnerability in a specific product context. Together they move supply chain security from static listing to governed interpretation. Without VEX, an SBOM can only tell you that a component exists; with VEX, teams can distinguish affected, fixed, not affected and under investigation. That distinction matters because remediation capacity is finite and false positives drain it quickly.

Practical implication: ingest SBOMs continuously and require VEX or equivalent context before escalating every flagged vulnerability.

Why build pipelines are a high-value target

Build pipelines are attractive because they often hold broad, long-lived credentials and sit below the scrutiny applied to production services. If an attacker compromises the pipeline, malicious code or tainted artifacts can propagate downstream through trusted delivery paths. That makes the pipeline part of the attack surface, not just the place where software is assembled. The article’s link to CI/CD risk is important because the compromise point can be far upstream from the eventual customer impact.

Practical implication: govern pipeline identities, secrets and trust paths as production-grade assets, not implementation detail.

Threat narrative

Attacker objective: The attacker aims to gain broad downstream reach by inserting malicious code, compromising credentials or propagating tainted software through trusted delivery channels.

1. Entry begins when an attacker compromises a trusted dependency, maintainer account or build pipeline rather than attacking the application directly.
2. Credential access or trust abuse then allows the malicious package or tainted artifact to ride through legitimate installs and CI/CD workflows.
3. Impact occurs when downstream systems inherit the compromised component or build output, spreading exposure across multiple environments and organisations.

Breaches seen in the wild

• reviewdog Action compromise 2025: A stolen maintainer token poisoned reviewdog/action-setup, leaking CI secrets including the tj-actions bot token used in the next attack.
• LiteLLM PyPI package breach: LiteLLM PyPI supply chain attack, credentials stolen from users.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Risk-based prioritisation is now the control that makes supply chain security operable. The article is right to move beyond raw severity scoring because CVSS does not answer whether a component is reachable, exposed or business-critical. That gap is why teams drown in findings and still miss the handful that matter most. Practitioners should treat prioritisation as a governance control, not a reporting function.

SBOMs without exploitability context create inventory debt. An SBOM proves that components exist, but it does not prove whether they are actionable risks. Once that inventory is produced, the program still needs continuous enrichment, validation and ownership mapping. Otherwise the organisation accumulates documents faster than it reduces exposure, which is a maturity problem rather than a tooling problem.

Build pipeline identity is the overlooked control plane in software supply chain risk. The article’s discussion of CI/CD credential breadth is a reminder that pipeline accounts and automation tokens function as machine identities with production impact. That makes this a governance issue across NHI, DevSecOps and cloud delivery, not just application security. Practitioners should manage pipeline identities as scoped, monitored and revocable access paths.

CTEM gives supply chain teams a practical operating model, but only if the data feeding it is trustworthy. Continuous threat exposure management works best when exposure, exploitability and ownership are correlated before a queue reaches humans. The article’s focus on context graphs and VEX is therefore directionally correct. Teams should use CTEM to decide what to fix first, not to justify creating another alert stream.

Software supply chain security is becoming a third-party governance problem as much as a vulnerability problem. Once third-party code, build systems and outside maintainers are in scope, the boundary between technical exposure and supplier accountability disappears. That means security leaders need procurement, engineering and identity teams to share responsibility for the same attack surface. Practitioners should align supplier oversight with runtime exposure, not contract language alone.

From our research library:

• 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
• Read next: Third-Party, B2B and Contractor Access Guide

What this signals

Risk-based prioritisation is becoming the practical control boundary for software supply chain security. Teams that keep treating severity as the deciding factor will continue to overwork analysts and underprotect the assets most likely to be reached by an attacker. The better model is to score reachability, ownership and exposure before a finding enters the remediation queue.

Pipeline identity is now part of third-party governance. Build systems, automation tokens and CI/CD runners behave like machine identities, so their permissions and trust relationships need explicit lifecycle control. If organisations do not govern those identities, a supplier compromise can become a delivery-path compromise very quickly.

For practitioners

• Define a supply chain prioritisation model Rank findings by exploitability, exposure and asset criticality rather than by scanner severity alone so teams know what to fix first.
• Ingest SBOMs into a single control plane Normalise CycloneDX, SPDX and other SBOM formats into one view so component inventory, ownership and exposure can be assessed together.
• Require VEX before escalating every flagged CVE Use affected, not affected, fixed and under investigation status to suppress dead-end alerts and focus analyst effort on reachable risk.
• Govern CI/CD identities and secrets as production assets Review pipeline accounts, tokens and service credentials with the same discipline used for runtime access because build compromise can propagate downstream.
• Correlate third-party access with dependency exposure Map which suppliers, maintainers and integration partners can influence the software path, then align that with your SBOM and remediation workflow.

Key takeaways

• Software supply chain security fails when organisations treat SCA output as the end state rather than the start of decision-making.
• The article points to a clear scale problem: third-party involvement in breaches rose from 15% to 30% in a single year, while scanner noise continues to outpace human triage capacity.
• SBOMs, VEX and contextual prioritisation are the controls that turn inventory into action, especially where build pipelines and third-party access create machine-identity risk.

Key terms

• Software Supply Chain Security: Software supply chain security is the practice of protecting the people, code, tools, dependencies, and delivery paths used to build and ship software. It covers source integrity, dependency risk, build system hardening, artifact signing, provenance, and release controls so malicious changes are detected before software reaches production.
• SBOM: A software bill of materials is an inventory of components, dependencies, and often transitive packages used in an application or build. It gives defenders visibility into what entered the software supply chain and helps spot risky or newly introduced dependencies.
• Vex: VEX, or Vulnerability Exploitability eXchange, is a way to state whether a known vulnerability is exploitable in a specific product, build, or deployment. It helps security teams avoid treating every matching CVE as equally urgent and improves prioritisation in software supply chains.
• Continuous Threat Exposure Management: Continuous Threat Exposure Management is the ongoing process of finding which assets, identities, and paths are actually reachable from the current environment. It moves risk assessment away from static inventories and toward live exposure, so security teams can prioritise what an attacker or misuse path can reach now.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security and secrets management. It helps security and identity practitioners connect supply chain exposure to the access paths that make it exploitable.