The long-running debate over Dockerfiles vs. buildpacks has become a security argument.

Where a Dockerfile leaves base image selection and patch cadence with individual application teams, Cloud Native Buildpacks move those decisions to platform engineering, deciding how quickly a critical CVE is remediated across a fleet of hundreds of services.

The difference lies in where the base image is declared. In a Dockerfile, it is a FROM line in every repository, so propagating a patched base means changing every service. Renovate and Dependabot automate the mechanical part, but they cannot remove the rebuild: every updated FROM line still triggers a full build, a CI queue slot, a test run and a redeploy, multiplied by the number of services.

Buildpacks invert this. A builder is an OCI image packaging an ordered set of buildpacks, the lifecycle and a build-time base image, together with a reference to a separate runtime base image, the "run image", held as metadata. Subsequent builds pick up a new run image, while existing compatible application images can be rebased without rebuilding their application layers, though updating production still requires testing, promotion and deployment.

The Cloud Native Buildpacks project, which graduated within the CNCF on 17 July 2026, frames this as a way to "concentrate the knowledge of container build best practices within a specialized team, instead of having application developers across the organization individually maintain their own Dockerfiles." The mechanism is the rebase command, which detects a newer runtime base image and rewrites the OCI manifest and configuration.

Swapping the OS layer digests for those of the new run image bypasses the rebuild cycle entirely. Writing for the CNCF TAG Environmental Sustainability group in December 2023, Joe Kutner described it as essentially an edit to a JSON file, taking milliseconds and very little compute, with no rebuild, source access or CI queue. Rebase only replaces compatible run-image layers; vulnerabilities in application dependencies still require a rebuild.

That efficiency is one reason buildpack vendors now compete on builder security. BellSoft announced general availability on 21 July 2026 of a hardened Paketo builder built on its Alpaquita Linux-based Hardened Images, replacing both the build and run stacks: a reduced package set, non-root defaults, signatures and SBOM data, although platform teams must still sign, attest, test and promote the resulting application images.

BellSoft itself describes patches reaching applications "on the next build" rather than through rebase, so the millisecond path is a property of the model rather than a vendor claim. It states that a patched image is published "typically within 24 hours" of disclosure; contractually, its Standard tier advertises a 7-day remediation SLA for critical vulnerabilities and 14 days for all others, while the free Community tier does not list one.

Other vendors including Chainguard, Docker, Wiz and Minimus compete on low- or zero-CVE image catalogues, and the market is commoditising: Docker made its entire hardened image catalogue free under an Apache 2.0 licence in December 2025, retaining paid tiers for SLA-backed remediation. Docker's Select tier commits to remediating critical CVEs within seven days, matching BellSoft's Standard tier. If the images are free and the SLAs converge, differentiation moves to delivery and accountability, which is the argument for treating the builder, not the image, as the control point.

Research on Dockerfile drift shows build definitions easily fall out of step with the code they support, and BellSoft's own survey of 250 Spring developers, tech leads and architects at Spring I/O 2026 found that 64% did not recognise their Dockerfile as a security risk. Patch discipline is weak more broadly: a cross-tag study of 6,292 Docker images (ICSME 2025) found nearly 61% of repositories carried vulnerable application dependencies in every tag examined. Those are application-layer findings that rebase does not address, but they describe the same habit that leaves base images unpatched.

Buildpacks are not a universal fix. They trade away the step-by-step control of hand-written Dockerfiles, which is awkward for workloads needing custom OS packages or language ecosystems the buildpacks do not cover. Image extensions close much of that gap, letting platform teams generate build.Dockerfile and run.Dockerfile steps within an otherwise standard build, but extending the run image can compromise rebase-ability, so teams buy back Dockerfile-style control at the cost of the fast patching path that made the model attractive.

Buildpacks can also mean slower cold builds and larger images, and they concentrate trust in the platform’s builder. The choice is control versus blast radius: governance shifts to whoever maintains, signs and promotes the builder, and that pressure is only increasing with regulations like the EU Cyber Resilience Act.