Open-source software (OSS), including OSS LLMs, MCP Servers, and AI agent code, has become a foundational component of modern software and AI application development, enabling rapid innovation by allowing developers to build on existing, community-driven code.
of risk is outsourced
of vulnerabilities can be exploited by LLMs
The culture and collaboration of the open-source community provides a strong backbone for innovation. But while efficient, open-source software introduces exponential risks, and the innovation-driven open-source community can only do so much to keep existing software secure.
The open and transparent nature of OSS, while core to its success, inherently introduces security concerns. Because the source code is publicly accessible, cyber threat actors have the opportunity not only to study it for vulnerabilities but also to manipulate or compromise it for malicious purposes.
This openness can provide attackers with pathways into organizational networks and systems, especially when vulnerable components are deeply embedded in critical applications.
Dependencies introduce challenging complexity
Software includes extensive webs of open-source dependencies, many of which pull in additional libraries behind the scenes. Direct dependencies drag in transient dependencies up to 60 levels deep that even open-source developers don’t have visibility into. This creates long, interconnected chains that organizations often struggle to map or monitor. When even a small or obscure dependency contains a weakness, the issue can ripple upward into countless applications. A single flaw in the software supply chain can therefore have outsized consequences, especially when it is deeply embedded and widely reused.
Code quality and trustworthiness varies
Not all OSS undergoes rigorous testing or expert security review, and there is no universal standard ensuring that contributors thoroughly vet changes before they are released. 8.65% of open-source software is of dubious origin, which means its provenance is provably incorrect and unattested. Additionally, many open-source libraries begin with active development but gradually lose contributors or fall out of maintenance. Organizations may continue to rely on these aging components without realizing that updates have slowed or stopped entirely. As a result, organizations may unknowingly adopt components with undetected flaws and vulnerabilities.
Most of the open-source ecosystems rely on volunteer contributors to identify, report, and patch security issues rather than having dedicated support teams. Also, due to the nature of rapid iteration or community-driven feature development, comprehensive security practices are not always embedded in the workflow. Formal elements like threat modeling, secure coding guidelines, or automated security scanning may be absent or inconsistently applied. Without these guardrails, vulnerabilities can enter the code early and persist unnoticed, ultimately propagating into the products and services that rely on them. More than 70% of critical and high vulnerabilities are never fixed but they continue to live in organization’s code.
The sole reliance on a community effort can also lead to delays in updates and inconsistent availability of security fixes. This leaves organizations scrambling to find fixes for code they did not create. In the absence of timely remediation, known vulnerabilities remain exposed, giving threat actors opportunities to infiltrate systems, escalate attacks, disrupt operations and compromise sensitive information.
Even daily reprioritization cannot keep up with hourly code changes. Reachability changes with every code changes and detection tools cannot keep up.
If an attacker can load and execute vulnerable code, it does not matter that a developer did not call that function. It’s reachable!
Three quarters of open-source critical and high vulnerabilities are unfixed. A developer can’t fix them, VM tools ignore them and DevSecOp teams give them a pass.
Developers increasingly use tools like Cursor, Claude Code and CoPilot to rapidly generate code, which expands risk and drags in open-source dependencies without developer being aware.
New vulnerabilities are discovered in code faster than developers can fix them.
Modern application security tools consistently fall short because they weren’t built for today’s rapidly evolving, highly connected and AI-fueled development practices. Most tools generate noise instead of clarity, bog teams down with alerts that lack meaningful context, and often interrupt developer workflows. As applications grow more complex and AI accelerates code creation, these limitations leave organizations with an increasing pile of unresolved security issues and an illusion of safety.
Most traditional security platforms were designed around older, monolithic release cycles. They can’t adapt to the constant change and automation of cloud-native development or handle the distributed nature of modern systems.
Security teams are often buried under mountains of alerts that lack business or environmental context. Critical issues that directly affect exposed services can be buried beneath false positives or minor findings in areas that pose little real-world risk.
Developers are forced to jump between their IDEs and external security interfaces, breaking concentration and slowing delivery. Instead of embedding security into the natural flow of coding, these tools add extra steps that feel disconnected from day-to-day work.
Legacy solutions inspect isolated pieces of the development lifecycle but fail to provide an end-to-end view from source code to running workloads. Without this holistic perspective, organizations miss how vulnerabilities actually manifest or interact in real environments.
Slow scanning, high rates of false positives, and poor workflow integration leave many issues unaddressed. Over time, this compounds into significant security debt that teams struggle to manage.
As AI-generated code and machine-learning components become more common, new categories of risk such as prompt-based attacks or model manipulation have emerged. Traditional security tools can’t match the velocity at which AI has accelerated software development and increased the related attack surface.
Most tools focus on fixing vulnerabilities in the latest versions of dependencies, and latest versions frequently break existing applications. On an average, a dependency is used by 2.7 developers in their code. Coordinating their changes simultaneously is hard creating additional breakage when one developer updates and others do not.
Most tools focus on fixing vulnerabilities in the latest versions of dependencies, and latest versions frequently break existing applications. On an average, a dependency is used by 2.7 developers in their code. Coordinating their changes simultaneously is hard creating additional breakage when one developer updates and others do not.
Reduction in critical and high vulnerabilities by sourcing safe software
Reduction in developer toil with auto remediation
Compatible software and fixes that do not break builds
