From Zero to DevSecOps: How to Implement Security at the Speed of DevOps 

The following is a guest post from Sharon Sharin, product marketing manager at WhiteSource.

DevOps has become a popular buzzword in the software development industry. Many organizations have already embraced the DevOps methodology, but what about security? A common concern is that adding security to DevOps practices will severely slow down development processes, but this doesn’t need to be the case. 

Recently, Jeff Martin, senior director of product at WhiteSource, and Anders Wallgren, vice president of technology strategy at CloudBees, got together to discuss why traditional DevOps has shifted, who should own security in the age of DevOps, and which tools and strategies are needed to implement continuous security throughout the DevOps pipeline. Here is a recap of that webinar. 

Watch the Webinar

A lot is changing in DevOps as a culture. Security which used to be a step added at the end of the development cycle, is now being embedded at every stage, in and around everything. Security is a huge aspect of quality, a measurement problem. The important questions to consider are how frequently you measure, and how deeply when you do. It’s become clear that the sooner you can start measuring, the better. 

In the old days of waterfall the old methodology — which unfortunately is still used by many — security was sprinkled on at the end of development, much like performance, quality, or stability. We’ve learned that’s not the right way to do it. Security specifically doesn't happen by accident, it’s achieved when treated like a priority in development teams’ feature set. If security isn’t baked in from the start, you’re not going to have a lot of it, and there isn’t much that you can do about it towards the end of the development process. 

The cost of fixing security and quality issues rises significantly as the development cycle advances. 

Shutting down production is a huge cost, and catching things late - in QA or in production amounts to much more than a dollar figure. It affects the entire cycle: from practically every internal team in the organization all the way down to your customers and your brand. On the other hand, catching a security issue while coding only affects the few people that will have to fix it. 

Finding issues in production has a ripple effect on the rest of the people in the company. Think of what you could have been working on instead of fixing a security issue that was caught late in the pipeline. 

The short answer is ideally: everyone. Proactive security has become a necessity. Processes like quality assurance and security can no longer be siloed and managed at a late stage by one dedicated person or team. The agile approach has broken down those silos. While security and quality still require professional experts, that doesn’t mean that other teams can’t share that responsibility. 

Security needs to be democratized, so that rather than having to wait for weeks for the security team to approve design, security is embedded throughout the process. This process must be performed continuously, testing throughout the devops pipeline, throughout design, build and production. Over time we see developer ownership over security expanding and broadening, enabling everyone to lend a hand. 

There are quite a few benefits to DevSecOps adoption, both for business and operation. Cost reduction -- as Anders Wallgren puts it: “The cheapest place to fix a bug is on the whiteboard. The most expensive is in production.” 

Security by design is also an important benefit, since it puts security in every stage of development, helping us avoid slapping quick band-aids on security when they are discovered late in the game. Security by design shifts security scanning left and empowers developers to get security right the first time, which provides the added benefit of increased delivery speed. 

The real operational benefit of DevSecOps is culture – shifting from siloed ownership to everybody taking some level of ownership enables a culture of constant iterative improvements. Versions are up to date, and re-work tasks decrease substantially. 

Knowing what you have is the starting point to all mitigation, but it’s not easy, and it requires a new mindset, as well as new processes and tools. 

Baking security into the DevOps pipeline means addressing it at every single stage. Before the build, security comes into consideration as we’re writing the code, when we plan design and architecture. During the build, security scanning comes into play - testing the build and checking the supply chain for vulnerabilities. The next step is continued scanning against production. 

Jeff Martin stresses the importance of managing the quality and hygiene of the supply chain, especially considering the volume of open source components that we all rely on. Open source is the biggest attack surface for code since it’s shared, public and the security vulnerabilities are announced publicly. 

In order to ensure the security of our supply chains, traceability is crucial. Being able to easily produce a real-time electronic bill of material is important. Broad end-to-end automation for the software development pipeline supports the documentation of what you do, providing a continuous audit. It allows you to follow source code from design to production, to when it gets to customers. 

Teams need to make sure that they understand all the steps, so that they can be automated, replicated, be made reliable, fixed and updated. 

Automation plays a huge part in DevSecOps. When you focus on the machinery of how you build and deliver code, and ensure that machinery has security in it, your processes become secure, predictable and reliable. When you invest effort optimizing your automating and orchestrating processes, you can quickly go to production with a small change, deploying reliably, frequently and predictably. Getting good at that means that when you detect a security vulnerability you can fix quickly. 

DevSecOps isn’t just about processes or just about people. If you’re not automating, you can't scale it or measure it. It’s not transferable. You need process, people, culture change and you also must have tools. Developers need robust tools that fit into their workflows, to enable all the other pieces. Tooling is necessary if you want to implement DevSecOps at a realistic scale. 

DevSecOps allows us to use agile methodologies to deliver small, secure pieces of code in frequent releases, and automate security processes whenever possible. It provides the best response to the bottleneck effect of older security models on the modern continuous delivery pipeline. 

In order to integrate security aspects and practices with DevOps processes, we need to shift the traditional mindset, shift testing left and close the loop between development and security. Use automation and tooling to empower developers to build security guardrails into the DevOps pipeline, rather than having to be or rely on gatekeepers, but don’t forget about teamwork. 

Make security everyone's responsibility by facilitating regular discussions about application security throughout development. Use tooling to make sure that people are having meaningful discussions that are effective and efficient about security. That’s how you embed security across the entire development cycle.