Executive Summary
The security community has incorrectly framed open source software as inherently risky, when the actual vulnerability lies in organizational blindness to software dependencies. Open source components power over 90% of modern applications, yet most organizations cannot answer basic questions: What open source libraries are we using? Which versions? What vulnerabilities exist in them? What dependencies do those libraries have? This dependency blindness creates exploitable gaps that attackers systematically target. The problem is not that open source code is less secure than proprietary alternatives, but that organizations consume open source without inventory, monitoring, or lifecycle management. High-profile incidents like Log4Shell exposed not an open source problem, but a dependency visibility problem. Organizations discovered critical vulnerabilities in libraries they did not know they were using, nested several layers deep in their dependency trees. The solution requires treating open source dependencies as managed assets: maintaining software bill of materials (SBOM), implementing automated vulnerability scanning, establishing update and patching processes, and understanding transitive dependencies. Read on to understand why blaming open source misses the point and what dependency visibility actually requires.
In December 2021, the Log4Shell vulnerability created global panic. Organizations scrambled to identify whether they used Log4j, a ubiquitous Java logging library. Most could not answer that question quickly. Some discovered they were vulnerable through components they did not know existed in their applications.
The incident sparked renewed criticism of open source security. That criticism misses the fundamental issue. The problem was not that Log4j was open source. The problem was that organizations had no visibility into what software components they actually used.
After three decades building identity and access management systems—many incorporating open source components – I can state definitively: open source is not your security problem. Your inability to see what you depend on is the problem.
The Dependency Blindness Reality
Ask your development and operations teams these questions:
What open source libraries does our customer portal use? Most teams can name the major frameworks. Spring, React, Node.js. The obvious components.
What dependencies do those frameworks have? Silence. Nobody tracks this systematically.
How many total open source components are in our production environment? Wild guesses follow. The actual number is typically 5-10x higher than estimates.
Which versions are we running? “Whatever the package manager installed” is the most honest answer you will get.
Do any of these components have known vulnerabilities? “We would need to check” means they have not checked.
This is dependency blindness. Organizations consume hundreds of open source components without inventory, monitoring, or lifecycle management. Then they blame open source when vulnerabilities emerge in software they did not know they were using.
How Modern Software Actually Works
Software development has fundamentally changed. Developers no longer write every line of code in an application. They assemble applications from components: frameworks, libraries, modules, packages.
A typical modern web application includes:
- A frontend framework with 50-100 dependencies
- A backend framework with 100-200 dependencies
- Database drivers, authentication libraries, logging frameworks
- API clients, data validation libraries, utility packages
- Build tools, testing frameworks, deployment scripts
Each of these has its own dependencies. Those dependencies have dependencies. The transitive dependency tree explodes exponentially.
A “simple” Node.js application can easily incorporate 500-1,000 open source packages. Your development team wrote 10,000 lines of code. The application actually contains 500,000 lines of code when dependencies are included.
This is not reckless behavior. This is modern software development. Reusing proven components is more secure and efficient than rewriting functionality that thousands of other developers have already implemented and tested.
The problem emerges when organizations treat these dependencies as invisible. They manage the code they write but ignore the code they consume.
The False Dichotomy of Open Source Versus Proprietary
Critics argue that proprietary software is more secure because vendors are accountable for security. This reasoning collapses under examination.
Proprietary software has dependencies too. Commercial products incorporate open source components extensively. That commercial database you license? It includes dozens of open source libraries. Your enterprise software vendor is running the same Node.js packages, Python libraries, and Java frameworks as everyone else.
The difference is not presence or absence of open source dependencies. The difference is visibility.
When you license proprietary software, you have zero visibility into its dependency tree. You trust the vendor to manage those dependencies securely. Sometimes that trust is warranted. Often it is not.
Open source provides the option of visibility. You can inspect dependencies, track versions, monitor vulnerabilities, and update components independently. Most organizations do not exercise this option, but the option exists.
With proprietary software, you have no option. You are entirely dependent on vendor security practices you cannot verify or audit.
The Log4Shell incident affected both open source and proprietary software users. The difference was response time. Organizations with dependency visibility patched quickly. Those without visibility—whether using open source or proprietary software—spent weeks determining exposure.
Why Dependency Blindness Persists
If dependency visibility is this critical, why do organizations lack it? Several factors converge:
Development Speed Pressure
Developers face intense pressure to ship features quickly. Package managers make consuming dependencies effortless: one command installs a library and all its dependencies automatically. Stopping to inventory and assess those dependencies would slow development.
Organizations optimize for speed over visibility. They accept dependency blindness as the cost of rapid development.
Assumed Transitive Security
Development teams assume that if they choose reputable direct dependencies, the entire dependency tree is secure. This assumption is false.
A popular, well-maintained library can depend on an obscure, poorly maintained package that has not been updated in years. Vulnerabilities in that obscure transitive dependency affect your application just as critically as vulnerabilities in your direct dependencies.
Security cannot be assumed transitively. It must be verified at every level.
Tooling Gaps
Until recently, tools for dependency visibility were limited. Package managers tracked dependencies for installation purposes but not for security purposes. Developers had no easy way to answer “what vulnerabilities exist in my dependency tree?”
This has improved significantly with software composition analysis tools, but many organizations have not adopted them or integrated them into development workflows.
Organizational Silos
Development teams manage code. Security teams manage vulnerabilities. Operations teams manage production systems. Nobody owns the dependency inventory.
When Log4Shell emerged, security teams asked development what was vulnerable. Development checked their direct dependencies and said “we don’t use Log4j.” But operations found Log4j in production because it was a transitive dependency of a framework the developers did use.
The gap between these teams created the visibility gap.
What Attackers Know About Your Dependencies
While organizations remain blind to their dependencies, attackers actively map them.
Attackers monitor open source vulnerability disclosures obsessively. When a vulnerability is published, they immediately begin scanning the internet for exposed systems. They know that most organizations cannot quickly determine whether they are vulnerable, creating a window of opportunity.
They also know that transitive dependencies provide easier targets than direct dependencies. Organizations might patch their direct dependencies relatively quickly. Transitive dependencies three or four levels deep often go unpatched for months.
Attackers specifically target popular libraries with broad dependency trees. Compromising one widely-used package potentially affects thousands of applications. This is why package repository attacks have increased dramatically.
The 2021 ua-parser-js compromise demonstrated this perfectly. Attackers injected malicious code into a popular JavaScript library. Because hundreds of other packages depended on it, the malicious code propagated through dependency trees into countless applications. Organizations running automated dependency updates pulled in the compromised version without realizing it.
Dependency blindness meant they did not notice until the damage was done.
The Software Bill of Materials Imperative
Manufacturing industries solved this problem decades ago. Every manufactured product has a bill of materials listing every component. If a component is found defective, manufacturers know exactly which products are affected.
Software needs the same discipline. A Software Bill of Materials (SBOM) is an inventory of all components in an application: libraries, frameworks, modules, their versions, and their dependencies.
With an SBOM, the question “are we vulnerable to this newly disclosed issue?” becomes answerable in minutes rather than weeks. You check the SBOM against the vulnerability disclosure. If the vulnerable component appears anywhere in your dependency tree, you know you are affected.
Without an SBOM, you begin a manual investigation that might take weeks and might miss transitive dependencies.
SBOMs are not optional anymore. The U.S. government now requires them for software sold to federal agencies. This requirement will cascade to private sector procurement eventually.
Beyond compliance, SBOMs are fundamental security hygiene. You cannot secure what you cannot see. An SBOM makes dependencies visible.
What Dependency Visibility Actually Requires
Achieving dependency visibility requires systematic processes, not one-time efforts.
Automated Dependency Inventory
Generate SBOMs automatically as part of the build process. Every application version should produce an updated SBOM listing all dependencies at that point in time.
This cannot be manual. Dependency trees change with every build as packages update. Automation is the only scalable approach.
Continuous Vulnerability Scanning
Scan your dependency inventory against vulnerability databases continuously. New vulnerabilities are disclosed constantly. Scanning once per quarter is inadequate.
Modern software composition analysis tools automate this, flagging vulnerable dependencies as vulnerabilities are published.
Transitive Dependency Analysis
Do not stop at direct dependencies. Map the entire dependency tree. Understand what your dependencies depend on, recursively.
The vulnerability might be five levels deep in a package you have never heard of. You still need to know about it.
Dependency Update Policies
Establish policies for dependency updates. How quickly must you update when vulnerabilities are disclosed? What is your process for testing updates before deployment?
Organizations that patch direct dependencies within 48 hours but leave transitive dependencies unpatched for months have not actually solved the problem.
License Compliance
Dependency visibility is not only about security. Open source licenses impose obligations. Some require you to publish your source code if you distribute software using them. Others prohibit commercial use.
License violations create legal risk and reputational damage. Dependency inventory must include license tracking.
The Build Versus Buy Decision
Organizations face a choice: build dependency management processes internally or adopt tools that provide this capability.
Given the complexity of modern dependency trees and the speed at which new vulnerabilities emerge, building this capability internally is rarely the right choice unless you are a large technology company with dedicated resources.
Software composition analysis tools have matured significantly. They integrate with development workflows, provide automated scanning, generate SBOMs, and alert on vulnerabilities.
The investment in these tools is minimal compared to the cost of remediating a breach that exploited an unknown dependency vulnerability.
The Real Open Source Security Problem
If I were to identify a genuine open source security concern, it would not be code quality or vulnerability rates. It would be maintainer burnout.
Critical infrastructure relies on open source projects maintained by volunteers in their spare time. These maintainers receive little or no compensation. They face constant pressure from users demanding features and fixes.
When maintainers burn out and abandon projects, those projects stop receiving security updates. But applications continue depending on them. This creates risk.
Organizations consuming open source should consider contributing back: funding maintainers, contributing code, or paying for commercial support when available.
Treating open source as free infrastructure you consume without supporting is unsustainable. The security implications of widespread maintainer burnout would be catastrophic.
The Path Forward
Dependency blindness is solvable. The technology exists. The processes are well understood. What is required is organizational commitment to treating software dependencies as managed assets rather than invisible implementation details.
Stop blaming open source for security problems rooted in poor dependency management. Start building visibility into what you actually use.
Generate SBOMs. Scan for vulnerabilities. Understand your dependency trees. Patch systematically. Monitor continuously.
These practices apply whether you use open source or proprietary software. The difference is that open source gives you the option to see and control your dependencies. Exercise that option.
The alternative is remaining blind until the next Log4Shell forces you to discover what you should have known all along.
How Cross Identity Addresses Identity Dependency Risks
While this article focuses on software dependencies, identity systems face analogous dependency challenges. Modern identity infrastructure relies on chains of trust: federated identity providers, authentication services, directory systems, and privileged access management platforms. Each component in this chain represents a potential point of failure or compromise.
Cross Identity provides comprehensive visibility across your entire identity infrastructure stack. Rather than managing identity components in silos, Cross Identity maps dependencies between identity systems, tracks authentication chains, monitors federation trust relationships, and identifies vulnerabilities in your identity supply chain.
When an identity component is compromised or a vulnerability is disclosed in an identity service, Cross Identity immediately identifies all downstream systems and access points affected, enabling rapid containment and remediation before attackers exploit the dependency chain.
Just as you need an SBOM for software, you need complete visibility into your identity architecture dependencies. Cross Identity delivers that visibility while automating the governance and monitoring that keeps identity infrastructure secure.
Take a gap assessment to understand your identity dependency risk and eliminate the blind spots that attackers are already mapping.
