Source code scanning finds direct dependencies in repositories, but it misses libraries embedded in build systems, CI/CD workflows, plugins, IaC templates, and deployed infrastructure. Full pipeline scanning traces the dependency from code through build and runtime locations, which gives a much more complete view of exposure. That broader context helps teams find every exploitable instance and reduce false positives.
Why source-code scanning only sees part of the dependency picture
Source-code scanning is good at answering a narrow question: what is declared in the repository. It usually finds direct package references, manifests, and obvious imported libraries, but that is not the same as understanding where dependency risk actually exists. Build logic, pipeline jobs, IaC templates, runtime images, and embedded plugins can all introduce dependencies that never appear in the application source itself.
The practical difference is visibility. If you only inspect code, you are assuming the repository is the whole delivery system. In reality, modern software is assembled and reassembled across delivery stages where secrets and dependencies often spread beyond the codebase, so a single scan point can leave material exposure unobserved.
Full pipeline scanning treats the software path as the unit of analysis. It follows dependencies from source control into build steps, CI/CD jobs, package managers, containers, deployment manifests, and runtime assets, so the team can see whether the same vulnerable component is present in more than one place. That broader view is what reduces blind spots and prevents teams from assuming a fix in one layer removed the risk everywhere.
What changes when you trace dependencies through build and runtime
The biggest change is that the answer moves from “is this dependency in the repository?” to “where does this dependency actually run, and under what conditions?” A library may be declared in source, replaced during build, pinned in a lockfile, pulled in by a plugin, or bundled into an image. Each of those paths can change the real exposure, especially when the vulnerable component is only reachable in one environment or only used by one workflow.
That is why pipeline scanning is usually better at separating theoretical findings from exploitable ones. A repository-only tool can flag a dependency that never ships, while missing a vulnerable package injected by the build process. Pipeline context lets you decide whether the issue is just present in code, present in a build artifact, or present in something actually deployed and reachable.
For teams that want a delivery-chain view rather than a repository snapshot, CI/CD pipeline exploitation case study shows why build-time exposure matters as much as source-time exposure. The same logic applies to dependency management: the more handoffs you inspect, the better you can tell whether a vulnerable library is truly operational or only incidental.
Why false positives and missed instances diverge across the delivery pipeline
Source-only scanning tends to overreport in one direction and underreport in another. It can overreport because a declared dependency may be unused, replaced, or never packaged. It can underreport because the actual vulnerable component may enter through a build tool, dependency cache, container base image, or deployment template that the source scanner never inspects.
Full pipeline scanning narrows both problems by matching findings to the software lifecycle stage where they matter. That is especially useful when one repository feeds multiple artifacts, or when different environments assemble the same code in different ways. In those cases, the same vulnerability may be real in production, absent in staging, or present only in one service variant.
The secret sprawl challenge is a useful parallel: exposure often spreads across repositories, CI/CD systems, and runtime stores, not just in the code that developers review. Dependency scanning works the same way, the control is only reliable when it follows the thing you are trying to secure through every stage that can change it.
Risk and Threat Considerations
Pipeline gaps create a simple but serious exposure pattern: defenders think a vulnerable dependency is gone because the repository is clean, while the build or deployment path quietly reintroduces it. That is a common failure mode in modern delivery systems, and it matters most when the same component can be consumed from multiple sources or repackaged by automation.
Failure mechanism: A vulnerable library, plugin, or image layer is introduced outside the source tree, or survives in a downstream artifact after source-level cleanup, so scanning the repository alone gives a false sense of remediation.
Impact: Teams may miss exploitable instances, ship vulnerable artifacts, or waste time chasing findings that never reach runtime. The result is weaker remediation accuracy and a larger attack surface than the source scan suggests.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
SLSA, NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| SLSA | Supply-chain Levels for Software Artifacts | Dependency exposure can change between source, build, and runtime artifacts. |
| Recommendation — Adopt provenance and integrity checks so scanned dependencies match shipped artifacts. | ||
| NIST SP 800-53 Rev 5 | CM-8 — System Component Inventory | Pipeline scanning depends on knowing all components and artifact locations across delivery stages. |
| SI-2 — Flaw Remediation | Vulnerable dependencies require timely identification and correction across the delivery pipeline. | |
| Recommendation — Maintain a complete component inventory across source, build, and deployment assets. Track vulnerable dependencies through remediation and verify fixes in downstream artifacts. | ||
| CIS Controls v8 | CIS-2 — Inventory and Control of Software Assets | Full-pipeline scanning needs software asset inventory beyond repositories. |
| Recommendation — Inventory software assets across build and runtime to catch non-source dependency exposure. | ||
| ISO/IEC 27001:2022 | A.8.9 — Configuration management | Build and deployment configuration can introduce or preserve vulnerable dependencies. |
| Recommendation — Control and review build and deployment configurations that affect dependency inclusion. | ||
Practitioner Guidance
What to verify: Confirm which stages your scanning actually covers, then test whether a known dependency can appear in build outputs, containers, and deployment templates without being visible in source. If the answer is yes, source scanning alone is not sufficient for release decisions.
Common mistake: Treating a clean repository scan as evidence that the release is clean. For dependency risk, the release artifact is the control point that matters, not the repository snapshot by itself.
Practitioner takeaway: Use source scanning for early signal, but use pipeline-level traceability to decide whether a dependency is truly present, truly reachable, and truly worth remediation.
SLSA helps frame this correctly because build provenance and artifact integrity are what make dependency findings trustworthy across the delivery chain.
Related resources from NHI Mgmt Group
- What is the difference between scanning for a vulnerable sink and building a full source to sink analysis rule?
- What is the difference between scanning source code dependencies and inventorying build-time dependencies?
- What is the difference between protecting source code and protecting the build pipeline in software supply chain security?
- What is the difference between scanning Ruby source code and scanning Ruby dependencies for vulnerabilities?