Vulnerability Management

The vulnerability management lifecycle

Vulnerability management is the continuous process of identifying, assessing, prioritizing, remediating and verifying weaknesses in an organization's systems and software. "Continuous" is the key word: new vulnerabilities are published every day, and new systems appear every week, so a one-time cleanup is outdated within a month.

Report closes the loop: management needs to see whether the number of open critical findings goes down, how long fixes take, and which risks were accepted. Those numbers decide whether the process gets enough people and maintenance windows.

Asset inventory first

You cannot protect what you do not know you have. A scanner only scans the address ranges and systems it is pointed at; the forgotten test server, the webcam on the office network and the cloud account a project team opened with a credit card stay invisible. An asset inventory lists hardware, software, cloud resources and their owners, together with how critical each one is to the business. It is the foundation of vulnerability management: it defines the scope, tells you whom to call about a finding, and supplies the "how important is this system?" context for prioritization.

Inventories drift, so they are kept current by several sources at once: the configuration management database, endpoint management and endpoint detection and response (EDR) agents, network discovery scans, and the cloud providers' own resource listings. Differences between those sources are themselves useful findings.

Vulnerability scanning

A vulnerability scanner is a tool that automatically checks systems against a database of known vulnerabilities and misconfigurations, and reports what it finds with a severity for each. Scanners work in three main ways:

Scanners report false positives, for example a vulnerability "found" because of a version number, while the operating system vendor has already backported the fix into that version. They also miss things: custom applications, logic flaws and anything outside the scope. Every finding is therefore assessed before work is assigned: is it real, does it apply in this configuration, and who owns the system?

Container images and infrastructure code are scanned too: see image scanning and security scanners for IaC.

CVE and CVSS

CVE: a name for each vulnerability

CVE (Common Vulnerabilities and Exposures) is the public list of identifiers for known vulnerabilities, in the form CVE-year-number. Each identifier refers to one vulnerability, so a vendor advisory, a scanner finding and a news article can all be sure they mean the same thing. The well-known Log4Shell vulnerability in the Log4j logging library, for example, is CVE-2021-44228. The program is operated by the MITRE Corporation with funding from the United States Cybersecurity and Infrastructure Security Agency (CISA), and identifiers are assigned by many CVE Numbering Authorities, including large software vendors. A CVE entry says what the vulnerability is, not how bad it is in your environment.

CVSS: how severe is it?

CVSS (Common Vulnerability Scoring System) is an open standard, maintained by FIRST (the Forum of Incident Response and Security Teams), that rates the technical severity of a vulnerability with a score from 0.0 to 10.0. The base score is calculated from base metrics that describe the vulnerability itself. In CVSS version 3.1 those are:

• Exploitability: attack vector (from network down to physical access), attack complexity, privileges required, and whether user interaction is needed.
• Scope: whether a successful attack can affect components beyond the vulnerable one.
• Impact: the effect on confidentiality, integrity and availability (none, low or high).

The metrics are written as a vector string. CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H reads: reachable over the network, low complexity, no privileges and no user interaction needed, and high impact on all three; its base score is 9.8. Version 4.0, published in 2023, refines the metrics (it adds "attack requirements" and drops "scope", among other changes) and renames the optional groups; both versions are in use, so check which one a score comes from. Optional threat and environmental metrics let an organization adjust the base score for active exploitation and for its own environment.

Severity bands

Scores are grouped into qualitative bands, which most tools and patch policies use:

The program below maps scores to these bands, including the boundary values, and then sorts a fake list of scan findings. It does not sort by score alone: findings on the CISA list of known exploited vulnerabilities (see the next section) come first, then the severity band, and within a band, internet-facing systems before internal ones.

def severity(score):
    """Map a CVSS base score (0.0-10.0) to its qualitative severity band."""
    if not 0.0 <= score <= 10.0:
        raise ValueError(f"not a CVSS score: {score}")
    if score == 0.0:
        return "None"
    if score < 4.0:
        return "Low"
    if score < 7.0:
        return "Medium"
    if score < 9.0:
        return "High"
    return "Critical"


# Fake scan findings: (finding, host, CVSS base score, known exploited, internet-facing)
findings = [
    ("Outdated TLS configuration", "web01", 5.3, False, True),
    ("Remote code execution in VPN gateway", "vpn01", 9.8, True, True),
    ("Privilege escalation in print service", "pc-0447", 7.8, True, False),
    ("SQL injection in intranet app", "intra01", 8.8, False, False),
    ("Server version shown in HTTP header", "web01", 0.0, False, True),
    ("Denial of service in file server", "fs01", 6.5, False, False),
    ("Weak SSH cipher allowed", "jump01", 3.7, False, True),
]

for score in (0.0, 3.9, 4.0, 6.9, 7.0, 8.9, 9.0, 10.0):
    print(f"{score:>4}  {severity(score)}")
print()

BANDS = ["None", "Low", "Medium", "High", "Critical"]


def priority(finding):
    name, host, score, exploited, exposed = finding
    # Known exploited first, then severity band, then internet-facing, then score.
    return (exploited, BANDS.index(severity(score)), exposed, score)


ranked = sorted(findings, key=priority, reverse=True)
for name, host, score, exploited, exposed in ranked:
    flags = ("KEV " if exploited else "    ") + ("internet" if exposed else "internal")
    print(f"{score:>4}  {severity(score):<8}  {flags:<12}  {host:<8}  {name}")

 0.0  None
 3.9  Low
 4.0  Medium
 6.9  Medium
 7.0  High
 8.9  High
 9.0  Critical
10.0  Critical

 9.8  Critical  KEV internet  vpn01     Remote code execution in VPN gateway
 7.8  High      KEV internal  pc-0447   Privilege escalation in print service
 8.8  High          internal  intra01   SQL injection in intranet app
 5.3  Medium        internet  web01     Outdated TLS configuration
 6.5  Medium        internal  fs01      Denial of service in file server
 3.7  Low           internet  jump01    Weak SSH cipher allowed
 0.0  None          internet  web01     Server version shown in HTTP header

Notice that the 7.8 privilege escalation ranks above the 8.8 SQL injection: one is known to be used by attackers right now, the other is not. That is the core idea of the next section.

Prioritizing beyond the score

A large organization easily has tens of thousands of open findings, far more than it can fix at once, and a large share of them are rated High or Critical. CVSS describes how bad a vulnerability could be; it does not say how likely it is to be used against you, or how much that system matters. Good prioritization combines several inputs:

• Known exploitation. The Known Exploited Vulnerabilities (KEV) catalog of CISA lists vulnerabilities with evidence of active exploitation. A KEV entry moves a finding to the top of the list, whatever its score. The KEV catalog is not complete; absence from it is no proof of safety.
• Likelihood of exploitation. The Exploit Prediction Scoring System (EPSS), also maintained by FIRST, estimates the probability that a vulnerability will be exploited in the coming 30 days. Most vulnerabilities are never exploited in practice; EPSS helps find the few that probably will be.
• Asset criticality. The same vulnerability matters more on the payment server or a system that controls a physical process than on a test machine. This is where the asset inventory pays off.
• Exposure. A system reachable from the internet can be attacked by anyone; one deep inside a segmented network first requires another foothold. Network segmentation and other controls change the real risk.

Zero-day vulnerabilities

A zero-day vulnerability is a vulnerability that attackers know about or exploit before the vendor has released a fix, so defenders have had "zero days" to patch. No scanner can find a vulnerability that is not yet in its database, and no patch exists. The defenses are the general ones: defense in depth, least privilege, segmentation, monitoring for unusual behavior, and the ability to apply the vendor's temporary mitigation quickly once it is announced. When a zero-day in a product you use makes the news, the first question is the asset inventory's: where do we run this?

Remediation, deadlines and exceptions

Remediation usually means applying a patch or upgrade; sometimes it means changing a configuration or removing software nobody needs. To make the work predictable, organizations set remediation deadlines (service level agreements, SLAs) per severity. The exact numbers are a policy decision; a typical example:

After the fix, the finding is verified by a rescan or a manual check. A ticket closed as "patched" while the old version still runs is one of the most common gaps in vulnerability management.

Compensating controls and exceptions

Sometimes a fix cannot be applied in time: the vendor has no patch yet, the system is certified in its current state (common in medical and industrial equipment), or the patch breaks a critical application. Then a compensating control reduces the risk another way: isolating the system in its own network segment, blocking the vulnerable service at the firewall, adding extra monitoring, or disabling the affected feature.

When the remaining risk is accepted, that is recorded as a formal exception: which finding, why it cannot be fixed, which compensating controls apply, who accepted the risk (a business owner with the authority to do so, not the administrator) and an expiry date for review. Risk acceptance is one of the risk treatment options described in threats, vulnerabilities and risk. An exception without an expiry date tends to become permanent.

Penetration testing and red teaming

Scanning finds known weaknesses one by one. A penetration test is an authorized, simulated attack on a defined set of systems by skilled testers, to find vulnerabilities and show what an attacker could actually achieve by exploiting and combining them. Its report lists findings with evidence and advice for fixing them. A red team exercise goes further: a longer, goal-oriented simulation of a real adversary, often unannounced to the defenders, to test detection and response as much as the systems.

Every test is bounded by rules of engagement: the scope (which systems, addresses and applications are in, and which are explicitly out), the allowed techniques, the time windows, how to handle sensitive data found along the way, emergency contacts and a stop procedure if something breaks. When a development team should call one in, and what to prepare: Security Testing › Penetration testing.

Disclosure, bug bounties and security.txt

Vulnerabilities are also found by outsiders: researchers, students, customers. Responsible disclosure, now usually called coordinated vulnerability disclosure (CVD), is the practice in which the finder reports a vulnerability privately to the owner, the owner fixes it within a reasonable time, and details are published only afterward, ideally in agreement. The finder acts in good faith and does no more than needed to demonstrate the problem; the owner promises not to report finders who follow its policy to the police or take legal action against them.

A bug bounty program adds a reward, often run through a specialized platform, with its own scope and rules.

security.txt

Finders often fail to reach the right person: the general inbox ignores the report, or it lands with marketing. RFC 9116 defines a small text file at /.well-known/security.txt on a website, which tells researchers where to send reports. Contact and Expires are required; the other fields are optional:

Contact: mailto:security@example.com
Expires: 2027-09-30T22:00:00.000Z
Preferred-Languages: nl, en
Policy: https://www.example.com/coordinated-vulnerability-disclosure
Canonical: https://www.example.com/.well-known/security.txt