Sonatype CEO on self-service: The vulnerability data gap undermining AI-driven development
This is a guest post for the Computer Weekly Developer Network written by Bhagwat Swaroop, is his capacity as CEO of Sonatype.
Sonatype is known for its software supply chain security toolset (with a focus on open souce technologies) and its AI services, which are designed to automate dependency management and compliance controls with products such as Nexus Repository for artifact management and vulnerability scanning.
Swaroop writes in full as follows…
A shadow is looming over self-service developer platforms, generative AI coding assistants and agentic tools: automation is accelerating, but the data feeding it is not designed for the speed, autonomy and decision-making now expected of it.
Increasingly, self-service tools and internal developer platforms (IDPs) are configured to make critical decisions, but they’re relying on vulnerability feeds that lack the fidelity, consistency and timeliness required for automated action.
The result is a growing paradox: systems that appear intelligent but whose confidence is only as strong as the data and guard rails behind them.
Developer decisioning
Developers aren’t making bad decisions; they’re being served incomplete information. Self-service tooling only works when the underlying intelligence is trustworthy. When 90% of a typical application is open source, poor-quality vulnerability intelligence that lacks accuracy or context doesn’t affect the margins of a business – it affects its very core.
Put simply, automation is only as smart as the vulnerability intelligence that powers it.
Right now, that intelligence is dangerously out of date.
The scale of the problem
Out of 1,552 open-source vulnerabilities disclosed in 2025, nearly two-thirds (64%) lacked a CVSS severity score from the National Vulnerability Database (NVD) – so only 36% of CVEs were triage-ready. Even when scores are assigned, reliability is weak: fewer than one in five severity ratings were accurate, with 62% of NVD scores overstating and 34% understating risk.
To make matters worse, the average delay between disclosure and scoring exceeded six weeks – long after exploits spread. In some cases, delays climbed to a substantial 50 weeks. On top of that, 19,945 false positives and 156,474 false negatives were identified across CVE records, leaving AI-driven development pipelines exposed.
Collectively, this wastes developer time, exacerbates alert fatigue and obscures real threats. Taken together, it’s clear that the systems teams rely on to power automated decisions are being stretched beyond their original design limits, particularly across coverage, accuracy and timeliness.
Why this matters for self-service
When developers have autonomy – from picking packages and choosing workflows, to
pushing releases – the platform must act as a reliable safety net. But if the Internet is built with weak foundations, the result is a false sense of security. IDPs that route remediation, trigger automatic fixes, or prioritise vulnerabilities depend on good intelligence.
With flawed data, these systems fail to triage accurately and prioritise effectively – leading either to wasted effort (false positives) or unchecked risk (false negatives). So how does this happen, exactly? Automation might flag a vulnerability as low risk because it lacks a CVSS score, or it might sit unresolved because the feed is six weeks old.
Developers move on – but, crucially, the attack chain doesn’t. Over time, trust in the system erodes and teams compensate with manual gates, undermining the promise of developer self-service.
What’s at stake (closing the gap)
The stakes are high because development processes are faster than ever. With cloud-native, containerised and AI-driven workflows, a vulnerability can be published, consumed and exploited in hours. If intelligence lags days or weeks behind, teams are effectively flying blind.
This is not theoretical. Over 34,319 malicious open-source packages were identified in Q3 2025 alone and many exploited dependencies trusted by developers. Automation built on stale data is simply amplifying risk.
The answer is not less automation but more clarity.
Five practical steps
For developers and platform owners, here are some practical steps to start closing the gap between automation and intelligence:
- Diversify and validate your feeds: Don’t rely solely on CVE/NVD. Use multiple sources, cross-check them and highlight potential unscored risk.
- Prioritise timeliness: If a vulnerability lacks a score past a defined SLA (for example, 7 days), escalate it manually or automatically treat it as high risk.
- Expose intelligence-quality metrics inside IDPs: Show developers if the data is stale, missing, or not directly sourced; transparency builds trust.
- Make remediation decisions risk-based, not rule-based: Automation must consider context: dependency age, usage, exposure-surface – not just raw severity.
- Treat intelligence as infrastructure, not tooling: Make a data feed part of the core platform, not an optional plugin.
Those who treat data quality as a second-class concern will find themselves burdened with automation as a second-class defence.
In a world where developer self-service is non-negotiable, the underlying intelligence must mature. Automation isn’t the answer by itself; after all, it’s only as smart as the data it’s fed. For self-service tools to deliver both speed and safety, we must fix the data foundations first.
When automation is operating on inferior intelligence, people aren’t moving fast; they’re flying blind – like driving at night with broken headlights.