Buildpacks are increasingly being framed not just as a cleaner way to build containers, but as a security control point that moves hardening decisions away from individual Dockerfiles and into platform engineering. That shift matters because it changes how quickly a vulnerable base image can be patched across hundreds of services, and who is responsible for making that happen.
Why Dockerfile-based patching becomes a scaling problem
In a traditional Dockerfile workflow, the base image is usually declared in a FROM line inside each repository. If a critical CVE hits that base image, every application team must update its file, rebuild the image, run tests, wait for CI, and redeploy. Tools such as Renovate and Dependabot can automate the version bump, but they do not eliminate the rebuild step.
That model may be manageable for a few services, but it becomes slow and repetitive at fleet scale. The article notes that patching one base image can translate into the same operational work repeated across many repositories, CI jobs, and deployment pipelines.
How Cloud Native Buildpacks change the control point
Cloud Native Buildpacks shift the base image decision into a builder, which is an OCI image that packages an ordered set of buildpacks, the lifecycle, and a build-time base image. The runtime base image, called the run image, is stored separately as metadata. That separation lets later builds pick up a newer run image without each team hand-editing a Dockerfile.
The Cloud Native Buildpacks project, which graduated within the CNCF on 17 July 2026, describes this approach 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.” In practice, that means platform engineers can standardize the builder and absorb more of the patching responsibility.
The role of rebase in faster remediation
The key mechanism is rebase. When a newer runtime base image is available, the command can rewrite the OCI manifest and configuration so an application image points to the new run image without rebuilding the application layers. The article cites Joe Kutner of the CNCF TAG Environmental Sustainability group, who wrote in December 2023 that this is essentially an edit to a JSON file, taking milliseconds and very little compute, with no rebuild, source access, or CI queue.
That efficiency is significant, but it is not a complete solution. Rebase only swaps compatible run-image layers; it does not fix vulnerabilities in application dependencies. If the problem is in the app itself, the image still needs a rebuild.
Security becomes a platform responsibility
Because buildpacks centralize the build and runtime stack, vendors are competing on builder security. BellSoft announced general availability on 21 July 2026 of a hardened Paketo builder based on its Alpaquita Linux-based Hardened Images. The builder replaces both the build and run stacks and emphasizes a reduced package set, non-root defaults, signatures, and SBOM data.
BellSoft says patches reach applications “on the next build” rather than through rebase, while also stating that a patched image is typically published within 24 hours of disclosure. The company’s Standard tier advertises a 7-day remediation SLA for critical vulnerabilities and 14 days for all others; its free Community tier does not list an SLA.
That makes the broader market look more like a services race than a pure image race. Docker, Chainguard, Wiz, and Minimus are all competing on hardened or low-CVE image catalogs, and Docker made its hardened image catalogue free under an Apache 2.0 licence in December 2025 while keeping paid tiers for SLA-backed remediation.
What platform teams gain, and what they give up
The article argues that if hardened images are free and vendor SLAs begin to converge, the differentiation shifts toward delivery and accountability. In that view, the builder becomes the real control point, because it determines how fast security fixes can be propagated and who owns the process.
There is also evidence that this governance gap is real. BellSoft’s survey of 250 Spring developers, tech leads, and architects at Spring I/O 2026 found that 64% did not recognize their Dockerfile as a security risk. More broadly, a cross-tag study of 6,292 Docker images published in ICSME 2025 found nearly 61% of repositories carried vulnerable application dependencies in every tag examined.
Those findings do not mean buildpacks solve application-layer weakness. They do suggest that manual Dockerfile maintenance is often a poor place to rely on consistent patch discipline, especially when teams are already stretched thin.
Buildpacks are not a universal replacement
Buildpacks come with trade-offs. They reduce the step-by-step control of hand-written Dockerfiles, which can be a problem for workloads that need custom OS packages or language ecosystems not covered by the buildpacks being used. The article notes that image extensions can fill some of those gaps by generating build.Dockerfile and run.Dockerfile steps inside a standard build.
But that flexibility can come at a cost. Extending the run image may break rebase-ability, which means teams can regain Dockerfile-style control only by giving up the fast patching path that made the buildpack model attractive in the first place.
Other trade-offs to weigh
- Potentially slower cold builds compared with handcrafted images.
- Larger final images in some cases.
- More trust concentrated in the platform team that maintains and signs the builder.
- Greater dependence on governance processes for testing, promotion, and deployment.
The article closes by noting that this trust concentration is becoming more important as regulations such as the EU Cyber Resilience Act raise the bar for software supply-chain governance.
Explore more: Blog Our Services Contact Us
Source: Original report
Was this helpful?
Last Modified: August 10, 2026 at 4:49 pm
2 views
