News

Only 26% of AI-Generated Patches Worked. That's Why TrueSource Exists.

Broadcom's supply chain announcement rests on an uncomfortable number, and the number is the most useful thing in it. AI finds vulnerabilities faster than people can. It still can't be trusted to fix them alone.

Seven announcements came out of the opening day of Explore 2026, and six of them were about AI infrastructure. This is the one that wasn't, and there's a statistic buried in it that's worth more than the product it supports.

Testing by 1Password's Off-by-1 Labs found that of 6,000 AI-generated patches evaluated, only 26 percent fixed the vulnerability without breaking the application.

Roughly three in four either missed the problem or created a new one. If your remediation strategy is drifting toward fully automated AI patching, and plenty of vendors are selling exactly that, this is the number to put in front of whoever is making the decision.

The asymmetry

This creates an awkward situation. AI has made vulnerability discovery and exploitation much faster. Attackers weaponise a disclosure in hours now, which is the trend this series has tracked all year through the collapsing time-to-exploit figures. Remediation hasn't become correspondingly safe to automate.

So the attack side is automated and the defence side isn't. TrueSource is positioned into that gap, and the positioning is honest about it. Use frontier models for scanning at machine speed, keep humans on verification.

Broadcom says its engineers continuously scan Spring and its dependency tree with frontier models, finding vulnerabilities before attackers do, then verifying each patch by hand. They put a number on the scale: more than 12 billion tokens spent on this in the past five months.

What TrueSource is

Three components, available now under tiered site licensing.

• Spring Enterprise. The flagship offering, delivering curated Spring releases from the team that maintains Spring, with frontier-model-scanned and human-verified patches shipped simultaneously across every supported release line. Broadcom cites coverage of more than 5,000 Java libraries.

• TrueSource Trusted Artifacts. Clean-room builds at SLSA Build Level 3 for the wider Java ecosystem, Python and Node.js, incorporating the Bitnami Secure Images catalogue of hardened container images.

• TrueSource Data Services. The same approach applied to the data tier: PostgreSQL, RabbitMQ, MySQL and Valkey, with validated builds, Helm charts, Kubernetes operators and support.

Tooling includes automated pull-request remediation and blast-radius impact dashboards. SLSA Build Level 3 is worth noting because it's a recognised supply chain integrity standard rather than a vendor-defined one, which makes the claim checkable.

Two principles

Broadcom states two design principles that are more interesting than the feature list.

The first is remediation with maintainers rather than around them. Fixes go upstream, and Broadcom backs community maintainers with engineering time and funding. If you've watched commercial vendors fork open source rather than fix it, that's a commitment worth noting, and it's checkable over time through upstream contribution history.

The second is an early access programme. Licensed customers can bring not-yet-public vulnerabilities they discover, and there's a dedicated programme for critical infrastructure organisations to get patch insights and mitigation advice. That second part is aimed squarely at the sector most readers here work in.

Why this belongs in an infrastructure blog

Because the supply chain is an infrastructure concern now, not only an application one. Your VCF estate runs Kubernetes clusters running containers built from base images assembled from libraries nobody on your team wrote. The blast radius of a compromised widely-used library reaches your platform whether or not your team writes Java.

Three things worth doing regardless of whether you buy anything.

• Find out whether anyone owns open-source dependency risk. In a lot of enterprises application teams own their own dependencies and nobody owns the aggregate.

• Check whether your remediation approach assumes automated patching is safe. The 26% figure is a good conversation starter and it's from an independent lab, not a vendor.

• Look at where your container base images actually come from. Hardened, verifiably-built base images are cheap to adopt and hard to retrofit after an incident.

The commercial offering may or may not suit your organisation. The underlying argument holds either way: AI-speed exploitation calls for verified remediation, not automated remediation.