The Bottleneck in Supply Chain Security Has Moved

When Snyk ran its fixathon in 2023 and closed half a million open source vulnerabilities, container projects finished with the highest fix ratio of any category at 73.3%, which Snyk attributed largely to its base image recommendations. One line in a Dockerfile clears more vulnerabilities than weeks of package-by-package triage.

Hannah Foxwell brought that finding into our weekly knowledge-sharing session last week. She was product director for Snyk Container, ran platform engineering at VMware Tanzu, founded the AI for the Rest of Us community, and is now building BIMP, a platform for keeping base images current across large repository estates. She walked through the problem, demonstrated the product, and the discussion that followed was mostly about the conditions an organisation needs in place before any of it works.

The supply side is largely solved

Zero-CVE and near-zero-CVE base images have become a normal procurement option. Chainguard publishes a contractual SLA of seven days for critical CVEs and reports an average critical remediation time under 24 hours. Docker Hardened Images commit to critical fixes within seven days on the Select tier. Red Hat and SUSE offer comparable guarantees. The market is consolidating around this: on 27 August, Echo acquired the hardened container assets of Minimus, which had begun winding down its registry a few days earlier.

A patched, minimal base image now exists within hours or days of a CVE landing. The open question is how long it takes that image to reach every place your organisation references it.

The gap between three teams

Base image currency falls between three groups. Developers own the repository artifacts and the Dockerfiles. Platform teams provide the tooling and the registries. Security teams receive a dashboard of bad news and have limited authority to change anyone else's code. Each group owns part of it and none of them owns the loop end to end.

At a handful of repositories this is a chore; at ten thousand image references spread across a few thousand repositories, manual updating stops being possible at all.

The timeline no longer allows human-speed triage

FIRST forecasts a median of roughly 59,400 new CVEs in 2026, which would make it the first year above 50,000. July alone set a monthly record at 9,771 published CVEs.

Discovery is being automated on both sides. Google's Big Sleep autonomously found 20 zero-days in open source projects, XBOW's agent reached the top of HackerOne's global leaderboard, and one research lab reported 21 FFmpeg zero-days for around a thousand dollars of compute. The exploitation window has compressed to match, with close to 29% of known-exploited vulnerabilities now attacked on or before the day they are disclosed.

Hannah also raised the chaining problem. An attacker running agents can combine several low and medium severity issues into a working exploit path, and a backlog sorted by severity will never surface that combination. What would have been triaged as acceptable risk may not be acceptable risk going forwards. A triage process running at human speed produces a saturated backlog where patches sit behind a queue that grows faster than anyone works through it.

What automated propagation looks like in practice

In the demo, Hannah created an organisation, set a 28-day remediation routine, and connected a GitHub org through a native GitHub app that reads image references without needing access to the underlying source. It scanned the repositories for Dockerfiles, Helm charts and compose files, and she replaced a set of wildcard Python references with a hardened zero-CVE Python 3.14 image on Debian. Pull requests were generated and published across multiple repositories in about thirty seconds.

The same mechanism runs in two modes. Routine remediation follows a schedule, every two, four or six weeks depending on the policy. Incident mode is triggered by a critical zero-day and cascades emergency pull requests to every impacted repository, with remediation progress tracked from a single view.

The part worth paying attention to is the exception handling. A team that cannot take the update runs a snooze command in the pull request comments and gives the reason, and security reviews it there. The exception, its justification, and the audit evidence end up in the same place as the change itself, rather than in a spreadsheet or a Jira ticket nobody reads.

BIMP does not scan images. It integrates with Trivy, Syft and Grype, or ingests SBOMs from the image provider. On the roadmap: the policy engine is being refactored onto OPA, along with private registry integration for SBOMs, attestations and signatures.

Bogdan asked the question that matters for anyone running this in an enterprise — whether a merged pull request tells you anything about production. Today it does not, and closing that gap is what the roadmap is aimed at. Reconciling image references across repositories, registries and running clusters is in development, and the goal Hannah described is end-to-end visibility, automation and governance running from the image provider through to production. On her account, that would make BIMP the first platform to offer this traceability as a single solution.

The prerequisite most organisations do not have

All of this assumes a mature delivery pipeline: short cycle times, traceability, and test automation good enough that a dependency bump can be merged without a person reading every diff.

A lot of large enterprises do not have that. Some still run significant parts of the estate without containers at all. Others have pipelines their own engineers do not trust, where developers hesitate to accept automated changes because a broken build is expensive and the test suite will not catch it before it hurts. The current version of BIMP accommodates this by keeping a human on the merge, which is the right call, and it also means the ceiling on remediation speed is set by how much trust an organisation can place in its own pipeline.

The same constraint appeared when the conversation turned to AI-assisted modernisation. We discussed a proposal put to a large European manufacturer to rewrite 26 products from scratch using AI coding agents in nine months. Code generation has got faster, while building the delivery factory around it — validation gates, test coverage, a transition roadmap that keeps the existing products running while the replacements are built — has not. Rewrites at that scale fail on the requirements nobody wrote down and the bugs the current system has quietly absorbed for a decade.

Where this leaves engineering leaders

None of this is specific to base images. The pattern repeats across most of the AI-native work we see: the supplier side improves, the automation becomes available, and the constraint turns out to be whether the engineering organisation can absorb change at that rate.

The work that unlocks automated remediation is the same work that unlocks agentic development. Cycle time, test automation, traceability, and enough confidence in the pipeline to let a machine merge into it. Organisations that have built that can adopt each new capability as it arrives. Organisations that have not will keep buying tools that stall at the pilot.

BIMP is in closed beta at bimp.ai. If the pipeline maturity question is the one you are stuck on, that is most of what we cover in From Cloud Native to AI Native, free to download.