Open source dependencies leave apps dangerously exposed

Secure.com has published research arguing that open source software dependencies remain a major source of security and compliance exposure for application teams. Most codebases contain known vulnerabilities, and many issues go unpatched for long periods.

Its analysis found that 84% of codebases built with open source components contained at least one known security vulnerability. It put the average number of critical or high-severity vulnerabilities linked to open source dependencies at 13 per application each year.

Founder and CEO Uzair Gadit said organisations are often slow to address problems even when fixes are available. "The average application carries 13 critical or high-severity vulnerabilities per year from open source dependencies alone. Over 80% of vulnerable dependencies go unpatched for more than a year, even when fixes are available," he said.

Hidden dependencies

A core theme of the analysis is the risk posed by transitive dependencies-components introduced indirectly through other libraries. They can significantly expand the number of packages in a build and reduce visibility for development teams.

Gadit said this layer often sits outside normal review processes. "Transitive dependencies (dependencies of dependencies) are invisible to most teams but carry the same level of risk, and license violations can be just as damaging as security flaws, exposing your company to legal and compliance risk," he said.

The report highlighted the scale of modern dependency chains, citing an average Java application with around 150 direct and transitive dependencies. It also cited a Node.js example in which a 12-package application could result in 345 installed packages once transitive dependencies are included.

Attack methods

The analysis points to several attack patterns that target software supply chains through open source ecosystems. These include typosquatting, which uses look-alike package names, and dependency confusion, which relies on package naming to trick build systems. It also flagged the risk of backdoored packages and compromised maintainer accounts.

It referenced Log4Shell, the widely exploited Log4j flaw, as an example of how a single vulnerability in a popular library can cascade across thousands of organisations. It also cited the 2024 XZ Utils backdoor as a case in which a trusted contributor introduced malicious code.

Secure.com said the average codebase now contains 581 known open source vulnerabilities-double the count from a year earlier. The analysis argues that many organisations lack the tooling and processes needed to reduce the backlog quickly enough.

Regulatory focus

The research also linked dependency management to rising regulatory expectations, citing the EU Cyber Resilience Act as an example. The rules require organisations to maintain a software bill of materials (SBOM) and report vulnerabilities within set timelines.

Unfixed vulnerabilities tend to compound over time, it said, with backlogs growing unless teams add controls to prevent new high-risk components from entering production systems.

Licensing exposure

Beyond security defects, the analysis frames software licensing as a material source of risk in open source adoption. It distinguishes permissive licences such as MIT and Apache from more restrictive licences, including GPL and AGPL.

Misusing a restrictive licence in a proprietary product could lead to legal action, contract disputes, or requirements to disclose source code, the report said. It argues that licence compliance reviews should happen before packages are adopted, not after a product ships.

Suggested practices

Secure.com outlined practices it said could reduce risk without a full process overhaul. It recommended starting small with one team and one codebase, because initial scans often uncover a larger backlog than expected.

It also suggested defining approved and prohibited licence types for different classes of software, with policies aligned to deployment models and legal risk appetite. Another recommendation focused on quality gates that block new high-severity issues from being merged, with controls tightening over time as teams build remediation routines.

Tracking was positioned as a baseline requirement, with the SBOM described as a foundation for inventory and measurement. Secure.com said projects using an SBOM fixed vulnerabilities an average of 264 days faster than those that did not.

Product positioning

Secure.com said its Digital Security Teammate product addresses open source dependency risk through build-time scanning, consolidating results from multiple software composition analysis tools, and automated gating in CI/CD workflows. It also described routing remediation through tools such as Slack, Teams, and Jira, with actions logged for audit purposes.

In closing comments, Gadit said organisations must choose between early intervention and post-incident response.

"The question isn't whether to manage open source risk. It's whether you'll do it proactively (with the right tools and processes) or reactively after a breach forces your hand," he said.