Human vs. Robot: Why you should automate your vulnerability management program

### Overview In this Forward CloudSec talk, Kazia (Senior Software Engineer at Airbnb) and Katya Marshall (Engineering Manager at Airbnb) discuss transforming traditional vulnerability management into an automated, engineering-driven program. Comparing repetitive manual triage to the myth of Sisyphus—suggesting an alternate talk title, "Sisyphus and the CVE Feed"—the speakers highlight the impossibility of manually triaging every alert or catching 100% of vulnerabilities. Instead of relying on manual security operations and chasing asset owners, organizations should automate detection, risk contextualization, ticket lifecycle management, and remediation verification.

### Key Topics - **Traditional Vulnerability Management Pitfalls**: Manual triage, inflated severities, vague advisories, scanner noise, and alert fatigue lead to slow remediation and degraded trust with developer teams. - **Engineering-Driven Objectives**: Shifting the focus from manual review to reducing false positives, scaling across cloud infrastructure, establishing service owner accountability via programmatic SLAs, and understanding root causes. - **Preventative Measures**: Pairing automated detection with preventative guardrails like patching cadences and frequent image deployments (containers, EC2) to stop vulnerabilities before they reach production. - **Developer Partnership**: Avoiding purely top-down mandates, aligning security goals with engineering priorities (e.g., deprecating old internal tool versions), and implementing clear SLA extension procedures.

### Technical Details - **Data Ingestion and Standardization**: Rather than using proprietary vendor consoles, Airbnb ingests raw scanner findings programmatically via vendor APIs. Data pipelines leverage Apache Airflow to handle large vulnerability streams and store standardized data in Hive/Presto. - **Unique Identifiers (UUIDs)**: Findings are assigned UUIDs representing the asset and the vulnerability (or package version), allowing deduplication and lifecycle tracking across multiple scanning tools. - **Risk Contextualization**: Risk scoring merges external metrics (vendor scores, CVSS environmental factors, exploit mechanics like network vs. local or required user interaction) with rich internal metadata. Metadata gathered via tools like OSquery and internal infrastructure services identifies whether an asset is externally facing, holds PII, or resides in an isolated sandbox environment. - **Central Reporting Service & Verification**: A modular reporting service ingests standardized risk data, manages programmatic Jira ticketing, deduplicates findings across scanners, and handles owner assignment. Upon closure, the system programmatically verifies remediation by checking ongoing scanner output or cross-referencing internal deployment data. - **Real-World Incident Response**: During the Log4Shell incident, the team rapidly wrote code tracking vulnerable Java services, fed them into the reporting service to generate targeted remediation tasks with tight SLAs, and cross-referenced fixed tickets against actual deployment data to catch unpatched deployments.

### Takeaways Organizations should treat vulnerability management as a software engineering discipline. By aggregating scanner data via APIs into centralized, standard data formats, leveraging non-traditional tools (like Apache Airflow and OSquery), and prioritizing programmatic risk contextualization over manual operations, security teams can scale effectively and drive down false positive noise.