What is runtime security?

Build-time and deployment security methods, such as scanning a codebase or container image for known vulnerabilities, help minimize security risks. But they cannot catch everything. Some flaws don’t become apparent until the production environment, where security researchers and threat actors alike constantly scour live processes for previously unknown vulnerabilities. Armed with cybersecurity-focused large language models (LLMs), they can find and weaponize more of these flaws in less time than ever.

Runtime security tools help combat these cyberthreats and vulnerabilities in the live environment. They help monitor application behavior, automate responses to suspicious activity and enforcing least-privilege access controls on apps, virtual machines and other resources. 

While runtime protection has long been an important part of cybersecurity, it became especially prominent with the proliferation of cloud-native environments. Ephemeral cloud workloads and assets cannot always be scanned before deployment, so organizations must lean on real-time threat detection to protect cloud systems.

And developments in generative AI have only made runtime security more critical. AI-powered vulnerability scanners have dramatically increased the speed and scale at which malicious actors can exploit zero-day flaws. Runtime security tools can catch that exploitation in action.

Furthermore, as AI agents come to the enterprise, they can cause serious problems when they go off the rails, whether through active manipulation or sheer accident. Because these agents are nondeterministic, runtime security is often the only way to catch them behaving badly.

The core practices of runtime security include modeling baseline activity, continuous monitoring, responding to suspicious activity and logging incidents. Security teams also use a set of proactive tools, including process isolation, least-privilege access policies, and secure networking. 

A baseline model captures the normal activity of apps, processes and their related infrastructure in an IT environment.

At the simplest level, a baseline can be a collection of security policies, allowlists and process maps that outline what live processes can or can’t do. However, many runtime security solutions also use artificial intelligence (AI) and machine learning (ML) to analyze live processes and create models of what they really do when they’re running.

Runtime security tools continuously monitor active processes, looking not only at the processes themselves but also the file systems, network traffic and other IT infrastructure surrounding them. These monitoring tools compare live activity against the baseline model to spot deviations from the norm that might signal malicious activity.

For example:

• Abnormal inbound or outbound traffic, such as an app calling an application programming interface (API) it has never called before or an AI agent reading sensitive data it’s not supposed to.
  
  
• An unrecognized process running in a container.
  
  
• A Kubernetes pod that is using more memory than normal.

In addition to looking for anomalous behavior, monitoring tools also look for known signs of established security threats, such as signatures of malicious code or common app misconfigurations.

System call monitoring is especially important to runtime security. System calls are the calls that processes make to the operating system kernel to request resources such as RAM and CPU, access files and open network connections. If a malicious actor hijacks system calls, they can gain kernel-level access to the OS. That, in turn, would allow them to escalate privileges, evade detection or compromise the underlying host. Therefore, runtime security tools watch these calls closely.

When runtime security tools detect a potential security incident, they flag it to the relevant stakeholders. Many runtime security tools can also automate incident response and remediation functions, such as terminating unrecognized processes, blocking unauthorized connections and denying access requests.

Capturing event data, system telemetry, and other information surrounding security incidents is important to any cybersecurity effort. It is doubly important to runtime security, which deals with live processes.

In cloud, DevOps and containerized environments, infrastructure and processes can spin up or down on a moment’s notice. By the time a breach investigation starts, the network might look different from the way it did when the incident happened. Thorough logs allow security teams to reconstruct what occurred so that they can remediate problems and mitigate future risk. 

Runtime security also involves tools and practices for strengthening the security posture of running processes so that they are less likely to be compromised in the first place. These measures include process isolation, network segmentation, secure networking and identity and access management.

Process isolation prevents processes from interacting with one another, or with system resources, when they shouldn’t. Common isolation methods include virtualization, sandboxing (running a process in a restricted environment) and namespaces (dividing kernel resources so that each process has its own view of the broader system).

Isolation helps reduce the blast radius of breaches by limiting lateral movement.

For example, a web server process and a database process running on the same host should have no reason to directly access each other’s memory. Process isolation enforces that boundary, perhaps by running each process in a separate namespace. Even if the web server is compromised, an attacker cannot read credentials or query data directly from the database process’s memory space.

Much like process isolation, network segmentation helps prevent lateral movement by limiting a process’s access to other parts of the network. The key difference is the level at which these controls exist. Process isolation cordons individual processes off from one another, whereas network segmentation draws boundaries between parts of the enterprise network.

While isolation and segmentation can help mitigate security risks, live processes do occasionally need to talk to one another or access resources. Secure networking tools and practices help ensure that these connections are safe.

Security lifecycle management (SLM) tools are helpful here. SLM tools can facilitate encrypted, identity-based connections that use continuous authentication and attribute-based authorization to ensure that only legitimate processes can connect with one another or sensitive resources. Every access request is vetted, and services are granted access based on their attributes rather than network location. SLM tools can also support automated provisioning of secure network infrastructure, such as service meshes, load balancers, firewalls and gateways. 

Much like human users, live processes often have credentials that allow them to authenticate to sensitive resources and assets. These credentials are popular targets for attackers because they allow them to masquerade as legitimate processes, evading detection while abusing their access permissions.

As Nick Bradley, manager, X-Force Threat Intelligence, said on an episode of the IBM Security Intelligence podcast:

“[Attackers target nonhuman identities’ credentials] because no one is watching. If I steal your password and log in to your account or your machine, it’s only a matter of time before you figure out that somebody has gotten hold of your credentials. But if I get a hold of a service account, no one is going to find out unless they’re actively watching it or auditing its activities.”

In runtime security, IAM focuses primarily on protecting the credentials of nonhuman accounts and properly scoping their permissions to minimize the damage that a rogue or impersonated process can do.

Security teams use secrets management platforms to find exposed credentials—such as passwords hardcoded into CI/CD pipelines—and bring them under control. Credentials might be locked in a secure vault or replaced with dynamic alternatives.

Similarly, many security teams are replacing standing privileges with just-in-time access that grants live processes least-privilege access to the resources they need, only for the duration they need it.

Organizations use various runtime security tools, ranging from focused point solutions to comprehensive monitoring suites. Common solutions include:

Runtime security covers all efforts to protect live processes and the infrastructure and resources surrounding them, such as the runtime environment in which a program operates or the endpoint hosting it.

Security teams sometimes break runtime security into a set of subdisciplines, usually to emphasize security in one particular part of the broader runtime ecosystem.

• Kubernetes runtime security: Kubernetes security focuses on protecting Kubernetes clusters, the computing nodes that run containerized applications managed by the Kubernetes container orchestration platform.
  
  
• Container runtime security: Container security focuses on securing actively running containers, the executable units of software that package application code along with its libraries and dependencies.
  
  
• Cloud runtime security: Cloud runtime security focuses on protecting processes from the peculiar risks and threats of running in cloud environments, including unauthorized access to cloud APIs and services and lateral movement across cloud-native infrastructure.

Aside from these distinct focuses, there tends to be little difference in how each type of runtime security is practiced. Continuous monitoring tools watch for abnormal activity and either flag it or automatically intervene.

What might vary is the type of tool used. For example, agentless monitoring is more common in cloud runtime security, where ephemeral, distributed workloads, such as serverless functions and managed containers, are the target.

Runtime security can be considered a type of application security that focuses on detecting and preventing real-time threats in apps as they run. But there are other kinds of application security, too—notably, build-time security and deployment security.

Build-time security refers to security measures that focus on code as developers are writing it. Build-time security uses methods such as static application security testing (SAST) to find and fix vulnerabilities before an app is deployed to production.

Deployment security refers to measures taken to ensure that code is secure at the time of deployment: properly configured, complies with security policies and has the right supporting infrastructure.

In a sense, runtime security, build-time security and deployment security can be thought as three phases of application security, each handling a different stage of the software development lifecycle (SDLC).

Live processes are vital points in the enterprise attack surface. According to the IBM X-Force Threat Intelligence Index, the exploitation of public-facing apps is the most common initial attack vector, accounting for 40% of the security breaches that X-Force analyzed.  Runtime security tools offer organizations a way to detect and respond to attacks on these apps and other running processes.

But two developments in particular have made organizations prioritize runtime security today.

The first is the widespread shift to cloud-based operations, microservices architectures and containerized environments. Because these environments are ephemeral and dynamic—with processes and infrastructure spinning up and down at a moment’s notice—security teams need runtime security tools to track what’s happening.  

The complexity of microservices-based apps is another factor here. These apps often contain open-source code and libraries that the organization didn’t write itself. Because this code isn’t developed in-house, the organization might not be aware of vulnerabilities until the application runs—and that’s where runtime security comes in.

The second development is the rise of generative AI, which has influenced runtime security in two distinct ways: by making it easier to find and weaponize vulnerabilities in code and by introducing AI agents to enterprise environments.

AI-powered vulnerability scanners have made it easier than ever for both attackers and defenders to find flaws in code, chain them together in novel ways and weaponize zero days.

For example, Anthropic reported that during initial testing, Claude Mythos Preview found thousands of “high- and critical-severity vulnerabilities” in common software. More than 99% of those vulnerabilities had not been patched.

And the Zero Day Clock initiative reports that the mean time to exploit a publicly disclosed CVE is now 10 hours, compared to 2.3 years back in 2018.

While runtime security cannot stop people from finding and weaponizing these zero days, it can catch them in the act, enabling the organization to respond more quickly.

And as LLMs and AI agents are increasingly incorporated into the enterprise network, they pose new kinds of security challenges. Because these tools are nondeterministic, one cannot simply fix their flaws by tweaking their code. Most of their vulnerabilities exist only at runtime, with hackers using techniques such as prompt injection to manipulate their behavior. And AI can act autonomously, making decisions and calling tools without human oversight. Runtime security helps organizations keep tabs on what their AI systems are up to and intervene when things go awry. 

A runtime attack is any attack carried out on a live application or process. Common examples include:

• Code injections, which introduce malware or other malicious code into an application while it runs.
  
  
• Prompt injections, which pass malicious prompts to AIs to trick them into doing a malicious actor’s dirty work.
  
  
• Container breakouts, where malicious actors exploit a vulnerability in one container to gain unauthorized access to other parts of the host system through lateral movement and privilege escalation. Because containers often interact with OS kernels, container breakouts can be dangerous, leading to serious system damage and data breaches.
  
  
• Memory attacks exploit vulnerabilities in how a running process handles memory. In a buffer overflow attack, for example, a malicious actor sends more data to a process than it can handle, overwriting adjacent memory and hijacking the process’s execution flow.
  
  
• Runtime supply chain attacks involve a malicious actor compromising a third-party library or dependency—either by tampering with a legitimate package or introducing a malicious one—so that it executes malicious code when the application runs. 

AI agents are emerging as prime use cases for runtime security. Because of their unique combination of nondeterministic behavior, tool-calling privileges and high autonomy, they have the potential to do significant damage if they go off script.

Agents can be manipulated by malicious actors, but they can also cause problems by executing a legitimate prompt in an unexpected way. As IBM’s Dave McGinnis, vice president/senior partner, global cyberthreat management, has said on the Security Intelligence podcast: “AI agents are our most helpful insider threats.”

Common runtime security challenges for AI agents include:

• Rightsizing permissions: If an AI agent’s privileges are too high, they can cause serious issues. Consider the AI customer service agents that were tricked into helping hackers take over Instagram accounts by changing the associated email addresses to attacker-controlled ones. But if an agent’s privileges are too low, much of the value of an autonomous, tool-calling AI is lost.
  
  
• Susceptibility to manipulation: Threat actors can use direct prompt injections, indirect prompt injections, jailbreaking and other techniques to make AI agents do things they shouldn’t, analogous to how human users fall for social engineering.
  
  
• Honest mistakes: AI agents don’t always execute prompts the way that one might expect them to. For example, an agent directed to “help customers” might start approving refunds it really shouldn’t, simply because the customers it was prompted to help asked for refunds.
  
  
• Workflow isolation: In addition to calling tools, agents can also call other agents. This capability can become a problem when, for example, an attacker tries to use a compromised agent to do something like fetch sensitive data. Even if the compromised agent can’t access that data, it might be able to call an agent that can. As Jake Lundberg, HashiCorp field CTO, explained on an episode of the Security Intelligence podcast:

“What if an agent figures out a creative way of asking another agent to do another job for it? It has the ability to reach out to those particular agents because a lot of folks aren’t putting the isolation of the workloads into the workflows themselves. How do I ring-fence not just the identity, but the scope and how those agents run?”

To address these and other issues, organizations are beginning to develop AI agent runtime security strategies. While this particular form of runtime security is still in its early stages, emerging best practices include:

• Adopting session- and intention-bound credentials: As an alternative to standing permissions, these narrowly scoped credentials enable AI agents to have useful levels of access with less potential for exploitation. When an agent requests some kind of permission, the system can use the full context of the request—the agent’s identity, the user it is acting for, what it wants to do and why—to determine what kind of access to grant, if any at all.
  
  
• Isolating agentic workflows: On the same Security Intelligence episode mentioned previously, HashiCorp’s Jake Lundberg discussed using a messaging or stream-processing layer, such as Apache Kafka, so that agents can see only the things that are within their scope of context. “Think of Kafka as almost another element of the partitioning layer to allow an agent to watch only for the work that it’s supposed to be doing, and it can’t be called by other agents,” Lundberg said.
  
  
• Continuous monitoring and policy enforcement: Verifying each API call, query and tool invocation against the appropriate policies at runtime can help catch when agents try to do things they shouldn’t—and stop them from succeeding. Implementing client-initiated backchannel authentication (CIBA) for especially sensitive actions can bring humans into the loop for the riskiest activities.