What is runtime security?

Runtime security is the practice of using evidence from a running application to determine which security risks are real. Instead of asking what could be vulnerable based on source code or a dependency manifest, it observes what actually loads into memory, which functions actually execute, which code paths are reachable from a live entry point, and which components are exposed. Static analysis describes possibility. Runtime security describes reality.

That distinction is not academic. It decides what a security team works on tomorrow morning.

Runtime security observes execution. Static analysis observes possibility

As of 4 August 2026 the National Vulnerability Database lists 372,906 CVE records. On the same date, CISA's Known Exploited Vulnerabilities catalog (version 2026.08.03) lists 1,657. That is 0.44%. Both numbers are correct. The gap between them is the problem runtime security exists to address, because a scanner works against the first and a security team has to make decisions against something much closer to the second.

Filtering by severity helps less than it should, because severity is a property of the vulnerability, not of your application. A critical CVE in a package your application never loads is not urgent. A medium-severity issue in a function that runs on every request, reachable from a public endpoint, may be the most important thing in the queue. Severity without execution context creates noise.

Static analysis reasons about code as written. It can tell you a vulnerable function exists in a dependency and that a path to it exists in theory. It cannot tell you whether that path is ever taken, whether the package loads at all, or whether a production configuration removes the condition the exploit needs. Runtime security answers those questions from observation rather than inference.

Static reachability identifies what could be called from an entry point. Runtime reachability identifies what actually gets called in production. The second set is far smaller, and it is the one worth acting on.

What runtime security observes, and where the evidence comes from

A useful runtime signal has to come from the process itself, not from a proxy for it. Kodem collects it through user-space memory analysis and event-driven analysis, with instrumentation down to function level, deployed as a Kubernetes DaemonSet with no application code changes and no restarts. The mechanism matters less than what it yields, which is four kinds of fact that source code cannot supply:

• What loaded. The packages actually resident in memory, which routinely differs from the manifest. Packages present at runtime but absent from the manifest are shadow dependencies, and static tooling cannot see them at all. The reverse case is just as useful: a declared dependency that never loads is a queue item you can put down.
• What executed. Function-level visibility into which code actually ran, so reachability becomes an observation instead of an estimate. This is the difference between "a path exists" and "this path is taken".
• What is exposed. Which services accept traffic, from where, and through which entry points, so an internal-only service and an internet-facing one stop being ranked identically.
• What behaved unexpectedly. Exploit attempts, in-memory techniques, and other runtime behavior that never appears in source at all, because it is not in your code. It is in what someone did to your code.

Correlation is what turns those four into decisions. A loaded package has to resolve back to the dependency that shipped it, the repository it came from, the image it was built into, and the team that owns it. Evidence without that chain tells you something is happening but not who should act.

Operationally this is meant to be undramatic. Kodem deploys in approximately five minutes and delivers meaningful runtime intelligence within an hour, which matters mainly because the evidence arrives before the argument about priorities does.

Most products in this category watch the host. The application layer is where the decisions are made

"Runtime security" is used loosely, and the difference matters when you are choosing tools. Most of the market means infrastructure runtime: container escapes, host process anomalies, suspicious syscalls, cluster misconfiguration. That work is necessary and it answers real questions about the platform.

It does not answer the question a security engineer actually has, which is about the application: does this specific vulnerability, in this specific service, in this specific deployment, matter. Answering that requires correlating runtime evidence back to code, to the dependency that shipped it, to the repository it came from, and to the team that owns it.

"My team does not have the hours to argue about severity scores. Runtime settles it: either the code ran and the path is reachable, or it did not. Whether it is an application we build, one we deploy, or an agentic one, runtime is what gives us the laser focus."

Nir Rothenberg, Chief Information Security Officer, Rapyd

Kodem is an application security platform built on runtime intelligence, and the ordering matters: runtime is the foundation, not a detection feature added on top. Every other layer reads from it. That is the whole architectural bet, and it is why the same evidence base serves open-source dependency risk, first-party code, and application detection and response rather than requiring three disconnected products that each guess at context.

Runtime security next to the categories it gets confused with

Almost every tool in application security is doing one honest thing well and being asked to do a second thing it cannot. Sorting that out is most of the confusion around this term.

Category	What it observes	What it can decide	What it cannot
SCA	Declared dependencies in the manifest	Which known-vulnerable packages you depend on	Whether they ever load or execute
SAST	Source code as written	Where insecure patterns exist in first-party code	Whether that path runs in production
Container and cloud runtime	Host, kernel and container behavior	Platform compromise and misconfiguration	Which application vulnerability matters
WAF	Inbound traffic at the perimeter	Whether a request looks malicious	What the application then does internally
RASP	The application, via code instrumentation	In-process attacks with high granularity	Run cheaply and simply at cloud scale
Application runtime security	What loads, executes, is reachable and is exposed	Which findings are real, and what to do about them	Find what has never run (see below)

Two of these are complements rather than competitors, and it is worth being precise about it. A WAF is a genuine enforcement point; it is more effective, not less necessary, when it is fed application context about which paths are actually reachable. RASP looks at the same layer runtime security does and gets granular results, at a cost in overhead and operational tuning that is hard to carry across a large estate.

The honest limit belongs here too. Runtime evidence tells you what is happening, so by construction it says nothing about code that has never run. A path that is dormant today is not proven safe, it is unobserved, and a feature flag or a new release can make it live tomorrow. This is why runtime security does not replace static coverage; it makes static output decidable. Anyone selling you runtime as a total replacement for looking at your code is selling you a blind spot.

Runtime evidence changes what you can prioritize, and what you can safely change

Prioritization is the obvious benefit and the smaller one. The larger shift is that execution evidence changes what you can responsibly do about a risk.

Knowing which function is reachable, from which entry point, under which configuration, is what makes it possible to reconstruct the conditions an exploit actually needs, confirm whether the risk can produce real application impact, and then verify that a proposed change removes it. That is a different loop from scanning and ticketing. Understand the risk, validate its impact, deliver the appropriate response, verify the outcome. The last step is the one most programs never get to, because without execution evidence there is nothing to verify against except the absence of a finding.

It also opens a response option static tooling cannot support. When a durable fix is not available immediately, the same validated attack condition can generate a targeted, reversible runtime control: scoped to a specific operation, tested against both the attack and representative legitimate traffic before it is enforced, deployed progressively under your approval, and retired once the real fix lands. Kodem calls this self-healing application security. It is deliberately not framed as automatic protection. It is immediate containment, validated before enforcement, and reversible by design.

Where the problem is queue volume rather than incident response, the same evidence base makes it possible to deprioritize risks with evidence and revalidate them automatically when application conditions change, rather than deprioritizing by assumption and hoping nobody audits the reasoning.

The next thing runtime security has to see is what AI agents do inside applications

Applications now contain agents that call tools, bind models, read files, and reach data, and most of that structure is assembled at runtime rather than declared in code. A manifest shows that an agent framework is installed. It does not show that an agent exists, which tools it can invoke, which model it binds, or whether a guardrail is actually loaded in the process as opposed to configured in a console.

This is a runtime problem by construction, which is why it belongs inside this category rather than beside it. Local models never touch the network. Tool surfaces expand at runtime through MCP connections no code review ever saw. Capability that is loaded but has never fired is invisible to anything watching activity, and unused agent capability is itself worth knowing about.

Kodem does this today. AI runtime discovery reconstructs the agents, workflows, tools, MCP servers, models, and guardrails actually running inside an application from runtime evidence, and correlates each one back to the repository and image it ships from. Those become first-class issues rather than a separate inventory to reconcile by hand, mapped to the OWASP LLM Top 10 and scored from observed evidence. Coverage is strongest on open-source agent frameworks; an in-house framework may show less.

What it reports is structure and reachable paths, not recorded traffic. Knowing that an agent can reach a data surface is a different claim from having watched it do so, and the honest version is the first one.

That inventory is what makes precise control possible, and this is the part the industry has been missing. Most controls see one workload with one identity, even when several decision-makers live inside it: an orchestrator, its sub-agents, ordinary deterministic code, and sometimes an agent nobody declared. The same action carries different risk depending on which of them originated it. Because the agent hierarchy is reconstructed from runtime evidence, an action can be attributed to the agent that originated it and to the delegation chain behind it, so policy can allow the refund agent to issue a refund after approval while denying the summarization agent, or an unknown sub-agent, the identical call. That is the difference between a blunt control, where a service either may or may not reach the refund system, and a targeted one.

Kodem ships that governance today, and the same honesty applies to it as to any other response: controls are validated before they are enforced, scoped to a specific operation, reversible, and applied under your approval. They are not a guarantee that nothing gets through. Identity was the missing control signal for agentic applications, and runtime is where identity actually lives.

Runtime is becoming the single source of truth for application security

Every layer of this discipline has been an attempt to answer one question without being able to observe it: is this real. Manifests approximated it with declared dependencies. Static analysis approximated it with paths through source. Severity scores approximated it with an average across everyone's deployment rather than yours. Each was a reasonable proxy for execution, adopted because execution was hard to see.

It is not hard to see any more. Once you can observe what loads, what runs, what is reachable and what is exposed, and correlate all of it back to code and ownership, the proxies stop being the best available answer and become a lossy copy of one you already hold. That is the shift worth naming: runtime stops being a detection feature bolted onto a scanning workflow and becomes the layer the rest of the program reads from.

The direction this points is a security program that argues about evidence instead of about severity, and that can prove a risk is gone rather than reporting that a ticket closed. Agents inside applications accelerate this rather than complicating it, because agentic structure barely exists on paper at all. You cannot govern what you cannot see, and in an application you cannot see it from the manifest.

Frequently Asked Questions