Open source software (OSS) and components are everywhere in enterprise environments. According to some estimates, more than 90% of today's software relies on open-source components. The widespread success of open source is for good reason, as OSS offers cost efficiency and access to pipelines of innovation. However, significant security challenges are associated with managing the impact OSS has on software security, and it's just as accurate in environments that manage operational technology and industrial control systems (OT/ICS).
"Using open source software is a massive benefit to any business," says Jeff Williams, co-founder and CTO at Contrast Security. "However, it comes with some responsibility. You must establish strong processes to keep it up-to-date and detect and respond to new CVEs as they emerge."
Williams recalls an OT environment he once worked with where, despite OT systems being deployed across power lines in very remote areas, they had many versions of their monitoring equipment and no deployment records, and accessing OT devices required climbing poles without any way to update the software on those devices. "OT/ICS environments are often difficult to monitor, update, and perform critical tasks," he says.
While proprietary software has its own set of challenges around the risks of exposing vulnerabilities, OSS has its own challenges stemming from its openness. Like all software, once OSS flaws are publicly visible, they're prime targets for widespread exploitation and also vulnerable to bad actors corrupting the OSS supply chain. A good example is the backdoor in the popular XZ Utils data compression library that enabled unauthorized users to gain administrative access to systems.
In that incident, malicious code was inserted into the utility software by an individual who took over the maintenance of the open-source project over the course of years and managed to slip a backdoor into a version release they signed.
When such attacks happen, enterprises often lack visibility into all the open-source software they use within their environments, let alone the open-source components within their commercial software. So when events such as the XZ Utils backdoor happen, they may not be able to respond adequately.
A 2025 Anchore study found 68% are unable to create a comprehensive software bill of materials (SBOM) for their applications, while many developers rely upon outdated OSS versions due to compatibility fears, perpetuating exposure to known CVEs.
This is why organizations need to understand the vulnerabilities within their open source components and applications, including vulnerabilities within COTS that include open source.
Williams says at times SBOMs are not as usable. There have been challenges with machine readability, standards compatibility, scalability for large enterprises, or whether SBOMs are kept current. And even if enterprises did have accurate SBOMs, most CVEs are not exploitable in their production environments. Williams says organizations need to know the exact versions of their OSS components and a way to measure the actual risk any associated vulnerabilities create for the organization.
Adam Ennamli, chief risk and security officer at General Bank of Canada, shares additional ideas on the relevant capabilities enterprises need, and he says any open-source security strategy needs to be multi-faceted across their COTS applications and those applications developed in-house.
"Organizations should look at implementing continuous software composition analysis in their CI/CD pipelines to detect vulnerabilities, maintain internal mirrors of verified repositories, and establish risk-based controls that vary by system criticality. This must be paired with a comprehensive vendor management program requiring software bills of materials (SBOMs) and specific contractual requirements around vulnerability remediation and prohibited components," Ennamili adds.
Such measures advocated by Williams and Ennamli are cornerstones of managing enterprise security risks associated with their OSS deployments, OSS components in COTS, and their in-house developed software that contains OSS components. Such governance encompasses policies for software selection, approval, auditing, distribution, and compliance with OSS licensing terms.
"Like most of security, a risk-based approach is best. Start with the most critical issues and start making updates," Williams advises, adding that while some vulnerabilities will require updates, others may need additional compensating controls, such as ways to detect and respond to attacks targeting the vulnerability in real-time.
"Long term, consider establishing a policy that encourages keeping OSS up-to-date, rather than letting it slowly age. This will make responding to new CVEs much easier," he adds.
Ennamli explains that establishing policies and getting some security defenses in place is just the start and that these tools must be used and policies enforced. "The policy should start with a clear approved license list based on risk tolerance, define criteria for when open source can be used versus building in-house, taking into account factors like project sustainability and security track record, and establish processes for contributing back to open source projects. The policy needs to be backed by tooling that makes secure open source usage the path of least resistance for developers while maintaining appropriate controls through automation," Ennamli says.
Whenever implementing new security controls and policies, one of the biggest challenges is balancing flexibility with power, and overly restrictive policies can slow innovation. In contrast, inadequate security and policy governance will expose enterprises to increased legal/licensing, operational, and security risks. Still, according to OpenLogic, only half of organizations have OSS security and compliance policies.
That's not enough with the increased reliance on OSS in commercial software and elsewhere in enterprises. At the very least, enterprises need to implement appropriate OSS governance policies, track what open source components are in use throughout their organization, which components are currently vulnerable, and if they should be patched or other compensating controls put into place. "A wide variety of tools, including free ones, can inventory OSS and help enterprises rate their risk. And some tools can digest this information and create prioritized dashboards," says Williams. The catch: enterprises must actually create their OSS policies and use the tools to enforce them.
George V. Hulme is an award-winning journalist and internationally recognized information security and business technology writer. He has covered business, technology, and IT security topics for more than 20 years. His work has appeared in CSOOnline, ComputerWorld, InformationWeek, Security Boulevard, and dozens of other technology publications. He is also a founding editor at DevOps.com.
