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

Traditional software bill of materials approaches often stop at a dependency list, which leaves out internal components, CI/CD systems, data flows, and runtime conditions. That creates blind spots in ownership, provenance, and attack surface understanding. Modern software supply chains are interconnected, so visibility must extend beyond inventory to show how components relate and where risk actually concentrates.

Why This Matters for Security Teams

Traditional software bill of materials approaches are useful for answering what is present in an application, but they often stop short of explaining how software is actually assembled, deployed, and operated. That matters because security teams do not secure dependency lists in isolation; they secure pipelines, build artefacts, secrets, service accounts, and runtime behaviour. The gap is especially visible where modern application security programmes also need to account for NHI and secret sprawl, as highlighted in The State of Secrets in AppSec.

When a BOM cannot show which internal component owns a library, which CI/CD step injects a token, or which data flow exposes a credential at runtime, risk becomes invisible until it is exploited. That is why current guidance increasingly treats SBOMs as one control input rather than a complete security answer, with NIST SP 800-53 Rev 5 Security and Privacy Controls emphasizing broader supply chain and configuration management disciplines. In practice, many security teams discover these blind spots only after a leaked secret, a compromised build step, or a third-party dependency abuse has already altered the blast radius.

How It Works in Practice

A mature application security programme treats the SBOM as one layer in a wider evidence chain. The dependency manifest should be joined to build metadata, provenance attestations, deployment topology, secret inventory, and runtime telemetry so teams can answer four questions: what was built, who built it, what it can reach, and what identities it uses. This is where software composition data starts to intersect with NHI governance, because service accounts, API keys, OAuth tokens, and ephemeral workload credentials are often the real control points.

Practitioners increasingly combine SBOMs with adjacent artefacts such as:

• Source and build provenance to verify where artefacts came from
• CI/CD policy checks to identify when secrets, signed artefacts, or unreviewed steps enter the pipeline
• Runtime inventories to distinguish dormant packages from reachable attack paths
• Identity and secrets mapping to show which workloads can impersonate other systems

That is why the broader operating model described in The State of Non-Human Identity Security is relevant even for SBOM conversations: visibility failures are often identity failures in disguise. For identity proofing and lifecycle discipline, NIST SP 800-63 Digital Identity Guidelines is a useful anchor for evaluating assurance, binding, and authentication strength. The practical goal is not a larger inventory, but a connected inventory that shows ownership, trust boundaries, and blast radius.

These controls tend to break down in fast-moving polyglot environments where ephemeral containers, generated code, and third-party SaaS integrations change faster than the inventory pipeline can refresh.

Common Variations and Edge Cases

Tighter inventory correlation often increases operational overhead, requiring organisations to balance visibility against pipeline speed and engineering friction. That tradeoff is real, especially when teams support monorepos, internal package registries, and multiple deployment targets. Best practice is evolving, but there is no universal standard for whether an SBOM should include only packaged dependencies or also internal services, transitive infrastructure components, and identity artefacts.

Edge cases usually appear in systems with heavy automation or platform abstraction. For example, container images may look clean while the orchestration layer injects privileged secrets at deploy time. Serverless systems may have minimal package depth but strong dependency on event permissions and managed identities. AI-enabled applications introduce another layer of ambiguity because model calls, tool use, and prompt routing can create effective dependencies that never appear in a traditional BOM. The OWASP Agentic Applications Top 10 is especially useful here because it reflects the emerging reality that runtime authority can matter more than static package content.

For that reason, modern programmes should define the SBOM boundary explicitly, then pair it with provenance, secret scanning, runtime access analysis, and ownership mapping. Without that expansion, the inventory looks complete while the actual attack surface remains partially hidden.

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?
• Why do mature security programmes still leave exposed gaps?