Cloud Runtime Security: Beyond Infrastructure (2026)

Every week, security teams investigate breaches in cloud environments that had all the expected controls in place: posture management, workload monitoring, a perimeter firewall. The attacker still got through, executed a SQL injection, and exfiltrated data from a production database. The post-mortem conclusion is always the same: those tools were protecting the infrastructure, not the application code.

This is the core problem with how most organizations think about cloud runtime security. Cloud security and application security in the cloud are not the same thing. Infrastructure-level protection tells you when an S3 bucket is misconfigured or when a container is making unexpected syscalls. It says nothing about whether the SQL query your Node.js API is about to execute contains a malicious payload.

This guide maps out exactly where that gap lives, why it matters more as workloads move to serverless and microservices, and how application runtime security fills the layer that infrastructure tools leave open.

Index

What Is Cloud Runtime Security?

Cloud runtime security is the protection of applications while they are actively running in cloud environments: not at build time, not during a scan, but in production, handling real traffic.

The term gets used loosely to describe anything from kernel-level container monitoring to SAST scans triggered in CI/CD pipelines. That imprecision creates real blind spots. For clarity, cloud runtime security covers three distinct activities:

Detection: identifying attack patterns and anomalous behavior as requests are processed.

Interception: blocking malicious inputs before they reach vulnerable code or data stores.

Response: logging events, terminating sessions, alerting teams, and feeding data back into the vulnerability management cycle.

What separates cloud runtime security from static analysis is timing. Static analysis (SAST) runs before deployment and finds vulnerabilities in code. Runtime security operates after deployment and stops exploits against those vulnerabilities, including vulnerabilities that static analysis missed, introduced by third-party libraries, or present in generated code that was never reviewed.

What separates it from cloud infrastructure monitoring is scope. Infrastructure tools watch the environment. Runtime security watches the application.

The Three Layers of Cloud Security (and the Gap in the Middle)

Most cloud security architectures are built around two well-understood layers. The third layer, the one closest to your code, is the one consistently left unprotected.

Layer 1: Cloud Posture (CSPM)

Cloud Security Posture Management tools continuously scan your cloud configuration for misconfigurations, policy violations, and compliance drift. They catch things like public S3 buckets, overly permissive IAM roles, unencrypted storage volumes, and open security groups.

CSPM is essential. A misconfigured storage bucket has caused more data exposures than almost any other single mistake in cloud security history. But CSPM operates entirely at the configuration layer. It has no visibility into what your application is doing at runtime.

Layer 2: Workload Runtime Protection (CWPP / eBPF)

Cloud Workload Protection Platforms add a layer of runtime visibility at the OS and kernel level. eBPF-based agents instrument the Linux kernel to monitor syscalls, process behavior, network connections, and filesystem activity. They detect when a container spawns an unexpected shell, makes an unusual outbound connection, or executes a binary it has never run before.

This is valuable for detecting post-exploitation activity: lateral movement, privilege escalation, and persistence mechanisms. If an attacker has already compromised your application and is moving through your infrastructure, this layer catches it.

The problem is that by the time workload-level tools detect something, the initial exploit has usually already succeeded. A SQL injection attack does not trigger unusual syscalls. It executes a database query through a normal database driver, over a normal TCP connection, using credentials the application already has. The kernel sees nothing suspicious. The database executes the query.

Layer 3: Application Runtime Protection (RASP / In-App WAF)

This is the layer that most cloud security stacks are missing. Application runtime protection operates inside the application itself, intercepting operations at the point where attacker-controlled input meets vulnerable code.

A RASP security component hooks into the application runtime (the SQL driver, the OS command executor, the HTTP response renderer, the LLM client) and validates each operation before execution. It does not analyze the HTTP request at the network level. It analyzes the exact SQL statement before it hits the database, the exact command before it reaches the shell, the exact content before it renders in the browser.

This is the difference between pattern-matching on request headers and intercepting the actual operation that would cause harm.

Security Layer	What It Protects	What It Misses
CSPM	Cloud configuration, IAM, compliance	Everything that happens at runtime
CWPP / eBPF	OS, kernel, process behavior	Application-layer attacks (SQLi, XSS, injections)
RASP / In-App WAF	SQL, commands, HTTP output, LLM prompts	Infrastructure misconfigurations

A complete cloud security posture requires all three. Most stacks have layers one and two. Almost none have three.

Three layers of cloud security: CSPM, CWPP/eBPF, and application runtime protection (RASP/In-App WAF)

Why Infrastructure Security Isn’t Enough

Consider a straightforward attack scenario: a REST API running in an AWS ECS container receives a request with a parameter containing '; DR0P TABLE users; --.

At Layer 1, the CSPM tool sees nothing. This is not a misconfiguration.

At Layer 2, the eBPF agent sees a database connection being made. The application connects to the database regularly. Normal behavior. No alert fires.

At the network perimeter, if a WAF is in place, it may or may not catch this depending on how the payload is encoded. URL encoding, Unicode normalization, comment injection, and whitespace variations are standard bypass techniques against pattern-based perimeter rules. If the WAF misses it, there is no second line of defense.

At Layer 3, an In-App WAF intercepts the exact SQL statement the ORM is about to execute. It sees SELECT * FROM users WHERE id = ''; DR0P TABLE users; --'. It recognizes the injected statement, blocks the query, logs the payload, the source IP, the affected endpoint, and the line of code that would have executed it, then sends an alert.

For a broader picture, here is how the three layers perform against the most common cloud application attacks. Worth noting that OWASP’s Injection category (A03:2021) covers SQL, NoSQL, command, and LDAP injection all attack types that only application-layer protection can reliably catch:

Attack Type	CSPM	CWPP / eBPF	RASP / In-App WAF
SQL Injection	❌	❌	✅
NoSQL Injection	❌	❌	✅
XSS (stored / reflected)	❌	❌	✅
Command Injection	❌	⚠️ Post-execution	✅ Pre-execution
SSRF	❌	⚠️ Network anomaly	✅
Path Traversal	❌	⚠️ Filesystem alert	✅
LLM Prompt Injection	❌	❌	✅
IAM Misconfiguration	✅	❌	❌
Open S3 Bucket	✅	❌	❌
Container Escape	❌	✅	❌
Lateral Movement	❌	✅	❌

As runtime threat detection at the workload layer shows, command injection is caught post-execution, after the command has already run. Application-layer interception catches it before the process is spawned. That distinction matters: one layer contains damage, the other prevents it.

Application Runtime Protection in Cloud Environments

The architecture of application runtime protection is straightforward: the protection component embeds directly in the application and intercepts operations through the runtime itself, not through a network proxy, not through a kernel module, not through infrastructure agents.

This has a practical implication that teams often underestimate: the protection works identically regardless of where the application runs. On a VM, in a container, in a Kubernetes pod, or in a serverless function.

Runtime Protection Inside Containers (Docker and Kubernetes)

Containerized .NET and Node.js applications in ECS, GKE, or AKS environments integrate runtime protection through standard package installation and initialization. No Dockerfile changes are required beyond adding the dependency. No sidecar containers. No service mesh configuration.

For a .NET application deployed as a container in Azure Kubernetes Service:

// Program.cs: ASP.NET Core with Monitor
using ByteHide.Monitor;

var builder = WebApplication.CreateBuilder(args);

// Initialize Monitor: reads configuration from ByteHide dashboard
// Works inside containers without any infrastructure changes
builder.Services.AddByteHideMonitor(options =>
{
    options.ProjectToken = Environment.GetEnvironmentVariable("BYTEHIDE_TOKEN");
    options.Environment = "production";
    
    // Response actions: log the event AND block the request
    options.OnThreatDetected = ThreatAction.Block | ThreatAction.Log | ThreatAction.Notify;
});

builder.Services.AddControllers();
var app = builder.Build();

// Monitor intercepts SQL, NoSQL, XSS, SSRF, Command Injection
// at the execution point, inside the container, without kernel agents
app.UseByteHideMonitor();
app.MapControllers();
app.Run();

// Program.cs: ASP.NET Core with Monitor
using ByteHide.Monitor;

var builder = WebApplication.CreateBuilder(args);

// Initialize Monitor: reads configuration from ByteHide dashboard
// Works inside containers without any infrastructure changes
builder.Services.AddByteHideMonitor(options =>
{
    options.ProjectToken = Environment.GetEnvironmentVariable("BYTEHIDE_TOKEN");
    options.Environment = "production";
    
    // Response actions: log the event AND block the request
    options.OnThreatDetected = ThreatAction.Block | ThreatAction.Log | ThreatAction.Notify;
});

builder.Services.AddControllers();
var app = builder.Build();

// Monitor intercepts SQL, NoSQL, XSS, SSRF, Command Injection
// at the execution point, inside the container, without kernel agents
app.UseByteHideMonitor();
app.MapControllers();
app.Run();

Once initialized, Monitor hooks into Entity Framework Core, Dapper, ADO.NET, and other database drivers automatically. The Docker runtime security layer handles OS-level isolation; Monitor handles what happens inside the application code running in that container.

Serverless Runtime Security

Serverless functions represent the sharpest edge of the application layer gap. Perimeter WAFs are architected around the assumption of persistent, addressable infrastructure: a load balancer, a fixed IP, a consistent request routing path. Lambda invocations are ephemeral by definition. Each invocation may run in a different execution environment. There is no persistent agent to install, no consistent network path to inspect.

In my experience reviewing serverless security configurations, the answer to “what protects this Lambda function at the application code layer?” is more often than not silence. Perimeter tools simply cannot protect serverless functions the same way they protect VM-based workloads, and teams either haven’t noticed the gap or haven’t found a solution that fits the serverless model.

Application runtime protection works differently. The protection is embedded in the function code itself, so it executes in every invocation regardless of the underlying infrastructure:

// AWS Lambda: Node.js with Express and Monitor
const serverless = require('serverless-http');
const express = require('express');
const { Monitor } = require('@bytehide/monitor');

const app = express();

// Initialize Monitor: runs in every Lambda invocation
Monitor.init({
  projectToken: process.env.BYTEHIDE_TOKEN,
  environment: 'production',
  
  // Intercepts SQL injection in database queries,
  // NoSQL injection in MongoDB operations,
  // XSS in response content, SSRF in outbound requests
  interceptors: ['sql', 'nosql', 'xss', 'ssrf', 'path-traversal', 'command-injection', 'llm-prompt-injection'],
  
  onThreat: {
    action: 'block', // Block the operation before execution
    notify: true     // Send alert to configured webhook/Slack
  }
});

app.use(express.json());

app.get('/api/products', async (req, res) => {
  // If this query contains SQL injection, Monitor blocks it
  // before the database driver executes it, not after
  const products = await db.query(
    `SELECT * FR0M products WHERE category = '${req.query.category}'`
  );
  res.json(products);
});

module.exports.handler = serverless(app);

// AWS Lambda: Node.js with Express and Monitor
const serverless = require('serverless-http');
const express = require('express');
const { Monitor } = require('@bytehide/monitor');

const app = express();

// Initialize Monitor: runs in every Lambda invocation
Monitor.init({
  projectToken: process.env.BYTEHIDE_TOKEN,
  environment: 'production',
  
  // Intercepts SQL injection in database queries,
  // NoSQL injection in MongoDB operations,
  // XSS in response content, SSRF in outbound requests
  interceptors: ['sql', 'nosql', 'xss', 'ssrf', 'path-traversal', 'command-injection', 'llm-prompt-injection'],
  
  onThreat: {
    action: 'block', // Block the operation before execution
    notify: true     // Send alert to configured webhook/Slack
  }
});

app.use(express.json());

app.get('/api/products', async (req, res) => {
  // If this query contains SQL injection, Monitor blocks it
  // before the database driver executes it, not after
  const products = await db.query(
    `SELECT * FR0M products WHERE category = '${req.query.category}'`
  );
  res.json(products);
});

module.exports.handler = serverless(app);

Every invocation of this function has SQL injection protection active from the first line of execution. No WAF rule update required. No deployment configuration change. The security travels with the code.

API Runtime Protection in Multi-Cloud Environments

For teams running APIs across multiple cloud providers, a common pattern in microservices architectures, perimeter-based security creates management overhead and inconsistent coverage. Each cloud provider has its own WAF implementation with its own rule syntax, its own pricing model, and its own set of bypass edge cases.

Application-layer protection is cloud-agnostic by design. The same Monitor configuration that protects an Express API on Google Cloud Run protects an ASP.NET API on Azure Container Apps and a NestJS service on AWS Fargate. One dashboard, one rule set, one alert channel.

This also eliminates the operational gap that appears when teams migrate workloads between providers, run blue-green deployments across clouds, or add a new region. The application carries its protection with it.

Cloud Runtime Security vs. Traditional Perimeter Security

Perimeter WAFs and application runtime protection are not competing tools. They operate at different layers and catch different things. Understanding what each one does well is what lets you make the right architectural decision.

Dimension	Perimeter WAF	In-App WAF (RASP)
Where it operates	Network edge (CDN, load balancer)	Inside the application code
What it analyzes	HTTP request patterns	Exact SQL, commands, output before execution
False positive rate	High (no visibility into code context)	Low (sees the exact operation)
Serverless support	Limited (no persistent infrastructure)	Full (embedded in function code)
Bypass resistance	Vulnerable to encoding, obfuscation	Sees the decoded, final operation
Forensic data	IP, URL, headers	Line of code, method, payload, confidence score
Infrastructure dependency	DNS/CDN/load balancer required	None. Integrates directly in the application
Multi-cloud consistency	Requires per-provider configuration	Single configuration across all environments
LLM prompt injection detection	Not supported	Supported

The RASP vs WAF decision is often framed as either/or. In practice, the combination makes more sense than either alone: perimeter rules filter high-volume, low-sophistication attack traffic before it reaches your application; application runtime protection handles everything that makes it through, including targeted attacks and encoding-based bypasses.

Implementing Cloud Runtime Security: Getting Started

Adding application runtime protection to an existing cloud application takes approximately the same effort as adding a logging library. No infrastructure changes, no DNS modifications, no Dockerfile rewrites.

The typical setup path:

1. Install the package. npm install @bytehide/monitor for Node.js or the NuGet package for .NET.

2. Initialize at startup. One call at application boot, passing your project token from an environment variable. Monitor reads its configuration from the ByteHide dashboard, where interceptors, response actions, and notification channels are configured.

3. Deploy normally. Your existing deployment pipeline stays unchanged. The container image, the Lambda package, the Kubernetes manifest, nothing changes. Monitor runs inside the application process.

4. Configure response actions. From the dashboard, set what happens when a threat is detected: log only, block and log, block and alert, or custom webhook. Changes apply immediately without redeployment.

5. Connect to Radar (optional). If you are running ByteHide Radar for static analysis, Monitor can feed runtime data back to reprioritize findings. A SQL injection vulnerability that Monitor detects being actively exploited in production gets automatically escalated from medium to critical in the Radar report, regardless of its original CVSS score.

Configuration can also be managed as code if your team prefers that over dashboard management:

// appsettings.json: production
{
  "ByteHide": {
    "Monitor": {
      "ProjectToken": "your-token-here",
      "Interceptors": ["SqlInjection", "XSS", "CommandInjection", "SSRF", "LLMPromptInjection"],
      "ThreatAction": "BlockAndLog",
      "Notifications": {
        "Slack": "<https://hooks.slack.com/your-webhook>"
      }
    }
  }
}

// appsettings.json: production
{
  "ByteHide": {
    "Monitor": {
      "ProjectToken": "your-token-here",
      "Interceptors": ["SqlInjection", "XSS", "CommandInjection", "SSRF", "LLMPromptInjection"],
      "ThreatAction": "BlockAndLog",
      "Notifications": {
        "Slack": "<https://hooks.slack.com/your-webhook>"
      }
    }
  }
}

For teams moving toward security-as-code, this configuration lives in the repository alongside the application code: versioned, reviewed, and deployed through the same pipeline.

Frequently Asked Questions

What is cloud runtime security?

Cloud runtime security is the protection of applications while they are actively running in cloud environments, including containers, serverless functions, and cloud-hosted APIs. It covers both infrastructure-level monitoring (detecting anomalous workload behavior) and application-level protection (intercepting SQL injection, XSS, command injection, and other code-layer attacks before they execute).

How does cloud runtime security differ from CSPM?

CSPM (Cloud Security Posture Management) protects cloud configuration: IAM policies, storage bucket permissions, network rules, and compliance posture. Cloud runtime security protects applications while they are running. CSPM catches misconfigured resources before an attacker exploits them; runtime security stops attacks against correctly-configured resources when an attacker reaches the application code.

Does cloud security protect against SQL injection?

Infrastructure-layer cloud security tools, including CSPM, CWPP, and network-level WAFs, do not reliably protect against SQL injection. CSPM has no visibility into application queries. eBPF-based workload monitoring sees database connections as normal traffic. Perimeter WAFs can be bypassed with encoding techniques. Application runtime protection (RASP / In-App WAF) intercepts the exact SQL statement before execution and blocks injected payloads regardless of how they were encoded in the original HTTP request.

What is the difference between CWPP and application runtime protection?

CWPP (Cloud Workload Protection Platform) operates at the kernel and OS level, monitoring syscalls, process behavior, network connections, and container activity. It detects threats that manifest as abnormal system behavior: container escapes, lateral movement, and post-exploitation activity. Application runtime protection operates inside the application code, intercepting SQL queries, OS commands, HTTP output, and LLM prompts before execution. CWPP catches what happens after a successful exploit; application runtime protection prevents the exploit from succeeding.

How do you secure serverless functions at runtime?

Serverless functions cannot be protected by perimeter WAFs the same way persistent infrastructure can, because each invocation may run in a new ephemeral execution environment. The most reliable approach is embedding application runtime protection directly in the function code. An In-App WAF module initializes at function startup and intercepts all database queries, outbound requests, and output operations in every invocation, regardless of the underlying infrastructure.

What tools provide cloud runtime security for Node.js and .NET?

ByteHide Monitor provides application runtime protection for both Node.js (Express, NestJS, Next.js) and .NET (ASP.NET Core, .NET 6/7/8/9) in cloud environments. It integrates directly into the application code, requires no infrastructure changes, and protects against SQL injection, NoSQL injection, XSS, SSRF, command injection, path traversal, and LLM prompt injection. It works identically across containers, Kubernetes, serverless functions, and VM-based deployments.

The shift toward cloud-native architectures has changed the attack surface in ways that infrastructure security tools were not designed to handle. eBPF-based monitoring and posture management solve real problems, but they solve infrastructure problems. SQL injection, XSS, and LLM prompt injection are application problems, and they require protection at the application layer, running inside the code, at the point where attacker input meets vulnerable operations. That is not a gap that more infrastructure tooling closes. It requires a different architectural layer entirely.