Cloud Native Buildpacks: How to Stop Writing Dockerfiles and Ship Secure Container Images at Platform Scale

I have spent twenty years watching the same argument play out in different organizations: a developer writes a Dockerfile, it works on their laptop, it gets copy-pasted by seven other teams with minor tweaks, and then six months later nobody knows who owns the base image, the OS packages are three years out of date, and patching a critical CVE means hunting down every team that copied that original Dockerfile. The Dockerfile is readable, hackable, and produces the wrong organizational outcome at scale.

Cloud Native Buildpacks (CNBs) are not a new idea; Heroku introduced buildpacks in the early 2010s (the public Buildpack API launched in 2012) and Cloud Foundry adopted them early. What changed is that the Cloud Native Computing Foundation formalized the spec, the tooling caught up to the promise, and in August 2026 the CNCF announced the graduation of Cloud Native Buildpacks, signaling production-readiness and mature governance. If your platform team is still on the “every team writes their own Dockerfile” model, this is the moment to reconsider.

The Dockerfile Problem at Scale

The Dockerfile problem is not a security laziness problem; it is a separation-of-concerns problem. Developers know their application. Platform teams know which base image configurations are hardened, which OS packages are acceptable, and when a zero-day requires a rebase across every image in the registry. Dockerfiles collapse those two concerns into a single file that developers own, which means the platform team can advise but cannot enforce.

The blast radius is not theoretical. I have walked into organizations with several hundred services, all built from developer-owned Dockerfiles, during a critical OpenSSL or glibc vulnerability disclosure. The CVE response process was essentially emailing every team individually and hoping they would rebuild and push before attackers started scanning. Most took days. Some took weeks. A few never updated at all. The platform team had visibility into what was deployed but no mechanism to push a fix without every individual team’s cooperation.

This is the actual problem CNBs solve, and the solution is structural rather than cultural: separate the application layer from the OS/runtime layer so that the platform team can update the OS layer without touching application code at all.

What Cloud Native Buildpacks Actually Are

A buildpack, at its core, is a script pair: detect (does this buildpack apply to this application?) and build (if yes, compile and stage the app). The spec formalizes how those scripts interact with the filesystem, how they produce layers, and how those layers get assembled into an OCI-compliant image.

The CNB spec introduces three abstractions on top of raw buildpacks:

Stacks (now called Build/Run images in the v0.12 spec) define the base OS images used during build and at runtime. The build image is used to run the buildpack; the run image becomes the base of the final container. Separating them matters: you can use a heavier build image with compilers and dev tools while shipping a minimal run image.

Builders bundle a set of buildpacks and a stack together into a single OCI image. When you run pack build, you hand it a builder, and the builder handles language detection, compilation, and layer assembly. Paketo provides reference builders (tiny, base, and full) for common use cases. Google and Heroku maintain their own builders.

Buildpack groups define a detection order. The lifecycle tries each buildpack in sequence; the first group where every buildpack’s detect script succeeds wins. This is how a builder can support Java, Go, Node.js, Python, and Ruby from the same entry point without any application-level configuration.

The Build Lifecycle: What Happens Between Source and Image

When you run pack build myapp --builder paketobuildpacks/builder-jammy-base, the CNB lifecycle takes over and runs through five phases:

Analyze: The lifecycle inspects any existing image for the same app in the registry and extracts layer metadata. As of Platform API 0.7, analyze runs first to validate registry access early and fail fast if credentials are wrong. This phase also enables layer caching across builds; if your dependencies have not changed, the dependency layer is not rebuilt.

Detect: The lifecycle runs each buildpack group’s detect script against your source tree. For a Node.js app, the Node.js buildpack detects a package.json. For a Java app with Spring Boot, the Maven or Gradle buildpack detects a pom.xml or build.gradle. No --language flag needed, no convention configuration. Detection is automatic and falls back cleanly when no buildpack matches.

Restore: The lifecycle copies cached layers from a previous build into the build container. This is separate from analyze: analyze reads metadata from the existing registry image; restore actually materializes the cached layer contents so the build phase can use them.

Build: Each buildpack in the detected group runs its build script. The buildpack stages application artifacts, installs language runtimes, resolves dependencies, and writes layers to disk. The layers are organized by cache behavior: some are cached between builds (dependency layers), some are always regenerated (application code layers), and some exist only at build time and are not exported into the final image.

Export: The lifecycle assembles the staged layers onto the run image base and pushes the final OCI image to the registry. It also writes an SBOM (software bill of materials) that records exactly which buildpack contributed which layer, which OS packages are present, and which application dependencies were detected.

The separation of build and run images in the export phase is where the security story lives.

Rebase: The Feature That Changes the Security Math

Rebase is the CNB capability that makes OS-layer patching tractable at scale. When a CVE in glibc or OpenSSL is disclosed, the standard Dockerfile workflow requires rebuilding every application image. Rebase does not.

Because the CNB lifecycle tracks layer provenance in OCI image metadata, the pack rebase command can swap out the run image base without running the build lifecycle at all. The application layers sit on top of the run image layers. Rebase detaches the application layers, swaps the run image base to a patched version, and re-stacks the application layers on top. The result is a new image SHA that has the patched OS but the same application code, and the operation takes seconds instead of minutes.

The platform team controls the run image. When the run image gets patched, they can trigger a rebase across every image in the registry that was built from that run image. Applications do not need to rebuild. Developers do not need to be emailed. The compliance team gets a consistent answer to “all images are based on a patched OS.”

This is the reason I bring CNBs up when talking to platform teams managing more than a few dozen services. The rebase capability alone is a persuasive operational argument. Pair it with how container image hardening is typically handled today (per-team Dockerfile maintenance), and the value becomes obvious.

Buildpack Implementations Worth Knowing

Paketo Buildpacks are the reference implementation for most teams not running a Heroku or Google platform. Paketo is a vendor-neutral project under the Cloud Foundry Foundation and maintains buildpacks for Java (including Spring Boot layered jar support), Node.js, Go, Python, .NET Core, PHP, and Ruby. The reference builders are regularly updated and the security posture is thoughtful: applications run as non-root users by default, and each buildpack publishes a CycloneDX SBOM.

Google Cloud Buildpacks are what powers Cloud Run, App Engine, and Cloud Functions when you deploy source code directly. Google maintains buildpacks for Go, Java, Node.js, Python, and Ruby. If you are deploying to Google Cloud, the Google buildpacks are what runs under the hood whether you use them explicitly or not.

Heroku Buildpacks were the original, and Heroku migrated them to the CNB spec. If you have used Heroku and appreciated the zero-configuration deploy experience, the CNB spec is essentially that idea formalized and made portable.

Tanzu Build Service (now VMware/Broadcom’s commercial offering) builds on top of kpack, which is a Kubernetes-native build system that uses CNBs. If you are managing CNB builds at scale inside Kubernetes, kpack gives you a controller that watches for base image updates and automatically triggers rebuilds and rebases. That is the platform-team dream: declare your builders, let the controller handle the image maintenance lifecycle.

CNBs in Kubernetes: kpack and Shipwright

Running pack build locally is a great way to understand the tool. Running CNBs at platform scale means integrating them into your cluster. Two projects matter here.

kpack is a Kubernetes controller that models CNB concepts as custom resources: Builder, Image, and Build objects. You declare an Image object pointing at your source repository, and kpack watches for new commits, new buildpack versions, and new run images. When any of those change, kpack triggers a new build automatically. The result is that a security patch to your run image triggers a rebase (or rebuild if necessary) across every Image resource in the cluster without any manual intervention. This is how platform teams operationalize the rebase story.

Shipwright is a higher-level abstraction that supports multiple build strategies, including CNBs, but also Kaniko, Buildah, and custom builds. If your platform needs to support teams with different opinions about their build tool, Shipwright provides a unified Build API that abstracts the underlying strategy. The downside is complexity; if your organization is going all-in on CNBs, kpack is simpler.

Both kpack and Shipwright integrate cleanly with GitOps workflows. When ArgoCD or Flux is managing your workloads, you want image updates to happen automatically when the image tag changes. kpack produces new image SHAs on rebase; image automation controllers like the Flux Image Reflector can watch for those new SHAs and open pull requests to update the image references in your GitOps repo.

SBOM Support and Supply Chain Security

The CNB lifecycle generates SBOMs as a first-class output, not as an afterthought. Every buildpack can publish SBOM data in CycloneDX, SPDX, or Syft format describing what it installed. The lifecycle aggregates these into a per-layer SBOM and embeds it in the image as an OCI annotation.

This matters for software supply chain security requirements. When your security team or an auditor asks “what OS packages are in this image, what language runtime, and what application dependencies,” the CNB SBOM gives you a complete, machine-readable answer that was generated at build time rather than scanned after the fact. Scanning is still valuable as a verification step, but having authoritative SBOM data from the build process itself is more reliable than inference from image contents.

The August 2026 CNCF graduation announcement specifically called out that the project passed a third-party security audit conducted by Quarkslab and OSTIF and received an OpenSSF Best Practices badge, which means the toolchain itself has been evaluated rather than just the spec.

For SLSA build provenance, CNBs are a strong foundation: the lifecycle produces a deterministic build from a known builder image, the SBOM captures layer provenance, and kpack’s integration with signing toolchains like Sigstore/cosign means you can sign every image produced by the platform.

When Dockerfiles Are Still the Right Answer

I would not write this as a “CNBs are always better” argument, because they are not. Dockerfiles are still the right answer in several situations.

Highly customized images: If your application needs a specific system library that is not available in any existing buildpack, or if your build process requires unusual system-level configuration, writing a custom buildpack is significantly more work than adding a RUN apt-get install line. The Dockerfile wins on raw flexibility.

Multi-stage builds with complex artifact dependencies: Some build pipelines produce artifacts in one stage that feed into another in ways that do not map cleanly to the CNB layer model. A Dockerfile with several FROM stages and COPY --from directives is often clearer for these cases.

Short-lived utility images: If you need a quick one-off image for a job or migration runner, the overhead of selecting a builder and understanding the detection heuristics is not worth it. Write the Dockerfile.

Teams that need to understand exactly what is in their image: This sounds counterintuitive, but the opacity of auto-detection is occasionally a genuine problem. Developers who need fine-grained control over their dependency resolution sometimes find Dockerfiles easier to reason about. The SBOM helps, but it is a post-hoc artifact, not a specification.

The organizational calculus is: the more images you manage, and the more important security patch velocity is, the more CNBs pay off. For a startup with five services and a small platform team, Dockerfiles plus good CI/CD hygiene is usually fine. For an enterprise with hundreds of services and a dedicated security team asking for evidence of CVE remediation timelines, CNBs with kpack and rebase are compelling.

Integration with CI/CD Pipelines

For teams not ready to run kpack in Kubernetes, CNBs integrate into standard CI/CD pipelines straightforwardly. The pack CLI is a single binary and the build command is simple: pack build registry.example.com/myapp:latest --builder paketobuildpacks/builder-jammy-base --publish.

That single command replaces docker build, handles caching via registry layers, and produces a SBOM. Dropping it into a GitHub Actions or CI/CD workflow is a one-line replacement for the Docker build step.

For Tekton users, the Paketo project maintains Tekton tasks for CNB builds. For teams using Argo Workflows, the pack CLI runs in any container. The operational difference from Dockerfiles is minimal at the CI/CD integration layer; the organizational difference in who owns the builder is substantial.

One gotcha I have seen trip teams up: the pack CLI needs access to the registry to pull the builder and push the image. In CI environments with ephemeral runners, ensure the runner has appropriate registry credentials and that the builder image is either pre-pulled into a local registry or cached. Cold-start build times are dominated by pulling the builder image, which can be large. Mirroring the builder into your internal registry is worth doing early.

Developer Experience: The Honest Assessment

The developer experience story for CNBs is mostly positive but not without friction. The zero-configuration detect-and-build experience is genuinely magical for standard language stacks: put a Spring Boot project directory in front of the Paketo Java builder and it compiles, stages, and produces a production-ready OCI image without a single Dockerfile line. Developers coming from Heroku recognize the pattern immediately.

The friction comes at the edges. When detection fails because your project has an unusual structure, the error messages are not always informative. Debugging why a buildpack did or did not detect requires understanding the detection heuristics, which means reading buildpack source code. This is a solvable documentation problem, but it is a real one today.

Custom buildpack development, while well-specified, has a meaningful learning curve. The buildpack API is clear, but the layering model, the cache semantics, and the SBOM integration require investment to understand correctly. Teams that need custom buildpacks should plan for that learning time rather than assuming it is a weekend project.

The platform engineering argument for CNBs is stronger than the individual developer argument. A platform team that absorbs the complexity of builder maintenance, SBOM generation, and rebase automation creates a dramatically simpler experience for application developers: write code, push, get a compliant image. The complexity does not disappear; it moves to the right place.

Getting Started

The fastest path to understanding CNBs is the pack CLI against a real application. Install it via the GitHub releases page or Homebrew on macOS, then run pack build against any of your existing applications. Compare the result against your existing Docker build in terms of image size, layer structure, and SBOM content. The output from pack sbom download against the resulting image is a useful artifact to show your security team.

For Kubernetes, the kpack documentation is the right starting point. The Getting Started guide will have you running builds inside the cluster in under an hour. From there, integrating with Kubernetes RBAC to control who can create or modify Builder and Image resources is the first production hardening step; your platform team should own the builder definitions, not individual application teams.

For organizations evaluating CNBs for broad adoption, the CNCF graduation of Cloud Native Buildpacks in August 2026 is a meaningful signal. It means the project has demonstrated production adoption, vendor-neutral governance, a completed security audit, and a committed maintainer community. The graduation is not a reason to adopt blindly, but it is a reason to take the evaluation seriously rather than treating CNBs as an experimental niche tool.

The Organizational Shift

The deepest change CNBs enable is not technical; it is organizational. The Dockerfile model puts image maintenance responsibility on every development team. The CNB model puts base image maintenance on the platform team and application layer responsibility on the development team. Neither team can violate the other’s boundary accidentally.

That separation is exactly what makes the rebase story work. It is also what makes compliance conversations tractable. When a regulator or auditor asks “how do you ensure all your container images are based on patched base images,” the answer with CNBs and kpack is a concrete, automated, auditable process rather than a policy that depends on every team following procedure.

Twenty years of watching security incidents has taught me that the most effective security controls are the ones developers do not have to remember to apply. Rebase is automatic. SBOM generation is automatic. Non-root execution is the buildpack default. The developer ships an application. The platform team owns the security envelope. That is the right split.

The Dockerfile is not going away, and it should not. But for platform teams managing images at scale, Cloud Native Buildpacks offer a structural solution to a problem that process and tooling guidelines have never fully solved.