Vulnerabilities Are Overwhelming
Open-source software is at near universal adoption with 96% of commercial and government codebases containing open-source components to drive innovation. And while its adoption fuels speed and efficiency, it also introduces unique and exponential risks.
130-140 of new CVEs are disclosed every day.
New vulnerabilities are disclosed on a daily basis. In 2023, over 28,000 CVEs were published and that number soared to 40,000 in 2024. In 2025, that number is expected to reach or surpass 50,000. No team of humans can realistically track and analyze this constant stream of issues without help.
95% of vulnerabilities in applications originate from open-source components.
With open source making up the bulk of our codebases, it’s no surprise that the vast majority of software vulnerabilities come from open-source dependencies. High-profile incidents like Log4Shell showed how a bug in a common library can wreak havoc across thousands of products downstream. Every new dependency you pull in may bring along dozens of transitive sub-dependencies, any of which could harbor an exploit waiting to happen.
500+ open-source components are used in the average software project.
Today’s applications aren’t simple stacks, they’re sprawling dependency graphs. A typical application can depend on hundreds of open-source libraries. Thanks to transitive (indirect) dependencies, the graph fan-outs quickly. For example, the average JavaScript project has only ~10 direct packages but ends up with 683 total dependency modules once all transitive dependencies are included . These deeply nested relationships make it incredibly hard to assess which vulnerabilities actually affect your product.
~ 45% of discovered enterprise vulnerabilities go unpatched after 12 months.
Identifying a vulnerability is only half the battle, fixing it is an arduous process that many teams chronically postpone. Applying patches or upgrading libraries often falls outside planned sprints and budgets. In many organizations, developers operate with a vulnerability backlog that grows faster than it’s addressed. Not only do a high percentage of vulnerabilities go unfixed, but Lineaje AI Labs found that 76% of critical and high severity vulnerabilities remain open after 12 months. It’s easy to understand why: every hour spent chasing CVEs is an hour not spent building product features. Under tight deadlines, security fixes get deferred release after release, until a breach or compliance mandate forces action.
80%+ of vulnerabilities are in dependencies, making fixing hard without breaking things.
Even when teams do prioritize an update, patching can be risky and disruptive. Updating a dependency or container base image can introduce breaking changes that result in failed builds, regressions, or outages. Many dev teams have felt the pain of an urgent security fix that unexpectedly broke compatibility elsewhere in the application. In fact, fear of breaking something is a major reason developers avoid frequent dependency updates. Lineaje AI Labs data shows 63% of vulnerable dependencies require minor or major version updates that either potentially or do break source code. It’s a Catch-22: patching is necessary for security, but can destabilize the software we’re trying to protect and it is time consuming.
82% of developers use AI coding tools
AI-powered coding tools have quickly become integral to modern development workflows, accelerating delivery and reducing manual effort, but they also introduce new and often overlooked security risks. By generating code based on vast training data and probabilistic patterns, these tools can inadvertently produce insecure logic, outdated dependencies, or vulnerable configurations that mirror known flaws from public repositories. Developers may trust AI-generated output without fully reviewing it, allowing subtle vulnerabilities, license violations, or insecure defaults to slip into production at scale. In addition, AI tools can obscure code provenance, making it difficult to verify where logic originated, whether it complies with organizational policies, or if it has been tampered with.
The net result of these challenges is an unsustainable status quo. Engineering and DevSecOps teams are overwhelmed by the volume of vulnerabilities and the complexity of addressing them. They either burn cycles chasing issues across myriad open-source components, or they fall behind, leaving critical exposures unaddressed. Neither outcome is acceptable in today’s threat landscape. Additionally, as AI-assisted development increases both code velocity and volume, organizations face a growing risk of compounding security debt unless strong validation, governance, and supply chain controls are applied alongside these tools. We’ve reached a point where manual approaches to open-source security simply can’t keep up with the deluge of vulnerabilities and the intricate dependency chains in modern software. Without a new approach, teams face an impossible trade-off between security and innovation: either slow down development to triage vulnerabilities or move fast and risk running on insecure foundations.
Zero-Vulnerability Software is Achievable and Enforceable
There are two major pillars that will get you on a viable path to zero-vulnerability software: sourcing safe software, and self-healing source code and containers. This approach augments human efforts with intelligent automation that focuses on risk reduction, auto-fixing and continuous compliance. Rooted in software supply chain security, Lineaje is advancing software security for the AI era. With technology designed for today’s rapidly evolving software development practices and risks, organizations can pair trusted software sourcing, auto-remediation and advanced policy management to meaningfully reduce risk and move toward a future with zero vulnerabilities.
Learn more about how Lineaje can get you on a viable path to zero vulnerabilities here.
