Continuous Discussions Video Podcast: DevSecOps, Best Practices and More

Source – devops.com

In a recent episode of the Continuous Discussions (#c9d9) podcast, a group of industry experts discussed why DevSecOps is officially more than just a buzzword, tips on how to get everyone in the organization to own security and some of their own challenges and experiences baking security into the software delivery pipeline.

The panel included: Alan Shimel, editor in chief at DevOps.com; Chenxi Wang, managing general partner at Rain Capital; Derek E. Weeks, VP and DevOps Advocate at Sonatype; Paula Thrasher, Chief Architect, National Security Division at GDIT; Geetika Tandon, director of technology at Federal Civilian CTO Group; and Electric Cloud’s Sam Fell and Anders Wallgren.

Continue reading for some of their top takeaways!

Why DevSecOps?

DevSecOps is really more about a cultural shift, said Shimel: “DevOps is DevOps. It’s not just about Dev and Ops, though. DevOps is about the whole organization adapting a common cultural way of interacting including security, and bringing security into that culture, into that software ordination assembly line.”

Integrating security into development practices takes a lot of collaboration and communication, per Wang: “It’s easy to say security should be part of the process. But in practice, it’s difficult to do. When you have a security testing process that takes days to complete from the input to the output, and then you have developer teams releasing 500 releases a day, those are two very different cultures. It’s usually an iteration process but it takes a lot of team communication, a lot of sitting down, figuring things out for security to be part of it, and so it’s a not an easy process.”

Why DevSecOps and not just DevOps? Well, security people weren’t necessarily invited to the party, explained Thrasher: “It’s a cultural challenge that security hasn’t necessarily been an integrative part of a lot of the DevOps transformations. I think ‘DevSecOps’ exists because either we’ve left security out or they’ve stayed outside this transformation that’s happening.”

There really shouldn’t be a trade-off between security and quality, according to Wallgren: “I long for the day when we don’t distinguish between security and quality because, yes, there are different disciplines to them in some extent, but as far as the end user is concerned a bug is a bug.”

Weeks wanted to let nonbelievers know that DevSecOps is real and more than just a buzzword: “DevOps and security can integrate with each other and integrate successfully at scale. There are organizations of a couple of hundred or even a couple of thousand people that have a DevSecOps practice in place that are continuously improving it, adding an automated security, so it’s definitely gone beyond buzzword status.”

Including security in the release process should be a no-brainer, according to Tandon: “I think of it as common sense. I don’t even understand how security has been left out. I don’t understand how we have these huge pipelines, we’re releasing a hundred code releases a day and then, boom, we’re stopped. We’re stopped for scanning.”

Common Barriers to DevSecOps and Patterns for DevSecOps Success

Progress takes time, but Shimel remains hopeful of the future: “We’re not going to boil the ocean or change the world in a day, but we will change the world and we will change the way software is delivered so that software and security is synonymous with quality.”

Wang explained how one company is utilizing automation to successfully bake security into their process: “A company that I have worked with is in the container world and they have what they call a Brown’s registry. So they have code that is assembled by the development team and then goes into a Brown’s registry.  No other code can get in to the Brown’s registry unless it’s from their own team. Then from that Brown’s registry the security team automatically goes in and scans it and then only those that pass the scan gets put into what they called a Gold registry. And from there then they could deploy it to the server.”

Everyone in the organization should practice and be prepared to respond to security incidents, advised Thrasher: “The people that need to practice responding to vulnerabilities the most actually aren’t the security people. They’re used to responding to security issues. It’s the ops and the developers who aren’t used to responding to security incidents and they aren’t equipped, they aren’t trained on how to respond. So when your vulnerability happens it’s a bad new story.”

Many security issues have been around for a notorious amount of time, which is where the software delivery industry can improve, said Wallgren: “Where are most of the exploits coming from? The vast majority of them as I understand it are coming from well-known longstanding security issues that have been out there for a long time or, at least long by technology standards. And so a lot of it is just simple stuff that we need to be better at.”

Security as code is the next step in truly integrating security with DevOps, explained Weeks: “I was just talking to someone in Europe at a big telecom company, and they were saying, ‘I’m on the security team, we’re working with development, and we’re getting closer. We have all these rules and things that developers need to follow and we’ve been working with getting them to follow them more.’ And I said, ‘That’s really cool. Any of those rules or policies instrumented as code?’ And he responded cross-eyed like, ‘What? Code?’”

Tandon shared an eye-opening experience with a customer: “I’ve seen a situation where we were about to go to production—it was DevOps with security toward the end—and we got 4,000 hits and we had to go to production, most of them were ignored. So are we really securing our system or are we making our own system even more insecure by doing that?”