Why do traditional software bill of materials approaches leave gaps in modern application security programmes?

Where SBOMs Stop Being Enough for Modern Supply Chains

Traditional software bill of materials approaches are useful for answering a narrow question: what components are present? That is not the same as answering what the application depends on, how trust is established, or where a compromise would actually spread. For modern programmes, the gap matters because security teams need to understand build systems, nested dependencies, generated artefacts, runtime relationships, and the ownership context around each component. That broader view is what turns inventory into actionable risk intelligence.

An SBOM can support procurement, vulnerability triage, and disclosure workflows, but it can also create false confidence if teams treat it as a complete picture. A dependency list rarely captures internal code paths, ephemeral build infrastructure, secrets handling, or the data exchanges that make one component materially dependent on another. NIST’s control catalogues make the same practical point through asset, configuration, and supply-chain controls, but those controls only become effective when the SBOM is treated as one input to a wider assurance model rather than the model itself. In practice, many security teams discover the missing relationships only after an incident review forces them to reconstruct how software was actually built and deployed.

What the Missing Context Looks Like in Practice

The main limitation is that most SBOM implementations describe software composition at a point in time, while modern application security programmes need to understand composition across the full lifecycle. An SBOM may identify libraries, but it usually does not show whether a package is used at build time only, embedded into a container image, fetched dynamically, or replaced at runtime. That distinction changes the real exposure because not every listed dependency has the same attack surface or operational importance.

Practically, the blind spots usually fall into four areas:

• Build and delivery systems: CI/CD runners, package registries, signing services, and automation accounts can become the real trust anchors.

• Internal and generated components: custom code, generated artefacts, shared modules, and vendored assets often sit outside a simple external dependency list.

• Runtime relationships: service-to-service calls, data flows, permissions, and environment-specific configuration determine what a compromise can reach.

• Ownership and provenance: teams often lack a reliable way to tell who maintains a component, who approved it, and what verification evidence exists.

That is why SBOM data is most valuable when it is linked to other forms of evidence such as build provenance, change records, vulnerability intelligence, and deployment context. Otherwise, organisations may know what is in the package manifest but still not know whether the component is reachable, trusted, or business-critical. The question is not only whether a dependency exists, but whether it can be exploited in the environment in which it is actually used. The NIST SP 800-53 Rev 5 Security and Privacy Controls are relevant here because they emphasise control over inventory, configuration, and system integrity, which SBOMs alone do not deliver.

Where this guidance breaks down is in environments that intentionally change composition at high speed without reliable build metadata or deployment traceability, because the SBOM then becomes an incomplete snapshot rather than a trustworthy security reference.

When SBOM Gaps Become Operational Risk

Tighter software transparency often increases integration and maintenance overhead, so organisations have to balance better visibility against the cost of collecting and correlating more evidence. The tradeoff is real: a pure SBOM approach is easier to produce, but it leaves governance teams with an inventory that can be accurate and still operationally misleading.

This becomes more serious in a few common edge cases. First, multi-stage builds and container images can hide what was present during compilation versus what is present at runtime. Second, ephemeral or serverless workloads may not leave a stable artefact trail that a conventional SBOM can fully describe. Third, open-source components can be secure in one release and risky in another, which means a dependency list without versioning and provenance context can age quickly. There is not full industry consensus on how far an “SBOM-plus” model should extend, but there is broad agreement that the minimum useful view must include provenance, dependency relationships, and deployment context if the programme is meant to support real risk decisions.

For modern application security programmes, the practical failure is not lack of inventory alone. It is the assumption that inventory equals understanding. Once teams make decisions on that assumption, they can miss the most important part of the supply chain: where trust is created, where it is transferred, and where it can fail.

Practitioner Guidance

What to prioritise: Treat SBOM output as a starting point for assurance, not as the assurance layer itself. The first decision is whether the programme needs only component visibility or whether it also needs provenance, build, and runtime context to make security decisions.

What to verify: Confirm that the same component record can be traced through build inputs, signing or approval evidence, deployment target, and ownership. If any one of those links is missing, the SBOM should be treated as partial evidence rather than authoritative inventory.

Common mistake: Teams often focus on completeness of the package list and ignore whether the listed items are actually security-relevant in the deployed environment. A smaller but contextualised evidence set is usually more useful than a larger list with no relationship data.

Practitioner takeaway: The strongest modern programmes do not ask SBOMs to solve supply-chain assurance on their own; they use them to anchor a wider chain of provenance, dependency, and runtime evidence that shows where risk actually concentrates.

Related resources from NHI Mgmt Group

• Why do software supply chain threats expose gaps in traditional application security programmes?
• How should security teams implement a software bill of materials across modern application stacks?
• Why do traditional security tools often fail to reduce application risk in modern software teams?
• How should security teams use an extended software bill of materials to prioritise application risk?