Call it DevSecOps or SecDevOps or security in DevOps, but no matter what you call it your development organization will be tackling it soon.
DevOps is hard to do and security is harder. But at a time when security breaches continue to dominate the headlines, there’s no question that security and DevOps need to come together. The only issues are when and how.
A recent survey by DevOps software supply chain provider Sonatype found that for every 100 developers there is only one security person, and that’s a huge part of the reason breaches continue, said Derek Weeks, vice president and DevOps evangelist at Sonatype. “Those numbers leave you completely outnumbered and that’s not going to change anytime soon,” he said.
So what to do? We asked experts at the intersection of DevOps and security for their best advice on trying DevSecOps.
It’s tempting to just think you can set a security person next to a developer so that they can begin to understand one another. But Weeks said that doesn’t go far enough. His alternative: Have a security person spend a week building an app and then have the developers see if they can take it apart looking for flaws. “This is a way to begin to create empathy in the roles,” he explained. “It’s hard to do and harder to build it, but this lets each see how it looks to the other side.”
Gene Kim, the co-author of the upcoming DevOps Handbook, thinks small steps can mean huge changes when moving to DevSecOps. Start by inviting the security person to the weekly code review meeting. “You don’t need new tools to do this,” Kim said. It’s a chance for the security expert to offer some suggestions right on the spot, and for the developer team to see — and appreciate — the quick easy feedback rather than a 120-page response letter when the code is heading out the door. “Informality builds gratitude and mutual trust when you have a common goal,” he said.
Since security people are in such short supply in most organizations, it makes sense to change the development process to reflect that, Weeks said. “You want to be less of a hunter for the problem and instead focus more on creating an early automated testing solution,” he said. Automated testing is the key to making DevOps work, but most companies aren’t building security testing into that process. His DevSecOps take: Start talking about it at the requirements stage and build the testing to reflect it at every stage, rather than saving it all for the end.
“Even if we wanted to make security the number one priority in DevOps, there are not enough security experts in existence to do that,” explained Tim Buntel, vice president of products at XebiaLabs. So instead, companies and developers need to get creative. Buntel suggested creating “developer security champions” to help bridge this gap. These champions can take a special interest in security and push the security agenda in a development group in a low-key way.
There are a number of benefits to the organization, of course, but this is also something that could help a developer’s career. “You can use this to appeal to developers desirous of increasing their own value. Security is something highly valued. If someone takes the time to learn about the top 10 security flaws, it’s going to increase the professional value and the value to the team.” How can a developer get that specialized DevSecOps knowledge? Partner up with a security professional and then take that expertise back to the development team.
Sometimes it pays to tackle the obvious. Developers aren’t trained in security, said Pete Chestna, director of developer engagement at Veracode. So simply educating developers in the basics of security will go a long way, he said. “There is a 90/10 rule for a lot of this stuff and it can be done” by a developer with some training. “A developer can understand SQL injection and other simple security concepts. This is really the low-hanging fruit.” Contact Musato Technologies today to learn how to can assist your business to adopt IT systems that boost productivity and profitability.