Vulnerability management is the continuous process of identifying, assessing, prioritising, remediating and verifying weaknesses across your systems. It runs in a loop rather than as a project, and it is not a synonym for scanning - scanning is one input to one stage of it.
The distinction from a vulnerability assessment matters and gets muddled constantly. An assessment is a point-in-time snapshot: what was wrong on Tuesday. Management is the ongoing programme that snapshot feeds.
The five stages
- Inventory. Establishing what you actually have: applications, services, dependencies, endpoints, cloud resources, and who owns each. Continuous, because the estate changes constantly.
- Assess. Examining those assets for weaknesses. Scanning contributes here, and so does penetration testing, code review, and dependency analysis. Different methods find different things.
- Prioritise. Deciding order. Severity, exploitation likelihood, reachability in your specific deployment, and business impact all feed this, and it is the stage most often reduced to sorting by a single score.
- Remediate. Fixing, mitigating, or formally accepting. Accepting is a legitimate outcome as long as it is a decision with an owner and a date, rather than a queue item that aged out.
- Verify. Confirming the fix actually closed the hole. Then back to stage one.
Where programmes actually break
Two stages, consistently, and neither is the assessment.
Inventory. You cannot protect what you do not know exists. The recurring pattern in real incidents is not an unpatched known asset - it is a forgotten one. A staging environment that was never decommissioned, an internal admin tool exposed to the internet, an API version kept alive for one legacy client. None of it appears in a scan of the assets you remembered to scan.
Verification. The fix ships, the ticket closes, and nobody re-runs the specific attack. Sometimes the patch was incomplete. Sometimes it was correct and a later change reintroduced the flaw. Without verification, closed means "someone said so".
The stage everyone invests in is assessment, because it is the one you can buy. The two that decide whether the programme works are the unglamorous ones at either end of it.
Assessment methods are not interchangeable
A frequent source of false confidence is treating one assessment method as covering the ground of another.
| Method | Finds | Misses |
|---|---|---|
| Dependency scanning | Known-vulnerable libraries | Anything in your own code |
| Configuration scanning | Misconfigurations and exposure | Application logic |
| Static code analysis | Dangerous patterns in source | Flaws that exist only at runtime |
| Penetration testing | Exploitable chains, logic abuse | Whatever was left out of scope |
The gap that catches people is the last row of the third method. A broken authorisation check is not a dangerous pattern in the source - the code is written correctly, and the flaw is a decision nobody made. It exists only in the running system, which is why dynamic testing is not optional if you want that class covered.
How each compliance framework treats this cycle is mapped on compliance frameworks and testing.
A note on what this article is not
Worth being direct, because plenty of pages on this topic are a product pitch in a cardigan: Intrudify is not a vulnerability management platform. We do not do asset inventory, we do not aggregate your scanner output, and we are not a network or infrastructure product. We test web applications and APIs, deeply, and we report what we proved.
Vulnerability management is the programme around that. We think the concepts are worth explaining properly whether or not you ever buy anything from us.