Security

Omer Yair

Runtime Security vs. Runtime Application Security: Why Code-Level Context Matters

Organizations invest heavily in pre-production security: SAST, SCA, vulnerability scanning, penetration testing, WAFs, firewalls, EDR, and cloud workload protection. These controls are necessary, but attacks still happen where software actually runs: in production, against live code, dependencies, frameworks, APIs, language runtimes, and AI-generated workloads.

That is why runtime security has become a critical security layer. But the term “runtime security” is often used too broadly. Not every runtime security tool sees the same thing. Some tools observe the infrastructure around the application. Others understand the application code executing inside the process.

That distinction matters. Seeing that a Python process spawned a child process is useful. Understanding that a specific NumPy function, called through SciPy, triggered the execution path that spawned that process is a different level of evidence. One is infrastructure-level visibility. The other is application-level runtime context.

Infrastructure runtime security answers: “What did the workload do?” Runtime Application Security answers: “Which code caused it, through which library, function, and call chain?”

Key Takeaways

Runtime security protects software while it executes in production, not only before deployment.
There are two very different layers: infrastructure-level runtime security and application-level runtime security.
Infrastructure runtime security sees hosts, containers, processes, system calls, files, and network activity.
Runtime Application Security sees inside the running application: language runtime, package, library, function, call chain, and execution context.
Programming languages matter because Java, Python, Node.js, Go, .NET, PHP, and Ruby execute code differently and expose different attack paths.
Call-level context changes vulnerability prioritization, exploit detection, incident response, and prevention.
Raven is focused on Runtime Application Security: runtime SCA, ADR, and prevention based on observed application execution evidence.

What Is Runtime Security?

Runtime security is the set of technologies that protect software while it executes in production. It detects, investigates, and in some cases blocks malicious behavior at the moment it occurs, rather than only identifying risk before deployment.

But runtime security is not one thing. The most important distinction is whether a tool observes the infrastructure around the application or understands the application code running inside the process.

Layer	Primary Visibility	Typical Evidence	What It Can Explain	What It Usually Misses
Infrastructure Runtime Security	Host, kernel, container, process, file, and network behavior	System calls, process trees, file writes, network connections, container events	That a workload executed a command, opened a connection, wrote a file, or behaved abnormally	Which application library, package, framework, function, or call chain caused the behavior
Runtime Application Security	Running application code and language runtime execution	Library state, loaded package, executed function, call chain, code path, vulnerable function reachability	Which code path caused the behavior and whether it came from application logic, a dependency, or attacker-controlled input	It complements rather than replaces infrastructure telemetry such as host compromise, lateral movement, and kernel-level signals

Why Infrastructure Runtime Security Is Necessary but Incomplete

Infrastructure runtime security is important. It can detect container escapes, privilege escalation, malware behavior, unexpected process spawning, suspicious file access, and abnormal network connections. For cloud and Kubernetes environments, this layer is a required control.

The limitation is not that infrastructure visibility is useless. The limitation is that it usually sees the application from the outside. It can tell you that java, node, python, or dotnet behaved suspiciously, but it often cannot tell you which library or function inside that runtime caused the behavior.

Infrastructure-Level Observation	Application-Level Question It Cannot Fully Answer
python spawned /usr/bin/lscpu	Was this expected behavior from a legitimate package, an exploit path, or malicious code execution? Which package and function caused it?
java opened an outbound network connection	Was it Spring, Log4j, a business SDK, a deserialization gadget, or application code? Which call chain led to the connection?
node wrote a file under the application directory	Was this normal caching, template rendering, attacker-controlled file write, or package behavior?
dotnet created a new process	Which assembly, method, and request path triggered the process execution?
A container performed an unusual syscall	Which application execution path caused that syscall, and was it reachable from attacker input?

What Runtime Application Security Adds

Runtime Application Security operates at the layer where exploitation actually becomes code execution. It connects runtime behavior back to the application components responsible for it: the programming language runtime, framework, package, library, function, and call chain.

From Process-Level Evidence to Call-Level Context

A process-level alert might say:

python spawned lscpu in production.

A call-level runtime application view can explain:

Customer application -> SciPy -> NumPy -> CPU feature detection function -> fork/exec -> lscpu.

That difference is the difference between a vague production incident and an explainable application-level event. It allows security and engineering teams to understand whether the behavior was expected library behavior, misuse of a dependency, exploitation, or malicious code execution.

Evidence Level	Example Finding	Security Value
Process	python executed lscpu	Useful for detection, but often noisy without application context
Container	A container spawned a process not seen before	Useful for workload anomaly detection, but not enough to identify root cause
Library	NumPy was the package involved in the execution path	Connects behavior to a dependency rather than only to the process
Function	A specific function triggered the behavior	Shows whether the risky code path actually executed
Call Chain	Application code called SciPy, which called NumPy, which triggered fork/exec	Provides root cause, triage context, and remediation guidance
Behavior + Context	Function-level behavior occurred in a production workload under a specific application path	Enables high-confidence prioritization, ADR investigation, and prevention decisions

Why Programming Languages Matter

Runtime Application Security cannot be generic. Java, Python, Node.js, Go, .NET, PHP, and Ruby do not execute code the same way. Each language has its own runtime model, dependency ecosystem, package loading behavior, reflection or dynamic execution patterns, and exploitation paths.

A true application-level runtime security layer must understand these language runtimes rather than only watching the operating system underneath them.

Language / Runtime	What Application-Level Runtime Security Needs to Understand	Common Runtime Risk Examples
Java / JVM	JARs, classes, methods, reflection, deserialization chains, frameworks such as Spring	Log4Shell-style lookup abuse, Spring exploitation, unsafe deserialization, expression language injection
Python / CPython	Packages, modules, dynamic imports, eval/exec, pickle/YAML loading, native extensions	Command execution, unsafe pickle, YAML object loading, ML model loading, dependency abuse
Node.js / V8	NPM packages, require/import, child_process, template engines, prototype behavior	Post-install abuse, command execution, unsafe template rendering, dependency confusion
Go	Compiled binaries, modules, call paths, reflection, network and file APIs	SSRF, command execution, unsafe file operations, exposed internal packages
.NET / .NET Framework	Assemblies, methods, reflection, serialization, ASP.NET request paths	Deserialization, reflection abuse, command execution, unsafe file/network operations
PHP	Composer packages, dynamic includes, unserialize, file operations, template rendering	RFI/LFI, unsafe unserialize, webshell writes, command injection
Ruby	Gems, dynamic dispatch, metaprogramming, YAML/marshal loading, Rails patterns	Unsafe deserialization, template injection, command execution, package abuse
AI / ML Workloads	Python-based agents, LangChain-style tool calls, model loading, notebooks, vector/database connectors	AI-generated code execution, unsafe model or pickle loading, data exfiltration paths, tool misuse

How Code-Level Context Changes Vulnerability Prioritization

Traditional SCA answers an important question: “Do we have a vulnerable package?” Runtime SCA adds the question that matters in production: “Is the vulnerable code actually loaded, reachable, or executed?”

This is where application-level runtime evidence changes the economics of vulnerability management. A dependency can be present in an image, but never loaded. It can be loaded, but the vulnerable function is never called. It can be called, but only in a safe internal code path. Or it can be actively executed in a risky application context.

Stage	Question	Why It Matters
Present	Is the package included in the image, repository, or artifact?	Traditional SCA usually stops here, creating large vulnerability backlogs
Loaded	Was the library loaded by the running application?	Reduces noise by separating deployed dependencies from runtime dependencies
Executed	Was the library actually used in production?	Prioritizes what the application really does, not only what it ships with
Vulnerable Function Executed	Was the specific vulnerable function called?	Turns CVE prioritization into runtime exposure evidence
Exploit-Like Behavior Observed	Did the call chain lead to suspicious behavior such as process spawn, file write, network callback, or deserialization?	Connects vulnerability management to detection, response, and prevention

How Runtime Application Security Changes Detection and Response

In traditional runtime detection, a SOC team may receive an alert that a workload spawned a shell, made an abnormal network connection, or wrote a suspicious file. That is useful, but it often starts a long investigation.

Application Detection and Response (ADR) adds the missing root cause: which application, language runtime, package, library, function, and call chain created the behavior. Instead of investigating from the host upward, the team can start from the application cause.

Question During an Incident	Infrastructure Runtime Answer	Runtime Application Security Answer
What happened?	A process spawned another process or opened a connection	A specific application call chain caused a runtime behavior
Where did it happen?	Host, container, pod, process	Application, service, package, library, function, and call path
Is it expected?	Maybe, based on baseline or policy	Can be compared to known library behavior and observed execution context
Who should fix it?	Security or platform team starts triage	Security can route directly to the owning application or dependency owner
Can it be prevented?	Often detect-and-alert or block at infrastructure layer	Can block or constrain risky application behavior at the library/function level when prevention is supported

Runtime Application Security in Kubernetes

Kubernetes provides RBAC, network policies, pod security standards, admission controls, and workload orchestration. These controls are important, but they do not explain what code inside a Java, Python, Node.js, Go, .NET, PHP, or Ruby application is doing at runtime.

Container runtime security can monitor what containers do at the host and kernel layer. Runtime Application Security adds visibility into what the application code is doing inside those containers.

Types of Runtime Security Tools

Category	Layer	Typical Strength	Typical Limitation
Container Runtime Security / CWPP	Infrastructure / container	Detects suspicious container, syscall, process, file, and network behavior	Usually limited visibility into application libraries, functions, and call chains
EDR / XDR	Endpoint / host	Strong for malware, host compromise, lateral movement, and endpoint response	Not designed to understand application-level exploit paths inside language runtimes
WAF	Perimeter / HTTP request	Blocks known request patterns before they reach the application	Cannot confirm whether vulnerable code actually executed inside the application
RASP legacy	Application runtime	Can block exploitation from inside the running process	Often requires instrumentation or language-specific integration; visibility depth varies by implementation
Runtime SCA	Application dependencies	Prioritizes vulnerable dependencies based on runtime loading and execution evidence	Needs deep runtime context to reach function-level accuracy
ADR	Application detection and response	Connects runtime behavior to package, library, function, and call chain	Most valuable when paired with runtime SCA and prevention
Runtime Application Prevention	Application enforcement	Constrains or blocks malicious behavior at execution time	Requires high-confidence runtime evidence to avoid breaking legitimate behavior

Where Raven Fits

Raven focuses on Runtime Application Security. The goal is not only to observe that something happened at the process or container layer. The goal is to explain what the running application code did and why.

Raven combines runtime SCA, ADR, and prevention to connect production behavior to application-level evidence:

Which packages and libraries are actually present, loaded, and executed.
Which vulnerable functions are actually called in production.
Which runtime behaviors are caused by specific libraries, functions, and call chains.
Which CVE-less capabilities exist in executed libraries, even when no CVE is attached.
Which application-level behaviors should be detected, investigated, constrained, or prevented.

Raven’s position: Runtime Application Security is the missing layer between infrastructure runtime telemetry and the actual code paths that attackers exploit.

FAQs

What is runtime security in cybersecurity?

Runtime security protects software while it executes in production. It detects, investigates, and sometimes blocks malicious behavior that appears only when code, dependencies, users, data, and infrastructure interact in real time.

What is the difference between runtime security and Runtime Application Security?

Runtime security is the broader category. It can include host, container, kernel, process, file, network, and application-layer controls. Runtime Application Security is the application-aware layer that understands running code, packages, libraries, functions, call chains, and execution context.

Why does call-level context matter?

Call-level context turns a generic runtime alert into an explainable application event. Instead of only knowing that a process spawned a command or opened a connection, teams can see which package, library, function, and call chain caused the behavior.

Is infrastructure runtime security still needed?

Yes. Infrastructure runtime security is necessary for container escapes, privilege escalation, malware, suspicious syscalls, and host-level behavior. It is incomplete on its own because it usually cannot explain the application code path that caused the event.

How is Runtime Application Security different from EDR?

EDR is built primarily for endpoint and host-level detection and response. It is strong at malware, process behavior, and lateral movement. Runtime Application Security focuses on production applications and language runtimes, connecting behavior to application code, dependencies, and functions.

How is Runtime Application Security different from WAF?

A WAF inspects traffic before it reaches the application and blocks known request patterns. Runtime Application Security observes what happens inside the running application after code executes, including whether a vulnerable or risky function was actually reached.

How is Runtime Application Security different from SCA?

SCA identifies known vulnerable dependencies before deployment or from artifacts. Runtime Application Security can show which dependencies are loaded, executed, and whether the vulnerable function is actually called in production.

What programming languages matter for Runtime Application Security?

Java, Python, Node.js, Go, .NET, PHP, and Ruby all matter because each language runtime loads packages, executes code, and exposes risk differently. AI and ML workloads also matter because they often rely on dynamic Python ecosystems, model loading, tool execution, and agent-driven code paths.

Can Runtime Application Security help with CVE-less threats?

Yes, when it observes risky runtime capabilities and behaviors even without a known CVE. Examples include unsafe deserialization, template rendering, command execution, file write, network callbacks, and model loading paths exposed in a specific application context.

Does Runtime Application Security replace SAST, SCA, WAF, EDR, or container security?

No. It complements them. Pre-production tools improve posture before code ships. WAFs protect the perimeter. EDR and container tools protect the host and workload environment. Runtime Application Security adds the missing application-level context inside production execution.

What should security teams look for in a Runtime Application Security platform?

Look for deep language-runtime coverage, no-code-change deployment where possible, package/library/function-level visibility, call-chain evidence, runtime SCA prioritization, ADR investigation context, and high-confidence prevention controls.

‍

Share this post

The Rise of  CVE-Less Attacks

Beyond Zero-Day. 
Into the AI Exploitation Era.

Download eBook Black book cover showing half a butterfly with text about CVE-less attacks and AI exploitation era.

Contents

This is some text inside of a div block.