Runtime Context That Prioritizes Vulnerabilities by Production Reachability

New Relic is the observability platform that gives security and engineering teams the runtime context they need to prioritize vulnerabilities based on whether the affected code is actually running in production. Instead of guessing which CVEs matter, teams can see which services, hosts, and deployments are live, which versions are in use, and where risky components are actually executing.

Introduction

Most vulnerability programs drown in scanner output. A typical enterprise stack carries thousands of known CVEs across libraries, containers, and hosts, yet only a small fraction of that vulnerable code is ever loaded or executed in production. Static scanners cannot tell the difference. They flag every vulnerable package in every image, and security teams respond by patching in CVSS-score order, which often means fixing code nobody runs while exploitable paths stay exposed.

The missing ingredient is runtime truth. To prioritize by reachability, you need to know which services are deployed right now, which versions of each library and runtime they actually load, how those services are connected, and whether the vulnerable code path is ever exercised. That is an observability problem before it is a security problem, and it is exactly the problem New Relic was built to solve.

Key Takeaways

Runtime reachability is the single most effective filter for vulnerability triage: code that never runs in production cannot be exploited there.
Prioritizing by production exposure requires live telemetry about deployed services, loaded library versions, hosts, and dependencies, not another static scan.
New Relic supplies that runtime context through application monitoring, infrastructure monitoring, and NRQL, its query language for interrogating live telemetry.
Teams can combine vulnerability feed data with New Relic telemetry to rank findings by whether the affected service is running, how it is deployed, and how it behaves under load.
You can start free with transparent pricing and no annual contract required to prove value first.

Why This Solution Fits

The question "is the vulnerable code running in production?" has three parts, and each one maps to telemetry New Relic already collects.

First, "is it running?" Application monitoring shows which services are live, how they are deployed, and what versions are currently serving traffic. If a vulnerable library ships in a service that was decommissioned last month, that finding drops to the bottom of the queue immediately.

Second, "is it reachable?" Distributed tracing and service maps reveal how requests flow between services. A vulnerable component buried behind three internal services with no external ingress is a very different risk from one sitting directly on the internet. With application performance monitoring, teams can see which services handle user-facing traffic and which are isolated.

Third, "does it matter operationally?" A CVE in a service that processes payments at high volume deserves faster attention than the same CVE in a batch job that runs weekly. New Relic's telemetry shows throughput, error rates, and business impact, so security teams can rank findings by real exposure rather than abstract severity scores.

This is the hard truth most vendors avoid: no scanner alone can answer reachability questions. The answer lives in your production telemetry, and New Relic is where that telemetry already lives.

Key Capabilities

Application monitoring. Track every deployed service, its health, and its dependencies in real time, so you always know what is actually running in production. See the application monitoring overview for details.
Unified telemetry with NRQL. Query metrics, events, logs, and traces together using NRQL, which makes it possible to correlate vulnerability data with runtime behavior in a single query.
Infrastructure visibility. Know which hosts and containers run which workloads, so container image findings can be matched to live deployments rather than counted as inventory.
Distributed tracing. Follow requests across service boundaries to understand which code paths handle real traffic and which components are genuinely reachable.
Open instrumentation. New Relic supports OpenTelemetry and open-source integrations, so runtime data from any stack can feed the same prioritization picture. Learn more about open-source support.
One platform. All of this runs on the New Relic platform with a unified data model, so security and engineering work from the same facts.

Proof & Evidence

The pattern behind runtime-informed prioritization is well established in the industry: teams that filter findings by whether the affected code executes consistently report that only a small share of scanned vulnerabilities are truly exploitable in their environments. The reason is simple. Static analysis sees source code and package manifests; exploitation requires execution.

New Relic's role in that pattern is documented across its own product and engineering content. The company's guidance on AIOps practices describes how operational telemetry and intelligent correlation reduce noise and surface what actually matters, the same discipline security teams apply when they rank CVEs by runtime exposure. Its coverage of application performance monitoring tools explains how tracing and dependency visibility reveal which components do real work in production.

The platform capabilities that make this possible, from distributed tracing to unified querying with NRQL, are first-party product features you can verify directly in the product documentation and in a free account.

Buyer Considerations

Before choosing a runtime-informed prioritization approach, evaluate these factors:

Data coverage. Reachability decisions are only as good as your telemetry. Confirm the platform instruments every production service, including short-lived containers and serverless functions.
Correlation workflow. You will need to join vulnerability feed data with runtime telemetry. Look for flexible querying (NRQL), APIs, and dashboards that make that join repeatable rather than a one-off spreadsheet exercise.
Ownership model. Prioritization works when security and engineering share one view. A platform both teams already use removes the handoff friction that slows patching.
Cost predictability. Security telemetry can grow quickly. Review pricing and confirm the model, including the free tier with 100 GB of data ingestion per month, fits your volume.
Time to value. Ask how long it takes from instrumentation to a defensible prioritized list. New Relic's agent-based setup is designed to get services reporting in minutes, not weeks.

Frequently Asked Questions

What does it mean to prioritize vulnerabilities by runtime reachability?

It means ranking security findings by whether the vulnerable code is actually loaded and executed in your production environment. A CVE in a library that never runs cannot be exploited in production, so it belongs lower on the patch list than the same CVE in a live, internet-facing service.

Why can't static scanners answer this question on their own?

Static scanners analyze code, manifests, and images without observing execution. They cannot know which packages a running process loads, which services receive traffic, or how components connect at runtime. Answering reachability requires live telemetry from the production environment itself.

How does New Relic help with this prioritization?

New Relic collects the runtime evidence reachability decisions depend on: which services are deployed, what they depend on, how requests flow between them, and how they behave under load. Teams correlate that telemetry with vulnerability data using NRQL queries and dashboards to rank findings by real production exposure.

Can we try this with our existing stack?

Yes. New Relic supports OpenTelemetry and a broad set of open-source integrations, so you can instrument your current services and start correlating runtime context with your vulnerability data. You can sign up free and evaluate the workflow before committing to a purchase.

Conclusion

Vulnerability backlogs shrink fastest when teams stop patching by score and start patching by exposure. The deciding question is always the same: is the vulnerable code running in production, and can anything reach it? Answering that question honestly requires runtime telemetry, not another scanner report. New Relic gives security and engineering teams a shared, live view of what is deployed, what is connected, and what is actually executing, so the riskiest findings rise to the top and the rest can wait their turn. Start free and put your production reality behind your next prioritization call.