Know
What is Vulnerability Management?
Vulnerability management is broader than scanning. It requires knowing what assets exist, determining which findings are real and relevant, prioritizing based on risk, coordinating remediation, validating fixes, managing exceptions, and measuring whether exposure is actually decreasing.
Why it matters
Organizations usually have more findings than they can fix immediately. Effective programs focus attention on vulnerabilities most likely to create meaningful business risk.
Evidence, not hype
Validated in the real world
Every record is labeled by evidence type and source strength so an incident, a standard, and emerging research are never presented as if they are the same thing.
Chrome release addresses a V8 vulnerability with an exploit in the wild
Google's September 3 desktop release includes 12 security fixes and states that an exploit for CVE-2026-85046 exists in the wild. The notice lists Chrome 152.0.7977.82/.83 for Windows and Mac and 152.0.7977.82 for Linux.
This connects a vulnerability identifier, exploitation evidence, and a software release. The listed versions belong to this announcement; they are not a continuously maintained latest-version list. The notice does not establish victim counts or attacker identity.
EU manufacturer reporting duties apply from September 11, 2026
The Cyber Resilience Act's Article 14 covers actively exploited vulnerabilities and severe product-security incidents: early warning within 24 hours and notification within 72 hours of awareness. Final vulnerability reports are due within 14 days after a corrective or mitigating measure becomes available; final severe-incident reports within one month after the incident notification.
Articles 14, 69, and 71 distinguish reporting triggers and transitional coverage. Article 14 applies from September 11, 2026; general application begins December 11, 2027. These are duties for in-scope manufacturers and products, not universal reporting requirements for every organization.
SolarWinds confirmed malicious code was inserted into Orion software builds
SolarWinds disclosed to the SEC that a compromise of its software build system inserted a vulnerability into Orion product updates released between March and June 2020.
This primary-source disclosure is direct evidence of software supply-chain compromise and the downstream risk created by trusted updates.
Capital One data theft exploited a misconfigured cloud-facing control
The Justice Department described an intrusion into Capital One data through a misconfigured web application firewall; the case ultimately resulted in a federal conviction for computer intrusions and wire fraud.
The case demonstrates how cloud security depends on configuration, identity permissions, monitoring, and data-access controls rather than the cloud provider alone.
Log4Shell provides a concrete example of a CVE with remote-code-execution impact
NVD records CVE-2021-44228, commonly known as Log4Shell, describing how attacker-controlled JNDI endpoints could lead to arbitrary code execution in affected Log4j versions.
This is a practical example of how a CVE identifier, severity information, affected versions, and technical impact are used together during vulnerability response.
CVSS v4.0 formalizes severity, threat, and environmental context
FIRST's CVSS v4.0 specification defines Base, Threat, Environmental, and Supplemental metrics and explains that CVSS communicates vulnerability severity rather than serving as a complete business-risk score.
The standard validates why vulnerability teams should use the vector and relevant context instead of treating one numeric score as the entire remediation decision.
Understand the mechanics
How it works
- 1
Discover and inventory assets.
- 2
Identify vulnerabilities and exposures.
- 3
Enrich findings with exploitability, exposure, asset criticality, and threat context.
- 4
Prioritize remediation.
- 5
Patch, mitigate, remove, or formally accept risk.
- 6
Verify remediation and measure aging or recurrence.
Practice
What to watch for
- Internet-facing vulnerable assets
- Known exploited vulnerabilities
- Long-lived critical findings
- Unknown asset ownership
- Repeated exceptions
- Scanner findings without remediation accountability
Perform
What to do
- 1
Confirm the affected asset and vulnerability.
- 2
Check known exploitation and external exposure.
- 3
Apply the safest effective remediation or mitigation.
- 4
Verify the fix rather than assuming deployment succeeded.
How to reduce the risk
- Asset inventory
- Secure configuration
- Patch management
- Dependency management
- Secure development
- Exposure management
Business impact
- Reduced exploitable attack surface
- Lower incident probability
- Operational patching risk
- Compliance and audit implications
What different roles should do
Security
- Prioritize with context, not scanner severity alone
IT/Engineering
- Own remediation and verification
Executive
- Track aging, exploitable exposure, and exceptions rather than raw vulnerability counts
Framework & standards context
- NIST CSF 2.0
- CISA Known Exploited Vulnerabilities Catalog
Source transparency
Authoritative sources
Last reviewed: 2026-09-02