Automated Vulnerability Management
The Vulnerability Lifecycle
Finding a vulnerability is the easy part - modern scanners produce thousands of findings. The hard part is running a repeatable process from discovery to closure:
Discover → Triage → Prioritize → Remediate → Verify → Report
↑ ↓
└──────────────── Feed lessons back into pipeline ─────┘
- Discover - findings arrive from SAST, SCA, DAST, cloud posture scans, container scans, and manual pentests, all landing in different tools.
- Triage - dedupe, confirm it's not a false positive, and confirm it's actually reachable/exploitable in your context.
- Prioritize - rank by real risk, not just CVSS (see below).
- Remediate - patch, reconfigure, or apply a compensating control.
- Verify - re-scan or re-test to confirm the fix actually closed the finding.
- Report - track metrics over time (open count by severity, mean-time-to-remediate, SLA compliance).
Prioritization: Beyond CVSS
CVSS alone is a poor prioritization signal - it measures theoretical severity, not real-world risk. A mature program combines:
| Signal | What It Tells You |
|---|---|
| CVSS base score | Theoretical severity if exploited |
| EPSS (Exploit Prediction Scoring System) | Probability this specific CVE will be exploited in the next 30 days |
| CISA KEV (Known Exploited Vulnerabilities) | Confirmed active exploitation in the wild - treat as automatic critical priority |
| Reachability/exploitability | Is the vulnerable code path actually called by your application, or is it dead/unused dependency code? |
| Exposure | Is the affected asset internet-facing or internal-only? |
| Business context | Does this asset process payment data, PII, or sit in a regulated workflow? |
A CVSS 9.8 finding in an unreachable code path of an internal tool is lower priority than a CVSS 7.5 finding on an internet-facing login endpoint that's on the CISA KEV list.
SLA-Based Remediation Timelines
A common baseline (adjust to your risk appetite and regulatory obligations):
| Severity | Internet-Facing | Internal Only |
|---|---|---|
| Critical / KEV-listed | 24-72 hours | 7 days |
| High | 7 days | 30 days |
| Medium | 30 days | 90 days |
| Low | 90 days | Best effort / next release cycle |
Track SLA compliance as a leadership-visible metric - "% of critical findings remediated within SLA" is a much more actionable KPI than "total number of open findings."
Centralizing Findings from Multiple Sources
By the time a mid-sized org runs SAST, SCA, container scanning, cloud posture management, and DAST, findings are scattered across 5+ tool dashboards. Options to unify:
- Vulnerability management platforms (DefectDojo - open source, Kenna/Cisco Vulnerability Management, Orca, Wiz) that ingest scanner output via API/webhook and dedupe across sources.
- Ticketing integration - auto-create Jira/GitHub Issues from new critical/high findings so remediation lives where engineers already work, rather than a separate portal nobody checks.
- A single source of truth for risk acceptance - when a team formally accepts a risk instead of fixing it, that decision needs to be recorded and time-bound (with a re-review date), not just left as a dismissed finding.
What a Vulnerability Management Engineer Is Actually Expected to Do
In an interview, be ready to describe: how you'd triage a sudden spike of 200 new SCA findings after a scanner rule update (hint: check if it's a rule change vs. a real new dependency, dedupe against already-accepted risks, don't blanket-assign to already-overloaded teams), and how you'd handle a critical finding in a vendor-supplied component you can't patch directly (compensating controls: WAF rule, network segmentation, disabling the vulnerable feature, escalating to the vendor with a defined timeline).
Best Practices
- Automate ticket creation, not just detection - a finding that doesn't reach an owner's queue doesn't get fixed.
- Track time-to-remediate by team, not just org-wide - it surfaces which teams need help or process changes.
- Re-verify fixes - don't close a finding just because a PR merged; confirm the next scan actually shows it resolved.
- Make risk acceptance visible and time-bound - an "accepted risk" that's never revisited is just an unfixed vulnerability with extra paperwork.