What breaks when software supply chain scanning stops at dependency inventory?

Why This Matters for Security Teams

Dependency inventory answers only the first question in software supply chain security: what was pulled into the build. It does not answer whether the vulnerable code is actually executed, whether the package is present only in a test path, or whether a weakness can touch secrets and production data. That gap turns scanning into a reporting exercise instead of exposure reduction, and it is exactly why teams drown in findings that do not change risk.

Practitioners see this most clearly when inventory-based tools flag a long list of transitive packages, but the real exploit path comes from a reachable function, a poisoned build step, or an exposed credential chain. The OWASP Non-Human Identity Top 10 is relevant here because supply chain compromise often becomes an identity and secrets problem once attackers land in CI/CD or package workflows. NHIMG research has repeatedly shown that package attacks move fast and target credentials first, as seen in the LiteLLM PyPI package breach.

In practice, many security teams discover the difference between “present” and “exploitable” only after a dependency alert has already been triaged, escalated, and manually dismissed.

How It Works in Practice

Effective software supply chain scanning has to go beyond inventory and ask whether a dependency is reachable, how it is deployed, and what it can touch. A package that exists in a lockfile is not the same as a package that is imported in a production code path, loaded by an agent, or executed inside a build runner with access to secrets. Current guidance suggests combining software composition analysis with reachability analysis, build provenance, secret detection, and runtime context so teams can separate theoretical exposure from active risk.

That means security teams should evaluate at least four layers together:

• Inventory: what components are present in source, build, and artifact manifests.
• Reachability: whether the vulnerable function or code path is actually called.
• Execution context: whether the package runs in production, CI/CD, or a sandbox.
• Data sensitivity: whether the flaw can affect secrets, tokens, customer data, or privileged workflows.

This approach is especially important because supply chain compromise often comes through non-obvious routes. In the Mastra npm Supply Chain Attack, malicious packages were used to extend attacker access rapidly across AI-related ecosystems. The operational lesson is that inventory alone is too shallow when a package can be used to trigger outbound calls, manipulate build steps, or expose stored credentials. For implementation maturity, teams should align scanning with SLSA, Sigstore, and the NIST Secure Software Development Framework so findings can be connected to provenance and release trust, not just package lists.

Where this breaks down is in polyglot monorepos and ephemeral CI/CD systems with heavy code generation, because static inventories often cannot keep pace with dynamically assembled build graphs and runtime-loaded dependencies.

Common Variations and Edge Cases

Tighter dependency validation often increases build-time overhead and review volume, so organisations have to balance deeper assurance against delivery speed. The best practice is evolving, not universal: there is no single standard for how much reachability evidence is enough, especially for internal libraries, generated code, and agentic workloads that assemble toolchains at runtime.

One common edge case is private packages that never appear in public advisories but still carry serious risk because they are used by privileged pipelines or internal automation. Another is AI-enabled development, where a package may be imported by code generation tools, preview environments, or ephemeral agent runners that traditional scanners miss. NHIMG reporting on the 52 NHI Breaches Analysis shows how quickly identity and secret exposure can amplify a supply chain event once attackers gain execution on trusted infrastructure.

For that reason, teams should treat inventory as the starting point, then add policy for reachability, data access, and runtime trust. Where this guidance most often fails is in organisations that scan only on merge or release, because the risky dependency is frequently introduced earlier in the developer workflow or later in the deployment pipeline.

Related resources from NHI Mgmt Group

• What breaks when software supply chain security relies only on SCA scanning?
• What breaks when software supply chain controls are only partially automated?
• What breaks when secrets are exposed in a software supply chain incident?
• What breaks when software supply chain trust is not continuously verified?