New vulnerabilities are published every day, and attackers exploit many of them within days. Vulnerability management is the continuous process of finding weaknesses in your own assets and fixing them in order of risk; patch management is the operational part that tests and deploys updates. It is a cycle, not a project. For what a vulnerability is, see Vulnerabilities and Risk; for CVE, NVD, Exploit-DB and scanner tools see Vulnerability Scanning.
The Lifecycle
Discover --> Prioritise --> Remediate --> Verify --> Report
^ |
+--------------------- repeat ---------------------+
| Stage | Activities |
|---|---|
| Discover | Maintain asset inventory, scan, ingest advisories and vendor bulletins |
| Prioritise | Combine severity, exploitability, exposure and asset value |
| Remediate | Patch, mitigate, compensate or accept |
| Verify | Rescan and confirm the vulnerability is gone |
| Report | Metrics to management, exceptions, trends |
Asset inventory dependency
You cannot scan or patch what you do not know exists. Keep a current inventory of hardware, software, cloud resources and owners, with criticality ratings (see Asset Classification). Unknown "shadow IT" is usually where the worst findings hide. See also Attack Surface and Vectors.
Scan Types
| Dimension | Options | Notes |
|---|---|---|
| Credentials | Authenticated vs unauthenticated | Authenticated logs in and sees installed software and configuration: more accurate, fewer false positives. Unauthenticated shows the attacker's outside view |
| Method | Network scan, agent-based, web-application scan | Agents work for roaming or remote laptops and cloud instances; web-app scanners test for flaws such as injection |
| Position | Internal vs external | External shows what the internet sees; internal shows what an intruder or insider could reach |
Scanning can disrupt fragile systems and generate load, so schedule it and get authorisation. Use both authenticated internal scans and external scans regularly. Lab walk-through: Vulnerability Scanner Overview.
Scoring and Prioritisation
You will not fix everything at once, so rank by real risk.
| Input | Meaning |
|---|---|
| CVSS | Standard 0-10 severity score of the flaw itself; says nothing about your environment |
| Exploit availability | Public exploit code or active attacks make a flaw urgent |
| CISA KEV | Catalogue of vulnerabilities known to be exploited in the wild; treat entries as top priority |
| EPSS | Probability estimate that a vulnerability will be exploited soon |
| Asset criticality | Business importance and data sensitivity of the affected system |
| Exposure | Internet-facing vs internal, reachable by untrusted users, existing compensating controls |
A medium CVSS flaw on an internet-facing system with a public exploit usually outranks a critical CVSS on an isolated test box. This is risk-based prioritisation, linking to risk assessment.
False positives
Scanners guess from version banners and checks. Validate findings before sending them to system owners (confirm the version, test safely, check if a backport patched it); too many false findings erodes trust.
Remediation Options
| Option | When |
|---|---|
| Patch / update | Default; fixes the root cause |
| Mitigate | Config change, disable a feature or service, restrict access until a patch exists |
| Compensate | Add controls (WAF, segmentation, extra monitoring) when the flaw cannot be removed |
| Accept | Documented, approved, time-limited decision when cost outweighs risk |
| Transfer / avoid | Insurance, or retire the system |
These map directly onto Risk Response. Every exception needs an owner, expiry date and sign-off.
Patch Management Cycle
Monitor vendor releases --> Test --> Stage (pilot group) --> Deploy --> Verify --> Document
- Test in a non-production environment for compatibility.
- Stage to a small pilot ring, then widen.
- Deploy in maintenance windows with a rollback plan.
- Verify with rescans and endpoint compliance reports.
Patches are changes, so follow Change Management. Emergency patching (actively exploited flaw) uses an expedited change path: shorter testing, tighter monitoring, retrospective documentation.
Hard cases: legacy and end-of-life software, operational technology, and systems with no vendor patch.
SLAs
Set remediation deadlines by severity and exposure, for example faster for KEV-listed or internet-facing items and slower for low-risk internal findings. Define them in policy (Security Policy) and measure compliance. Exact timeframes are an organisational decision; do not copy numbers blindly.
Zero-Days and Virtual Patching
A zero-day is exploited before a fix exists. Responses: apply vendor workarounds, restrict exposure, increase monitoring, and use virtual patching - blocking the exploit at a WAF, IPS or firewall rule without changing the vulnerable software. It buys time but is not a substitute for the real patch. Also see System Hardening.
Metrics
| Metric | Why |
|---|---|
| Asset coverage (scanned vs known) | Visibility gaps |
| Mean time to remediate by severity | Speed |
| SLA compliance rate | Process health |
| Open critical/KEV findings, age | Exposure |
| Recurring and reopened findings | Quality of fixes |
| Exceptions outstanding | Accepted risk |
Key Points
- Inventory first; you can only manage what you know.
- Prioritise using exploitability, exposure and asset value, not CVSS alone.
- Patch through change management; keep an emergency path.
- If you cannot patch, mitigate or compensate; document accepted risk.
- Verify with rescans and report trends.
Hands-on
- Vulnerability Scanner Overview - authenticated/unauthenticated scans, Nessus, OpenVAS, CVSS