Vulnerability management is the repeated process of finding weaknesses in your systems, deciding which matter most and fixing them. It is a cycle, not a one-time scan, because new flaws are published every day. This guide walks through the cycle step by step.
What Is The Vulnerability Management Cycle?
A vulnerability is a weakness that an attacker can use. Publicly disclosed flaws in software and hardware usually get a CVE ID, so everyone can refer to the same flaw. Vulnerability management is the routine that keeps track of them in your own systems. For the short definition, see the vulnerability management glossary entry.
The cycle, also called the lifecycle, has six steps: know your assets, scan, rank, fix, verify and report. Then it starts again, because the next batch of flaws is already coming.
Step One: Know What You Run
You cannot fix a system you do not know about. Build a list of servers, laptops, cloud services, applications and internet-facing assets, and note who owns each one.
The weak point is usually the forgotten asset, such as an old test server or an account in a cloud service that nobody tracks. Looking at your company from the outside, the way an attacker does, helps find them. See EASM 101.
Step Two: Scan For Weaknesses
A scanner checks your systems for known flaws, missing patches and risky settings. Scan on a schedule, and again after big changes. An authenticated scan signs in to the system and sees installed software. An unauthenticated scan sees only what a stranger sees. Scans from the inside show what an intruder could reach. Scans from the outside show what the internet can reach.
A scan result is a list of possibilities, not a list of facts. Some findings will be wrong or will not apply to how you use the system.
Step Three: Rank By Real Risk
A scan can return thousands of findings. You cannot fix them all at once, so ranking is the core skill. Three public sources help.
- The CVSS base score published with a flaw rates its general severity. It does not know your environment unless you add the environmental metrics yourself.
- EPSS, published by FIRST, estimates how likely a flaw is to be exploited in the next 30 days.
- The CISA Known Exploited Vulnerabilities catalog lists flaws that attackers are already using.
Start with flaws on the CISA list, then ones that sit on internet-facing systems, then the rest by score. Read more on vulnerability prioritization.
A worked example
CVE-2026-76519 is a CVSS 9.8 file write flaw in Cisco Secure Email Gateway. CISA added it to the catalog on 14 October 2026. A team with an affected gateway facing the internet would put it first, whatever else the scan found. See the CVE-2026-76519 page.
The October critical vulnerabilities review shows the same method across 25 CVEs, including every matching CISA KEV entry in its cutoff set.
Step Four: Fix Or Reduce The Risk
The usual fix is a patch. When a patch is not possible yet, reduce the risk: turn off the feature, block access with a firewall rule or limit who can reach the system.
A kernel example shows why availability and verification are separate: our Ubuntu kernel status and triage report distinguishes work targets from released packages. The CVE-2026-98432 technical profile explains the TCP and IPv4 path behind that patch decision.
Agree on target times for each risk level, and who is responsible for each system. CISA sets a due date for US federal agencies when it adds a flaw to its catalog. For CVE-2026-76519 that date was 17 October 2026, three days after the listing, and other teams can use such dates as a guide. A flaw that is being exploited should be fixed in days, not in the next quarterly window.
Steps Five And Six: Verify And Report
After a fix, scan again to prove it worked. Patches fail, and systems get rolled back.
Then report to the people who decide. Useful figures are the mean time to fix critical findings, how many exploited flaws are still open and which teams are behind. Keep the report to one page and show the trend from month to month.
Brandefense vulnerability intelligence helps with the ranking step by showing which flaws are being exploited.
Active exploitation can compress browser remediation timelines. See our Chrome CVE-2026-125350 alert for a current fixed-version example.
One vendor release may address unrelated privacy, pairing, and memory-safety risks. See our Apple iMessage and Bluetooth update alert for a triage example.
Exposure conditions can differ even when one product release fixes both issues. See our GPUStack SAML and cluster takeover flaws analysis for separate identity and Kubernetes authorization tests.
Fixed versions can differ across supported product branches. See our Firefox 160 sandbox escape fixes alert for a current channel-specific remediation example.
Known exploitation should influence remediation order beyond a base score. See the Outlook CVE-2026-124194 response steps.
Multi-product advisories require branch-specific inventory and remediation. See our Ivanti November 2026 security update comparison for five product families, attacker prerequisites, and fixed versions.
A high severity score still needs an exposure check. See the CVE-2026-120495 Checkmk profile for its monitored-host prerequisite and branch-specific fixes.
For a current example of version inventory and remediation proof, see the Apache HTTP Server CVE-2026-119618 patch playbook.
Research findings need to pass through validation, upstream reporting, vendor fixes, and installed builds. See our Microsoft MDASH Linux kernel research analysis for the 59-report funnel.
A high CVSS score should be read with its exposure conditions. See the CVE-2026-108186 Zoom Workplace profile for the Windows version range, user interaction condition, and update target.
The CVE-2026-110697 Red Hat Quay profile shows how to prioritize a shared registry flaw and verify the matching fixed branch.
The CVE-2026-65840 Fider profile shows why patch triage must check both the installed version and the multi-tenant host mode.
For a conditional login flaw, check configuration alongside version. The CVE-2026-126777 Traccar profile explains its LDAP bind prerequisite and fixed release.
The CVE-2026-106152 Telerik Report Server profile shows how to identify affected versions and confirm the fixed Server URL configuration.
Internet-facing network appliances deserve early remediation when a flaw affects default configurations. See the CVE-2026-120868 NetScaler profile for the affected builds and CERT-EU’s upgrade priority.
For an example of version-based triage and post-update checks, see the PostgreSQL November 2026 release roundup.
For a device-level example, the CVE-2026-124002 XWEB EVO vulnerability profile details an affected-version check and remediation questions for an end-of-service system.
For an end-of-support device example, see the CVE-2026-124010 XWEB EVO vulnerability profile and its inventory and migration checks.
Frequently Asked Questions
Is vulnerability management the same as patching?
No. Patching is one way to fix a flaw. The process also covers finding assets, scanning, ranking, checking and reporting.
How often should we scan?
Often enough that new flaws do not sit unseen. Many teams scan weekly or continuously, and again after major changes.
What is the difference between a vulnerability scan and a penetration test?
A scan runs automatically and lists known weaknesses. A penetration test is done by people who try to break in and show what an attacker could really do.
