AI is finding vulnerabilities faster. Who is funding the people expected to fix them?

Matt Caswell at the OpenSSL Foundation argues that AI is making vulnerability discovery cheaper and faster, but it isn’t creating more experienced engineers to investigate findings and develop fixes

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.

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.

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 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.

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 AI and cyber-security 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 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.

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 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.

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.

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?

These are exactly the kinds of questions the open-source community needs to together, and they will be part of the wider conversation at OpenSSL Conference 2026 in Prague this October.

Matt Caswell is Executive Director at the OpenSSL Foundation and Principal Software Engineer

Main image courtesy of iStockPhoto.com and sankai

Winston House, 3rd Floor, Units 306-309, 2-4 Dollis park, London, N3 1HF

[email protected]