Understanding DevSecOps KPIs – Part 2: Security Metrics
In this three-part series, we’re looking at the Key Performance Indicators that should be used when measuring the success of a DevSecOps project. In part 1, we built an understanding of traditional DevOps metrics.
In this blog post, we’ll look at the security metrics you should add to your DevSecOps KPIs.
Security Metrics for DevSecOps
The success of a DevSecOps implementation is often measured by how well organizations can repair holes in their software, and breaches in their security. Measuring the detection and resolution of security findings allows your company to understand future security procedures better, and is often highly correlated with success in engineering. Quickly and consistently patching your systems reduces risk and potential exposure to malicious activity and should be carefully tracked.
For the purposes of this article, a security finding is any security-related issue including, but not limited to, vulnerabilities, misconfiguration, or deviation from policy or standards. When responding to security findings, we are looking at four main indicators of success:
| Mean Time Between Findings | We advise you to first look at the meantime between security findings. This stands to represent the average time between each finding and should be as high as humanly possible, as the higher it is, the less frequent the issues. Your Mean Time to Detect (MTTD) will vary based on the industry you are in, as well as the experience and size of your IT team. The most useful preventative measures here are ensuring that both your development and operation teams are well-trained for identifying security threats in the software they are building. |
| Mean Time to Resolve Findings | Intuitively, after the first step of detection, resolution becomes the priority. The Mean Time to Resolve represents the average time between new security findings. You want this number to be as low as possible, allowing them to deal with issues quickly and efficiently to make sure that they do not remain outstanding. |
| Findings per Release | Not every product released by your DevSecOps teams is going to start perfectly. The security findings per release number represent the average amount of security findings for an organization across all production releases within a company not using sprint-based releases. Oftentimes companies release products that are not fully secure and spend tremendous amounts of time and effort in resolution after the fact. Spend as much time as possible to pre-emptively decrease this number. |
| Findings per Sprint | This number represents the average of security findings introduced per sprint (given that teams are releasing on a sprint schedule). Ideally, just like regular releases, you want this number to be as low as possible so that you can divert time and energy into other parts of your organization, so as not to get bogged down by the complexities of security breaches after the fact. |
Using Metrics to Fight Threats
Finding areas of weakness is the best way to fight potential threats. To uncover these areas of weakness use security-focused metrics to see how the security area of your DevSecOps is operating.
Building metrics for findings and resolutions to those findings promotes both a healthy investigation of your product and ensures potential exploits are fixed and resolved in a timely manner.
Looking Ahead – Measuring Culture
Now that we understand the important security metrics to add to your DevOps KPI Metrics, we’ll put it all together in part 3 with one of the most important measurements – culture.
Questions about your DevSecOps? Looking for guidance as you prepare your next project? Reach out to us at [email protected]
Learn more: Revisit Part 1
Adding Security Metrics into DevOps is part 2 in a three-part series. To gain an understanding of the “Measure What Matters” series, and learn about traditional DevOps metrics, revisit part 1.
0 Comments