Sep 20, 2019
DevOps is a market buzzword, with nearly every enterprise trying to implement DevOps to remain relevant in their industry. When I was first introduced to DevOps, I was skeptical—over 40 deployments in a day and 200x shorter lead times? I was extremely concerned about the security and robustness of these builds being deployed, as the only artifacts to support this were from smaller companies. There was nothing to prove that DevOps worked in large enterprises.
I initially thought that DevOps could contribute nothing new—after all, I grew up coding using XP and dark launching. But as I dug deeper past the hype, I was able to find truly great ideas and patterns that added value to the way we build robust, secure and risk-free systems. My first “A-ha!” came when I learned that DevOps systems were proven to recover almost 150x faster than normal.
In this article, we will explore some of the important things that we can and need to do to implement DevSecOps (DevOps + Security), which enhances security and enforces compliance at the same time.
Before we get into the need and details of DevSecOps, let’s quickly refresh ourselves on the advantages of DevOps, along with a few corresponding challenges.
By wiring compliance and security into DevOps, otherwise known as “DevSecOps,” there are ways to tackle the aforementioned challenges. Below are three solutions to help you get started on your DevSecOps Journey.
First and foremost in DevSecOps, you must Shift Security Left. In other words, shift the responsibility for security and other quality factors upstream in the pipeline back to the teams building the solution. Currently, most companies test vulnerabilities at the very end of the development cycle, just before release. This is dangerous. To have a truly robust and effective security system, security must be incorporated as early as possible into the planning, designing, and coding of automated test cycles.
Etsy is a great example of a company that has successfully shifted security left. Etsy built their security culture on top of their engineering culture, which has resulted in an overall thriving company culture. Their driving principles are:
To ensure that security is built-in to your development pipeline, it is important to follow OWASP Proactive Controls. These are a set of development practices, guidelines and techniques that should be followed to build secure applications. These practices help shift security left by injecting security into planning, design, coding and testing. When we start following these practices, we are in turn creating “Security as Self-Service.” We want teams to inject security seamlessly into their features, similar to automation or virtualization.
At Twitter, for example, security checks are run automatically every time a developer makes a change. They use tools like Brakeman to check the code for security vulnerabilities and to provide the developer with direct feedback when something is found. Developers also have a “bullshit” button to reject false positive findings.
Another key to DevSecOps is Infrastructure as Code, or managing infrastructure configuration in code using tools like Ansible, Chef, Puppet, and Salt. This speeds up and simplifies provisioning and configuring systems, especially at scale. It also helps to ensure consistency between systems and test and production, standardizes configurations and minimizes configuration drift, and reduces the chance of an attacker finding and exploiting a one-off mistake.
Security teams can also use Infrastructure as Code to program security policies directly into configuration, to continuously audit and enforce policies at runtime, and to patch vulnerabilities quickly and safely. A good example of this is a service called UpGuard.
If you don’t want security or compliance going to a stage gate to stop the flow, then it is important to continuously build security and compliance into the code while building the CI/CD. In the image, you see “Continuous Security” in the center of the development cycle. This image reinforces that security needs to be checked throughout the entire lifecycle—continuously, from inception to completion.
In the organizations I’ve coached, moving to DevSecOps always started with DevOps and continued with small changes made along the journey. New skills, tools, and priorities, as well as open thinking, were required. My advice? Start small, but start soon!
With 18+ years in the software industry in a variety of roles and a decade’s experience working as a coach, Nishant possesses a unique skill set to find creative and sustainable ways in the midst of traditional transformation methods. He strongly believes that guiding leaders on a path to a coaching mindset is key to unlocking the potential of the individual, the team, and ultimately the organization. Nishant is a recognized Agile change agent and leader, and his experience in traditional/legacy environments and his pragmatic approach to Agile Transformation allows him to help organizations bridge the gap when adopting Agile practices. Most recently, Nishant has been working to incorporate various Enterprise Business Agility techniques along with DevOps and XSCALE principles to his method of training, coaching, and speaking to help his clients in their transformations.