Every stage of the pipeline produces findings — SAST, SCA, container, IaC, DAST, pentest, runtime, and bug-bounty reports. Without a process to collect, prioritize, and drive them to closure, these findings pile up faster than they can be fixed. Vulnerability management is the continuous lifecycle that turns a flood of raw findings into a manageable, risk-prioritized workflow.
- Aggregate — collect findings from all scanners and sources into one central platform. Every tool that generates findings must have an integration that prevents findings from staying siloed in tool-specific dashboards.
- Deduplicate and normalize — the same CVE reported by Trivy, Grype, and Snyk is one issue, not three. Normalize severity, description, and CWE mappings across tools.
- Prioritize by risk — rank by genuine risk, not just CVSS score (see below). The goal is to fix the right things first, not the most.
- Assign ownership — route each issue to the team that can fix it, with a named owner, a due date, and a link to the ticket. Findings without owners do not get fixed.
- Remediate or accept — fix, mitigate with a compensating control, or formally accept residual risk with justification and a time-boxed expiry.
- Verify — retest or re-scan to confirm the fix. A closed finding without verification is an assumption.
- Report and learn — track trends over time and feed insight back into the program: which tool finds the most exploited vulnerabilities? Which team has the highest remediation rate?
CVSS severity alone causes teams to chase thousands of "critical" issues that are not actually exploitable in their environment. A CVSS 9.8 RCE vulnerability in a library that is never invoked is less urgent than a CVSS 6.5 SQL injection in a production-facing endpoint. Modern prioritization combines multiple signals:
| Signal | What it adds | Source |
|---|---|---|
| CVSS | Base technical severity | NVD, vendor advisories |
| EPSS | Probability the CVE will be exploited in the wild (0–100%) | FIRST.org, updated daily |
| CISA KEV | Confirmed exploited in real attacks — fix these first | CISA Known Exploited Vulnerabilities |
| Reachability | Is the vulnerable code path actually called in your app? | SCA tools with call-graph analysis |
| Runtime exposure | Is the affected component loaded in a running production workload? | CNAPP/CSPM runtime context |
| Asset criticality | Is the affected service internet-facing, handling PII, or in the blast radius of a critical function? | Asset inventory / CMDB |
The practical prioritization formula: KEV > (EPSS > 0.5) > reachable critical > reachable high > unreachable critical > ...
This is the heart of ASPM: correlating code-to-runtime context so teams fix what truly matters.
Define and enforce remediation timelines by risk tier:
| Risk tier | Criteria | SLA |
|---|---|---|
| Critical | CVSS ≥ 9.0 OR KEV listed | 24 hours for mitigation, 7 days for full fix |
| High | CVSS 7.0–8.9 OR EPSS > 0.5 | 14 days |
| Medium | CVSS 4.0–6.9, reachable | 60 days |
| Low / informational | CVSS < 4.0 or unreachable | 90 days or next sprint |
Track SLA adherence as a metric and escalate breaches to engineering management. SLAs without enforcement are aspirations, not commitments.
Not every reported CVE is exploitable in your application. VEX allows you to formally document and communicate the exploitability status of each CVE in each of your products:
- Affected — the vulnerable component is present and the vulnerable code path is reachable.
- Not affected — the CVE is present but not exploitable (e.g., the vulnerable function is not called, or a mitigating configuration is in place).
- Fixed — the fix has been applied.
- Under investigation — status not yet determined.
VEX documents (in CycloneDX or OpenVEX format) can be attached to your SBOM and shared with customers, reducing downstream alert noise for vulnerabilities that do not affect them.
- Auto-ticket creation — when a new high/critical finding is ingested, automatically create a Jira/GitHub issue, assign it to the owning team based on code ownership, and set the due date from SLA policy.
- Dependency update PRs — tools like Dependabot, Renovate, and Snyk Fix automatically open pull requests to update vulnerable dependencies to a patched version.
- AI-assisted fix suggestions — emerging AI agents can analyze a vulnerability, locate the affected code, draft a fix, and open a PR for human review. This significantly reduces the human effort required for known vulnerability patterns.
- Auto-close on fix verification — when a scanner no longer detects a finding in a new scan, automatically transition the ticket to "resolved pending verification" and route to a reviewer.
- Central dashboard — give leadership and teams a single view of open vulnerabilities by severity, age, and team (see Central Vulnerability Management Dashboard).
- Trending, not just snapshots — track open finding counts over time. A program that is finding and fixing vulnerabilities will show a stable or declining trend even as new findings are discovered.
- Exception register — accepted risks are visible, time-boxed, and reviewed regularly. See Security Gates for the exception process.
- Prioritizing by CVSS alone — without exploitability and reachability context, teams exhaust themselves on theoretical risks while genuine exposures go unpatched.
- No ownership model — findings that belong to "the security team" do not get fixed; they belong to the security team forever. Findings must be owned by the development team that can resolve them.
- Alert fatigue from too many tools without deduplication — five security tools reporting the same CVE five times creates the illusion of five separate problems and inflates finding counts. Deduplicate before routing.
- SLAs without tracking — defining SLAs and then never measuring adherence provides no accountability. Build SLA breach reports into weekly engineering reviews.
- Re-opening without root-cause analysis — when the same vulnerability recurs after being marked fixed, it indicates the remediation was superficial. Track recurrence as a metric and invest in root-cause fixes.
Starter — Centralize findings from SAST and SCA into DefectDojo. Apply CVSS-based SLAs. Assign findings to development teams. Track open critical/high counts weekly.
Intermediate — Enrich findings with EPSS and KEV data for prioritization. Automated ticket creation and assignment by code ownership. VEX for the top 10 most-flagged false-positive CVEs. SLA adherence tracked and reported to leadership.
Advanced — Full ASPM platform with code-to-runtime context. AI-assisted remediation PRs for known vulnerability patterns. Automated VEX generation from call-graph reachability analysis. Real-time SLA breach escalation. Vulnerability aging and recurrence analytics in the engineering KPI dashboard.
- Open critical/high finding count — track over time; a declining trend indicates program health.
- SLA adherence rate — percentage of findings remediated within SLA by tier; target > 90% for critical.
- Mean time to remediate (MTTR) — by severity and by source (SAST vs SCA vs pentest vs runtime).
- Escape rate — findings discovered in production that were not caught earlier in the pipeline; indicates where earlier detection is needed.
- Recurrence rate — percentage of findings that reappear after being marked fixed; indicates superficial or incomplete remediation.
Tools1
- Faraday — Collaborative vulnerability management platform; aggregates findings from a wide range of security tools; suited for pentest-focused teams.
- OWASP DefectDojo — Vulnerability aggregation, deduplication, and management; supports importers for 150+ scanner formats; widely used for DevSecOps pipeline integration.
- OWASP Dependency-Track — Continuous component vulnerability tracking from SBOMs in CycloneDX/SPDX format; evaluates every component against NVD, OSV, and GitHub Advisory databases.
- Kenna / Cisco Vulnerability Management — Risk-based vulnerability prioritization using EPSS and threat intelligence; strong for infrastructure vulnerability data from Tenable/Qualys.
- Tenable — Vulnerability management and exposure platform; broad coverage from on-prem to cloud; Tenable One adds ASPM-like exposure management.
- Vulcan Cyber — Risk-based vulnerability orchestration and remediation; integrates fix intelligence from vendors and community sources to accelerate remediation.
Footnotes
-
Listed in alphabetical order. ↩