Runtime Correlation with Radar (SAST)

Monitor feeds runtime exploit data back to Radar, 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 Monitor and Radar connect.

How It Works

When both Monitor and Radar are active on the same project, they share data bidirectionally through the ByteHide platform.

Escalation: Theoretical to Actively Exploited

1. Radar flags a vulnerability in your codebase (for example, a SQL injection in an API endpoint)
2. Radar assigns it a severity based on static analysis: medium
3. Monitor detects a SQL injection attempt targeting that same endpoint in production
4. Monitor reports the incident with full context: payload, source IP, method, confidence score
5. Radar 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 Radar dashboard, with a direct link to the Monitor incident that validated it.

De-escalation: Flagged but Unreachable

The loop works in the other direction too:

1. Radar flags a vulnerability in an endpoint
2. Monitor has runtime visibility into how that endpoint is accessed
3. Monitor confirms the endpoint is internal, behind authentication, or unreachable from the outside
4. Radar 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 Radar

Findings enriched with runtime data display additional context:

• Runtime Status: Whether Monitor 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 Monitor confirms the vulnerable code path is reachable from external traffic

In Monitor

Incidents that match a Radar finding display:

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

Impact on Prioritization

Without runtime correlation:

With runtime correlation from Monitor:

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 Monitor, your team would fix the SSRF first. With Monitor, they fix the SQL injection first.

Setup

Runtime correlation is automatic when both products are active:

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

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

Related