OpenSSL: Open-Source Security and the Explosion of AI Bugs

A running theme in the technology sector today is paying off the technical debt that has been piling up since the advent of code.

OpenSSL is no exception to the rule, having closed more than 600 long-standing code issues in the past year, with the help of the Sovereign Tech Agency – a German public-interest organisation that helps maintain open-source infrastructure.

The developer interest in the software is ever growing, with the number of open pull requests in OpenSSL touching 558 at the start of October 2026, up from 309 requests same time last year.

But the truth, as Matt Caswell , Executive Director of the OpenSSL Foundation , points out in his opening talk on Day three of the OpenSSL Conference in Prague, is that security reports have now become “cheap to write” but they are still expensive “to assess”.

He calls the technology a “fantastic tool”. “AI can increase the speed at which potential problems are discovered,” Matt says.

The issue is that it “does not automatically increase the number of experienced engineers available to deal with them”.

This is a big problem, particularly in community-maintained, open-source software that is so widely deployed across global banks, cloud providers, governments, telecom networks and critical-infrastructure operators.

Not all of the AI-discovered bugs escalate into actual vulnerabilities with a CVE (common vulnerabilities and exposures) assigned, but they still have to be assessed by maintainers, who are getting increasing security reports to go through, that often include duplicate issues.

Similar thoughts were echoed by Anton Arapov , Director, Treasurer and Secretary at the OpenSSL Corporation , who tells Cyber Magazine that though AI makes coding fast, it has “not made our job easy”.

The solution requires recognising the fact that “critical open source is infrastructure and needs funding as infrastructure,” according to Matt.

OpenSSL security response process and why CVSS score may be ‘nonsense’

With AI raising the number of vulnerabilities coming in, community and open-source supported projects are taking the heat.

This is where OpenSSL’s Security Response Team (SRT) comes in. The team consists mostly of people with committer status who have to work around what is called a threat model, which sets the baseline for security issues the team deals with.

In his session Tomáš Mráz , Chief Technology Officer and Member of the Board of Directors of the OpenSSL Foundation, explains this threat model.

Vulnerabilities where an attacker can have RCE (remote code execution), DoS (denial of service) or cause a data leak in an otherwise working application by supplying untrusted input are things that require attention.

Here, private keys and configuration are considered to be generally trusted.

The threat model includes issues where the legitimate behaviour of the application causes encrypted or authenticated data to become unencrypted or unauthenticated.

Anything with missing context, incorrect authorisation checks or even if timing side-channels are exploitable, all come under this threat model.

Issues like physical fault injection, API misuse, private keys supplied by attackers etc. sit outside the scope.

Tomáš is quick to note that just because the bugs come in, it does not necessarily mean they are going to be exploited.

Sometimes the issues are “extremely unlikely application scenarios” and without any real-world exploitations and remain so.

In its approach to remediation, OpenSSL does not assign CVSS (common vulnerability scoring system) score to assess severity.

For good reason too, as Tomáš points to an example where an empty ciphertext is passed to an EVP_Cipher – which is an API that is documented as “dangerous and not to be used”.

Yet the CVSS scoring for this came up as 9.1 Critical for what Tomáš confirms was an “extremely unlikely configuration”.

He jokes that the scoring implies “everybody should update” though “nobody is affected”.

Tomáš reasons that the CVSS score is there for “nonsense” to the team.

AI slop in reported vulnerabilities: is the embargo process obsolete?

OpenSSL started receiving AI reports in 2024, most of which Tomáš says was “AI slop”.

It was in the second half of 2025 that quality security reports started coming in, and in 2026, he says “everything exploded”.

This increase was still quite focussed in the low and moderate range of issues and not all of these bugs translate into actual exploitable vulnerabilities.

There is still a challenge of dealing with increased reporting even if they are duplicates, because “everything needs to be investigated,” he says.

A result of using AI to find bugs is that embargoes could now be obsolete.

The system of embargo is where open-source vulnerabilities are kept private while developers prepare fixes for them.

It was created to give the companies time to fix major issues before attackers can take advantage of them when publicly disclosed without being patched.

The question that Tomáš raises is: “If we get three duplicate reports of the same issue, is it really secret?”

Will the number of bugs go down?

An audience member posed this very important question to Matt, to which he responded: “We hope so.”

Matt explains that a lot of the vulnerabilities currently being reported are of low severity. “AIs are looking at the deep corners of the codebase that humans are not looking at and finding lots of stuff.”

The hope is that eventually these tools would explore and clean out these “deep, dark corners” to have the numbers go back to normal.

Anton Arapov Director, Treasurer & Secretary

Director, Treasurer & Secretary

Matt Caswell Executive Director

Tomáš Mráz Chief Technology Officer

Chief Technology Officer

Top 10: Cloud Security Companies Cloud Security

OpenSSL Conference: AI, Quantum and the Future of Encryption Cyber Security

Cryptography Legend Tim Hudson on Software Security Operational Security

Top 10: Machine Learning Threat Detection Companies Cyber Security