Security and Risk Prioritization
Security and Risk Prioritization focuses on New Relic Vulnerability Management: finding vulnerable dependencies and prioritizing them by runtime context rather than by severity alone. The exam tests whether you can explain why a critical CVE can be low priority and a medium CVE can be urgent.
Core rules
- Vulnerability Management inventories third-party libraries and OS packages, correlates them with known CVEs, and supports SBOM-style visibility. Entities include vulnerabilities, packages, and the workloads that contain them.
- Risk is contextual. A useful prioritization combines CVSS severity with exploitability, whether the vulnerable code path is reachable at runtime, whether the workload is internet-facing, and business criticality. A high CVSS in an unreachable test service is not the same risk as a medium CVE in a reachable production API.
- Runtime reachability reduces scanner noise: a library can be present without the vulnerable function being invoked.
- Prioritize production, internet-facing, reachable, high-severity findings first. Track remediation ownership and verify that a fixed version is actually deployed, not just merged.
- Security findings should feed the same incident and ownership workflows as reliability findings, otherwise they are ignored.
Worked example
Two services contain a CVSS 9.8 deserialization CVE. Service A is a test job that never calls the vulnerable method and is not exposed. Service B is a public API that calls it on every request. Service B is prioritized for immediate patching; Service A is scheduled but not treated as an outage-level emergency. CVSS alone would have ranked them equally.
Traps
Do not rank by CVSS alone. Do not assume a dependency is safe because it is transitive and not directly imported; reachability still matters. A stale SBOM hides new CVEs. Do not treat a merged pull request as remediation until the deployed version is confirmed.