The discipline of finding, prioritising, and remediating vulnerabilities at the rate they appear — recognising that discovery is incomplete by definition, prioritisation is a judgement that scores cannot replace, and remediation is a workflow rather than a spreadsheet.
A passive approach to vulnerability management treats it as a periodic audit: a scanner runs monthly or quarterly, produces a report listing thousands of findings sorted by CVSS score, the report is filed somewhere, and most findings persist from one report to the next. The activity exists; the outcomes do not. The team is not less exposed than it was last quarter, the patches that did get applied happened by chance rather than priority, and when a Log4Shell-class disclosure arrives, the team scrambles to figure out where the affected library actually runs because the scan reports were never connected to operational reality.
An active approach treats vulnerability management as a continuous workflow. Discovery happens through multiple complementary methods (each catches what the others miss). Prioritisation considers exploitability and exposure, not just severity score. Remediation has owners, SLAs, and tracking. Patch debt is monitored as a compounding liability, not as background. When patching is impossible, mitigations are documented and tracked alongside the un-patched vulnerability — not absorbed silently and forgotten. Bug bounties are deployed deliberately to expand discovery beyond what internal tooling reaches, with the maturity to triage what the programme returns.
The architectural shift is not "we run a scanner." It is: vulnerability management is the operational discipline of converting raw discovery signal into closed remediations on a defined cadence, with prioritisation that reflects actual risk and a workflow that makes accountability explicit — not a stack of reports nobody reads.
No single discovery method finds every vulnerability. SAST finds patterns visible in static code. DAST finds bugs visible in a running application. Dependency scanning finds known-CVE issues in third-party code. Infrastructure scanning finds misconfigurations and unpatched services in the runtime environment. Penetration testing finds chains of weaknesses that automated tools miss. Bug bounties find what creative external researchers find. Threat hunting finds active compromise. Each method has a coverage profile — the categories of vulnerability it does and does not find — and the gaps between methods are where unfound vulnerabilities live. The architectural response is to use complementary methods deliberately, with explicit awareness of what each covers and what each misses.
Pick a category of vulnerability that has not appeared in your scan reports for the last year. Is that because the category is genuinely absent from your environment, or because nothing you run is looking for it? If you can't tell, the discovery surface has gaps you don't know the size of.
NVD — National Vulnerability Database — the canonical source for known CVEs, but only one input in a complete discovery surface; CVE-based tooling finds known issues but cannot find the bugs that haven't been catalogued yet.
The Common Vulnerability Scoring System (CVSS) produces a numerical severity score from 0.0 to 10.0 based on the inherent properties of a vulnerability: attack vector, complexity, privilege required, impact. The score is useful as a normalised description of how bad a vulnerability could be in the abstract. It is not, by itself, a prioritisation. A CVSS 9.8 in code that's never deployed is irrelevant. A CVSS 5.0 in your most internet-exposed service handling the most sensitive data is critical. The relevant question is not severity but risk — and risk is severity multiplied by likelihood multiplied by impact in your environment. EPSS (Exploit Prediction Scoring System) adds likelihood data; CISA's KEV (Known Exploited Vulnerabilities) catalogue tells you what attackers are actually exploiting today; exposure analysis tells you what's reachable from outside; business criticality tells you what damage matters. Risk-based prioritisation considers all of these; score-based prioritisation considers only the first.
Pick the vulnerability backlog in your environment. How is it ordered, and what does the order reflect? If it's sorted by CVSS score alone, the highest-scored items are not necessarily the most-likely-to-be-exploited items, and the ordering is misleading the remediation effort.
FIRST — EPSS (Exploit Prediction Scoring System) — the canonical reference for likelihood-adjusted prioritisation; CISA's Known Exploited Vulnerabilities (KEV) Catalog provides the empirical "what's being exploited right now" data; both are essential complements to CVSS.
A list of CVEs, even a well-prioritised one, is not vulnerability management. The list becomes management when each entry has an owner, an SLA, a status (open / in progress / verified / closed / accepted), an audit trail, and an escalation path when SLAs are missed. Without workflow, findings sit in spreadsheets that nobody reads; with workflow, findings move through states with accountability at each step. The architectural choice is what tool encodes the workflow — purpose-built vulnerability management platforms (Tenable, Rapid7, Qualys), generic ticketing systems (Jira, ServiceNow) configured for vulnerability tracking, or integrated security operations platforms — but the workflow itself is non-negotiable. Without it, the discipline is theatre.
Pick a vulnerability your scanner found six months ago. What's its current status, who owns it, and what changed in the last 30 days? If the status is "open" and no one knows why, the workflow is decorative.
ISO/IEC 27002 — Vulnerability Management Guidance and the underlying ISO 27001 framework — the standards-level treatment that names workflow, ownership, and SLA tracking as core control requirements rather than as nice-to-haves.
Deferred patches accumulate. The single delayed patch this month becomes the deferred queue next quarter, becomes the technical debt that takes a year to address, becomes the unpatched vulnerability that the next opportunistic attacker exploits. Log4Shell — disclosed in late 2021 — was still being exploited successfully in 2024 against systems that had never patched, because the deferral that made sense in week one became the policy that nobody revisited. The architectural response is to treat patching as a sustainability discipline: regular cadence, automation where it can be automated, deliberate exception process where it can't, with the exception list reviewed and pruned, not allowed to grow unbounded. Patch debt is monitored as a metric. Deferred patches have stated reasons and review dates. The team that defers everything because each individual deferral seems reasonable is the team whose patch debt eventually exceeds their ability to address it.
Pick a patch that was deferred in your environment six months ago. What was the deferral justification, what was the review date, and what's its current status? If the answer is "it's still deferred and we don't remember why," the deferral has become the policy, and the patch debt has grown invisibly.
CISA — Patch Management Guidance — the operational reference for sustainable patching practices; ENISA's vulnerability handling guidance provides complementary EU-perspective recommendations on deferral and exception processes.
Sometimes patching is genuinely impossible: the vendor hasn't released a fix, the patch is a breaking change the application can't absorb, the affected system is legacy code with no maintainer, the compensating cost exceeds the residual risk. In these cases, mitigation — compensating controls that reduce exploitability without fixing the underlying flaw — is a legitimate response. WAF rules that block known exploit patterns. Network segmentation that limits the attacker's reach if the vulnerability is exploited. Detection rules that alert on attempted exploitation. Exposure reduction that takes the vulnerable system off the internet. Each is a real control. The architectural discipline is visibility: the mitigation is documented alongside the un-patched vulnerability, tracked in the same workflow, reviewed at the same cadence — not silently absorbed and forgotten. A mitigation that nobody knows is in place will not be maintained, and the mitigation that is not maintained eventually fails to mitigate.
Pick a vulnerability that's been mitigated rather than patched in your environment. Where is the mitigation documented, who owns it, and when was the last verification that it's still effective? If the answer is "we know we have one but we'd have to dig to find it," the mitigation is one personnel turnover away from being lost entirely.
NIST SP 800-40 Rev. 4 — Guide to Enterprise Patch Management — names the patch / mitigate / accept-risk decision explicitly, with documentation requirements for each, framing mitigation as a deliberate alternative rather than a fallback.
Bug bounty programmes are powerful for one specific reason: they bring outside expertise, motivation, and time to your application's security in ways that internal teams cannot match. A well-run bounty programme finds bugs that SAST, DAST, internal pentests, and the internal security team would not — different perspectives find different things. Premature bounties, however, produce two failure modes. They flood the team with low-quality submissions (duplicate reports, out-of-scope findings, abuse) that the team cannot triage. They expose the application to scrutiny it is not ready to receive — bugs are reported faster than they can be fixed, the public history of unfixed bugs becomes a recruiting target for non-bounty attackers. Maturity for a bounty programme means: the application has had its baseline cleaned via internal scanning and pentesting; clear scope (what's in, what's out) is defined; remediation capacity exists to handle the inflow; payout policy is funded and credible. Without these, the bounty produces noise; with them, it produces gold.
If you launched a public bug bounty next month, what's your current capacity to triage and remediate the inflow? If "we'd be overwhelmed in week one," the bounty is premature; the gap to address first is the internal capacity, not the external sourcing.
HackerOne — Vulnerability Disclosure Programmes and Bugcrowd — Vulnerability Disclosure — both maintain documentation on prerequisites, scope-setting, and operational maturity required for effective programmes; the VDP framework from CISA provides government-aligned guidance on coordinated disclosure processes.
The diagram below shows a canonical vulnerability management workflow: multiple discovery sources (SAST, DAST, dependency scanning, infra scanning, pentest, bug bounty) feed a common triage pipeline that prioritises by CVSS + EPSS + exposure + business criticality; findings flow into a workflow with owners, SLAs, and status tracking; remediation produces patches or documented mitigations; metrics (MTTR, patch debt, SLA misses) feed back into the prioritisation and capacity planning.
The team works through findings in CVSS order, top-down. The CVSS 9.8 internal-only theoretical issue gets fixed first; the CVSS 6.5 internet-facing actively-exploited vulnerability waits. The metrics show "we addressed all critical findings" while the actual exposure remains.
Risk-based prioritisation: CVSS as one input alongside EPSS (likelihood), KEV (active exploitation), exposure (reachability), and business criticality. The "fix first" queue is determined by risk, not by score.
A scanner runs, produces 50,000 findings, gets nobody's attention, runs again next week. The activity is theatre — produced output without consumed action. The team has the appearance of vulnerability management without the substance.
Scanning produces managed findings: triaged into queues, assigned to owners, tracked through remediation. Findings without owners and SLAs are not managed; they are decoration. The signal-to-noise ratio of the scanner itself is tuned — false positives suppressed with documented reasoning, not absorbed as background noise.
Every patch this month is deferred to next month. The deferral cycle continues. Six months later, the team has hundreds of un-applied patches, no clear path to applying them, and a steadily worsening exposure profile.
A regular patch cadence with automation handles the routine majority. Exceptions are deliberate, documented, and time-bounded — not the default. Patch debt is tracked as a metric; growing debt triggers attention. Deferral has a justification and a review date; both are reviewed before the next deferral.
A WAF rule was added years ago to block exploitation of a vulnerability. The vulnerability is still un-patched. Nobody currently on the team remembers why the rule exists, but they know not to disable it. The institutional memory is fragile, and the next person to touch the WAF will eventually disable the rule for being noisy.
Mitigations are documented alongside the vulnerabilities they address. The link is explicit: "Vulnerability X is mitigated by control Y; if Y is removed, X re-surfaces at priority Z." Reviews catch when mitigations have lost their context.
The team launches a public bug bounty before internal scanning is mature. Submissions flood in: duplicates of findings the team's own tools would have found, out-of-scope reports, low-quality noise. The team's triage capacity is overwhelmed; quality submitters get discouraged by slow responses; the programme produces little signal.
The bounty starts after the internal programme is mature: baseline findings cleared via SAST/DAST/pentest; scope and rules of engagement clear; triage SLAs realistic; payout policy credible. Begin private (invite-only researchers) before going public; expand scope as capacity proves out.
Each method has a coverage profile; gaps between methods are where undiscovered vulnerabilities live. The full discovery surface is mapped; gaps are addressed deliberately, not hoped away.
Severity is one input; likelihood, active exploitation, reachability, and business impact are others. Risk-based prioritisation puts the actually-most-dangerous items at the top, regardless of what the CVSS score alone would say.
Without ownership, findings drift indefinitely. SLAs by severity make remediation accountable; status transitions track movement; without these, the workflow is theatre.
A metric reveals what reports cannot. Improving MTTR means the system is getting more secure over time; deteriorating MTTR means capacity or process needs adjustment.
Patch debt compounds. The single justified deferral becomes the policy if not reviewed. The metric makes the trend visible; the visibility prompts the conversation.
Deferral without justification is incipient patch debt. Deferral with named owner and review date is a deliberate decision that gets revisited; the difference matters.
Mitigations require maintenance, and maintenance requires visibility. The link between vulnerability and mitigation is explicit; reviews verify the mitigation is still effective.
Unsuppressed false positives drown real findings; silently ignored false positives become "the dashboard everyone learned to skip." Suppressing with reasoning preserves both signal and audit trail.
Exceptions accumulate. Without periodic review, the exception list becomes the hidden risk register. Reviews ensure exceptions still make sense as the environment evolves.
The bounty's value depends on the team's ability to triage and remediate the inflow. Without that ability, the bounty produces noise; with it, the bounty extends the discovery surface in ways no internal programme alone can match.
Other substantive pages in the library that link here: