Scanning only application code creates blind spots because vulnerable dependencies often exist in build tools, CI systems, plugins, and infrastructure code that help produce the final software artifact. Those dependencies can introduce risk even when the source code itself looks clean. Without pipeline-wide visibility, teams may miss where a vulnerability is introduced, deployed, or left active in production.
Where the Blind Spots Actually Come From
Application code is only one layer of the delivery chain. Vulnerabilities can enter through package managers, build scripts, CI runners, plugins, container images, and infrastructure-as-code, then survive all the way to production even if the application source itself is clean. That is why software supply chain security has to follow the artifact lifecycle, not just the repo.
The practical blind spot is provenance. A team may scan application files and still miss the dependency version that was resolved at build time, the CI plugin that injected unreviewed behaviour, or the infrastructure template that created an exposed control plane. Those are different attack surfaces, and each one can change what actually ships.
One useful way to think about it is that code scanning answers “what is in the source tree?”, while supply chain security asks “what was assembled, by whom, from which inputs, and with what trust?” If the answer stops at the source tree, the team has not really assessed the software that runs.
Supply chain risk also widens when tooling is allowed to fetch, transform, sign, or publish artifacts automatically. The more trust you place in build-time automation, the more important it becomes to inspect dependency resolution, pipeline configuration, and integrity controls with the same seriousness as the application code itself. Ultimate Guide to NHIs is a useful reference point here because secrets, tokens, and service credentials often sit in the pipeline layer rather than in the application repository.
What Teams Miss When They Focus Too Narrowly
A narrow scan can miss vulnerable or malicious dependencies that are not committed to the main codebase. That includes transitive libraries, build-time utilities, CI actions, package registries, extension ecosystems, and deployment templates. The result is a false sense of confidence, because the application can pass code scanning while still inheriting an exploitable component chain.
Teams also miss the difference between source risk and delivery risk. A commit may be safe, but the build may pull a compromised package, a plugin may leak tokens, or a deployment step may introduce insecure infrastructure defaults. In practice, that means the defect is sometimes introduced after code review, which is exactly where code-only scanning has the least visibility.
- Build systems can introduce hidden trust decisions through pinned versus floating dependencies.
- CI/CD tooling can store or expose credentials that never appear in application code.
- Infrastructure code can create access paths, permissions, and exposed services that the app scanner will not evaluate.
- Plugins and actions can change artefacts during build or deployment, so the final product differs from the reviewed source.
That is why pipeline-level controls matter as much as source analysis. NIST SSDF (SP 800-218) is directly relevant because it frames secure development as a broader set of practices, including dependency integrity and build assurance, not just source inspection. SLSA adds the provenance angle by focusing on how build integrity and artifact trust are established.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0, CIS Controls v8 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.IP — Information Protection Processes and Procedures | Covers secure build and software supply chain process discipline for the delivery pipeline. |
| Recommendation — Apply PR.IP to govern build inputs, artifact provenance, and release integrity beyond source code scanning. | ||
| CIS Controls v8 | 16 — Application Software Security | Directly addresses secure development and software integrity across the application lifecycle. |
| Recommendation — Extend Control 16 to include dependencies, build tooling, and deployment artifacts in security review. | ||
| MITRE ATT&CK | T1195 — Supply Chain Compromise | Matches the core threat path where malicious or vulnerable dependencies are introduced outside application code. |
| Recommendation — Map trusted build inputs to T1195 and hunt for tampered packages, build steps, and delivery tooling. | ||
| NIST AI RMF | GV.4 — Map, Measure, and Manage AI Risks | Selected only where pipeline trust and provenance govern AI software delivery risk. |
| Recommendation — Use GV.4 to measure and govern provenance across model and software delivery pipelines. | ||
Practitioner Guidance
What to prioritise: Scan the full software path, not only the application repository. The highest-value next step is usually to map where dependencies are resolved, where secrets are used, and where artifacts are built or promoted, because that is where source-only scanning most often loses coverage.
What to verify: Confirm that your controls can answer three questions for any production artifact: which inputs were used, which pipeline steps touched them, and whether the resulting package or image can be tied back to a trusted build. If you cannot trace those three points, code scanning is only giving partial assurance.
Common mistake: Treating a clean source scan as evidence of a clean release. That assumption fails whenever a risk is introduced through dependency resolution, CI automation, or infrastructure changes after the code review boundary.
Practitioner takeaway: The real control objective is not “scan more code”, it is “understand where trust enters the build and deployment path”, because that is where supply chain compromise usually escapes application-only review.
Related resources from NHI Mgmt Group
- Why do fragmented AppSec tools create blind spots in software supply chain defence?
- Why do traditional threat detection tools create blind spots in software supply chain risk?
- What breaks when code-to-cloud visibility is missing in software supply chain security?
- How should security teams govern software supply chain risk in application delivery?
