BellSoft Rings Change Bringing Zero-CVE Images to Buildpacks Users
TL;DR — Key Takeaways
-
Zero-CVE Commitment: BellSoft is introducing a hardened builder image for Paketo Buildpacks based on its lightweight Alpaquita OS, promising to publish security patches within 24 hours of a vulnerability disclosure.
-
Death of the Dockerfile: The solution eliminates “Dockerfile sprawl”—which BellSoft notes 60% of developers don’t realize can introduce security vulnerabilities—by automating container creation directly from source code.
-
Automated Compliance: Every image produced automatically includes a full Software Bill of Materials (SBOM) and verifiable provenance records, simplifying enterprise audits and regulatory compliance.
-
Surging Adoption: Driven by the need to reduce developer toil and “scanner fatigue,” BellSoft reported that user adoption of its buildpack tools more than doubled year-over-year between 2024 and 2025.
BellSoft is bolstering Paketo Buildpacks. As an OpenJDK vendor known for providing tested (and commercially supported) Java distributions, Bellsoft is now offering a new hardened builder image for Paketo Buildpacks.
Paketo Buildpacks is an open source project designed to transform application source code into production-ready container images automatically, without a Dockerfile.
As every good cloud-native software engineer will know, a Dockerfile might traditionally be used here if developers need custom operating system packages to be brought into existence, or it would be used to provide precise control over layers in the software system being built, or it might be used to help drive highly specific container configurations that Paketo itself cannot automatically detect.
Automated DevOps Pipeline in a Box
A Paketo Buildpacks buildpack (don’t say that with your mouth full) inspects application code, determines what it needs, downloads dependencies, compiles where necessary and produces a runnable Open Container Initiative (OCI) image (standardized, vendor-neutral container image format that ensures applications run consistently across any compliant container engine, sometimes described as an automated DevOps pipeline in a box, turning raw source code into a secure, production-ready image), all in a single command.
Built on BellSoft Hardened Images, the builder gives Paketo Buildpacks users a path to an improved security and compliance posture, including continuous vulnerability management under whatever service level agreement (SLA) is in place, across signed images and the team’s Software Bill of Materials (SBOM), all inherited automatically with no changes to existing developer workflows.
Anatomy of a Buildpack
What’s really inside the workings of the software being executed here?
At the center of the process is a builder, a curated container image that packages the buildpacks, a build environment (the “build stack”) and a runtime environment (the “run stack”) together.
The builder is the security foundation of every image produced: The OS packages, libraries and runtime binaries it contains become the base of every application container that uses it. BellSoft’s contribution is a hardened builder that replaces both stacks with Hardened Images, based on Alpaquita, BellSoft’s own lightweight OS, so every container produced automatically inherits BellSoft’s full security and compliance posture.
“Vulnerability management is a business problem, not an engineering one,” said Alex Belokrylov, CEO of BellSoft. “It deserves a business answer, not the silent accumulation of toil on already-stretched internal teams. Scanner fatigue is real, and so is the cost of ignoring it.
Rather than tracking CVE feeds, Belokrylov recommends triaging which vulnerabilities affect which base images and coordinating patches across teams, security and platform engineering teams to maintain a clean image baseline.
“Each published image [resulting from the use of our technology] comes with a full Software Bill of Materials and a verifiable provenance record, making compliance audits straightforward and transparent and providing the documented evidence that regulators and enterprise procurement teams increasingly demand,” added Belokrylov.
Dockerfiles are Dead (ish), Buildpack Tools Next?
Hugely upbeat about the prospects for users at this level, Belokrylov and team remind us that Dockerfiles are written by developers, one per service, updated manually, and are thus prone to drift.
According to a recent BellSoft survey, over 60% of developers are unaware that a poorly written Dockerfile can itself become a security vulnerability. The company suggests that “Dockerfile sprawl” can become a compliance and maintenance liability. This is often because base image updates must be propagated manually across every repository and (of course) security patches are only as fast as the slowest team.
Paketo Buildpacks concentrate container build expertise in a single, reusable layer maintained by platform engineering. Developers push code, and the buildpack tooling auto-detects the language, resolves dependencies, and produces a minimal, reproducible OCI image with a built-in Software Bill of Materials. No Dockerfile is required.
Doubled User Adoption
When a base image needs updating, buildpack rebasing patches the OS layer across every service on the next build, without touching application code. Among BellSoft’s user base, buildpack tool adoption more than doubled year-over-year from 2024 to 2025.
BellSoft Hardened Images built on Alpaquita have a reduced package footprint, a non-mutable component set (running as non-root, which in this case means the containerized application runs with restricted user privileges instead of administrative permissions to prevent malicious actors from gaining control over a host system if compromised), and other security configurations enabled by default.
They are maintained by BellSoft’s security team with a commitment to a zero-CVE window: when a vulnerability is disclosed, a patched image is published typically within 24 hours.
Frequently Asked Questions
Do Paketo Buildpacks eliminate the need for Dockerfiles?
Not completely. Buildpacks can remove the need for Dockerfiles in many standard application builds, but Dockerfiles may still be useful when teams need unusual OS packages, highly customized layers or precise container configuration.
How do buildpacks reduce Dockerfile sprawl?
Buildpacks centralize container-building logic in a reusable platform layer. Developers submit code, while the tooling detects the language, resolves dependencies and creates a consistent image.
Are buildpacks suitable for every application?
No. They work well for common application stacks and standardized deployments, but highly specialized workloads may still require custom Dockerfiles or other container-building tools.


