AI and open source security

Open source software is now foundational to modern application development, allowing teams to reuse mature libraries, frameworks, and tooling rather than rebuilding common capabilities from scratch.

The AI and open source security issue is not simply that open source contains vulnerabilities, but that widespread dependency reuse creates a large, dynamic attack surface across the software supply chain. What is changing is the speed at which vulnerabilities can move from latent defect to actionable exploit. AI-assisted vulnerability discovery is compressing the window between an unknown issue existing in code and that issue being identified, analyzed, and potentially operationalized.

Most organizations already operate with significant exposure. According to recent industry security reports, most commercial codebases include open source components with high-risk vulnerabilities, reflecting how deeply open source dependencies are embedded in modern software delivery. IBM's Cost of a Data Breach Report places the global average cost of a breach at USD 4.44 million, underscoring that vulnerability exposure is both a technical and financial risk.

Historically, teams often had time between discovery, disclosure, exploit development, and widespread exploitation. AI changes that model by accelerating discovery, exploitability assessment, and attack-path construction.

From detection to autonomous exploitation

Google’s OSS-Fuzz illustrates the progression from automated testing to AI-enhanced code exploration, with AI-generated test cases uncovering previously unknown vulnerabilities (reported in this Google Security blog), including a critical OpenSSL issue that had existed for nearly 20 years.

More recent work, including Anthropic's Glasswing vulnerability research initiative and Mythos model, points toward autonomous exploitation, where systems can identify vulnerabilities, assess exploitability, build multi-step attack chains, and execute them with limited human involvement. Meanwhile, vulnerable and end-of-life components continue to be used in active development, widening the response gap.

Spring vulnerabilities: A current view

The Spring ecosystem provides a useful example because of its scale and adoption.

Looking at April 2026 specifically, the Spring ecosystem saw a total of 14 CVEs disclosed, made up of:

• 2 Critical severity vulnerabilities
• 6 High severity vulnerabilities
• 6 Medium severity vulnerabilities

The two critical vulnerabilities are particularly significant, as they represent scenarios where attacker-controlled input can influence application behaviour and lead to remote code execution under certain conditions.

Both CVEs relate to how Spring handles dynamic input at runtime. This includes patterns such as:

• Unsafe deserialization, where crafted payloads can result in arbitrary object instantiation and execution paths.
• Expression evaluation mechanisms, including Spring Expression Language (SpEL), where unvalidated expressions may be interpreted and executed.

In practical terms, these issues create a pathway for:

• Execution of arbitrary code within the application context.
• Access to sensitive data or internal application state.
• Potential escalation depending on deployment and configuration.

The other High and Medium severity vulnerabilities continue to reflect familiar patterns across the ecosystem, including authentication bypass scenarios, data binding edge cases, and request mapping inconsistencies. What stands out is not just the severity of individual CVEs, but the volume and consistency of disclosures within a single month. This reflects both the complexity of the framework and the increasing effectiveness of modern analysis techniques in surfacing edge cases that were previously harder to detect.

Why end-of-support frameworks increase exposure

Framework lifecycle matters.

When a framework reaches end of support (EOS):

• Newly discovered vulnerabilities are not patched upstream.
• Fixes are not backported.
• Exposure increases over time.

In a slower discovery environment, this could be managed. In a faster one, the gap widens more quickly.

AI does not introduce new categories of vulnerabilities, but it accelerates how quickly they are found and understood.

What development teams should consider

The fundamentals of secure development do not change, but the pace does.

Teams should consider:

• Maintaining a clear inventory of open source dependencies.
• Identifying unsupported frameworks and components early.
• Prioritizing migration where possible.
• Ensuring vulnerability coverage where migration timelines are extended.

These practices become more important as discovery cycles shorten.

Extending support for critical frameworks

For organizations that cannot immediately migrate, extended support models for libraries that are end of support (EOS) will help reduce exposure.

IBM Library Support for Open Source provides continued CVE remediation for frameworks such as Spring (and others) beyond their upstream end of life.

It allows teams to maintain security coverage while planning longer-term modernisation.

Summary

AI is improving the ability to discover vulnerabilities across open source software. At the same time, many organizations continue to rely on frameworks that are no longer supported upstream. This combination reduces the available response window.

The implications of inaction are clear: Your team’s security posture needs to account not just for the presence of vulnerabilities, but for the speed at which they are discovered and can be exploited.

Learn more

Listen in to a special Security Intelligence podcast where AI and security experts address this question: How do you enjoy the unique benefits of open source AI while managing its very real risks?

Or, read about the Open Source AI Project Governance and Security Baseline, which provides security and governance standards for open source AI projects and is built on OpenSSF principles with AI-specific requirements.