Engineering brief
AI Finds Vulnerabilities Faster Than Open Source Can Fix Them
At a glance
The brief is enough
- Relevance
- Practical value
- Radar
- Time horizon
- This year
- Warnings
- None
AI tools are industrializing vulnerability discovery, but the fixing pipeline stays manual. With maintainers walking away and the CRA demanding fast fixes, dependency hygiene is becoming a board-level risk.
Dependency risk escalates from developer hygiene to compliance, insurance, and delivery exposure for engineering leaders.
Watch if you own software supply chain risk and want a practitioner's reasoning on how AI changes it.
Summary
The core claim. AI has changed the economics of finding bugs, not fixing them. Security researchers and bad actors can now run vulnerability discovery against every package in a system, continuously. Poole, a supply chain specialist who ran DevRel at Sonatype and now works for Hero Devs, argues the result will be packages that used to produce one CVE now producing four or five, and unsupported projects producing CVEs nobody fixes or reports.
The attack surface. None of the individual risks are new. Typo confusion, renamed packages, compromised maintainers, and developers piping remote scripts into a shell are familiar weak points. What changed is volume. AI-generated applications pull roughly three times more dependencies than a human-written app, according to studies Poole cites. That multiplies the attack surface without adding any understanding of vulnerability risk.
The maintainer math. The fixing side is still human. Maintainers who already burn out now face an order-of-magnitude increase in bug reports, and many will walk away. The consequence is a growing class of unmaintained but widely used packages where CVEs exist, researchers and attackers know them, and no one is obligated to publish a fix. Poole's company makes money from exactly this gap, which is worth remembering when evaluating the warning.
The regulatory turn. The Cyber Resilience Act and cyber insurers now push organizations toward reporting vulnerabilities and applying best-effort fixes in short timeframes. Staying close to the latest maintained release is the safest position, but it requires upgrade machinery most teams do not have. Poole predicts fragmentation: paid support for critical open source, free software left behind, and security patches landing in commercial forks first. That is a plausible future, not proven.
The Kubernetes signal. The Kubernetes project has already taken a visible position: no co-authorship with AI, human responsibility for AI-generated code, and skepticism about AI tool output quality. That is a concrete governance model other projects and companies can adopt. Poole also says an AI tool called Fable found real bugs he had missed and helped fix them, so the capability is improving, but non-deterministic output still has to be validated like any code.
The leadership takeaway. Teams should reduce dependency count, know which packages are unmaintained, and define a policy for AI-generated code and dependencies before an incident forces one. The urgency is high because the CRA is already in force, but the evidence is mostly anecdotal. Treat this as a risk-management conversation, not a prediction of collapse.
My take
I think the core warning is sound: AI makes discovery cheap and fixing expensive, and that shifts risk onto whoever consumes open source. What I'd push back on is the implied urgency for every team. Most engineering organizations have a handful of dependencies that actually matter; the rest can be pruned or pinned. The real work is not tracking every CVE, it is deciding which projects you are willing to maintain yourself. A fork or paid support contract is a legitimate answer, but only after you have removed the dependencies nobody can defend. The CRA talk is real, yet I would treat it as a governance lever, not an engineering panic. Start with an audit, set an owner, and make upgrades a weekly habit.
What to do with this
- Audit your top 20 runtime dependencies and verify each is on an actively maintained release; document the owner for each.
- Add a rule that any AI-generated code or dependency must pass the same license, CVE, and maintenance review as human-written code.
- Ask your security team to report the count of vulnerabilities in unmaintained open source packages over the last quarter and median time to patch.
Watch the video
This video is blocked due to your privacy settings. To watch this video, please accept YouTube marketing cookies.
Related breakdowns
AI Agents Won’t Work Without Platform Engineering
The book 'Thinking in Platforms' argues that AI agents require structured platforms. But the harder shift is organizational: treating platforms as products…
Architecture review boards are dead: continuous governance is the only path
Simon Rohrer dismantles traditional architecture review boards, advocating for continuous conversational governance and a DevOps operating model for EA…
You Think Languages Change Fast. Here’s the Data That Proves Otherwise.
Three independent rankings show the same thing: programming language adoption is slowing. AI is entrenching incumbents. Disruption isn’t coming.
Get TL;DW
Too Long; Didn't Watch.
A concise breakdowns of the AI and devtools videos that actually matter for engineering leaders.
Free. Weekly. No hype.
Video and thumbnails remain the property of their respective creators. tldw.news provides editorial analysis, commentary, and discovery links to original content.