Cloud Native Buildpacks Graduates CNCF: What It Means for Teams That Stopped Writing Dockerfiles

Bloomberg runs more than 500 applications built with Cloud Native Buildpacks, and centralized patching cut its vulnerability resolution time from weeks to hours. That sentence, buried in the coverage of the project's CNCF graduation, is the whole story: on August 11, 2026, the developer convenience of "push code, get an image" officially became supply-chain infrastructure.

Here is the verdict up front, because graduation announcements are long on ceremony and short on consequences. If your deploy path is already pack build instead of Dockerfiles, graduation changes nothing about the bytes your pipeline produces today.

What it changes is the conversation around those bytes: procurement, security review, and the queasy question of who maintains the buildpacks now that Heroku is in sustain mode. A graduated CNCF project has independent governance, a public third-party security audit, and active contribution from multiple vendors. That is the language enterprise risk committees understand, and as of August, the no-Dockerfile path speaks it fluently.

There is one caveat, and it is a large one: graduation covers the specification and the project, not every builder image you consume. The same ecosystem that just graduated also watched its most popular builder distribution nearly lose its registry hosting on two weeks' notice. This post covers both halves — what the stamp certifies, and what it doesn't — and ends with what a git-push PaaS should actually do this quarter.

What "graduated" actually certifies​

CNCF graduation is a multi-year audit, not a marketing badge. To graduate, a project must demonstrate sustained production adoption, vendor-neutral governance, an independent third-party security review, CNCF Code of Conduct adoption, and active contribution from multiple organizations. Cloud Native Buildpacks cleared every gate after eight years in the foundation — it entered the sandbox in October 2018, after Pivotal and Heroku jointly created it in January of that year, building on the Heroku buildpack model that dates to 2011.

The numbers behind the stamp are substantial. The project counts 535 contributors across 164 organizations, with more than 20 production adopters on record, including Bloomberg, Heroku, DigitalOcean, GitLab, Google, HashiCorp, Spring, VMware, and the Cloud Foundry ecosystem. Contribution data from the year before graduation shows Bloomberg and Heroku by Salesforce not merely using the technology but actively developing it — code, reviews, and pull-request activity across the project.

The security gates matter most for platform teams. The project completed a third-party security review with Quarkslab in partnership with the Open Source Technology Improvement Fund (OSTIF), earned an OpenSSF Best Practices passing badge, and adopted the CNCF Code of Conduct. These are not press-release checkboxes. They mean a build pipeline component — the exact stage where source becomes artifact, where supply-chain risk enters the system — has been subjected to the same scrutiny enterprises already demand of registries and admission controllers.

CNCF CTO Chris Aniszczyk framed it in operational terms: buildpacks' graduation solidifies it as a tool for standardized container images, providing the operational consistency required to manage and secure modern software supply chains. Strip the announcement prose and the claim is concrete: one governed specification for turning source into OCI images, instead of N hand-maintained Dockerfiles each encoding one team's folk knowledge about base images.

The mechanism that earns it: patch the base, keep the app​

Graduation certifies governance, but the reason platform teams should care is the mechanism underneath — specifically, what happens on CVE day. The buildpacks pipeline has two phases: detect, where buildpacks examine source to identify language and framework, and build, where they install dependencies, compile, and emit a layered OCI image. No Dockerfile anywhere in the loop:

pack build myapp --builder paketobuildpacks/builder-jammy-base

That single command is the developer contract. The platform contract is what the layers enable afterward. Buildpacks separate application code, dependencies, and operating-system layers, so each can be patched without rebuilding the others. When a vulnerability lands in the base image, you do not rebuild every application from source — you rebase, swapping the run layer underneath an untouched application layer:

pack rebase myapp

This is the operation behind Bloomberg's weeks-to-hours number: centralized base-image patches propagate to 500-plus applications without touching application code, rebuilding dependency trees, or re-running every team's bespoke Dockerfile. Add automatically generated SBOMs — increasingly a compliance requirement, not a nice-to-have — plus reproducible builds that make rollback and audit trails trustworthy, and you have the supply-chain framing the graduation announcement leans on: reproducible, patchable base images without rewriting app Dockerfiles.

Sambhav Kothari, Bloomberg's head of foundational AI platforms and a Buildpacks steering committee member, put the platform-engineering point precisely: the project helped Bloomberg shift controls left and apply consistent governance across its software supply chain, without pushing infrastructure complexity onto individual application teams. That last clause is the critical one. Platform engineering is a contract business — the platform guarantees the right thing happens at the build boundary, and developers stay focused on code.

The public roadmap points where this contract goes next: standardized packaging of OCI artifacts beyond container images, deeper SBOM workflows aligned with CycloneDX and SPDX for automated compliance reporting, and experimental WebAssembly module builds through the same interface. Whether Wasm builds matter to your fleet this year or not, the direction is consistent — one governed build abstraction across artifact formats, instead of a new snowflake pipeline per runtime.

The bus-factor warning graduation does not cover​

Now the other half. In March 2025 — seventeen months before graduation — the Paketo project, the ecosystem's most widely consumed builder distribution, published an urgent post: its sole GCP sponsor was halting sponsorship, the Paketo GCP project would shut down within roughly two weeks, and every image hosted on Google Container Registry had to move. No exact date was available because Paketo itself didn't have one. A month earlier, the same project had posted a contributors-wanted appeal after several maintainers moved on.

Read those two posts together and the lesson is sharp: the graduated artifact is the specification and the core project, but what your pipeline actually pulls is a builder image maintained by a specific community with its own sponsors and its own bus factor. CNCF graduation does not insure paketobuildpacks/builder-jammy-base against its next infrastructure scare. It answers "who governs the standard," not "who pays this builder's registry bill."

To be fair and representative, the scare did not kill Paketo — and the recovery is part of the story. Through 2026 the project shipped Ubuntu 26.04 "Resolute" builders, consolidated ten Python package-manager buildpacks down to two, collapsed ten JVM-vendor buildpacks into one selectable via BP_JVM_VENDOR, and published fresh Node.js guides for its Ubuntu Noble and UBI builders. That is a living project, not a dying one. But "living" and "structurally guaranteed" are different things, and a platform betting its entire build story on one builder distribution should treat them differently.

The mitigations are unglamorous and effective. Pin builder images by digest, not by floating tag, so an upstream move cannot silently change what you ship. Mirror the builders you depend on into a registry you control, so a repeat of the GCR sunset is your incident to schedule rather than your outage to discover. And prefer builders with more than one sponsor behind them — the whole point of a graduated, multi-vendor ecosystem is that you have alternatives when one distribution wobbles.

Who maintains the buildpacks now​

This is the question the graduation actually answers, and it has been open since Heroku — the birthplace of buildpacks — visibly entered sustain mode. If the company that invented the model is no longer driving it forward, who is?

The graduation record gives a concrete answer. Heroku by Salesforce remains an active code contributor to Cloud Native Buildpacks, not just a trademark in the history section — the CNCF cited a full year of contribution data showing code, reviews, and pull-request activity. Joe Kutner, a Buildpacks co-founder and maintainer now principal architect at Salesforce, described buildpacks as key to accelerating Salesforce's own product delivery. Bloomberg sits on the steering committee and runs its AI infrastructure on the project.

Spring Boot has shipped native buildpack support since early 2020, turning one Maven or Gradle task into a layered, SBOM-carrying image. Google, GitLab, HashiCorp, DigitalOcean, and VMware by Broadcom round out an adopter list that no longer has a single point of corporate failure.

That is precisely what "graduated" buys you: the maintenance question stops being "does one company still care" and becomes "does a governed, multi-organization community still ship" — with eight years of evidence saying yes. But apply the previous section's discipline here too.

The answer holds at the project level; at the builder level, you still verify per distribution. Check who commits to your builder, who funds its infrastructure, and what its release cadence looked like over the last year. Governance is transitive only if you confirm the chain.

What a git-push PaaS does this quarter​

For a platform whose promise is "push a git repo, get a running HTTPS service," buildpacks graduation is a tailwind with homework attached. The homework is small and concrete:

1. Default standard stacks to pack build. For mainstream language stacks with no exotic system dependencies, a maintained builder now carries a graduated project's governance behind it. Keep Dockerfiles as the escape hatch for snowflake builds — graduation argues for buildpacks-first, not buildpacks-only.
2. Put rebasing on a schedule, not on CVE day. The weeks-to-hours Bloomberg number comes from making base-image patching routine. A weekly rebase-and-redeploy pass over tenant images turns the next OpenSSL advisory into a non-event instead of a rebuild-the-world drill.
3. Consume the SBOMs you are already generating. If your builder emits bills of materials, wire them into image metadata and your vulnerability scanner instead of letting them evaporate in CI logs. Compliance teams will ask for them; graduation means you can answer with a standard artifact.
4. Pin and mirror your builders. Digest-pin every builder in your build fleet, mirror them to infrastructure you control, and alert on upstream releases so updates are deliberate. The Paketo GCR episode is the drill you run before the real fire.
5. Watch the roadmap at the edges. OCI artifacts and Wasm builds will not change your tenant story this quarter, but SBOM-workflow standardization might change your compliance story next year. Track the project, not just the builder.

None of this requires believing buildpacks will replace Dockerfiles everywhere. It requires believing that the boring, standard, CVE-patchable middle of your build fleet — the dozens of small services whose Dockerfiles nobody enjoys maintaining — deserves governed infrastructure rather than folk knowledge. That was a defensible bet in 2020 when Spring adopted it. After graduation, it is the default, and the Dockerfile-everywhere fleet is the position that needs justifying.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Star the repo on GitHub or deploy your first app today.