Runtime Correlation with Code (SAST)

App runtime feeds runtime exploit data back to Code, turning static analysis findings from theoretical risk into actionable intelligence. Vulnerabilities confirmed as actively exploited get escalated. Vulnerabilities confirmed as unreachable get deprioritized.

The Problem with Static Findings Alone

Static analysis (SAST) scans your source code and identifies potential vulnerabilities. This is essential work. But a report with 200 findings does not tell you which ones are actually being exploited right now in production.

Without runtime context, security teams are forced to prioritize by CVSS score and guesswork. A medium-severity SQL injection on line 847 might be the most critical finding in your codebase if attackers are actively targeting it. Or it might be buried in a code path no request ever reaches.

The gap between "this code is vulnerable" and "this vulnerability is being exploited" is where App runtime and Code connect.

How It Works

When both App runtime and Code are active on the same project, they share data bidirectionally through the ByteHide platform.

Escalation: Theoretical to Actively Exploited

1. Code flags a vulnerability in your codebase (for example, a SQL injection in an API endpoint)
2. Code assigns it a severity based on static analysis: medium
3. App runtime detects a SQL injection attempt targeting that same endpoint in production
4. App runtime reports the incident with full context: payload, source IP, method, confidence score
5. Code receives the runtime signal and reprioritizes the finding to critical, because it is no longer theoretical

The vulnerability now shows a "Runtime Confirmed" indicator in the Code dashboard, with a direct link to the App runtime incident that validated it.

De-escalation: Flagged but Unreachable

The loop works in the other direction too:

1. Code flags a vulnerability in an endpoint
2. App runtime has runtime visibility into how that endpoint is accessed
3. App runtime confirms the endpoint is internal, behind authentication, or unreachable from the outside
4. Code receives the runtime context and adjusts the priority downward

Your team stops spending time on vulnerabilities that cannot be exploited in the real deployment environment.

What You See in the Dashboard

In Code

Findings enriched with runtime data display additional context:

• Runtime Status: Whether App runtime has observed exploit attempts against this vulnerability
• Last Exploit Attempt: Timestamp of the most recent attack targeting this finding
• Attack Frequency: How often this vulnerability is being targeted
• Reachability: Whether App runtime confirms the vulnerable code path is reachable from external traffic

In App runtime

Incidents that match a Code finding display:

• Linked Vulnerability: Direct link to the corresponding Code finding with CWE/CVE reference
• Code Location: The exact file and line Code identified, alongside the runtime execution context App runtime captured

Impact on Prioritization

Without runtime correlation:

With runtime correlation from App runtime:

The SSRF finding had the highest CVSS score, but runtime data shows it is on an internal endpoint that external traffic never reaches. The SQL injection had a lower score, but it is actively under attack. Without App runtime, your team would fix the SSRF first. With App runtime, they fix the SQL injection first.

Setup

Runtime correlation is automatic when both products are active:

1. Set up a Code project and connect your repository
2. Set up App runtime on the same application
3. Both products share data through the ByteHide platform automatically

No additional configuration is needed. When App runtime detects an attack that matches a Code finding, the correlation appears in both dashboards.

Related