TL;DR

Security teams remediate an average of 6 vulnerabilities per application monthly, while approximately 17 new ones appear, creating an ever-growing backlog. Execution context reveals which vulnerabilities are exposed to external inputs and actively exercised in production, allowing teams to improve vulnerability prioritization by focusing on what attackers can actually exploit. This context transforms overwhelming scan results into manageable, risk-based remediation queues.

Key takeaways

• According to Contrast Security's Software Under Siege 2025 report, applications contain nearly 30 serious vulnerabilities on average
• Execution context reveals which vulnerabilities exist in actively executing code paths with external exposure
• Organizations can focus vulnerability remediation on issues that pose an immediate exploitable risk
• The approach complements SAST, SCA and DAST by adding runtime visibility that reveals actual exploitability indicators
• Execution context shows which code paths handle external data and how frequently they execute

Why vulnerability backlogs keep growing

Your security team scans applications continuously, triages findings weekly and works overtime to patch critical vulnerabilities. Yet according to Contrast Security's Software Under Siege 2025 report, the average application contains nearly 30 serious vulnerabilities.

The math reveals an impossible situation:

• An average of six vulnerabilities is remediated per application monthly
• Approximately 17 new vulnerabilities appear per application in that same period
• Net accumulation: Roughly 11 vulnerabilities per application each month

For organizations managing dozens or hundreds of applications, this means security teams are remediating hundreds of vulnerabilities each month, even as thousands more appear.

This creates a compounding backlog that grows without limit. Traditional vulnerability management treats every scanner finding as equally urgent, forcing teams to investigate thousands of theoretical risks. Most organizations respond by implementing severity-based triage, fixing critical and high findings first. However, severity scores measure potential impact, not actual exploitability in your specific environment.

A critical SQL injection vulnerability in rarely executed administrative code protected by multiple authentication layers poses a different risk than a medium authentication bypass in your main login flow. Without execution context, these critical distinctions remain invisible.

When every finding looks equal: The prioritization challenge

Static Application Security Testing (SAST) and Software Composition Analysis (SCA) excel at finding potential vulnerabilities in code. These tools analyze source code and dependencies without running the application, identifying every possible security weakness according to their rule sets.

The challenge lies in what these tools cannot see:

• Execution frequency: Your application might include vulnerable deserialization code that only executes during specific administrative tasks performed monthly
• External exposure: Authentication code flagged as vulnerable might only process internal service-to-service tokens, never user-supplied credentials
• Compensating controls: A path traversal vulnerability might exist in code that's protected by multiple layers of input validation and authentication
• Data sensitivity: Two identical SQL injection vulnerabilities might access completely different data stores, one containing public information, another containing sensitive customer records

Traditional scanners operate outside the running application. They analyze what could happen theoretically, not what actually happens when code executes with real data in production.

Execution context: Understanding actual risk in production

Execution context is a security methodology that monitors applications during runtime to identify which code paths are active, exposed to the internet and processing real-world data. By observing the application in its live environment, it provides the necessary data to determine a vulnerability's actual exploitability.

Execution context transforms vulnerability management by monitoring applications as they run, observing which code actually executes, which functions handle external data and how data flows through the application. This visibility changes vulnerability assessment from theoretical to practical.

How execution context reveals exploitability:

• Identifies external attack surface: A path traversal vulnerability might exist in your file-handling code, but the execution context shows whether that code ever processes user-supplied input. If the vulnerable function handles only internally generated file paths, the actual risk differs dramatically from that of the same vulnerability in user-facing upload functionality.
• Maps execution patterns: Your application might include dozens of third-party libraries containing known vulnerabilities. Execution context reveals which libraries actually load in production, which functions your code calls, and how frequently they execute. A vulnerability in a library function that never executes poses minimal immediate risk compared to one in your main request processing pipeline.
• Reveals compensating controls: Rather than treating each vulnerability in isolation, execution context shows the complete picture. That SQL injection vulnerability might exist in code that's behind three layers of authentication, only accessible to administrators, and processes data through stored procedures that limit potential damage.
• Tracks data flow paths: Execution context shows how data moves through your application, indicating which vulnerabilities can access sensitive information versus those limited to public data. This context enables risk-based decisions about remediation priority.

Transforming backlog management with execution context

Organizations using execution context follow a systematic approach to backlog reduction:

1. Deploy lightweight instrumentation that observes application behavior without changing source code
2. Establish baseline patterns by monitoring normal operations
3. Correlate runtime observations with vulnerability scan results from SAST, SCA and Dynamic Application Security Testing (DAST)
4. Identify exploitable vulnerabilities based on external exposure and execution patterns

A typical enterprise application might have hundreds of vulnerability findings from various scanners. Execution context reveals which subset represents an immediately exploitable risk based on actual production behavior.

For deserialization vulnerabilities, which represent roughly a third of viable attacks according to Software Under Siege 2025, execution context shows whether your application actually deserializes external input in production. If your code includes deserialization capabilities but only processes trusted internal data, the risk profile changes significantly.

Execution context advantages for common attack patterns

Execution context provides specific insights for prevalent vulnerability types:

Method tampering attacks

Representing about a fifth of viable attacks, method-tampering exploits HTTP verb confusion. Execution context identifies which API endpoints actually execute in production and which methods they accept, showing security teams exactly where to implement verb restrictions.

Path traversal vulnerabilities

Runtime visibility reveals which file access operations your application performs with external input versus internal paths. This distinction helps teams prioritize fixes in code that actually processes user-controlled file paths.

Cross-Site Scripting (XSS)

Execution context shows which code paths handle external input and generate HTML output. Teams can focus XSS prevention on functions that both receive user input and produce web content, rather than fixing theoretical vulnerabilities in rarely used administrative interfaces.

Authentication and authorization flaws

By observing actual authentication flows and authorization checks in production, execution context helps identify which vulnerabilities could lead to privilege escalation versus those in already-protected code paths.

Practical impact for security teams

Organizations implementing execution context report, transforming their vulnerability management approach:

• From overwhelming to manageable: Instead of facing hundreds of undifferentiated findings, teams work with a prioritized list based on actual exploitability indicators.
• From theoretical to practical: Security engineers investigate vulnerabilities with full context about how they manifest in production, eliminating guesswork about real-world impact.
• From conflict to collaboration: Development teams receive fewer but more relevant vulnerability tickets, each with clear evidence of exploitability and rich context for remediation.

Benefits for development teams

Execution context reduces friction between security and development:

Fewer but more relevant tickets

Developers receive vulnerability reports for issues that demonstrably pose risk in production, not theoretical problems in unused code. Each ticket includes evidence of why this specific vulnerability matters.

Faster remediation with better context

Execution context provides rich details about how vulnerabilities manifest:

• The specific code paths that execute in production
• What types of input trigger the vulnerable code
• How data flows through the affected functions
• Which users or services can reach the vulnerability

This context transforms vague security requirements into specific, actionable fixes.

Clear risk communication

Instead of debating CVSS scores or theoretical severity, teams discuss actual production behavior. A medium-severity vulnerability in code that is constantly executed during payment processing clearly takes priority over a critical vulnerability in a deprecated feature.

Focus your remediation where risk lives

The vulnerability backlog problem demands a new approach. When new vulnerabilities appear nearly three times faster than teams can remediate them, working harder isn't the answer. The solution requires working smarter by understanding which vulnerabilities pose actual risk in your production environment.

Execution context provides the visibility security teams need to make risk-based decisions about vulnerability remediation. By revealing which vulnerabilities are exposed to external attack and actively exercised in production, organizations can focus limited resources where they matter most.

Your development teams have finite capacity for security work. Your security team cannot investigate every finding manually. Execution context ensures both teams focus on vulnerabilities that represent genuine risk, where exploitation could cause real damage.

Learn how execution context helps your team identify which vulnerabilities pose real risk in your production environment. Contact us to see how runtime visibility can transform your vulnerability management from an endless backlog to a prioritized, risk-based program.

Frequently asked questions How does execution context differ from DAST?

Dynamic Application Security Testing (DAST) probes applications from the outside by sending test payloads and observing responses. It operates blindly, without visibility into the internal behavior of the application. Execution context observes applications from the inside during normal operations, seeing exactly which code executes, how data flows through functions and what controls are in place. This inside-out visibility provides a more complete and accurate risk assessment than external testing alone.

Does implementing execution context require source code changes?

No source code modifications are necessary. The instrumentation typically involves adding a lightweight agent to the application runtime or deploying a sidecar container in containerized environments. The application code itself remains unchanged, and instrumentation adds minimal performance overhead, similar to that of application performance monitoring tools.

How quickly can organizations see value from execution context?

Implementation timeframes vary based on application architecture and complexity. Most organizations complete initial deployment within days and begin receiving actionable intelligence within the first month of operation. The value increases over time as the system observes more application behavior patterns.

How does execution context handle third-party library vulnerabilities?

Execution context monitors which third-party libraries your application loads at runtime and which functions within those libraries your code actually calls. If your application includes a vulnerable library but never invokes the vulnerable function, or only calls it with internal data, the risk assessment reflects this limited exposure. This distinction is critical because modern applications often include dozens of dependencies, many of which contain known vulnerabilities in code paths your application never uses.

Can execution context identify zero-day vulnerabilities?

While execution context excels at providing context for known vulnerabilities, it also helps identify suspicious behavior patterns that might indicate zero-day exploitation. By establishing baseline behavior and detecting anomalies in code execution, data access patterns or authentication flows, execution context can surface potential zero days for investigation.