Blog Headers (1)

DevSecOps: 4 Best Practices the Pros Teach Us About Security and DevOps

Nov 13, 2015 By Sarah Vonnegut

Developers and engineers all around the world are deploying code hundreds of thousands of times a day. Hundreds of millions of lines of code are churned out on a monthly basis, and it’s only going to get faster. Yet the security industry continues to kick our feet about DevOps.

 

But security teams can’t afford to continue the tip-toeing act we’ve been doing around DevOps. We need to find a way to better integrate our security needs within DevOps processes – and we need to do it fast.  DevOps is here, and it’s up to the security team to determine how security processes and tools will fit into the mix – or risk being edged out.

 

 

DevOps teams have already figured out how to automate their build, testing, and deployment processes, and now they need to learn how to do it securely. DevOps, continuous integration and continuous deployment offer us a chance to whittle down the complicated processes we’ve built around security and fully rebuild into the SDLC. Finding security’s place within the SDLC has always been a struggle, so if anything, DevOps just offers a fresh start to find the realistic places where security can not only do its’ job, but make it easier for all stakeholders to deliver secure applications. 

 

Fast decisions are a cornerstone of the DevOps mindset, and traditional security just can’t stay up to speed.

 

DevSecOps: 4 Lessons to Take Away from the Pros

 

1. Learn to work at the speed of DevOps

 

“The problem for the security person who is used to turning around security reviews in a month or two weeks is they’re just being shoved out of the game,” says DevOps pioneer Gene Kim. “There’s no way with how InfoSec is currently configured that they can keep up with that. So, InfoSec gets all the complaints about being marginalized and getting in the way of doing what needs to be done.”

 

 

Whereas waterfall development environments offered security teams more time to get back test results and offer remediation advice, DevOps teams just can’t afford to offer the same time. It’s counterintuitive, to boot. When code is being deployed multiple times a day, it would make no sense for security teams to deliver results any later than that.

 

In the same vein, another DevSecOps expert, Nick Galbreath, has stated that one of his security features is the speed at which he can deploy security fixes.

 

It’s not easy to speed up processes that have traditionally taken weeks, months, or years to be completed, yet if you’re working in a DevOps environment, it’s not an option. Speed up or risk being pushed out. Or, as Josh Corman says, “You can take the initiative and lead the first pilot implementation, wait for it to happen in your organization and engage early, or you can pretend it won’t happen and be replaced.”

 

2. Automate security testing and move it to the left

 

“The only realistic way of maintaining security in an environment that grows so rapidly and changes so quickly is to make it automation first,” says Netflix’s Jason Chan. And truly, with the number of tools being created (many for free), there’s no reason businesses of all sizes can’t automate the

 

“The old way of security testing code is a really long process,” says James Wickett (@wickett), a senior engineer and creator of gauntIt, a rugged open source project. “Moving your security tests closer to where the code is being written is where the information security team can add real value to the DevOps movement.”

 

And when it comes to automating repetitive processes, Stephen de Vries writes that some testing would be a “terrible waste of resources” and suggests that while there “will always be a need for intelligent human testing both for security and quality…that doesn’t mean that all security testing must be manually driven.”

 

De Vries says that the security tests which determine which weaknesses and vulnerabilities are present in their code should be automated. This is where an automated static code analysis solution can find those dangerous or erroneous coding practices and unprotected functions and report back to the build team in minutes.

 

It’s just like the Matrix taught us: Never send a human to do a machine’s job.

 

3. Focus your efforts and detect risky functionalities

 

Zane Lackey of the Etsy security team offers some amazing advice in his Effective Approaches to Web Application Security talk (Slides here), and one of them is this:  “When sensitive portions of your codebase change – know about it.”

 

Watch Zane’s talk here

 

The idea is to map out your core applications and builds and determine the sensitive code snippets – business logic, for one – and to watch out for changes to them. By pinpointing the specific areas of the code the security team needs to watch out for, you’re identifying the areas where you need to place your attention for manual reviews when the code does change.

 

Director of Engineering at Netflix, Jason Chan, agrees.  “There’s a continuum of changes and some of those changes are benign and happen all the time and then there’s a small percentage of those changes that we need to look at more closely and have a human get involved,” he told the Wall Street Journal.

 

In addition, Zane says, watch out for new security functionalities being implemented. Security features like executing processes and controls or encryption and hashing can cause chaos if not done correctly, and if you’re paying attention, you can help smooth out any issues while they’re still writing its’ code.

 

“[Developers] know they should be throwing encryption at the problem, but that’s the extent of it,” Zane says. “And a lot of times you don’t want encryption, you want hashing.”

 

Being able to intervene well before the code ships will save effort, time, and resources later down the line. In addition, teaching the developers working on the security features how to better implement them will give them better understanding of the importance of security, and may help ease tensions if you come from a point of helping.

 

Check out more of the best talks on DevOps & Security here.

 

4. Be a part of the DevOps culture – Become DevSecOps

 

“DevOps involves processes and tool chains, but I think the defining attribute is culture, specifically empathy,” says Josh Corman. “DevOps works because dev and ops teams understand each other better and can make more informed decisions. Rather than solving problems in silos, they’re solving for the stream of activity and the goal. If you show DevOps teams how security can make them better, then as a reciprocation they tend to ask, “Well, are there any choices we make that would make your life easier?”

 

Josh is talking about how the culture of transparency and sharing information between teams has allowed the development and operations teams to better understand where the other team is coming from – allowing everyone to be on the same page. Especially in an environment where speed is of utmost importance, knowing exactly what is going on at any given time is going to be essential for the health of organization as a whole.

 

Transparency is an essential part of the DevSecOps world, and security processes and monitoring has to be seen by all stakeholders if it is going to thrive in a DevOps world.

 

What other best practices do you have for better integrating security with DevOps? Comment below or tweet us @Checkmarx!

 

The following two tabs change content below.
Sarah is in charge of social media and an editor and writer for the content team at Checkmarx. Her team sheds light on lesser-known AppSec issues and strives to launch content that will inspire, excite and teach security professionals about staying ahead of the hackers in an increasingly insecure world.

Latest posts by Sarah Vonnegut (see all)

Stay Connected

Sign up today & never miss an update from the Checkmarx blog

  • Brendan Stewart

    This isn’t a particularly difficult problem to solve.

    As is outlined in the article, simply have a static code analysis tool run as a build step which informs the developer than the most recent checkin has some (potential) security flaws.

    This could easily be integrated into a CI tool like Jenkins or TeamCity as a build step.

    • Hi Brendan, thanks for reading and commenting!

      I wholeheartedly agree that automating security is a relatively easy solution, yet the difficulties usually arise when trying to get the support of the board, development teams, and other stakeholders for a static code analysis tool – even if it is well-integrated.

      The problem stems from the historically embattled relationship between developers and the security teams, which has only been exaggerated by the requirements in DevOps environments.

      But yes, a high-quality Static Code Analysis tool, built with the developer in mind, is a great solution to the issue of how security should be automated in DevOps environments.

      – Sarah Vonnegut

  • zeroXten

    One thing that doesn’t get mentioned is threat modelling in an agile/devops context. I started a project to help make this a reality: http://threatspec.org

Get a Checkmarx Free Demo Now

Interested in trying CxSAST on your own code? You can now use Checkmarx's solution to scan uncompiled / unbuilt source code in 18 coding and scripting languages and identify the vulnerable lines of code. CxSAST will even find the best-fix locations for you and suggest the best remediation techniques. Sign up for your FREE trial now.

Checkmarx is now offering you the opportunity to see how CxSAST identifies application-layer vulnerabilities in real-time. Our in-house security experts will run the scan and demonstrate how the solution's queries can be tweaked as per your specific needs and requirements. Fill in your details and we'll schedule a FREE live demo with you.