Why the Container Image Is the Wrong Artifact to Gate Your SDLC Stages On

The declarative environment manifest should be the unit of promotion across dev, staging, and production. Container images package runtime outputs, while the manifest defines the tools, dependencies, and system inputs that produce them. Gating on that definition moves process controls upstream, before an image inherits build-environment risk, without requiring teams to abandon container delivery.

Why SDLC gates exist and what they are supposed to enforce

An SDLC gate is a trust checkpoint. Before promotion, it should check whether the work that produced an artifact met the conditions set for it. Those conditions include provenance, reproducibility, policy compliance, and dependency integrity. They concern who produced the work, how it was produced, and whether its inputs match what was intended. Moving an artifact from one system to another does not prove that it meets those conditions.

The timing of that checkpoint determines its reach. Who wrote the code, which dependencies were resolved, and whether the build environment was clean are established before an image exists. OX Security’s Secure SDLC in the Age of AI: From Static Checks to Active Risk Control describes traditional gates as relying on deliberate human choices evaluated at fixed points. Its analysis places security in the behavior of software and the inputs that produced it, rather than only in the appearance of the finished artifact.

How the container image became the default gate artifact despite not being designed for that role

Container images became common inspection points because they were concrete, transferable objects that tooling could examine. Their original role was runtime packaging. Ubiquity made them convenient gate artifacts. Once teams organized delivery around building and pushing images, security tools gravitated toward the same objects, even though dependency resolution and build-environment composition had already occurred.

That sequence creates a delay between introducing risk and evaluating it. An image builds, gets pushed, and is passed around. Security findings then appear in a registry dashboard or during an incident review.

OX Security’s Container Security Best Practices: An Enterprise Guide for 2026 describes the resulting loss of traceability as “lineage drift. A running container that cannot be traced to the specific pipeline, commit, and security check that authorized it has an unmeasurable risk posture. Mutable tags compound the problem. An image scanned during the build phase may differ from the image a cluster pulls after its tag has been overwritten. In that case, the tag no longer proves that the code in production passed the checks associated with it.

What the image gate cannot see: the build environment upstream of the image

A container image records what was packaged at build time and provides only a partial definition of the environment that produced it. Dependency resolution, tool selection, and environment composition happen upstream, where unpinned transitive dependencies and unmanaged system libraries can introduce drift. Inspecting the resulting package does not make those earlier inputs specified or attested.

Pinning dependencies with integrity hashes does not by itself guarantee that the shipped artifact contains those versions. The installation command remains part of the process. npm install is permitted to re-resolve against package.json ranges and rewrite the lockfile, whereas npm ci treats the lockfile as authoritative and refuses to modify it. A gate that recognizes a lockfile but cannot establish how it was used has incomplete evidence of dependency integrity.

The secure SDLC analysis identifies a broader version of this gap. AI-generated code, dependencies, CI workflows, and infrastructure definitions can be committed and merged without the step-by-step reviews on which traditional secure development relies. Build-time checks cannot fully establish what inputs produced the application or how it behaves at runtime. Checking the output, controlling which inputs are used, and applying runtime controls each cover work that the other checks cannot replace.

A single compromised build environment or base image can propagate into every downstream image built from it. Each image may be separately scanned, signed, or promoted, but those separate outputs still share the compromised ancestor. The decision to trust that shared input belongs at the point where it enters the process.

Why image hardening and signing patch the symptom without fixing the abstraction

Image hardening and signing are controls that teams need and should invest in. The growing hardened-image market in 2026 addresses real exposure in runtime packages. SLSA Level 2 build provenance, with Level 3 emerging as a best practice, in-toto attestations, and Sigstore signing provide a foundation for image-level provenance. These controls improve evidence about what was built and shipped. They deserve enforcement.

Signed attestations that deployment admission controls never verify do not enforce trust at runtime. The enterprise guide highlights mutable tags and registry drift, including cases where the digest scanned in CI differs from the one pulled at runtime. Its call for coverage from build through registry to runtime addresses this break in chain of custody.

A Build L3 attestation on its own does not cover the developer environment, local tool versions, or pre-CI dependency resolution. SLSA’s broader framework covers dependency ingestion separately through its draft Dependency Track and higher build levels, so it covers more than image signing. Nevertheless, an attestation about an image build is not a complete account of the environment in which development began. The missing artifact is an authoritative definition of those earlier inputs.

What should be the unit of promotion across dev, staging, and production?

A declarative environment manifest lists every tool, library version, and system dependency in a human-readable, version-controlled form. It states what should be resolved, rather than merely recording what a build happened to package. That makes it suitable for process gates. Its scope begins with the environment in which code is first written, allowing the same input definition to support development, CI, and promotion.

Source control gives that definition an attributable history. Changes to tools and dependencies become reviewable changes to the environment itself, and the inputs associated with a build remain recoverable without rescanning its image. Rollback can be atomic because the definition is versioned as a unit. This is a more readable promotion artifact than an opaque image tag update. The manifest exposes the input changes on which approval depends.

An input-derived hash gives the definition an identity that stays the same so teams can track affected environments. When a vulnerability is disclosed against a package, the association between that package, its environments, and their hashes enables hash-level blocking or patching. The hash identifies which environments declare the affected package among their inputs, without grepping logs or rescanning images.

The declarative environment manifest is therefore the unit of promotion across the SDLC, while the image remains a delivery output. Gates evaluate the definition that will produce the artifact before those inputs are inherited by a build. The definition must still be complete, its use must be enforced, and runtime behavior still requires security coverage.

How agentic development makes the image gate structurally incompatible with pipeline velocity

Agentic development compresses the interval between choosing inputs and shipping outputs. The secure SDLC analysis describes AI generating entire applications in a single step, including code, dependencies, pipelines, and deployment configurations. Agents can commit that work, preconfigured CI rules can merge it, or reviewers can approve it in bulk as one pull request. The intermediate review points may disappear entirely.

An image scan still starts only after an artifact exists. By then, the selected dependencies and build inputs have already shaped the output, while human review may have narrowed from understanding the changes to approving build success. Faster generation increases the amount of work that can pass through the upstream gap before the image gate has anything to inspect.

Agents operating across source, CI, registry, and runtime also need a coherent model of what they are changing. An OCI manifest alone does not provide the dependency graph, build inputs, and provenance chain needed to reason about downstream effects. An environment manifest makes those inputs available before a build runs. The agent can read, modify, and attest to that definition, allowing policy evaluation to occur at the point of change, before the packaged result exists.

What environment-first gating looks like in practice across the SDLC

For teams adopting this model, the operational shift is to evaluate declared inputs when they change and verify their use before execution. At the developer stage, the environment definition becomes a commit artifact. A dependency addition or tool-version change triggers policy evaluation when it is written, before an image build. The review surface is the input diff. This brings environment changes into the same attributable history as the code they support.

At the CI stage, the environment hash becomes a build input. Before compilation, CI can verify that the environment about to run the build matches the attested definition. This checkpoint answers a different question from an output scan. It establishes whether the build will use the approved environment, while later inspection evaluates what the build produced. Neither check needs to pretend it provides the evidence of the other.

At promotion, the manifest moves through dev, staging, and production as the controlled definition. Approval concerns a readable change rather than an opaque tag update, and rollback restores a versioned definition atomically. The artifact being promoted now states the intended inputs. Its identity links each stage to the environment approved for use, rather than relying on a mutable reference to a packaged result.

At audit and compliance, attaching the input-derived hash to the deployment record connects the deployment to its environment definition. That connection enables deterministic SBOM generation and CVE-to-patch workflows that identify affected environments without rescanning. Image checks and deployment verification remain relevant. The change is that the container image becomes an output of the governed process.

The organizational and tooling conditions that make environment-first gating achievable today

The tooling for versioned definitions, provenance, signing, and verification already makes this model achievable. Regulatory pressure strengthens the reason to adopt it. FedRAMP Rev 5, NIS2, and the EU CRA establish requirements for software provenance and supply chain visibility that image-only gates cannot fully satisfy. To meet those baselines, organizations are pushed to gather evidence earlier and cover more of the process. The remaining barrier is organizational habit.

An internal developer platform can serve as the authoritative source for environment definitions, with versioned, named environments as the standard developer interface. Teams already publishing those environments have completed much of the structural work. The next step is to make the definition the artifact evaluated and promoted, while retaining image-level controls for the outputs it produces. This changes the responsibility assigned to the image without discarding container workflows.

The secure SDLC analysis calls for security across creation, pipeline activity, and runtime, based on behavior, access paths, and execution context. Environment-first gating supports that continuity, but the definition must be complete enough to provision the environment it claims to describe. One-command onboarding provides a concrete test of that completeness. If the manifest cannot provision a new contributor’s machine from scratch, it is not a trustworthy gate artifact either. The adoption task is to make the environment definition authoritative from the first developer action, then enforce that authority through promotion and deployment.