Madness of Vulnerability Management in Modern Cloud, Container, How to Win the Battle...

## Overview

This talk addresses how cloud and container technologies have fundamentally transformed vulnerability management from traditional on-premise approaches. The speakers discuss the dramatic increase in vulnerabilities (262,000 CVEs in NVD at time of talk; 40x growth since 2015), the failure of traditional CVSS scoring and SLA-based remediation to address modern complexity, and present a threat-centric framework for prioritizing vulnerabilities.

## The Vulnerability Explosion

Vulnerability numbers have grown exponentially—40x since 2015, with projections reaching 1 million by 2031. Meanwhile, security team budgets grow only 6% annually, creating an impossible gap. Exploitation timelines have compressed dramatically: from 15 days to 3 minutes between CVE disclosure and working exploit. LLMs have accelerated both offense and defense: approximately 50% of new code is now generated via LLMs ("vibe coding"), and attackers can automatically generate working exploits by feeding vulnerability descriptions into ChatGPT. Additionally, attackers are developing GPT-style code scanners and exploit generators, giving them new scale and speed.

## The Complexity Shift-Left Exposed

Traditional vulnerability management in 2015 focused on network scanning and OS patching with simple remediation paths. Cloud adoption and shift-left scanning practices revealed nightmarish complexity: software composition analysis, container vulnerabilities, supply chain dependencies, and multiple deployment paths. A single import statement (e.g., importing a library or LLM SDK) can expose massive attack surface. The industry's response—running multiple scanners at every stage—creates overwhelming noise: the same vulnerability is reported 5-10 times (by code scanners, container scanners, registry scanners, runtime scanners) with no clear remediation path.

## Core Problem: Missing Context and Coordination

The speakers identify that application security and infrastructure/cloud security are treated as separate disciplines, creating gaps. Four foundational elements are missing from most programs: 1. **Attribution**: Who owns this vulnerability/asset? 2. **Lineage**: How does code transform through container images to running deployments? 3. **Traceability**: Which application built this specific container? 4. **Reachability**: Can this vulnerability actually be exploited (at code level, container level, network level, or by known threat actors)?

Containers are the "hinge point" between application and infrastructure security, but organizations rarely coordinate across application security, infrastructure security, and operations teams. The traditional response—dumping all findings into spreadsheets and telling developers to "fix all of this by SLA X, Y, Z"—fails because attackers only need to be right once while developers must be right always.

## Threat-Centric Prioritization Framework

Rather than reporting all discovered vulnerabilities, the speakers propose a layered risk model: - **CVSS score** (raw severity) - **Business context** (is the affected application running, and how critical is it?) - **Reachability analysis** at four levels: code-level loading, container runtime execution, network exposure, and threat actor interest (via CTI) - **Exploit evidence** (EPSS scoring, CISA Known Exploited Vulnerabilities, threat intelligence) - **Vulnerability DNA**: Using CWE classification and machine-learning-based reclassification of NVD data, they identify patterns that predict exploitability. Key finding: approximately 40% of ransomware exploits involve vulnerabilities with remote code execution or memory corruption as their threat impact, suggesting these types are inherently more likely to be targeted by threat actors. Zero-day exploits and ransomware campaigns show consistent patterns: remote code execution and memory corruption vulnerabilities are leveraged far more frequently.

This approach dramatically reduces noise: starting with 262,000+ raw vulnerabilities, filtering by exploit availability, reachability analysis, and predicted exploitability yields a tractable subset actually requiring remediation.

## Practical Recommendations

1. **Replace SLA-driven remediation** with risk-based targets. Instead of "fix all critical by SLA," communicate a risk threshold and allow teams to choose remediation strategies (patch, update library, rebuild deployment, decommission application). 2. **Eliminate contextual duplication**: Map duplicate reports of the same vulnerability back to the actual remediation location (source repository or library), rather than asking developers to fix the same issue across multiple scanner reports. 3. **Shift scanning left to registry level**: Scan container images before deployment to prevent vulnerable images from running in the first place. 4. **Coordinate teams intelligently**: Patch teams don't need vulnerability details until a patch exists; network security teams deploy signatures for temporary mitigation; development teams fix the source. Provide each team only actionable information relevant to their role. 5. **Use proven risk formulas**: Risk = likelihood × impact. Populate likelihood with cloud-specific factors (reachability, threat actor activity), and impact with business context (application criticality).

## Key Takeaways

Modern vulnerability management cannot treat application and infrastructure security as separate. It requires unified asset ownership, traceability through the entire software pipeline, and cross-team coordination. Traditional CVSS-centric scoring and blanket SLAs create false confidence and alert fatigue. A threat-centric approach using exploit evidence, reachability analysis, and vulnerability DNA classification allows security teams to focus remediation where it actually reduces business risk. The core insight: don't report more vulnerabilities—report fewer, but more accurate ones, to the right teams, at the right time.