Source control detection tells you whether the dependency is referenced in code or lockfiles, while container image detection shows whether the vulnerable library actually made it into a distributable runtime artifact. Both matter, but image scanning is essential because a dependency can be present in the build output even when it is not obvious in application repositories.
Source Control Visibility and Runtime Exposure Are Not the Same Signal
Scanning source control tells you what the codebase references, for example a dependency declared in a package file, build manifest, or lockfile. That is useful for finding vulnerable or outdated components early, but it does not prove the component ships. A package may be removed, excluded, replaced during build, or only present in a nested artifact that never reaches production.
Container image detection answers a different question: what is actually inside the distributable runtime artifact. That matters because the image is what gets deployed, replicated, and inherited by downstream environments. A vulnerability in a library hidden in the image is still operationally real even if the repository looks clean, which is why runtime artifact scanning catches exposure that source-only checks can miss. For container-specific guidance, see NIST SP 800-190 Container Security.
Build pipelines can also introduce drift between source and image. Multi-stage builds, vendored dependencies, transitive packages, and prebuilt base layers can all change the final bill of materials. If teams assume repository scanning is enough, they can miss the fact that a vulnerable component survived into the image through a copied artifact, a cached layer, or a base image inherited from elsewhere.
That distinction is easy to see in real-world exposure patterns. NHI Mgmt Group’s Ultimate Guide to NHIs, key challenges and risks notes that 96% of organisations store secrets outside secrets managers in vulnerable locations including code, config files, and CI/CD tools, which is the same kind of gap: the thing you inspect first is not always the thing that ultimately ships.
Why Build Artifacts Deserve Their Own Scan
Source scanning is strongest for developer feedback, dependency governance, and early remediation. It is usually cheaper to fix a bad dependency before packaging, and it gives teams a direct path back to the owning repository or lockfile. Image scanning is stronger for release assurance, because it checks the artifact that will actually run in production or be promoted through environments.
That difference changes the operational decision. If the vulnerable package exists only in source, you may be able to fix the dependency declaration, regenerate the lockfile, or remove the reference before release. If the same package appears in the image, you must assume the runtime surface is already affected and treat base images, layered artifacts, and deployment approvals as part of the remediation path. This is why image scanning is a control for artifact integrity, not just software hygiene. You can compare that release-artifact focus with NIST Cybersecurity Framework 2.0, especially its protect and detect functions.
It is also worth separating “vulnerable” from “reachable.” A package can exist in a source tree without ever being bundled, imported, or executed, while a package inside an image may be loaded by the runtime even if no application repository mentions it explicitly. The image view is therefore better for answering exposure questions about the deployed system, while the source view is better for answering provenance and change-control questions about the codebase.
For practitioners working with open source supply chains, that distinction is central. A package-level issue can start in source control, but the security relevance often becomes concrete only when it is preserved in a build output. The OpenSSF maintains broader supply chain security guidance at OpenSSF, which is useful context when you need to connect dependency governance to release-time assurance.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0, CIS Controls v8 and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | DE.CM — Security Continuous Monitoring | Image scanning supports ongoing detection of vulnerable runtime artifacts. |
| PR.IP — Information Protection Processes and Procedures | The source-to-image gap is a software release process control problem. | |
| ID.AM — Asset Management | You need a reliable inventory of dependencies and shipped artifacts to compare source and image exposure. | |
| Recommendation — Add runtime image scanning to continuous monitoring for shipped software. Embed dependency and artifact checks into secure build and release procedures. Maintain inventories for source dependencies, base images, and deployed artifacts. | ||
| CIS Controls v8 | 7 — Continuous Vulnerability Management | Scanning both source and images is part of finding vulnerable software before and after build. |
| 16 — Application Software Security | Dependency and build artifact validation are core software security practices here. | |
| 4 — Secure Configuration of Enterprise Assets and Software | Base images and layered artifacts are configuration choices that affect shipped risk. | |
| Recommendation — Scan software artifacts continuously, including container images, and remediate exposures promptly. Verify dependencies and build outputs before release to catch bundled vulnerabilities. Standardise and harden container base images and release configurations. | ||
| NIST SP 800-63 | Digital Identity Guidelines | Identity guidance does not materially address the source-control versus container-image distinction. |
Practitioner Guidance
What to verify: Treat source and image results as complementary evidence, not interchangeable findings. Before closing a ticket, verify whether the vulnerable package is merely referenced, actually bundled, or inherited from a base layer, because each state implies a different remediation path and different blast radius.
Decision rule: If a finding appears only in source control, prioritise dependency correction and rebuild validation. If it appears in the image, prioritise artifact replacement, base-image review, and deployment gating, because the runtime exposure already exists even if the repository looks clean.
What practitioners underestimate: Image scanning is often the first place you discover build-time drift, transitive dependencies, and hidden runtime libraries. The useful question is not “did we find it in code?” but “can this vulnerable component still execute in what we ship?”
Practitioner takeaway: Source control scanning tells you what developers declared; container image scanning tells you what users and attackers may actually inherit. In release pipelines, the image is the stronger proof of exposure.
Related resources from NHI Mgmt Group
- What is the difference between preventing malicious packages at download time and detecting vulnerable dependencies after they are installed?
- What is the difference between source control leakage and SharePoint secret exposure?
- What is the difference between detecting supply chain issues and preventing them?
- What is the difference between image signing and registry access control in container security?
