JPMorgan Reports 77% of Applications Are Open Source. AI Is Finding the Attack Paths.

Your company may employ hundreds of developers. It may enforce secure coding standards, review every pull request and scan every build. But most of the code running inside its applications did not originate with your team.

A recent J.P. Morgan Eye on the Market report puts a striking number on that reality: around 77% of the code in commercial applications consists of prebuilt open-source libraries and frameworks. Between 96% and 99% of commercial codebases contain open-source components.

Modern software is not primarily written from scratch. It is assembled.

That model created extraordinary speed. It also created a security reality most enterprises have not fully absorbed: attackers can study much of the code inside your applications without ever breaching your company.

Most of your application code is public

Open source powers the databases, web frameworks, cryptography, identity systems, serializers, template engines and network clients behind modern applications. These components are not peripheral utilities. They perform some of the most sensitive actions in the application.

The same accessibility that makes open source valuable to developers makes it valuable to attackers. An attacker does not need access to your private repository to begin mapping possible weaknesses. They can download the public libraries your software depends on, inspect their code, trace their dependency graphs and test dangerous execution paths in their own environment.

AI changes the economics of that work. What once required a skilled researcher to spend days understanding a codebase can increasingly be automated across thousands of projects. Models can search for unsafe assumptions, connect multiple low-severity behaviors into an exploitable path and generate variants faster than defenders can create signatures or advisories.

Open source made the code public. AI made every line searchable at machine speed.

The asymmetry is uncomfortable: attackers can inspect the code in public, while many security teams still cannot see what that same code is doing inside their own production applications.

The software economy runs on an unexpectedly small group of people

Open source is not inherently insecure, and maintainers are not the problem. The problem is the amount of economic and operational responsibility the software industry has quietly placed on a thinly resourced community.

The research cited by J.P. Morgan found that, among 50 major open-source projects, 94% had fewer than ten developers responsible for more than 90% of the code added. In 23% of the projects, one developer accounted for more than 80% of the added code.

That is an extraordinary concentration of responsibility. A library used by thousands of companies may depend on a handful of people reviewing contributions, validating vulnerability reports, managing releases and responding to security issues, often without the staffing, budgets or operating support expected inside an enterprise security organization.

Across the broader JavaScript ecosystem, more than 18 million packages list only one maintainer. Most are not widely used, but even a small fraction represents more critical dependencies than any enterprise can realistically evaluate one by one.

Your security program therefore depends on people you did not hire, code you did not write and release decisions you do not control.

The dependency you chose is only the beginning

The open-source components developers select directly are only the visible edge of the application. Each of those packages brings its own dependencies, and those dependencies bring more dependencies.

A typical JavaScript project may declare roughly 10 direct dependencies while inheriting 683 indirect ones. Across commercial applications, the mean number of open-source components is approximately 1,180. J.P. Morgan cites research estimating that 95% of open-source vulnerabilities live in these transitive layers.

That means a development team can carefully approve ten packages and still ship hundreds of components it never explicitly selected. A vulnerable function may sit five levels deep in the dependency tree, loaded dynamically by a framework and invoked only under a particular production condition.

An inventory can tell you the package exists. It cannot, by itself, tell you whether that package is loaded into memory, whether the vulnerable function executes, whether an internet-facing path can reach it or whether attacker-controlled input is driving it toward a sensitive operation.

Those are different runtime states, with very different implications for risk.

What if you could watch every library at runtime?

Traditional security controls observe the application from the outside. A WAF inspects traffic before it enters. An endpoint or workload tool sees processes, files and operating-system activity. Static analysis and software composition analysis inspect code and known package metadata.

Each view is useful. None consistently explains what is happening inside the application’s execution chain - which library ran, which function it called, how control moved through dependencies and exactly where that execution departed from normal behavior.

The question Raven asks is simple: What if every library had its own camera?

Raven watches application code at runtime, at the library and function level. It builds context around what actually executes rather than assuming every component on disk presents the same risk. When execution changes in a way associated with exploitation, Raven can identify the responsible library, function and call path and prevent the malicious action before it completes, even when no CVE or signature exists.

Consider a deserialization library that normally transforms application data. If attacker-controlled input causes that library to reach an unexpected command-execution function, an external control may see only a permitted web request followed by a process event. Runtime application context exposes the chain between them: the input path, the library, the function transition and the sensitive operation the exploit attempted to invoke.

That is the difference between knowing a risky package is somewhere in the application and seeing the moment a specific dependency becomes an attack path.

Runtime visibility changes the open-source risk equation

Enterprises cannot audit every line of every upstream dependency. They cannot guarantee that every important project has enough maintainers. They cannot control when an unknown weakness is discovered, whether it receives a CVE or how quickly an advisory reaches their scanners.

They can control what happens when that code executes in their environment.

Runtime visibility lets security teams focus on the libraries and functions that are active in production rather than treating every package in a manifest as equally dangerous. It gives incident responders application-level evidence instead of forcing them to reconstruct an exploit from disconnected network, process and log events. And runtime prevention creates an enforcement point where exploit behavior becomes real, regardless of whether the industry has already named the vulnerability.

This does not replace secure development, software composition analysis or the work of open-source maintainers. It gives the enterprise a control layer over software it did not write and upstream communities it cannot staff.

For maintainers, that means the security of millions of downstream applications does not have to depend entirely on one person seeing, validating and fixing every issue first. For enterprises, it means accepting open source no longer has to mean accepting invisible execution.

The questions CISOs should ask now

If most application code originated outside your company, the security review cannot stop at the code your developers wrote. Security leaders need answers to a different set of questions:

• Which open-source libraries are actually loaded and executing in production?
• Which sensitive functions can those libraries reach?
• Which dependency paths are exposed to attacker-controlled input?
• Can the security team trace a suspicious operating-system action back to the library and function that caused it?
• Can the application stop an unknown exploit without waiting for a CVE, signature or custom rule?

An SBOM cannot answer all of these questions. Neither can a severity score. The answers live inside the running application.

Open source is not the problem. Invisible trust is.

Open source made modern software possible. The goal is not to retreat from it, fork every dependency or place more impossible demands on maintainers.

The goal is to stop treating public code as a black box once it reaches production.

Attackers already have access to most of the code your applications run. AI gives them a faster way to study it. Security teams need an equally direct view of what those libraries do when theory becomes execution.

Put a camera on every library. See the path. Prevent the exploit.