A survey of 250 Spring developers, tech leads and architects conducted by BellSoft at Spring I/O 2026 found that 64% did not view their Dockerfile as a security vulnerability. The finding was published in an InfoQ report this month, coinciding with the Cloud Native Buildpacks project's graduation within the CNCF on 17 July 2026. The report argues that the longstanding technical debate between Dockerfiles and buildpacks has become a security question, with the central issue being who controls base image selection and how quickly critical vulnerabilities get fixed across large service fleets.

The security problem is widespread. A cross-tag examination of 6,292 Docker images presented at ICSME 2025 discovered that almost 61% of repositories contained vulnerable application dependencies in every tag the researchers checked. Separate research on Dockerfile drift shows that build definitions frequently fall out of sync with the code they're meant to support. When teams rely on Dockerfiles, a patched base image means updating a FROM line in every repository, which triggers a full build, occupies a CI queue slot, runs tests and requires redeployment for each service. Tools like Renovate and Dependabot handle the mechanical updates, but they can't eliminate the rebuild cycle that multiplies across hundreds of services.

Buildpacks reverse the model by packaging buildpacks, the lifecycle and a build-time base image into a builder, alongside a reference to a separate runtime base image stored as metadata. The Cloud Native Buildpacks project describes this as a method 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 rebase command detects a newer runtime base image and rewrites the OCI manifest and configuration, swapping OS layer digests for those of the new run image without rebuilding application layers. Writing for the CNCF TAG Environmental Sustainability group in December 2023, Joe Kutner characterized it as essentially editing a JSON file that takes milliseconds and minimal compute, with no rebuild, source code access or CI queue required. That efficiency is confined to compatible run-image layers; vulnerabilities in application dependencies still demand a rebuild.

The speed advantage has turned builder security into a competitive battleground. BellSoft released a hardened Paketo builder on 21 July 2026 built on Alpaquita Linux-based Hardened Images, featuring a reduced package set, non-root defaults, signatures and SBOM data, though platform teams must still sign, attest, test and promote the resulting application images. BellSoft says a patched image is published "typically within 24 hours" of disclosure, with its Standard tier contractually committing to a 7-day remediation SLA for critical vulnerabilities and 14 days for all others, while the free Community tier carries no listed SLA. Rivals including Chainguard, Docker, Wiz and Minimus compete on low- or zero-CVE image catalogues. Docker made its entire hardened image catalogue free under an Apache 2.0 licence in December 2025, keeping paid tiers for SLA-backed remediation; its Select tier commits to fixing critical CVEs within seven days, matching BellSoft's Standard tier. As images become free and SLAs converge, the report notes that differentiation shifts to delivery and accountability, making the builder rather than the image the control point.

Buildpacks aren't a universal solution. They sacrifice the step-by-step control of hand-written Dockerfiles, which creates friction for workloads requiring custom OS packages or language ecosystems the buildpacks don't support. Image extensions allow platform teams to generate build.Dockerfile and run.Dockerfile steps within an otherwise standard build, but extending the run image can undermine rebase-ability, so teams regain Dockerfile-style control at the expense of the fast patching path that made the model appealing. Buildpacks can also mean slower cold builds, larger images and concentrated trust in the platform's builder. The choice is control versus blast radius: governance moves to whoever maintains, signs and promotes the builder, and that pressure is only growing with regulations like the EU Cyber Resilience Act. Organizations that centralize builder management gain speed and consistency but must accept that a compromised builder affects every service it touches, while those that stick with Dockerfiles retain granular control but face the multiplication of effort that comes with distributed ownership. The rebase efficiency only matters if platform teams actually use it, and the market's shift toward SLA-backed remediation suggests that contractual accountability may matter more than the technical path to patching.