Vulnerability Management

What is a Vulnerability?

A vulnerability is a weakness in software, hardware, or system configuration that can be exploited to violate security policy. The NIST Glossary definition is precise: a flaw or weakness in system procedures, design, implementation, or controls that could be exercised accidentally or intentionally and result in a security breach. See NIST glossary. In practice, vulnerabilities include coding defects (like injection bugs), insecure defaults (like exposed admin interfaces), and design errors (like weak trust boundaries). A vulnerability is not automatically catastrophic; impact depends on where the weakness exists, who can reach it, and what controls sit around it.

It helps to separate commonly mixed terms. A threat is what can exploit the weakness: a threat actor, malware campaign, botnet, insider, or accidental misuse. Risk reflects likelihood multiplied by impact in your specific environment. Exposure is reachability: can an attacker realistically touch the vulnerable service from the internet, partner network, VPN, or only local host? One CVE in an isolated lab system and the same CVE on an internet-facing production gateway do not represent the same operational problem. Good vulnerability management begins with this distinction, because teams that collapse all terms into one tend to overreact to noisy findings and underreact to exploitable paths.

The CVE System

CVE stands for Common Vulnerabilities and Exposures. It is the global naming system that gives publicly disclosed vulnerabilities unique identifiers such as CVE-2024-3094. The program is managed by MITRE and sponsored by CISA in the United States. The public portal is cve.org, and process details are documented at CVE Program Process. CVE IDs solve a coordination problem: without a standard identifier, vendors, researchers, defenders, and tooling platforms would use inconsistent names for the same issue.

CVE Numbering Authorities (CNAs) are approved organisations that assign CVE IDs to vulnerabilities they discover or coordinate. CNAs include major vendors, open-source foundations, and national CERT-related entities. The lifecycle usually starts with a report, then triage and validation, then ID assignment, then publication with references and affected product details. A CVE record itself is an identifier and minimal description, not a full risk verdict. It tells you “this issue exists and is publicly tracked.” You still need enrichment from sources like NVD, vendor advisories, and exploitation intelligence to make remediation decisions.

The Vulnerability Lifecycle

Most vulnerabilities follow a recognisable lifecycle: discovery, disclosure, assignment, remediation, and eventual deprecation. Discovery can come from independent researchers, internal vendor security teams, bug bounty participants, or attackers. Disclosure paths vary. Coordinated disclosure gives vendors time to prepare fixes before details are fully public. Full disclosure publishes technical detail immediately, often increasing short-term defender pressure but reducing the chance a flaw remains quietly ignored. After validation, a CVE ID is assigned and advisory material is published.

Patch availability starts the operational race. Once updates are released, defenders begin remediation while attackers reverse-engineer patches and weaponise proof-of-concept code. For high-value vulnerabilities, exploitation may begin within hours or days of public release. The window between patch publication and broad deployment is often where incidents occur. Eventually, products reach end of support, and vulnerabilities in those versions may remain permanently unpatched unless organisations migrate or isolate them. Effective programs treat vulnerability lifecycle management as a time-sensitive workflow, not a monthly reporting ritual.

Vulnerability Databases

Vulnerability intelligence comes from multiple databases, each with distinct strengths. The National Vulnerability Database (NVD) is operated by NIST and enriches CVEs with structured metadata including CVSS scoring, Common Platform Enumeration (CPE) product matching, and Common Weakness Enumeration (CWE) categories. OSV focuses on open-source vulnerabilities with ecosystem-native package matching and commit-level ranges that often improve dependency triage. GitHub Security Advisories (GHSA) provides package and ecosystem advisories integrated with repository dependency analysis.

Vendor advisories remain essential because vendors publish product-specific context first, including mitigations, workarounds, exploit notes, and patch guidance. Examples include Microsoft MSRC, Cisco PSIRT, VMware advisories, and cloud-provider bulletins. No single source is complete in real time, so mature programs aggregate and reconcile. This is why operational platforms ingest CVE, NVD enrichment, EPSS probabilities, KEV indicators, and vendor updates together. If your process depends on one feed alone, you will either miss critical context or chase stale records with limited remediation value.

Prioritisation

Not all CVEs deserve immediate action, and severity alone is insufficient. Prioritisation combines several signals. CVSS estimates technical severity; EPSS estimates near-term exploitation probability; KEV confirms active exploitation; asset criticality captures business importance; and exposure describes attacker reachability. Add compensating controls such as network segmentation, endpoint hardening, application firewalls, and strong authentication. A remotely exploitable vulnerability on an internet-facing identity system with no compensating controls should outrank a higher-scored issue on an isolated internal test host.

Practical triage models use weighted scoring or clear decision buckets. Example: KEV-listed vulnerabilities on exposed assets are emergency remediation; high EPSS and high CVSS on production services are urgent; high CVSS but low EPSS with strong controls may fit standard patch cadence; low severity and low exposure may be accepted with review. The key is consistency and evidence. Document why an item was escalated, deferred, or accepted so decisions remain defensible during audits, incident reviews, and executive reporting.

Vulnerability Management Programs

A vulnerability management program is a continuous operating cycle: asset inventory, scanning and discovery, prioritisation, remediation, verification, and reporting. Asset inventory is foundational. You cannot protect systems you do not know exist, and unknown assets usually carry the oldest software and weakest controls. Discovery combines authenticated scanners, software composition analysis, cloud posture checks, and external attack surface monitoring. Prioritisation converts findings into action queues mapped to owners and service tiers.

Remediation includes patching, configuration hardening, compensating controls, and formal risk acceptance where necessary. Verification confirms that fixes are applied and effective, usually by rescanning or validation scripts. Reporting tracks trends, SLA adherence, and residual risk. Mature programs integrate with change management and release cadences so security work becomes routine rather than emergency-only. In Australia, ASD Essential Eight explicitly includes Patch Applications and Patch Operating Systems as core mitigation strategies, reinforcing that patch governance is not optional operational hygiene.

Common Mistakes

A frequent mistake is patching only vulnerabilities rated High or Critical by CVSS while ignoring medium-severity issues that show active exploitation. Another is failing to define and enforce remediation SLAs by severity and asset tier, which leads to indefinite backlog growth. Many teams also run scans without consistent ownership, leaving findings unresolved across business units. False confidence appears when dashboards look active but closure rates and verification quality remain poor.

The most damaging structural issue is missing or inaccurate asset inventory. If assets are not mapped to owners, environments, and business functions, prioritisation collapses. Other gaps include weak exception governance, no post-remediation validation, and limited executive reporting on residual risk. Improve by setting clear SLA policies, integrating exploitability signals, tracking mean time to remediate, and auditing exceptions regularly. Success is measured by reduced exploitable exposure over time, not by scan volume or number of open tickets.

Check Your Exposure

Turn theory into action by checking current exposure against known vulnerabilities and exploitation signals. Use patch8.link42.app to explore CVE, CVSS, EPSS, and KEV-informed prioritisation workflows.