Vulnerability management is the continuous process of finding weaknesses in systems, deciding which ones matter in context, fixing or mitigating them, and confirming the fix.
Our take. The scanner's severity score is the least important number on the report. What decides whether a weakness matters is whether the system is exposed, whether the flaw is being exploited in the wild, and what sits behind it, and none of those is in the score. Teams that patch by score patch the wrong things first and exhaust themselves doing it.
Every piece of software has flaws, some of them security-relevant, and a public catalogue assigns each disclosed one an identifier and a severity score. A scanner compares the software versions on your systems against that catalogue and produces a list. The list is the beginning of the work, not the result, because a scanner sees version numbers rather than exposure: a critical flaw in a library on a server that no network can reach is a lower priority than a moderate one in the login page facing the internet, and the score says the opposite. Vulnerability management is the discipline of turning the list into a priority order that reflects your systems rather than the catalogue's arithmetic.
Question
Why it changes the priority
Where the answer comes from
Is it exposed?
A flaw nobody can reach cannot be exploited
Your network and asset inventory
Is it being exploited in the wild?
Attackers work from the same catalogue and pick the ones that pay
Published lists of known exploited vulnerabilities
What is behind it?
A flaw in front of the customer database outranks the same flaw in front of a test server
Your data classification
Is there a fix, or only a mitigation?
A missing patch is one task; a configuration workaround is another
The vendor's advisory
Can it be patched without breaking anything?
The answer decides the window, not whether
Your change process
Discover: know what you have. Most missed vulnerabilities are on systems nobody knew were running.
Assess: scan, then apply the questions above. The score is one input.
Prioritise: exposed, exploited and in front of something valuable goes first, whatever the score.
Remediate: patch, reconfigure or isolate, inside a window the priority justifies.
Verify: rescan. A patch that did not apply looks identical to one that did until you check.
The certification exams treat this as an analyst's core skill: the vendor-neutral analyst paper gives vulnerability management a quarter of its weight and asks you to argue a score down or up from context, and the security management credentials ask who accepts the risk of the flaws that cannot be fixed on time. Both are testing the same judgement, which is that a report is not a plan.
In practice
A monthly scan reports four hundred findings, thirty of them rated critical. The team works the criticals in score order and gets through twelve before the next scan arrives. Meanwhile an attacker exploits a flaw rated high, not critical, in an internet-facing file transfer appliance whose exploit had been public for three weeks. The redesign inverts the order: first, anything internet-facing that appears on the known-exploited list, whatever its score; second, anything in front of classified data; then the rest by score. The first pass has nine items. The team clears them in a week, and the file transfer appliance is the second item on the list.
A vulnerability scan finds known weaknesses automatically and continuously. A penetration test has a person try to exploit them, chained together, on a schedule. The scan tells you what is there; the test tells you what it is worth.
Vulnerability management deals with technical weaknesses in systems. Risk assessment weighs threats, weaknesses and impact across the whole organisation, and decides which weaknesses are worth the cost of fixing at all.
Vulnerability management is what you do before an attacker uses a flaw. Incident response is what you do after one has, and a good response ends by feeding the flaw back into the management cycle.
Key takeaways
→The scanner sees versions, not exposure; the score is one input among five.
→Exposed, exploited in the wild, and in front of something valuable goes first.
→Rescan after patching; an unapplied patch looks like an applied one until checked.
Certifications that test this
Vendor exams whose syllabus covers this concept — facts, cost and a preparation path on each page.
A rotating selection from the course directory, drawn from the subcategories where this concept is taught rather than picked for it. Details, price and the provider link are on the course page.
Get certified with Salesforce Data Cloud Consultant certification by practicing actual exam type questions. This Course…
Udemy
FAQ
Should we patch everything rated critical first?
No. Patch what is exposed and being exploited first, whatever its rating, then what protects your most sensitive data, then the rest. A critical flaw on an isolated internal test system can wait behind a moderate one on the internet-facing login page.
How often should we scan?
Continuously for internet-facing systems and at least weekly internally, because new flaws are disclosed daily and the catalogue moves. The monthly scan-and-report cycle that many organisations still run was designed for a slower world.
What if a vulnerability cannot be patched?
Mitigate: isolate the system, restrict who can reach it, add a compensating control, and record who accepted the remaining risk and until when. A flaw with a named owner and a review date is managed; one that is simply left is an incident waiting for a date.
Sources
The primary text this definition rests on. Read it before you trust ours.
