Why does a pre-build SBOM sometimes miss vulnerable software that is present in production images?

A pre-build SBOM often reflects only manifest files or earlier build stages, so it can capture references to a dependency without the runtime library included in the container layer. That creates a visibility gap between declared dependencies and shipped artifacts. Post-build scanning closes that gap and gives a more reliable basis for remediation decisions.

Why pre-build SBOMs can understate what actually ships

A pre-build software bill of materials is only as complete as the inputs it sees. If it is generated from package manifests, lockfiles, or an earlier build stage, it can document intended dependencies without proving that the final image contains only those components. That matters because vulnerability management depends on what is actually present in the shipped artifact, not just what the build declared. A team that trusts an early SBOM too much can miss runtime libraries, transitive packages, or build-time additions that appear later in the container lifecycle. In practice, many teams discover this gap only after a production scan reveals packages they assumed had already been accounted for.

For image-heavy delivery pipelines, the issue is not theoretical. Build stages, multi-stage Dockerfiles, package manager behaviour, and base image inheritance can all change the final contents after the first inventory point. A pre-build SBOM may still be useful for design-time transparency, but it should not be treated as proof of the deployed filesystem. The broader lesson is that dependency declaration and artifact composition are related, but they are not the same thing.

Authorities such as the OWASP Non-Human Identity Top 10 are relevant only when the question involves machine identities or secret-bearing services; here, the core issue is artifact fidelity rather than identity governance.

How the gap appears between declared dependencies and production layers

Pre-build SBOM generation usually happens before the container is fully assembled, which means it can see source-level dependency declarations but not every file that later lands in the final image. A multi-stage build may compile artifacts in one stage, copy only some outputs into a slimmer runtime stage, and then add operating system packages during image assembly. The SBOM can therefore describe the build intention accurately while still missing the shipped reality.

That distinction becomes sharper when teams use shared base images or inherited layers. Vulnerable software can enter the final image from the base layer, from a package installed during build, or from a transitive dependency pulled in by the runtime environment. None of those necessarily appear in a pre-build view that stops at the manifest. Post-build or image-level scanning is what reconciles the declared software set with the container filesystem that will actually run.

Manifest-based SBOMs are strongest for proving what the project depends on, not what the image contains.
Build-stage-only inventories can miss files introduced after compilation or copied in from upstream layers.
Runtime images can inherit vulnerable packages from base images even when the application lockfile is clean.
Post-build scanning helps distinguish an expected dependency from an exposed artifact that must be patched or removed.

The guidance breaks down when build pipelines are opaque, base images are unmanaged, or teams treat one inventory artifact as complete evidence across all stages.

Where this breaks down in real pipelines

Tighter software inventory controls often increase build and governance overhead, so teams have to balance early visibility against artifact accuracy. That tradeoff is real because a pre-build SBOM is fast and useful for development workflows, while a post-build scan is better at detecting what actually shipped. The right answer is usually not to choose one or the other, but to understand which decision each one supports.

There are several common edge cases. Reproducible builds can reduce drift, but they do not eliminate the problem if the provenance inputs themselves are incomplete. Ephemeral build-time tools may appear briefly and disappear from the final image, which can confuse inventory expectations if the team does not separate build dependencies from runtime components. Package renaming, vendored code, and static linking can also make a component look absent from one inventory source while still being functionally present in the artifact. Guidance across the industry is consistent on the principle, but not always on the exact implementation pattern.

Where organisations get this wrong is assuming that a successful build-time inventory means there is no need to inspect the final image. That assumption is weakest in containerised delivery, layered images, and environments that frequently inherit third-party base content.

Risk and Threat Considerations

The material risk is visibility failure: vulnerable software can remain present in a production image even when the pre-build SBOM looks clean. That creates a governance gap because remediation decisions, exception handling, and exposure assessment may be based on incomplete evidence.

Failure mechanism: The gap arises when an SBOM is generated before packaging is complete, or when it only reflects declared dependencies rather than the final filesystem. Attackers do not need to defeat the SBOM itself; they benefit when defenders believe the inventory is authoritative and delay patching or removal of the actual shipped package.

Impact: Vulnerable libraries, inherited base-image packages, or copied runtime components can reach production unnoticed, leaving exploitable code in the runtime path and increasing the chance of delayed remediation, inaccurate risk acceptance, and missed exposure during incident response.

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 CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
CIS Controls v8	15 — Service Provider Management	Final images often inherit third-party base content and build supply-chain inputs.
	2 — Inventory and Control of Software Assets	The question is about software inventory completeness across build and production states.
	4 — Secure Configuration of Enterprise Assets and Software	Container layers and base images can introduce vulnerable software through configuration drift.
Recommendation — Inventory third-party components and validate inherited image content before release. Maintain an accurate software inventory for the shipped image, not only the build manifest. Harden image build and release configurations to prevent unexpected runtime packages.
NIST CSF 2.0	ID.AM — Asset Management	SBOM gaps are fundamentally an asset visibility and inventory problem.
	PR.IP — Information Protection Processes and Procedures	Build and post-build scanning are process controls for trustworthy software assurance.
	DE.CM — Continuous Monitoring	Runtime image scanning detects components missing from pre-build visibility.
Recommendation — Map the deployed image’s actual contents into your asset inventory process. Add post-build verification steps to your software assurance procedures. Continuously monitor released images for software that the pre-build SBOM missed.
MITRE ATT&CK	T1610 — Deploy Container	Container build and deployment mechanics explain how vulnerable packages reach production images.
	T1601 — Modify System Image	Base-image and layer manipulation can alter what is actually shipped.
Recommendation — Hunt for container-layer changes that introduce unexpected software into runtime images. Inspect image build chains for layer changes that alter the shipped software set.

Practitioner Guidance

What to prioritise: Treat the pre-build SBOM as a build-intent artifact and require a post-build or image-level inventory before the image is promoted. The key judgement is whether your current SBOM process can prove runtime composition, not just declared dependencies.

What to verify: Confirm that the final image is scanned after all layers are assembled and that the resulting findings are compared against the earlier SBOM. If the two views differ, investigate base images, copied artifacts, and build-stage outputs before relying on the earlier inventory for remediation.

Practitioner takeaway: The useful control is not “having an SBOM” but having an SBOM that matches the artifact you actually deploy.