Key Findings From the Black Duck 2025 Open Source Security and Risk Analysis Report
Securing your software supply chain begins with understanding what’s in your code — and your vendors’ code
The tenth annual OSSRA report audited 965 commercial codebases. The headline numbers should reshape how you think about software risk.
Nearly every application runs on open source code - and most of that code carries known vulnerabilities the business never chose and often cannot see.
The Black Duck OSSRA report is now in its tenth year, and the 2025 edition is built on the audit team's review of 1,658 analyses covering 965 commercial codebases during 2024. It is one of the clearest yearly looks at what is actually inside modern software. For any business that buys, builds, or depends on software - which is every business - the findings matter, because the risk does not stop at your own developers.
How Deep Open Source Runs
Open source is not a corner of modern software - it is most of it.
The report found open source in 97% of codebases, averaging 911 components each, with 70% of all scanned code originating in open source.
The scale has grown fast. The number of open source files in a typical application has tripled in four years - from 5,386 in 2020 to 16,082 in 2024. That is thousands of moving parts inside a single app, each one a component someone else maintains, updates, or abandons.
What the Report Found on Security
The vulnerabilities are widespread, severe, and often years old.
86% of codebases carried a known vulnerability and 81% carried a high- or critical-risk one - and most sat in outdated, unmaintained components.
- Severity is the norm, not the exception. 81% of codebases contained high- or critical-risk vulnerabilities; one codebase held 3,548 unique flaws, with a mean of 154 per codebase.
- Old, familiar libraries dominate. Eight of the ten most common high-risk vulnerabilities were found in jQuery - a reminder that the biggest risks are often well-known components no one updated.
- The same weaknesses repeat. Improper input validation (CWE-20) was tied to 71% of open source vulnerabilities found, followed by uncontrolled resource consumption (70%) and exposure of sensitive information (60%).
- Nobody is patching. 90% of codebases ran components more than four years out of date, and 91% included components with no development activity in the past two years.
Risk also varies sharply by industry. Even the lowest-risk sector in the report - Energy and Clean Tech - still had 60% of its codebases carrying high-risk vulnerabilities.
The Hidden Risk: Transitive Dependencies
The most dangerous components are the ones nobody chose.
Transitive dependencies made up 64% of all components found and introduced nearly half of the high- and critical-risk vulnerabilities.
A direct dependency is a component your team deliberately added. A transitive dependency is one pulled in automatically because a direct component needs it - and then another, and another, several layers deep. They rarely show up in a basic code review, which is exactly what makes them dangerous.
Transitive components also drove roughly 30% of the report's license conflicts. And licensing is its own exposure: 56% of codebases had a license conflict, and 33% contained components with missing or customized license terms. Even permissive licenses like MIT - found in 92% of codebases - carry attribution requirements that must be met.
When 97% of software runs on open source and two-thirds of it comes in through the back door as transitive dependencies, you cannot secure what you cannot see. The first job is visibility - knowing what is actually inside the software you and your vendors depend on.
Your Software Supply Chain Is an Attack Surface
CinchOps helps you see and manage open source risk across your own applications and your vendor ecosystem - software bills of materials, vulnerability monitoring, and vendor risk assessment - as part of our cybersecurity and managed IT services.
Explore CinchOps cybersecurity →How CinchOps Helps With Vendor and Supply-Chain Risk
CinchOps is a Katy, Texas managed IT services provider serving businesses across the Houston metro, extending your security beyond your own code to the vendors you depend on.
- Vendor code visibility. Help requesting and reviewing software bills of materials (SBOMs) so you know what open source lives in the products you buy.
- Third-party risk framework. Assessment questionnaires that check how vendors handle vulnerabilities, license compliance, and component maintenance.
- Due diligence for deals. Open source risk review for acquisitions and partnerships, where hidden flaws can affect real value.
- Continuous monitoring. Alerting when new critical vulnerabilities emerge in the third-party software you rely on.
- Supply-chain security program. Clear vendor requirements for open source management, vulnerability disclosure, and patching timelines.
When 97% of code contains open source, visibility across your whole supply chain is the difference between managed risk and a blind spot. Contact CinchOps to get started.
Frequently Asked Questions
What is the Black Duck OSSRA report?
The Open Source Security and Risk Analysis (OSSRA) report is an annual study from Black Duck. The 2025 edition, its tenth, is based on the audit team's review of 1,658 analyses covering 965 commercial codebases across 16 industries during 2024 - offering a data-backed look at how open source is used and where the risk sits.
What is a transitive dependency, and why does it matter?
A transitive dependency is an open source component your software pulls in automatically because another component requires it - not one your team chose directly. The report found 64% of all components were transitive, and they introduced nearly half of the high- and critical-risk vulnerabilities. Because they are often invisible to basic reviews, they are easy to miss and hard to patch.
My business does not build software. Does this still apply to me?
Yes. Nearly every application you buy or subscribe to is built from open source components - so the vulnerabilities in that code become your exposure. That is why reviewing your vendors' software and their handling of open source matters as much as securing your own systems.
What is an SBOM?
A software bill of materials (SBOM) is an itemized list of the components inside a piece of software, including its open source parts. Requesting SBOMs from vendors gives you the visibility needed to know when a newly discovered vulnerability affects a product you use.
How can a small business start managing open source risk?
Begin with visibility: inventory the software and vendors you depend on, ask vendors for SBOMs, and set up monitoring for new critical vulnerabilities. A managed IT provider can build a vendor risk process and keep those checks running so old or hidden components do not become an open door.
