Q&A: What You Need to Know About Open Source Software Risk in 2025
Understanding Open Source Usage in 2025
“I only use a little open source in my project. Should I really be concerned?”
You might be using more open source than you think! Recent data from the 2025 Open Source Security and Risk Analysis (OSSRA) report shows that 97% of commercial codebases contain open source, and on average, 70% of scanned code has open source origins. Even more surprising? The typical application contains 911 open source components.
“What’s this transitive dependency thing I keep hearing I should be concerned about?”
It means that “little bit” of open source you’re using might be bringing along a lot of friends!
Think of transitive dependencies as “friends of friends” in your code. Open source frequently uses other open source. So, when you add an open source component to your project, that component may call on other components to work properly. Those additional components are transitive dependencies.
Our data shows 64% of open source components in applications are transitive dependencies, most near impossible to locate or track without using an automated tool. It’s like ordering a pizza and discovering it comes with three toppings you didn’t know you were getting!
And yes, while you might be pleased with the hard-boiled egg, anchovy, and pineapple toppings, isn’t it better to know about them first? That’s what a software bill of materials (SBOM) is all about. Think of it as a detailed recipe that lists all the ingredients making up an application.
Open Source Security Vulnerabilities and Trends in 2025
“How common are security vulnerabilities in open source?”
Pretty common, unfortunately. About 86% of applications examined in OSSRA 2025 contained vulnerable open source components, and 81% had high or critical-risk vulnerabilities. But here’s the important part: all these vulnerabilities can be fixed by updating to newer versions of the components.
“I use jQuery in my projects. Should I be worried?”
jQuery deserves special attention because it’s a very popular open source component which your software is likely using. And popularity can breed problems. Eight of the top 10 high-risk vulnerabilities we found were in jQuery.
But don’t panic! The key is making sure you’re using an up-to-date version of the component. jQuery isn’t inherently insecure – it’s using outdated versions that can cause problems.
“What types of vulnerabilities should I be most concerned about?”
The top issues we’re seeing are:
● Cross-site scripting (XSS)
● Input validation problems
● Denial of service vulnerabilities
● Prototype pollution
The good news? Many of these can be prevented with proper coding practices on the part of developers and regular updates of the open source you use.
Open Source License Compliance and Legal Risks
“Do I really need to worry about open source licenses if I’m not selling my software?”
Yes! Even if you’re not selling your software, you still need to comply with open source licenses. Think of it like using music in a video – even if you’re not selling the video, you still need to respect copyright laws.
We found that 56% of applications we audited had license conflicts, and 33% had components with no license or custom licenses.
“No license means no problem, right?”
You might think so, but you’d be wrong. In the U.S. and other jurisdictions software is protected by exclusive copyright by default. That means no one can legally use, copy, distribute, or modify that software without explicit permission from the creator in the form of a license. Without a license, a company does not have that explicit permission to use the component and runs the risk of a costly and time-consuming lawsuit.
“What happens if I mix different open source licenses?”
It depends on the licenses involved. Some licenses play well together, while others conflict. The most important thing is to understand what you’re using. For example, mixing code with permissive licenses (like MIT) with restrictive licenses (like GPL) can create obligations you might not want to take on.
Why Updating Open Source Components Matters
“My open source components are working fine. Why should I update them?”
Here’s a scary stat: 90% of the applications audited for OSSRA 2025 contain open source components that are more than 10 versions behind the current release. While your components might work fine today, outdated versions often have known vulnerabilities that hackers can exploit. Plus, 79% of applications we audited contain components with no development activity in the last 24 months – meaning no one is watching for or fixing security issues.
“How can I keep track of all these open source components and their updates?”
Manual tracking isn’t practical anymore – there’s simply too much to monitor. That’s why tools like Software Composition Analysis (SCA) and Software Bills of Materials (SBOMs) are becoming essential. They’re like having a smart inventory system for your code.
Best Practices for Managing Open Source Software Risk
“What should I do right now to reduce my open source risk?”
Here are the key steps:
- Know what’s in your code (use SCA tools to generate an SBOM)
- Keep your components updated, especially security patches
- Pay attention to license compliance
- Monitor your components for vulnerabilities
- Implement secure coding practices, especially around input validation
“How do I convince my management to care about open source risk?”
Focus on business impact. Share these stats:
● 81% of codebases have high-risk vulnerabilities
● Security breaches can cost millions in damages
● License compliance issues can affect M&A deals
● Outdated components can lead to technical debt and security risks
The Future of Open Source Software Security
“Is open source safe to use?”
Absolutely! Open source software powers much of our digital world and offers tremendous benefits. The key is to use it responsibly. Think of it like driving a car – it’s safest when you follow the rules of the road, perform regular maintenance, and stay alert to potential issues.
“Where can I learn more about managing open source risk?”
Great question! Start by looking at the 2025 OSSRA report, which details a variety of tips on open source management best practices. From a practical aspect, you should
● Follow project websites and repositories to stay up to date on the open source you’re using
● Use package managers and version tracking tools
● Implement SCA tools to analyze and manage the open source you’re using. If you’re developing open source yourself, use security (SAST) and dynamic (DAST) analysis tools to catch coding flaws before potentially vulnerable open source is deployed.
● Join open source security communities
● Follow security advisories for components you use.
For example, Black Duck Security Advisories (BDSAs) are an exclusive vulnerability data feed. While providing more timely and detailed vulnerability insights, including severity, impact and exploitability metrics, BDSAs also provide actionable remediation guidance to save you time by providing details on fixed versions, patch information, exploits, and workarounds where available.
Remember: Open source isn’t inherently risky – it’s how we manage it that matters. Stay informed, stay updated, and use the tools available to help you manage your open source effectively!
*** This is a Security Bloggers Network syndicated blog from Blog authored by Fred Bals. Read the original post at: https://www.blackduck.com/blog/qa-open-source-software-risk-2025.html
