When managing multiple business systems running on containers, it is easy to end up with the same CVEs appearing month after month on vulnerability scans. The issues flagged do not stem from application code, but rather libraries contained in the underlying OS image. Even though not a single line of application code is involved, the report lists your company's systems by name.
And no owner is ever assigned. The custom development contractor says, "We only used the base image specified," while the infrastructure team says, "The application team built the image." The following month, the exact same CVEs appear again.
This dynamic is not a matter of personnel mindset. It is because Dockerfiles structurally scatter remediation locations across every individual application.
With Dockerfiles, remediation locations multiply with every application
In a Dockerfile, the base environment is specified on the initial FROM line. When a vulnerability is discovered in the base image, the fix consists of updating the FROM line to a new tag and rebuilding.
While it seems simple at first glance, everything that follows comes attached. A full build triggers, CI execution limits are consumed, an entire test suite runs, and deployment approval is required. This occurs for every single service. If you have 20 services, that means 20 separate times.
What is more, the FROM line resides inside the application repository. That means the team with the permissions and procedure to fix it is the application team (or their contractor in custom development). The team overseeing infrastructure cannot dictate what gets fixed across the company or when. Their only option is to go around asking teams, "Please fix this."
This is precisely why the same CVEs persist each month. From the perspective of each individual service, running an entire test and deployment cycle for an issue that is not an application bug never becomes a high priority.
Swapping the foundation without rebuilding
Cloud Native Buildpacks is a framework that produces OCI images directly from source code without writing a Dockerfile. It detects languages like Java, Python, Go, Node.js, and Ruby, assembling the required runtime and dependencies automatically.
The key architectural concept to understand is that build-time and runtime foundations are managed separately. An OCI image known as a builder bundles the buildpacks, the lifecycle, and the build-time base image, while maintaining a reference to the runtime base image (run image) as metadata.
Because of this separation, when the runtime foundation is updated, image layers can be swapped without rebuilding the application. This operation is known as a rebase, and it takes just a single command.
The difference becomes stark at scale. Where the Dockerfile approach demands building, testing, and deploying across 20 services, a rebase only requires swapping the underlying layer. Furthermore, the origin of this operation does not sit in the application repository—it belongs to the team managing the base image.
This is the practical meaning of shifting the control point. How quickly a critical vulnerability is addressed no longer depends on each application team's backlog priorities, but can be decided directly by the infrastructure team.
What graduation signals: criteria for adoption
On August 11, 2026, the CNCF announced the graduation of Cloud Native Buildpacks. CNCF projects progress through three tiers—Sandbox, Incubating, and Graduated—with graduation signifying that a project has achieved the maturity required for production adoption.
The key criteria highlighted for this milestone include the following:
| Dimension | Details |
|---|---|
| Development organization | 535 contributors across 164 organizations |
| Production adoption | More than 20 organizations, including DigitalOcean, GitLab, Google, HashiCorp, Spring, and VMware by Broadcom |
| Security verification | Third-party audits by Quarkslab and OSTIF; OpenSSF Best Practices badge achieved |
When proposing internal adoption, questions like "Has it passed third-party audits?" and "Is it free from single-vendor lock-in?" are raised well before feature discussions. That is where the practical value of graduation lies. Upcoming roadmap items include expanding support for OCI Artifacts, strengthening SBOM (Software Bill of Materials) capabilities, and adding WebAssembly support.
When it is not a fit, and the line to draw in contracts
It is not a silver bullet. There are two points to verify prior to adoption.
Build internals become less visible. Because a Dockerfile details every procedure, reading it makes it clear what goes in. Buildpacks assemble images through auto-detection, meaning you need alternative methods—such as reviewing the generated SBOM—to verify that unintended components were not included.
Unusual native dependencies can create blockers. Custom system libraries or components requiring specialized compilation steps may not be supported by standard buildpacks. In such cases, keeping a Dockerfile rather than forcing an unnatural fit will make long-term maintenance much easier.
Regardless of which approach you choose, the lines that need to be drawn in maintenance contracts remain the same.
- Who decides on base image updates, and who executes the work? Setting clear timelines, such as "within X business days of a critical vulnerability announcement," eliminates monthly games of passing the buck.
- Is this work covered by the regular maintenance fee, or billed per estimate? Leaving this ambiguous leads to negotiations every time a request is made.
- Who performs post-update verification, and to what extent? Swapping the underlying foundation does not eliminate the need to verify that the application still works.
With the rise of tools where AI detects vulnerabilities and generates fixes, what to write in maintenance contracts was also covered in What clients must decide in an era where AI fixes vulnerabilities. Validating incoming vulnerability reports themselves is addressed in The problem of phantom CVE reports.
What to do next
If you run containerized systems, open your latest vulnerability scan results and count how many flagged items originate from the base image. If the proportion is high, streamlining your base update pipeline will be far more effective than modifying application code.
Next, check whether your maintenance contract specifies responsibilities and deadlines for base image updates. More often than not, it is omitted, and adding it during the next contract renewal is completely fine. However, once you recognize the gap, someone needs to take temporary ownership in the meantime.
GleamHub assists with container infrastructure reviews, vulnerability response workflows, and maintenance architecture design for existing systems through our Development, AI, and Automation consulting services. Because the approach depends on system scale and current configuration, we provide individual estimates. Please reach out via Contact Us.
Sources
- CNCF Announces Graduation of Cloud Native Buildpacks, Advancing the Standard for Container Builds — CNCF
- Buildpacks Move the Container Hardening Control Point Away From the Dockerfile — InfoQ
- Build OCI containers from code without a Dockerfile: Cloud Native Buildpacks becomes a CNCF graduated project — Publickey
- Getting Started — Cloud Native Buildpacks
- Cloud Native Buildpacks Achieves Full CNCF Graduation Status — Open Source For You
