Artificial intelligence is reshaping how security vulnerabilities are discovered and at OpenSSL, we are seeing the impacts first-hand. In 2025, our security address received approximately nine separate reports and enquiries every month and now that number is as high as 70. AI tools can scan source code and flag potential security issues at a scale that once demanded significant time and effort from human experts.

This surge in detection rates is of course positive in many respects because finding vulnerabilities is an integral part of making software more secure. But discovery is only the beginning. Each new report creates work, and ultimately, someone with the right expertise must assess it and decide what happens next.

A flagged issue is not the same as a confirmed vulnerability. Each report still requires an experienced engineer to investigate it, judge the level of risk and, where necessary, build and thoroughly test a fix before deciding how and when it should be disclosed. AI may dramatically increase the volume of issues being discovered, but the pool of skilled people available to handle that workload is not growing at the same rate. For open-source projects, that growing gap between detection and response risks becoming a security problem of its own.

The Growing Gap Between Vulnerability Discovery and Response

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

Critical Software Often Relies on Invisible Support

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

The Human Bottleneck Behind AI-Powered Security

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 organizations 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 Alone Cannot Maintain the Software We Depend On

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 recognizes 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 organizations what standards they should meet. We also need to consider the health of the technology underneath the services we're trying to protect.

Understanding Open-Source Dependencies Are Key to Resilience

There is something businesses can do immediately. Understand your open-source dependencies. If a critical vulnerability appeared tomorrow in a project your organization 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.

Organizations 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 recognizing open source as infrastructure rather than free software that simply appears.

The Future of Cybersecurity Still Depends on People

AI’s ability to analyze software will only become more sophisticated, creating real exciting opportunities that have the potential to make technology significantly more secure. Yet finding more potential flaws is not the same as making software safer. That only happens when skilled people have the time and resources to investigate those findings and take the right action. For all the attention on what AI can do, the real test may be whether we have enough human expertise to keep pace.

How do we make sure the communities responsible for critical open-source infrastructure have the support they need? What responsibility should businesses take for the projects their operations rely on? And how do we cope if AI starts uncovering vulnerabilities faster than people can investigate and fix them?

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