Why This Matters#

Every system has vulnerabilities. The question isn’t whether they exist — it’s whether you find them before attackers do, and whether you fix the right ones fast enough. Vulnerability management is the continuous process of discovery, assessment, prioritization, and remediation.

Vulnerability Lifecycle#

flowchart LR
    Discover["Discover<br/>(scan, report, disclose)"] --> Assess["Assess<br/>(CVSS + context)"]
    Assess --> Prioritize["Prioritize<br/>(risk-based)"]
    Prioritize --> Remediate["Remediate<br/>(patch, mitigate, accept)"]
    Remediate --> Verify["Verify<br/>(rescan, validate)"]
    Verify --> Report["Report<br/>(metrics, trends)"]
    Report --> Discover

CVE, CWE, and CVSS#

CVE (Common Vulnerabilities and Exposures)#

Unique identifier for a specific vulnerability:

CVE-2024-3094 (XZ Utils backdoor)
CVE-2021-44228 (Log4Shell)
CVE-2023-44487 (HTTP/2 Rapid Reset)

CWE (Common Weakness Enumeration)#

Categories of vulnerability types (the “class” of bug):

CVSS (Common Vulnerability Scoring System)#

Standardized severity scoring (0.0–10.0):

CVSS Severity Ratings#

Beyond CVSS: Risk-Based Prioritization#

CVSS alone is insufficient — a Critical CVE in an isolated test system is less urgent than a High CVE in a public-facing production service.

Factors for Prioritization#

flowchart TD
    CVSS["CVSS Score<br/>(severity)"]
    Exploit["Exploit Availability<br/>(is it being used?)"]
    Exposure["Asset Exposure<br/>(internet-facing? sensitive data?)"]
    Business["Business Context<br/>(revenue impact? compliance?)"]
    
    CVSS --> Risk["Actual Risk"]
    Exploit --> Risk
    Exposure --> Risk
    Business --> Risk

EPSS (Exploit Prediction Scoring System)#

Predicts the probability a vulnerability will be exploited in the next 30 days (0–1.0):

CISA Known Exploited Vulnerabilities (KEV)#

Authoritative list of vulnerabilities actively exploited in the wild. If a CVE is on KEV, it’s being used by attackers NOW — treat as emergency.

Scanning Types#

Infrastructure Scanning#

Application Scanning#

Scanning Pipeline#

flowchart LR
    Commit["Developer<br/>Commit"] --> SAST["SAST<br/>(code scan)"]
    SAST --> SCA["SCA<br/>(dependency scan)"]
    SCA --> Build["Build<br/>(container)"]
    Build --> Image["Image Scan<br/>(CVEs)"]
    Image --> Deploy["Deploy to<br/>Staging"]
    Deploy --> DAST["DAST<br/>(runtime scan)"]
    DAST --> Prod["Production"]
    Prod --> Continuous["Continuous<br/>Scanning"]

Remediation Strategies#

Remediation SLAs#

Software Bill of Materials (SBOM)#

A complete inventory of all components in your software:

Why SBOM Matters#

• Incident response: “Are we affected by Log4Shell?” → check SBOM instantly
• Compliance: Regulatory requirements (US Executive Order 14028)
• Supply chain visibility: Know exactly what’s in your software
• Vulnerability tracking: Continuous monitoring of all components

Vulnerability Disclosure#

Responsible Disclosure Process#

sequenceDiagram
    participant R as Researcher
    participant V as Vendor
    participant P as Public
    
    R->>V: Report vulnerability (private)
    V->>R: Acknowledge (within 5 days)
    V->>V: Develop fix
    V->>R: Share fix timeline
    Note over V: 90-day disclosure deadline
    V->>P: Release patch + advisory
    R->>P: Publish details (after patch)

Bug Bounty Programs#

Metrics and Reporting#

Key Vulnerability Metrics#

Key Takeaways#

1. CVSS is not enough — combine with exploit availability, exposure, and business context
2. CISA KEV = emergency — if it’s on the list, attackers are using it now
3. Shift left — find vulnerabilities in code and dependencies before production
4. SBOM is essential — you can’t protect what you can’t inventory
5. Automate scanning — continuous, not quarterly
6. SLAs drive accountability — define, measure, report
7. Accept risk explicitly — document decisions, set review dates, never ignore silently