This document outlines good starting metrics to measure the effectiveness and operations of your vulnerability management program.
This metric highlights high and critical issues past their SLA to provide visibility to risk owners. By providing this information, opportunities to reprioritize fixes can be identified. This can potentially highlight:
- Engineering teams without proper resourcing or prioritization
- Problems assigning issues to the right owner
- Security team slowdowns in providing remediation guidance
Notes:
- This metric should exclude accepted risk delays, such as those that have been formally risk accepted or have a security exception in place.
- You can expand this to include low-medium as well, however the priority will be higher risk findings.
This metric can highlight a lack of prioritization in remediating internally discovered high or critical issues before a product's release. Generally, high-risk issues should either be addressed before going live, have an approved remediation extension, or have a risk acceptance or exception in place. Issues without an approved extension should be highlighted and investigated. This can potentially highlight:
- Miscommunication on fix guidance
- Inconsistencies between product/engineering team processes
This metric aligns directly with your vulnerability SLAs to determine if issues are fixed within the expected timeframe. This can potentially highlight:
- Compliance or contractual fix timeline violations
- Engineering teams without proper resourcing or prioritization
- Tickets assigned to the incorrect owner
- Security team slowdowns providing remediation guidance
This metric provides insight into vulnerability remediation velocity. This can potentially highlight:
- New security scanners or integrations being turned on, potentially by engineering teams
- Engineering teams without proper resourcing or prioritization
- Security team slowdown providing remediation guidance
This metric measures where vulnerabilities are coming from, for example:
- From vulnerability scanning in a CI/CD pipeline (e.g. SAST, third-party component scanning, secret scanning)
- From vulnerability scanning out of band (e.g. network vulnerability scanner, DAST scanners)
- From a bug bounty
- From a penetration test
- From a threat modeling exercise
- From a developer
This can potentially highlight:
- Where the high/critical issues are coming from and where perhaps additional funding should be focused
- Tools or security programs providing low value
- Where in the product lifecycle issues are being identified and remediated, including issues entering production. In theory, the older a program is, the earlier these issues should be discovered and the trend should improve over time.
The metrics below represent data points for a more advanced program.
This metric highlights vulnerabilities tied to a specific product/service or a particular organization in the company. This can potentially highlight:
- Missing vulnerability scanning adoption
- Deviated processes impacting security posture
- Lack of prioritization
- Lack of resourcing to address risk
By grouping vulnerability types by product or organization, you can highlight recurring issues that may result from missing security control solutions or adoption. Specifically, this can highlight:
- Common misconfigurations propagating internally
- Missing security frameworks for particular languages, frameworks, and/or tech stacks. For example, missing rate-limiting support for Python APIs, whereas Go applications have a solution.
- Teams not adopting available solutions due to lack of awareness
Metrics version 1.2 copied from Sectemplates.com 2024