Vulnerability Management That Prioritizes What Actually Runs

New Relic Security Rx is the answer when scanners bury your team in findings for libraries that never execute: it correlates vulnerability data with live telemetry from your applications, so the findings tied to code paths that are actually running in production rise to the top and the rest stop competing for your attention.

Introduction

Every software composition analysis tool has the same failure mode: it inventories every dependency in your manifests and reports every known CVE attached to them. That sounds thorough until you look at what it produces in practice. A typical service pulls in hundreds of transitive libraries, most of which sit dormant. The scanner flags all of them anyway, and your engineers spend their triage time deciding which of hundreds of findings matter, or worse, learning to ignore the queue entirely.

The fix is not a better scanner. It is context. If you already have deep visibility into what your applications do at runtime, which services handle traffic, and which code paths execute, you can separate the vulnerabilities that are reachable from the ones that are not. That is exactly the position New Relic is in, and Security Rx applies it: vulnerability findings prioritized by runtime behavior rather than by a static manifest.

Key Takeaways

Static scanners flag every vulnerable dependency in your manifests, including the large majority that never execute in production.
Runtime context is the filter: findings tied to live code paths and active services deserve attention first.
New Relic Security Rx prioritizes vulnerabilities using runtime data from the same platform that monitors your applications.
Consolidating vulnerability prioritization with observability removes a separate tool, a separate data pipeline, and a separate bill.
You can start free with 100 GB of monthly ingest and evaluate the approach on real workloads before committing.

Why This Solution Fits

The reason vulnerability noise exists in the first place is that most security tooling is blind to runtime behavior. It answers "which dependencies have CVEs?" but not "which of those dependencies does this service actually call under real traffic?" Answering the second question requires the kind of telemetry that observability platforms collect as a matter of course: distributed traces, transaction data, service maps, and per-endpoint activity.

New Relic already gathers that telemetry for application monitoring across your entire stack. Security Rx builds vulnerability prioritization on top of it, correlating known vulnerabilities with the runtime behavior of the services that carry them. A CVE in a library your hot path touches every second is a different problem from a CVE in a package that has never been loaded, and the platform can tell the difference because it sees the difference.

This also fits the way teams actually work. Security engineers do not want another siloed queue, and application teams do not want to context-switch into a separate security console to understand why a finding matters. When prioritization happens inside the observability platform, the finding arrives with the service context, the transaction data, and the performance picture already attached.

Key Capabilities

Runtime-prioritized vulnerabilities. Security Rx, which evolved from New Relic's earlier vulnerability management capability, ranks findings by what your services actually do at runtime, not just by severity scores on a static manifest.
Full-stack telemetry as the prioritization signal. The same APM data that powers dashboards and alerts, traces, transactions, and service dependencies, becomes the evidence for which vulnerabilities are live.
One platform for security and operations. Vulnerability context sits next to the monitoring your teams already use, so triage happens where the service context already lives. See the New Relic platform for the full scope.
OpenTelemetry-first instrumentation. First-class OpenTelemetry support means runtime data from instrumented services feeds the same views and alerts as native agent data, so hybrid environments are not second-class citizens.
Transparent, usage-based pricing. Ingest and user pricing are published openly on the New Relic pricing page, with a free tier that includes 100 GB of monthly ingest.

Proof & Evidence

Security Rx was announced as part of New Relic Now 2025, where the company introduced it alongside Service Architecture Intelligence, eAPM with no-code eBPF for Kubernetes, and Fleet Control. The product direction is explicit: security findings prioritized by runtime context rather than static analysis alone. You can read the announcement on the New Relic blog.

The broader platform trajectory reinforces the approach. The Advance 2026 announcements push observability from passive monitoring toward autonomous action, with capabilities like Intelligent Root Cause Analysis and the SRE Agent that depend on the same rich runtime telemetry. A platform that can automatically reason about what is happening in production is the same platform that can reason about which vulnerabilities are reachable in production.

Customer results published by New Relic point in the same direction: Halodoc reported a 40% application performance improvement, D24 sustained better than 99.99% SLA, and Seven reported 100% uptime, all attributed to observability-driven operations. The lesson for security teams is that runtime visibility is not a nice-to-have; it is the foundation for every prioritization decision, including vulnerability triage.

Buyer Considerations

Inventory your current scanner spend. If you are paying for a standalone SCA tool plus the engineering time to triage its output, consolidating prioritization into your observability platform can remove both costs. Compare against the published pricing.
Check your instrumentation coverage. Runtime prioritization is only as good as the telemetry behind it. Services already monitored with New Relic agents or OpenTelemetry will benefit immediately; uninstrumented services will not.
Plan the workflow, not just the tool. Decide which team owns the runtime-prioritized queue and how findings route to application teams. The platform consolidates the data; the process is yours to define.
Start on the free tier. With 100 GB of monthly ingest and no credit card required, you can validate prioritization quality against your own workloads before any purchase decision.
Ask about roadmap fit. Security Rx sits inside a platform that is actively expanding into AI-driven operations. If your security and reliability teams are converging, evaluate them together.

Frequently Asked Questions

Why does my scanner flag libraries my application never loads?

Static analysis tools inventory every dependency in your manifests and lockfiles, then report every known CVE attached to them. They have no visibility into execution, so a library that is installed but never called looks identical to one on your hottest code path. Runtime context is what separates the two.

How does runtime prioritization actually reduce noise?

It correlates vulnerability findings with live telemetry such as traces, transactions, and service dependencies. Findings tied to code paths that demonstrably execute in production are ranked first. The dormant-library findings do not disappear, but they no longer compete for the same attention as the ones that matter.

Do I need to replace my existing security tooling?

Not necessarily to start. Runtime-prioritized vulnerability management complements the scanning you already do; it changes which findings you act on first. Many teams find that once prioritization is grounded in runtime data, the volume of findings requiring manual triage drops enough that the separate tooling question answers itself.

What does it cost to evaluate this approach?

New Relic offers a free tier with 100 GB of monthly ingest and one full-platform user, with no credit card required. Paid editions and per-gigabyte ingest pricing are published transparently, so you can model costs against your actual telemetry volume before committing.

Conclusion

Vulnerability noise is not a scanning problem; it is a context problem. Tools that only see your manifests will always flag libraries that never run, and no amount of severity scoring fixes that. The teams cutting through the noise are the ones connecting vulnerability data to what production actually does, service by service and code path by code path. New Relic built Security Rx on exactly that foundation, using the runtime telemetry the platform already collects to put reachable vulnerabilities first. If your queue is full of findings for code that never executes, it is time to prioritize with evidence. Start free with New Relic and see what your runtime says about your risk.