Where are you using WebAssembly?
Wasm promises to let developers build once and run anywhere. Are you using it yet?
At work, for production apps
At work, but not for production apps
I don’t use WebAssembly but expect to when the technology matures
I have no plans to use WebAssembly
No plans and I get mad whenever I see the buzzword
DevOps / Security

6 DevSecOps Metrics for DevOps and Security Teams to Share

A primer on which types of goals security and DevOps can pursue collectively, and which metrics they can use to measure their shared progress.
Sep 16th, 2020 9:19am by
Featued image for: 6 DevSecOps Metrics for DevOps and Security Teams to Share

Prisma, from Palo Alto Networks, sponsored this post.

Chris Tozzi
Chris Tozzi has worked as a journalist and Linux systems administrator. He has particular interests in open source, agile infrastructure, and networking. He is senior editor of content and a DevOps analyst at Fixate IO.

If you work in DevOps, it’s easy to feel like the security team is there to make your job harder. Likewise, if you are a security engineer, you may sense that DevOps doesn’t share your priorities and will never take security as seriously as you’d like.

Fortunately, it doesn’t have to be this way. By setting and pursuing shared goals, your organization’s security and DevOps teams can reinforce each other’s success rather than working at cross-purposes.

Here’s a primer on which types of goals security and DevOps can pursue collectively, and which metrics they can use to measure their shared progress.

Why Share Goals and Metrics between Security and DevOps

This conceptual divide between DevOps and security is easy to understand. Both teams have traditionally had fundamentally different goals — DevOps wants fast, efficient releases, whereas security wants to eliminate all vulnerabilities, even if it means slowing the software development lifecycle — and there was little direct overlap between them.

In addition, the way goals were established left little room for a sense of shared purpose. Each team defined its own priorities, then demanded that the other support them.

This is far from ideal, and a better approach is possible. In a well-run IT organization, DevOps and security operations should reinforce each other by identifying and pursuing goals that are mutually beneficial (some may call this DevSecOps). Doing so makes each team feel that it shares ownership in the other’s success. It also provides a common language in the form of shared metrics that both teams can use to measure their progress toward collective goals.

Shared Metrics for DevOps and Security Teams

The best goals and metrics for your organization’s DevOps and security teams to share will vary depending on which types of software you deliver, how your applications are hosted and so on. But in general, the following goals and metrics are a good place to start.

Reduced Total Security Tickets Opened

Reducing the number of security tickets that are opened in a given period is an obvious goal for the security team. However, the DevOps team also benefits from reducing security tickets. A security issue often means a delay in software delivery, or (in the case of serious incidents) even a rollback to an earlier release — which is a huge blow to the DevOps team’s goal of continuous release velocity.

Both teams can contribute toward reducing the total security tickets opened per month or quarter. Security tools that integrate into the CI/CD pipeline can help security teams improve their review of vulnerabilities while helping automate DevOps efforts to find and fix security issues during development and testing.

Reduced Time-to-Deploy

Time-to-deploy is a metric that the DevOps team has traditionally focused on minimizing. The faster you can deploy each release, the closer you come to continuous delivery.

But security also benefits from lower time-to-deploy, because it means that security issues can be corrected by a new release more quickly. The security team can help minimize time-to-deploy by automating its review processes for release candidates and working to shift security left so that security issues are identified earlier in the pipeline, when they are typically easier to resolve.

Discovery of Preproduction Vulnerabilities

Speaking of shifting security left, the number of security vulnerabilities that are identified before software goes into production improves the outcome of both DevOps and security. For the DevOps team, it means a lower risk that post-deployment security issues will trigger a rollback or cause a serious disruption to the continuous delivery cycle. For security, it means fewer serious vulnerabilities making their way into production environments — where they can wreak the greatest havoc.

By working together to identify bugs in the preproduction code, then, DevOps and security can support each other’s success.

Reduced Time-to-Remediate

Remediating security issues demands collaboration between the security and DevOps teams. The security team takes the lead in identifying what went wrong, and the DevOps team is in charge of implementing a fix.

Because of the shared responsibility that is inherent to this metric, collectively tracking (and seeking to minimize) time-to-remediate is an effective goal for DevOps and security teams to share.

Reducing Failed Security Tests

When a release is rejected due to its failure to pass security tests, not only are security engineers unhappy to discover that DevOps was trying to push out a release that contained vulnerabilities, but the DevOps team is also forced to rewrite code and face delays to its delivery process. Tensions can also arise between the two teams if DevOps feels that the security tests are unnecessarily strict or focus on the wrong items.

However, by having both teams set a shared goal of reducing failed security tests, they gain a sense of collective ownership over this metric. In turn, they are more likely to work together to fix the problem, rather than wasting energy blaming each other.

Percentage of Security Audits Passed

It may be tempting for DevOps teams to think of security audits as something they have to muddle through, but can basically ignore in the end. They may face some criticism if security audits find flaws in DevOps processes, but the hammer lands primarily on the security team when audits fail.

The reality, however, is that failed security audits put both teams at risk, no matter where responsibility lies for the failure. Recurring security audit failures damage the overall IT organization’s reputation and could eventually trigger an overhaul of both teams.

On the other hand, a steady record of successful security audits reflects positively on security engineers and DevOps engineers alike. Members of both groups can take pride in (and brag to their next prospective employer about) being part of a team that demonstrated strong success in meeting security goals.


It’s easy to talk about the importance of bridging the divide between DevOps teams and security teams, but it’s often much harder to get these teams to work together in practice. By establishing shared goals and metrics that each team owns collectively, organizations can improve outcomes and reduce the tensions that tend to separate DevOps from security.

For more ways to bring security and DevOps together when hardening the CI/CD pipeline, check out this free, on-demand webinar from Prisma Cloud and CodeFresh

Feature image via Pixabay.

At this time, The New Stack does not allow comments directly on this website. We invite all readers who wish to discuss a story to visit us on Twitter or Facebook. We also welcome your news tips and feedback via email:

Group Created with Sketch.
TNS owner Insight Partners is an investor in: Pragma.
THE NEW STACK UPDATE A newsletter digest of the week’s most important stories & analyses.