Runtime Correlation

Code correlates static analysis findings with real-time exploit data from ByteHide App runtime (RASP) to eliminate false positives, discover zero-day vulnerabilities, and reprioritize findings based on actual exploitability, not just theoretical severity.

The Problem with Static Analysis Alone

Static analysis scans source code and identifies potential vulnerabilities. A typical scan produces dozens or hundreds of findings, all ranked by severity score. But severity alone does not tell your team what to fix first.

Runtime correlation solves all four problems by connecting what Code sees in your code with what App runtime sees in production.

How Runtime Correlation Works

When both Code (SAST/SCA/Secrets) and App runtime (RASP) are active on the same project, they share data bidirectionally through the ByteHide platform. No additional configuration is needed.

SAST: Code Vulnerabilities Meet Real Attacks

Escalation: theoretical to actively exploited.

1. Code flags a SQL injection in /api/users and assigns it Medium severity based on static analysis
2. App runtime detects 47 SQL injection attempts targeting that exact endpoint this week in production
3. Code receives the runtime signal and automatically escalates the finding to Critical
4. The finding shows a "Runtime Confirmed" indicator with a link to the Monitor incidents

The vulnerability is no longer theoretical. Your team knows it is actively under attack.

De-escalation: flagged but unreachable.

1. Code flags an SSRF vulnerability with Critical severity (CVSS 9.1)
2. App runtime has runtime visibility into how that endpoint is accessed
3. App runtime confirms the endpoint is internal-only, behind authentication, and unreachable from external traffic
4. Code adjusts the priority downward to Medium

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

Zero-day discovery: unknown patterns detected at runtime.

1. App runtime detects a new attack pattern that exploits a code path no static rule covers
2. App runtime classifies it as a potential zero-day and reports the incident with full context: payload, source, method, and the code path executed
3. Code receives the signal and creates a new finding for that code location, without needing a new code scan
4. The finding is automatically assigned Critical severity because it represents an actively exploited, previously unknown vulnerability

Static analysis alone would never have found it. The runtime detected the attack, and Code now tracks the remediation.

SCA: Vulnerable Dependencies in Real Environments

Static SCA analysis tells you which repositories contain a vulnerable library. Runtime correlation tells you which applications in production are actively loading and executing that library right now.

Real-time impact mapping.

1. A new CVE is published for a library (e.g., a critical prototype pollution in minimist)
2. Code's SCA scan identifies 12 repositories that include the vulnerable version in their dependencies
3. App runtime reports that only 3 of those 12 applications are actually loading minimist in production at this moment
4. Code reprioritizes: those 3 applications are Critical, the remaining 9 are Medium (the dependency exists but is not actively in use)

Your team fixes the 3 active applications first, instead of treating all 12 equally.

Runtime protection while you patch.

When a vulnerable library is detected in a running application, App runtime can block exploit attempts targeting that specific vulnerability in real time. This gives your team a protection window:

1. App runtime detects and blocks attacks targeting the vulnerable library
2. Your application stays protected while you prepare the fix
3. You use AutoFix to generate the dependency upgrade PR
4. You review, test, and merge on your schedule, not under emergency pressure

The combination of runtime blocking and automated remediation turns a zero-day emergency into a managed process.

Impact on Prioritization

Without runtime correlation, priority is based on severity score alone:

With runtime correlation from App runtime:

The SSRF 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 runtime correlation, your team fixes the SSRF first. With it, they fix the SQL injection first.

False Positive Reduction

Runtime correlation reduces false positives by up to 90% through three mechanisms:

Instead of triaging 200 findings manually, your team focuses on the findings that runtime data confirms are real, reachable, and actively targeted.

AutoFix on What Matters

Runtime correlation directly improves AutoFix effectiveness:

• Fix actively exploited vulnerabilities first. AutoFix generates PRs for runtime-confirmed findings, so your first merges address real attacks
• Skip false positives. Findings deprioritized by runtime data move to the bottom of the queue, so AutoFix is not wasted on unreachable code
• Prioritize SCA upgrades by runtime impact. When a CVE affects multiple repositories, AutoFix targets the applications that are actually running the vulnerable code in production

The result is a remediation workflow driven by real-world risk, not theoretical severity scores.

What You See in the Dashboard

Findings enriched with runtime data display additional context in Code:

Setup

Runtime correlation activates automatically when both products are connected:

1. Create 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 within seconds.

Next Steps