Artificial intelligence is changing vulnerability discovery. At OpenSSL, we are seeing that change first-hand. A year ago, our security address received around nine separate reports and enquiries a month. It now receives around 70. AI tools can examine source code and identify potential security issues at a scale that would previously have required significant human effort.
In many ways, that’s positive. Finding vulnerabilities is an essential part of making software more secure. But there is another side to this that deserves much more attention. Every vulnerability report has to go somewhere.
Someone needs to assess whether the issue is genuine. If it is, engineers need to understand its severity, develop a fix, test that fix and manage disclosure appropriately. AI can increase the speed at which potential problems are discovered. It does not automatically increase the number of experienced engineers available to deal with them. That imbalance could become a serious issue for open-source security.
Finding a vulnerability is only the beginning
There is an understandable tendency to treat vulnerability discovery as the success story. An AI system finds something humans missed. That makes a compelling headline. But identifying a potential weakness and resolving it are very different tasks.
A report might represent a serious vulnerability. It might be something already understood. It might be technically correct but have limited real-world security impact. It might simply be wrong. Working out which of those is true requires expertise. Then, if there is a genuine vulnerability, somebody has to fix it.
Over the past 12 months we received a little over 400 vulnerability reports. 43 resulted in a published CVE. Roughly one in ten. The other nine still had to be read, understood, reproduced where we could, and answered. A report that turns out not to be a vulnerability consumes much the same expert attention as one that is — sometimes more, because establishing that something cannot be exploited is often harder than confirming that it can.
For a commercial software company with large security teams, increasing the number of reports may be manageable. For an open-source project with limited resources, a sudden increase can create a very different problem. The technology for finding possible vulnerabilities is becoming cheaper and more accessible. However, the expertise required to investigate them is not.
Businesses depend on projects they may barely know exist
This connects to a much older problem with open-source. Most technology companies know they use open-source software. What is less clear is whether they understand exactly which projects their products and services depend upon. That distinction matters.
Open-source components can sit deep inside software stacks. They work quietly, so organisations may have little reason to think about the people maintaining them. Then something goes wrong.
Heartbleed was an important moment for OpenSSL because it exposed the gap between the importance of open-source infrastructure and the resources available to support it. The industry responded. Investment increased and organisations began paying much more attention to the sustainability of critical open-source projects.
My concern is that some of those lessons are beginning to fade, and AI could make the consequences of that particularly visible.
AI changes the economics of vulnerability discovery
There is an asymmetry developing. The cost of searching code for potential security weaknesses is falling. The volume of reports can therefore rise significantly. But the other side of the process remains stubbornly human. Experienced engineers still need to understand the code. They need to judge whether the finding matters and decide how it should be fixed without creating another problem somewhere else.
Those people are a scarce resource. This means the question organisations should be asking about AI and cybersecurity isn’t only: “What can AI find?” It should also be: “Who is going to deal with everything it finds?”
For open-source projects, that leads directly to questions about sustainable funding. If businesses depend on a project as part of their critical infrastructure, supporting the health of that project should be viewed as part of resilience, not philanthropy.
Regulation only gets us part of the way
Governments are understandably looking at how regulation can improve cyber resilience. That matters, but regulation cannot maintain software. Europe provides some interesting examples of a different approach. OpenSSL Foundation has received support from Germany’s Sovereign Tech Agency, which invests directly in open digital infrastructure.
That recognises something important: if technology is critical to the functioning of the digital economy, somebody needs to invest in the people maintaining it. I’d like to see more of that conversation in the UK. Cyber resilience isn’t only about telling organisations what standards they should meet. We also need to consider the health of the technology underneath the services we’re trying to protect.
Organisations need to know what they depend on
There is something businesses can do immediately. Understand your open-source dependencies. If a critical vulnerability appeared tomorrow in a project your organisation relies on, could you identify where that software was being used?
Would you know which products and services were affected? Would you know who maintains the project? And would you have any relationship with the community responsible for fixing it? If the answer is no that is a resilience gap.
Organisations don’t necessarily need to contribute code themselves. There are other ways to support projects, including funding, engineering resources and participation in the communities maintaining the technology they depend upon. The important shift is recognising open source as infrastructure rather than free software that simply appears.
We need to talk about the people behind the code
AI will continue getting better at analysing software. That’s exciting, and it has the potential to make technology significantly more secure. But more findings do not automatically produce more security. The benefit comes when we have the expertise and resources to act on what those tools discover. That makes this a human question as much as a technology question.
How do we sustain the communities maintaining critical open-source infrastructure? How should businesses support the projects they depend on? What happens when vulnerability discovery accelerates faster than our ability to respond?
