By Matt Caswell, Executive Director, OpenSSL Foundation and Principal Software Engineer
Most businesses would not expect critical infrastructure to maintain itself. If a company relies on a data center, cloud provider or network connection, somebody owns the relationship. There is a contract, a budget and an understanding of what happens when something goes wrong.
Open source often sits in a very different category. Software that is critical to a company’s products and services can be maintained by a community that the company has little or no relationship with. The technology may sit several layers down in its software stack. It works, so nobody has much reason to think about how it is maintained.
That creates an unusual situation. Businesses can become heavily dependent on technology without ever asking what responsibility comes with that dependence. As artificial intelligence changes how quickly software can be examined for security weaknesses, I think that question is becoming harder to ignore.
Consumption is easy, responsibility is not
Open source has been enormously successful because organizations can build on software developed by others. They can inspect it, use it and contribute improvements back. But using open source and sustaining open source are not the same thing.
For businesses, the first challenge is knowing what they actually depend on. Ask a relatively simple question: which open-source projects would cause a serious problem for your organization if a major vulnerability were discovered tomorrow?
For some companies, answering that may be surprisingly difficult. Knowing that your organization ‘uses open source’ isn’t enough. You need to understand which components are present in your products and services, where they are deployed, and how important they are to the systems your customers rely upon.
That knowledge changes the relationship. A project stops being an anonymous piece of free software somewhere in the technology stack. It becomes part of the infrastructure supporting the business.
AI is putting that relationship under pressure
There is another reason businesses should think about this now. AI is making it much easier to examine source code and identify potential vulnerabilities. At OpenSSL, we are seeing the effect first-hand. A year ago, our security address received around nine separate reports and enquiries a month. It now receives around 70.
That increase creates an interesting imbalance. The tools used to search for possible weaknesses can scale quickly. The experienced engineering work required after a report arrives does not scale in the same way.
Over the past 12 months, we received a little over 400 vulnerability reports. Of those, 43 resulted in a published CVE, roughly one in ten. The others still had to be read, understood, reproduced where possible and answered.
A report that turns out not to be a vulnerability can consume as much expert attention as one that is. Sometimes it can require even more work because establishing that something cannot be exploited can be harder than confirming that it can.
This matters because finding more potential vulnerabilities does not necessarily mean software becomes more secure at the same rate. The volume of findings can increase quickly, but the engineering expertise needed to assess and respond to them remains a finite resource.
For businesses that rely on open source infrastructure, that should change how they think about AI-assisted vulnerability discovery. Finding more potential weaknesses is valuable, but only if the people maintaining the software have the capacity to work through what is being reported.
Support should follow dependence
There isn’t a single model for how businesses should support open source, and writing a check isn’t the only answer. Some organizations may be able to contribute engineering expertise. Others can fund projects directly or support organizations that sustain important open source infrastructure. Companies can also participate in project communities and develop relationships with the people responsible for software they rely upon.
What matters is making the connection between dependency and support. The more important a project is to your business, the stronger the case for understanding how that project is maintained and what your organization can do to help sustain it. That requires open source to become part of normal business conversations about technology risk.
If a critical supplier represented a significant operational dependency, organizations would assess that relationship. They would want to understand whether the supplier could continue delivering the service they rely on. Critical open source software deserves similar attention, even though the relationship looks very different.
Procurement shouldn’t be the end of the conversation
This also raises questions about how organizations assess technology. Software supply chain discussions tend to concentrate on what is inside a product and whether components contain known vulnerabilities. Those are important questions, but they don’t tell the whole story.
Organizations should also be asking about the health of the projects underneath their technology. Who maintains a critical component? Is the project actively supported? Does it have the engineering capacity to respond when security issues are reported? Is your organization simply consuming that work, or does it have some form of relationship with the community behind it?
These aren’t questions that need to be answered for every small open source component a business encounters. They matter most where dependence is significant. The aim isn’t to turn every company into an open source maintainer. It is to stop treating critical open source infrastructure as though its continued availability and security are automatic.
This is ultimately a resilience question
Businesses have benefited enormously from open source, including OpenSSL, for decades. That model works because people continue to contribute expertise and time to maintaining the software. AI could make some aspects of security work much more efficiently. It may help us spot problems that would otherwise have remained hidden, and that is valuable.
But it could also expose a weakness in how we think about the resources behind critical software. If vulnerability discovery becomes much easier while the supply of experienced people capable of assessing and fixing those vulnerabilities remains constrained, organizations will need to think much more carefully about where responsibility sits.
For business leaders, the starting point is straightforward: identify the open source infrastructure your organization cannot afford to lose, then understand the people and projects keeping it working.
Once you know what your business truly depends on, the question of whether you should help sustain it becomes much harder to avoid. These questions around the future of open-source security, sustainability and the changing demands placed on maintainers will also form part of the wider discussion at the OpenSSL Conference 2026 in Prague this October.
##
ABOUT THE AUTHOR
Matt Caswell is the Executive Director of the OpenSSL Foundation where he is responsible for ensuring the delivery of the OpenSSL Mission. He also has expertise as a software developer, and is a subject matter expert in OpenSSL’s SSL/TLS implementation. Matt has been a member of the OpenSSL Library development team for over 10 years and has implemented TLSv1.3 in OpenSSL as well as many other high profile features and capabilities.
