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.
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.
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.
Then, as mentioned, in addition to shared goals there are shared tools that can help
This post originally appeared on TheNewStack.
By submitting this form, you agree to our Terms of Use and acknowledge our Privacy Statement. Please look for a confirmation email from us. If you don't receive it in the next 10 minutes, please check your spam folder.