Velocity + Safety: Security Metrics All DevOps Should Care About

The talk opens by asking why security metrics are so hard to get right, noting that a podcast discussion on the topic needed about half an hour to reach concrete choices. It argues that metrics should speak to engineers and leadership, not only the security team, and that they can explain strengths, weaknesses and resourcing needs. DORA measures such as deployment frequency, lead time, time to recovery and change failure rate are introduced as a simple model that engineering already understands.

Older approaches come under scrutiny. Count-based figures, raw tool totals and training completion rates are described as lacking context or misleading readers. Newer candidates include environment coverage, control rollout, open findings per control, a security detection rate that should fall as developers learn, mean time to resolve, and exposure windows for accepted risks. A cost view converts earlier fixes into saved developer hours.

Audience questions focused on ranking findings by real business risk and on moving leadership away from vulnerability counts, which the speaker acknowledged is hard in large organizations. Suggested transitions include showing old and new metrics side by side and gradually shrinking the old ones. The takeaway is to tie metrics to velocity and business risk, and to automate data collection so the numbers can be repeated. The talk closes with a product pitch for a centralized platform that gathers that data.