Posted by on Wednesday, August 12th, 2020
Making the shift from DevOps to DevSecOps requires better communication, which you can help your teams accomplish with security training and enablement.
If DevSecOps isn’t working very well in your organization, you can probably sum up the issue in the same way as “Cool Hand Luke”: “What we have here is a failure to communicate.”
Which should not be a shock. While DevSecOps has been around for at least five years, it is still working its way into the mainstream. Historically, the people on the three teams—development, security, and operations—worked independently of one another and frequently clashed, complaining that the other teams “don’t understand” them.
Which also makes sense. If teams don’t communicate, they won’t understand each other.
So for DevSecOps to work—and it has to, if an organization hopes to be competitive in the agile CI/CD environment of software development today—those teams need to collaborate effectively.
That requires a cultural shift in which development, security, and operations aren’t really separate teams. Instead, they play different roles on the same team, with the same goal: Produce secure, high-quality software faster.
Enabling that cultural shift requires better communication. And the way to initiate better communication in DevOps is with cross-training—helping each team better understand the roles of the other teams.
To bring security more effectively into DevOps, focus on two levels of security training: First, give all developers some basic training in secure coding. Second, create a security champions program that gives a few developers extra security expertise.
Basic training doesn’t mean turning developers into security experts. But any decent developer wants to produce quality code, and a key element of quality is security.
Basic secure coding training for developers should include knowing the ways applications can be attacked. Some great places to start are the OWASP Top 10, CWE Top 25, and similar publicly available guidelines.
Such guidelines cover fundamental security topics, including these:
The security champions concept builds on the reality that an insider is more likely to communicate effectively than an outsider.
Security teams need the help anyway—they are vastly outnumbered. Some estimate that for every 100 developers in a DevOps environment, there are 10 people in operations and just one in security.
So what better way both to give security a numerical boost and to bridge the communication gap than to create security champions within the development team? Who better to understand how to explain security to developers than another developer?
A security champions program does not mean conscription by force either. Security champions should be volunteers who are already interested in security and are looking to build their skill set and make themselves more marketable. Training as a security champion is a step up the career ladder.
For successful DevOps, it also helps to “build security in” throughout the software development life cycle (SDLC) from start to finish, instead of doing security testing at the end, when bugs and other defects are much more time-consuming and expensive to fix.
Plus, when you give developers more responsibility for security in the early stages of the SDLC, you reduce the number of issues your security team has to deal with. And since “dealing with” an issue usually means sending it back to the developer who introduced it, you reduce a major source of conflict between your development and security teams.
In short, enabling your developers to build security in through individual security training and a security champions program allows you to practice what the experts preach: Make the secure way the easier way. Which can then enable the ultimate goal: Build secure, high-quality software faster.