Building a Risk Based Vulnerability Management Program

The talk opens with the common ways vulnerability management programs fail. Teams left to their own devices end up with orphaned infrastructure and no clear owner, while strict, CVSS-driven mandates stall product delivery. Recurring prioritization meetings and pushing patching onto engineers also break down, especially when an urgent issue lands between planning cycles.

The approach presented sets default remediation timelines, such as 90, 30 and 7 days, then adjusts them using a likelihood and impact matrix tailored to the organization's own environment. Mitigations such as a WAF, a firewall in front of a system, or network segmentation can justify more time, and an internal risk rating can replace the severity stated in a penetration test report. A worked example involving a recent VMware vulnerability shows how an item moves through each step. Items that still cannot meet expectations escalate to senior leadership, who decide whether to accept the risk or fund the fix.

The takeaways centre on the security team informing risk decisions rather than owning them, feeding scanner output into sprint planning as a stack-ranked list, and monitoring exceptions as the main signal. The speaker acknowledges that the model is hard to scale to very large environments and suggests pairing a GRC function with a technical engineer. Bug bounty severity should also be aligned with what the program actually values.