Zero-CVE Buildpacks Are Here: What BellSoft's Hardened Paketo Builder Means for a Git-Push PaaS

Sixty percent of developers don't realize their Dockerfile can introduce security vulnerabilities. That number comes from BellSoft, the OpenJDK vendor, and it is the entire pitch behind what the company shipped on July 21, 2026: a generally available hardened builder image for Paketo Buildpacks that promises zero-CVE container images — patched within 24 hours of disclosure, signed, with a Software Bill of Materials attached — without changing a single step of the existing buildpacks workflow.

Here is the verdict before the why: if your platform already builds tenant apps with Paketo, trialing the hardened builder is the cheapest security upgrade on your roadmap — but it buys you a clean OS layer, not a clean app, and it trades one dependency (the stock Paketo stack) for another (a commercial hardened-image vendor). The comparison below is the whole decision on one screen; the rest of this post substantiates every cell.

Why base-image CVEs are a PaaS-scale problem​

Start with the background radiation every container platform swims in. Sysdig's container security report found 87% of container images ship with high or critical vulnerabilities. NetRise's analysis of popular images found an average of 604 known vulnerabilities per container, with more than 45% dating back two to ten-plus years — and 4% of them actively weaponized by botnets and threat actors. Prevasio's execution-based scan of Docker Hub put it more bluntly: 51% of images contain one or more critical vulnerabilities.

For a single team shipping one service, that is a scanner ticket. For a git-push PaaS, it is a multiplier: one vulnerable base image under every tenant app means one CVE becomes N incidents, N rebuilds, and N conversations with tenants asking why their app — which they did not change — suddenly fails a compliance scan. This is the "scanner fatigue" BellSoft cites as the adoption driver behind its buildpack tooling, which the company says more than doubled year-over-year between 2024 and 2025.

The PaaS operator's traditional answers are all expensive. Option one: own a CVE-patching pipeline — track base-image feeds, rebuild every tenant image on every patch, and absorb the support load when a rebuild changes behavior. Option two: push it to tenants, which means every tenant re-solves base-image hygiene badly. Option three: pay someone else to own the bottom of the stack. The hardened-builder announcement is option three arriving inside the buildpacks workflow you already run.

What the hardened builder actually changes​

To see why a builder swap is powerful rather than cosmetic, you need the one architectural fact that makes Cloud Native Buildpacks different from Dockerfiles: the builder/run-image split. A Paketo builder is the heavy build-time environment; the run image is the slim OS layer your app actually executes on top of. Because buildpack layers are content-addressable and the app layers sit cleanly above the OS layers, you can swap the OS underneath a built image without recompiling anything:

pack rebase my-app:latest --run-image bellsoft/hardened-run:latest

That command — seconds, not a rebuild — is the mechanism that turns "patched image within 24 hours" from a vendor claim into an operational property of your fleet. BellSoft publishes the fix; you rebase every tenant image onto it; no source rebuilds, no tenant coordination.

The stock Paketo workflow already supports this against Paketo's own run images. What changes with the hardened builder is what you are rebasing onto: a minimal Alpaquita-based image with a fraction of the packages a scanner can flag, maintained by a dedicated security team instead of riding the community stack-update cadence.

The second change is compliance paperwork becoming a build artifact. Every image from the hardened builder ships with a full SBOM and verifiable provenance records automatically. If you have ever answered an enterprise tenant's security questionnaire, you know the drill: "do you have SBOMs for what you run" is a question that today requires pipeline archaeology — Syft in CI, attestations wired by hand, provenance bolted on.

Automatic SBOM plus signed images flips the answer to "yes, attached to every build" with no per-tenant work. Pair that with signature verification at admission time (Kyverno policies that only admit signed, attested images are the standard pattern) and the platform gains a supply-chain story it can state in one sentence.

The third change is scope reduction at the OS layer. Reduced package footprint plus a non-mutable component set plus non-root defaults is the same recipe the whole hardened-image market converged on: Chainguard's Wolfi-based images (near-zero CVEs, average remediation under 20 hours, SLSA provenance and SBOM attached), Docker's Hardened Images (free and open source since December 2025), Google's distroless line. BellSoft is not inventing the pattern; it is plugging the pattern into the one build system — buildpacks — whose rebase mechanic makes the patched base deployable fleet-wide in minutes.

What it doesn't change​

Honesty first: "zero-CVE" describes the OS layer BellSoft owns. Three entire vulnerability surfaces sit above it, untouched by any builder swap.

Your tenants' application dependencies are still their problem. A Node.js app with a vulnerable lodash or a Python service pinned to an ancient requests produces the same scanner findings on a hardened base as on a stock one. The builder fixes the floor, not the furniture. If your platform markets "secure by default" to tenants, the hardened builder strengthens the claim but does not complete it — you still need the app-layer story (dependency scanning, tenant guidance, or opinionated base buildpacks that keep language runtimes fresh).

Buildpack-carried dependencies are a separate feed. Paketo buildpacks themselves download language runtimes, CA certs, and helper binaries at build time. Those ride Paketo's release cadence and the upstream language ecosystems, not BellSoft's 24-hour window. A CVE in the JRE a Java buildpack installs is fixed when the buildpack ships it, regardless of which builder orchestrated the build. Counting "days to patched tenant image" honestly means tracking both feeds, not quoting one SLA.

Vendor claims deserve a scanner, not trust. Early community reaction included at least one operator who went looking for BellSoft's hardened images in public registries and couldn't find tags matching the marketing — a fair prompt to verify rather than believe. The good news is that verification is cheap and decisive: build your canonical tenant app against both builders and scan both outputs with Trivy or Grype. The hardened builder's entire value proposition is a number — CVE count at build time, and hours from disclosure to patched rebase target — so measure the number before you migrate the fleet. Any hardened-image vendor that objects to being scanned is telling you everything.

The operator's decision: pin to a vendor or own the pipeline​

Strip away the launch-day framing and the decision is a classic platform build-vs-buy, with unusually concrete terms on both sides.

What pinning costs. Adopting the hardened builder wires a commercial vendor into your build path's lowest layer. The questions to answer before committing: what exactly does the SLA cover (24 hours from disclosure or from upstream patch availability — those differ by days for embargoed CVEs)? What happens to your fleet if you need to migrate back to stock Paketo or to another hardened base — is the exit just a --builder flag flip plus a rebase, or have tenants come to depend on BellSoft-specific behavior? And what is the support story when a scanner flags something in a BellSoft image — a ticket queue with a contract, or a community forum? None of these are reasons to say no; all of them belong in the evaluation doc.

What owning the pipeline costs. The alternative is keeping the stock builder and building the CVE machinery yourself: watching stack updates, automating fleet-wide rebases, generating and storing SBOMs, signing images, and answering tenant questionnaires from your own artifacts. That is genuinely buildable — Tekton Chains plus cosign plus Rekor is a well-trodden path to SLSA provenance and keyless signing, and pack rebase in a loop is a weekend project. But "buildable" is not "free": it is a permanent on-call surface (someone owns the feed watcher forever) and a compliance story you must write and defend yourself. For a small platform team, that toil is the most expensive line item, because it never ships a feature.

The evaluation checklist. Before deciding, run this drill — it takes an afternoon and produces the only numbers that matter:

1. Build your three most typical tenant apps (not one cherry-picked service) against both builders.
2. Scan all six images with the same scanner and profile; record CVE counts by severity.
3. Time a fleet rebase drill: how long from "new run image published" to "every image rebased and redeployed" with your current automation?
4. Consume one auto-generated SBOM: feed it to your audit tooling or just grype sbom: it — confirm the artifact is usable, not merely present.
5. Verify one signature end to end, and sketch the admission policy (Kyverno, Sigstore policy controller) that would enforce it.

If the CVE delta is large and the drill is boring, switch. If the delta is small — your tenants' scanner pain is mostly app-layer, which the builder can't fix — you just saved yourself a migration and learned exactly where your real exposure lives.

The default is moving under you​

Zoom out one level and the BellSoft launch is not an isolated product — it is the buildpacks ecosystem catching up to where the base-image market already went. Chainguard passed $40M in ARR on the premise that enterprises will pay to stop triaging base-image CVEs. Docker made its hardened images free. Google's distroless images normalized minimal runtimes years ago. The direction is unambiguous: the OS layer of a container is becoming a commodity you consume patched, signed, and attested — not a liability you manage per app.

For buildpacks-based platforms, that commoditization lands with unusual force, because rebase turns "a patched base exists" into "the fleet is patched" with no rebuild coordination. The platform that rebases onto a hardened run image weekly has a better patch posture than the platform that rebuilds Dockerfiles monthly, at a fraction of the toil. Whether the hardened base carries BellSoft's name, Chainguard's, or Docker's matters less than the posture: patched upstream, verified locally, rebased automatically.

So run the afternoon drill. Scan both builders, time the rebase, read one SBOM. Either you switch on evidence and delete a permanent toil stream from your roadmap, or you keep the stock builder knowing exactly what you kept and why. Both are better than the posture most small platforms have today: a base image nobody chose, a CVE backlog nobody owns, and a scanner getting louder every quarter.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Buildpack-based deploys mean your apps inherit whatever the platform's builder guarantees; hardened builders are exactly the kind of default we're tracking. Star the repo on GitHub or deploy your first app today.