How VRM Determines Runtime Security Flaws

Modern application environments are increasingly complex, combining containers, microservices, CI/CD pipelines, and ephemeral compute. While Static Application Security Testing (SAST) and Software Composition Analysis (SCA) can uncover vulnerabilities during build time, they often leave a critical gap: runtime security flaw detection and determining whether a detected flaw is actually exploitable and running in production. 

In other words, just because a vulnerability exists in code doesn’t mean it’s exploitable or even loaded in memory at runtime. For modern security engineering teams, this context is everything. 

That’s where VRM (Veracode Risk Manager) steps in. VRM correlates static analysis findings with actual runtime behaviour, allowing teams to prioritize what truly matters — the vulnerabilities that are most critical and actively present in production code. 

The Challenge

During a typical SAST or image scan, dozens of vulnerabilities may be flagged. But without knowing which of these flaws are actually part of running workloads, teams are forced to triage blindly. Time is wasted on dead code, unused libraries, or mitigated paths. 

VRM solves this by answering a simple but powerful question: 

“Is this specific vulnerable function or component currently running in production?” 

To do this, VRM requires deep integration between source control, build systems, container registries, and runtime clusters. 

Architecture Overview 

Here’s how VRM makes the connection from code → build → container → runtime: 

1. SCM Platform 

It all begins with the source code. Source code management (SCM) platforms, such as GitHub and Gitlab, store source code in repositories and provide us with different APIs and workflows to cooperate with these repositories. Veracode uses static scans directly in repositories which identifies and emits events related to different stages of the scans. From these events, VRM captures precise commit metadata, file diffs, author information, and build tags. It associates static findings (e.g., from a SAST scan) with specific commits and image builds. 

2. Image Metadata Capture 

Veracode’s repository scanner also captures data related to the build. With the images that are built during the CI process within SCM platforms, we capture important data, such as unique commit hash and file hashes into the container image labels. These serve as anchors for matching later in the pipeline. 

3. Runtime Agent in Kubernetes 

A lightweight Kubernetes agent observes running containers and images. It captures: 

• Image metadata (labels, digests, environment) 
• Cluster Metadata 

This information is then stored in the VRM systems for further processing, allowing us to construct a live map of which code is executing in the cluster. 

Code to Runtime Security Flaw Detection

The key to VRM is high-fidelity matching between static and runtime layers. Here’s how we achieve that: 

Step 1: Static Scan + Fingerprinting 

Each SAST result is fingerprinted using the file path, function signature, and commit SHA. This creates a unique identity for every detected flaw. 

Step 2: Image Build Linking 

Using CI/CD metadata, we associate the scan data with the container image(s) built from that commit. We tag images with commit SHAs and other build-time information. 

Step 3: Runtime Correlation 

At runtime, the agent extracts: 

• Cluster data 
• Images running with the name and tags (and more metadata) 

We then match this with the fingerprint database. If a match is found, we mark the vulnerability as active in runtime. 

This approach ensures: 

• No false positives from unused code 
• Prioritization of actively exploitable vulnerabilities 
• Faster response time for high-risk issues 

Alerting and Reporting

When a vulnerability is detected in runtime, VRM immediately: 

• Generates an alert
• Includes metadata, such as image name, namespace, pod name, and process tree 
• Maps the alert back to the original commit, developer, and owning team 

This allows: 

• Instant prioritization by the security team 
• Developer-level accountability and context 
• Integration with Security Information and Event Management platforms (SIEMs), PagerDuty, or Slack 

Alerts can be filtered based on exploitability, severity, and runtime exposure. In some environments, this can reduce alert noise by over 80%, since most static findings are not runtime-relevant. 

Final Thoughts

VRM represents a shift in vulnerability management — from passive scanning to contextual detection. By bridging the gap between static analysis and runtime reality, engineering and security teams can focus on what matters most: protecting what’s actually running. 

This approach doesn’t just help prioritize faster; it helps build trust between dev, ops, and security — because the conversation moves from theoretical risk to real-world exposure. 

If you’re building or operating modern Kubernetes-based applications, VRM isn’t a luxury — it’s a necessity.  Reach out to learn more.