What is the difference between scanning source code dependencies and inventorying build-time dependencies?

How the two dependency views answer different questions

scanning source code dependencies tells you what the application depends on to run, ship, or import at the package level. Inventorying build-time dependencies answers a different question: what software, actions, containers, plugins, and pipeline components participated in producing the release. That distinction matters because a clean package list can still hide risky build machinery in CI, repository automation, or ephemeral builder images.

The practical takeaway is that runtime dependency analysis is mostly about what ends up in the artifact, while build-time inventory is about how the artifact came into existence. A release can look healthy from the outside and still be exposed through a compromised pipeline step, a pinned workflow action, or an imported build container that never appears in the shipped code.

What source scanning can see, and what it usually misses

Dependency scanning is strongest when the risk lives in libraries, modules, and transitive packages that the application imports directly or indirectly. It helps you identify outdated components, vulnerable packages, and licence or supply-chain issues that attach to the delivered software itself. For that reason, it is usually the first control teams reach for when they want a quick view of known component exposure.

Its blind spot is the delivery path. A repository may depend on actions that fetch code, build images that pull untrusted base layers, or workflow steps that execute third-party tooling during release. Those elements are part of the software factory, not the application package, so they can evade standard dependency checks even though they can alter the artifact, exfiltrate secrets, or inject malicious behaviour into the build.

Why build-time inventory changes the security picture

Build-time inventory maps the chain of trust around software production: workflow definitions, pipeline imports, build containers, signing steps, and other automation that can influence what is published. That view is especially useful when the delivery chain is treated as code, because the build system itself becomes an attack surface and a governance boundary. For a broader control perspective, the same problem space is treated as software supply chain integrity by SLSA, which focuses attention on provenance and build assurance.

This is also where repository and CI tooling can become security-critical even when the application dependency list looks stable. If a workflow action is replaced, a build container is poisoned, or an import pulls in unexpected code at build time, the resulting release can be altered without changing the runtime dependency manifest in any obvious way. In other words, build-time inventory is what reveals the hidden dependencies that shape release integrity.

Risk and Threat Considerations

Build-time dependencies expand the attack surface because they often run with broad access to source, secrets, signing material, and release infrastructure. An attacker who compromises the pipeline may not need to touch the application’s declared packages at all, because the build system itself can become the delivery vector.

Failure mechanism: The organization scans only packaged libraries and misses workflow actions, builder images, and pipeline imports that can execute code or pull unreviewed content during release. That gap leaves the software factory vulnerable to supply-chain tampering, secret exposure, and artifact substitution.

Impact: A malicious or compromised build dependency can change what gets shipped, exfiltrate credentials from CI, or create a trusted-looking release artifact that carries hidden compromise downstream.

Practitioner Guidance

What to verify: Check that your inventory covers the complete production path, not just package manifests. The useful question is whether you can name every workflow action, builder image, plugin, and imported script that can influence a release outcome.

Implementation sequence: Start with source dependency scanning for application exposure, then add a separate build-time bill of materials for CI and repository automation, and finally compare the two views for unowned or externally sourced components.

Common mistake: Treating a green package scan as proof that the release chain is safe. If the build system can fetch, execute, or publish code, the pipeline itself needs inventory and review.

Practitioner takeaway: Use source dependency scanning to understand what the software runs, but use build-time inventory to understand who and what was allowed to shape the release. The second view is what closes the blind spot in CI and repository automation.

Related resources from NHI Mgmt Group

• Why do build-time dependencies increase source theft risk in CI and developer workstations?
• What is the difference between scanning Ruby source code and scanning Ruby dependencies for vulnerabilities?
• What is the difference between scanning only source code and scanning the full software delivery pipeline for vulnerable dependencies?
• What is the difference between build-time scanning and deployment-time policy checks?