As DevOps moves to DevSecOps, there is a significant “people” component involved in the shift. Development and security teams both need to overcome their “language barriers” and understand each other’s processes and priorities. The effort is worth it because we know that (1) the consequences of neglecting software security are getting more damaging and (2) embedding security early and often into dev processes gets results. In fact, our 2017 analysis of the applications we scanned this year revealed that DevOps organizations that tested frequently with sandbox scanning (developer-initiated scans early in the dev process) had a 48 percent better fix rate than those doing policy-only scanning (security-initiated scans late in the dev process). In addition, in a May 2017 report, Best Practices: Strategies for Making the Crucial Shift to DevSecOps, Forrester Research notes that “Recent research on high-performing DevOps teams shows they're spending 50% less time in remediating security issues because security teams are continually working within their DevOps teams to build security into their daily work.”
But getting these two teams to understand each other’s “language” is no easy feat. In the same report, Forrester Research explains, “Security has its own array of terminology and acronyms that are foreign to developers, I&O pros, and line-of-business managers. And each of those disciplines speaks its own language that's equally foreign to the security team. As a result, when these teams try to communicate, it's often unproductive, frustrating, and contentious. This language issue sustains isolation with little hope for resolution.” Here are a few tips to start breaking down these barriers and speaking the same language:
As our Director of Developer Engagement, Pete Chestna, recently noted, “Finding a developer trained in cybersecurity is like finding a needle in a haystack.” Overcome this impossible task with the creation of “security champions” on the dev team. Development managers should identify members of their team who are not necessarily trained in security, but show an interest in the subject. Again, Pete Chestna recommends to identify these champions with questions like, “Do they like to hack or reverse engineer devices, code, and systems? Have they ever participated in a bug bounty program or found a vulnerability? Do they follow security news and thought leaders? Do they participate in hacker culture, watching shows like ‘Mr. Robot’ and attending hackathons?”
Then what do you do with these people? Make them security champions who reduce culture conflict between development and security, help other developers by performing code reviews, and act as the security conscience of the team. They hold feet to the fire to make security a priority during planning and pre-production.
Watch this video to learn more about security champions.
In a DevSecOps environment, developers own the testing of applications in their development environment, fixing flaws to pass policy and continuing to build code. Security, on the other hand, owns setting policies, tracking KPIs and providing security coaching to developers. In addition, security is responsible for providing developers with support in integrating scalable AppSec tools into their SDLC.
In turn, the security function cannot be effective in a DevSecOps world without a thorough grasp of how developers work, the tools they use, the challenges they face and how security fits into this picture.
Bump up your development knowledge by:
Understanding the developer role: Try taking a developer or two to lunch, and have them explain their processes and challenges.
Learning to code: There are numerous free or almost-free software development classes available, such as Coursera and Ed-X.
Experiencing a “day in the life of a developer”: Shadow a developer for a day or part of one to understand their challenges and processes.
Learning about the tools of the trade and how they work – Git, Ansible, etc.: Focus on gaining a high-level understanding of the tools and what they do, rather than details about specific tools, i.e., focus on the “why” not the “what.”
Visiting online developer communities such as StackOverflow or joining development Slack channels: Find out what developers are thinking and talking about. Take it one step further by looking for security-related topics and questions, and contribute to the conversation where you can.
Get more tips and advice on security’s changing role in our new guide, The Security Professional’s Role in a DevSecOps World.
In the end, this move to DevSecOps is just as much about people as it is about technology. Learn more about all the factors involved in this changing landscape in Forrester’s Best Practices: Strategies For Making The Crucial Shift To DevSecOps.