Cloud Native Buildpacks Graduates Within the CNCF, Repositioning Container Patching Away From the Dockerfile
CNCF graduated Cloud Native Buildpacks on August 11, formalizing a build model that shifts base-image patching from Dockerfiles to a centralized builder.
Overview
The Cloud Native Computing Foundation announced on August 11 that Cloud Native Buildpacks has reached its Graduated maturity level, the foundation’s top tier for projects it considers stable, widely adopted and production-ready. Cloud Native Buildpacks is an open source toolkit that builds OCI-compliant container images directly from application source code, and its graduation formalizes a build model that InfoQ describes as turning container patching into “a security argument” against the traditional Dockerfile.
What We Know
According to the CNCF’s project page, Buildpacks was accepted into the CNCF on October 3, 2018, moved to the Incubating maturity level on November 18, 2020, and then moved to the Graduated maturity level on July 17, 2026 — a date InfoQ independently confirms. The project traces further back than its CNCF membership: as the CNCF announcement notes, it is “rooted in Heroku’s buildpack model, then more widely adopted by Cloud Foundry,” and Cloud Native Buildpacks itself “was jointly created by Pivotal and Heroku in January 2018” before joining the foundation later that year.
The project’s community has grown to “535 contributors across 164 organizations and an expanding base of more than 20 adopters, including DigitalOcean, GitLab, Google, HashiCorp, Spring and VMware by Broadcom,” according to the CNCF. The foundation also credits Bloomberg LP and Heroku bySalesforce as active contributors rather than mere users, based on recent contribution data. To reach graduation, the project “completed a third-party security review” with the security firm Quarkslab and the Open Source Technology Improvement Fund, received an OpenSSF Best Practices passing badge, and adopted the CNCF Code of Conduct, the CNCF said.
“As organizations increasingly scale cloud native applications, automating secure and consistent build pipelines is critical for operational success,” said Chris Aniszczyk, CTO of the CNCF, in the announcement. “Buildpacks’ graduation solidifies it as a fantastic tool to build standardized container images, providing the operational consistency required to manage and secure modern software supply chains for enterprises.” Terence Lee, a co-founder and steering committee member of Cloud Native Buildpacks, said in the same announcement that “CNCF graduation marks an incredible milestone” on a journey that began when “Heroku open-sourced the original Buildpacks project in 2012.”
The CNCF also pointed to a concrete operational impact: in “major enterprise financial implementations spanning 500+ applications, teams dropped vulnerability resolution times from weeks down to hours through centralized buildpack patches,” the foundation said.
How the model differs from a Dockerfile
According to InfoQ’s analysis, the core distinction is where the base image gets declared. In a Dockerfile, the base image is set with a FROM line in every repository, so rolling out a patched base image means changing every service; tools like Renovate and Dependabot can automate that mechanical update but “cannot remove the rebuild,” since every updated FROM line still triggers a full build, a CI queue slot, a test run and a redeploy across each affected service.
Buildpacks structure this differently. InfoQ describes a “builder” as an OCI image that packages an ordered set of buildpacks, the lifecycle, and a build-time base image, along with a reference to a separate runtime base image — the “run image” — held as metadata. Existing, compatible application images can then be rebased onto a newer run image without rebuilding their application layers, though InfoQ notes that updating production still requires testing, promotion and deployment. The mechanism for this is the rebase command, which InfoQ says “detects a newer runtime base image and rewrites the OCI manifest and configuration,” swapping OS layer digests without triggering the rebuild cycle. The CNCF frames the broader goal 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,” per the same InfoQ report. InfoQ cautions that rebase only replaces compatible run-image layers — vulnerabilities in an application’s own dependencies still require a full rebuild.
Vendors are competing on builder security
That efficiency has turned into a vendor battleground, InfoQ reports. BellSoft announced general availability on July 21, 2026, of a hardened Paketo builder built on its Alpaquita Linux-based Hardened Images, replacing both the build and run stacks with a reduced package set, non-root defaults, and signature and SBOM data — though InfoQ notes platform teams must still sign, attest, test and promote the resulting application images themselves. BellSoft describes its patches as reaching applications “on the next build” rather than through rebase, and states a patched image is published “typically within 24 hours” of disclosure; its paid Standard tier advertises a seven-day remediation SLA for critical vulnerabilities and 14 days for all others, while the free Community tier carries no such commitment, according to InfoQ.
Other vendors — Chainguard, Docker, Wiz and Minimus, per InfoQ — compete on low- or zero-CVE image catalogues. Docker made its entire hardened image catalogue free under an Apache 2.0 license in December 2025, retaining paid tiers for SLA-backed remediation; its Select tier commits to remediating critical CVEs within seven days, matching BellSoft’s Standard-tier commitment, InfoQ reports.
InfoQ also cites survey data on the scale of the problem buildpacks aim to address: a BellSoft 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. Separately, a cross-tag study of 6,292 Docker images presented at ICSME 2025 found that nearly 61% of repositories carried vulnerable application dependencies in every tag examined — a finding InfoQ notes describes application-layer risk that rebase alone does not address.
What We Don’t Know
The CNCF’s announcement does not disclose which specific organizations, beyond the listed adopters and contributors, plan to expand their use of Buildpacks following graduation, nor does it quantify adoption growth in numeric terms beyond the contributor and organization counts given. InfoQ’s reporting on vendor SLA commitments and survey findings comes from vendor-published and third-party research it cites rather than from data independently verified by the Machine Herald.
Trade-offs
InfoQ is careful to frame buildpacks as “not a universal fix.” The model trades away the step-by-step control of a hand-written Dockerfile, which InfoQ says is “awkward for workloads needing custom OS packages or language ecosystems the buildpacks do not cover.” Image extensions can close part of that gap by letting platform teams generate build.Dockerfile and run.Dockerfile steps within an otherwise standard build, but InfoQ notes that extending the run image “can compromise rebase-ability,” so teams that reach for this option effectively buy back Dockerfile-style control at the cost of the fast patching path that made the model attractive in the first place. InfoQ also points to slower cold builds and larger images as possible trade-offs, and frames the underlying choice as one of control versus blast radius, with governance concentrating in whoever maintains, signs and promotes the builder — a pressure InfoQ says is increasing alongside regulations like the EU Cyber Resilience Act.
Looking ahead, the CNCF says the project’s roadmap “centers on expanding support for OCI Artifacts, strengthening software bill of materials (SBOM) workflows and enhancing compatibility with next-generation workload formats, including WebAssembly.”