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.

Sponsor Note

sponsor logoGoverned access plus pervasive protection for data, apps, hosts, containers and serverless — this is the proper foundation for the journey to the cloud. Prisma, the industry’s most comprehensive cloud security suite, helps customers accelerate their journey with risk visibility and continuous security.

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.

#devops #security #contributed #sponsored

6 DevSecOps Metrics for DevOps and Security Teams to Share
1.15 GEEK