Open source in the enterprise: why it matters, and the risks hiding in your codebase
An audit of 965 commercial codebases found vulnerable open source in 86% of them. Open source isn't the problem. Not knowing what you're running is.
Open source software is code whose license lets anyone use, study, change and share it. The Open Source Initiative keeps the formal definition, which sets ten conditions a license must meet, including free redistribution, access to source code, permission to create derived works, and no discrimination against people, groups or fields of use.
Almost every modern application is built on it. Web frameworks, databases, encryption libraries and the operating systems underneath cloud services are mostly open source, and the commercial software you buy is full of it too.
What a codebase audit finds
Black Duck, a software security company, audits commercial codebases every year, often during mergers and acquisitions. Its 2025 report, covering 965 codebases across 16 industries in 2024, found:
| Finding | Share of codebases |
|---|---|
| Contained open source with known vulnerabilities | 86% |
| Contained high- or critical-risk vulnerabilities | 81% |
| Contained open source more than four years out of date | 90% |
| Had open source license conflicts | 56% |
| Contained open source with no license or a customized license | 33% |
The average application contained more than 16,000 open source files in 2024, up from more than 5,300 in 2020. And 77% of dependencies were found through package manager scanning, which means they were pulled in automatically rather than chosen by a developer.
Why it matters to IT buyers
Those numbers describe software companies sell, not just software they build. Three practical consequences follow.
First, you can't patch what you can't see. When a flaw like Log4Shell appears, the companies that respond fastest are the ones that already know which applications contain the affected library.
Second, outdated components are the norm. Old open source isn't always vulnerable, but it means fixes take longer, because upgrading across several major versions is harder than applying a patch.
Third, license problems are real business risk. Using a component under a license whose terms you don't meet can affect what you are allowed to sell or ship.
What good practice looks like
Ask vendors for a software bill of materials (SBOM), a list of the components in their product. Run software composition analysis on your own code, so new vulnerabilities in dependencies are flagged automatically. Set a policy on which licenses are acceptable in what context. And give someone the job of keeping core dependencies up to date, rather than only reacting to emergencies.
What IT teams should do
- Add an SBOM request to your software procurement checklist.
- Turn on dependency scanning in your code repositories.
- Agree an approved license list with legal, covering internal use and products you ship.
- Pick your five most critical applications and check how out of date their dependencies are.