This article was first published on Medium. You can take a look at it here.
With everyone moving to the cloud, there’s been so much hype over DevOps and how it can make processes faster, easier, and more efficient. As a developer, I love when things are made easier for me. As someone in security though, it scares me that there is no emphasis on moving to the cloud securely. Enter DevSecOps.
DevSecOps is about introducing security earlier in the software development life cycle (SDLC). The goal is to develop more secure applications by making everyone involved in the SDLC responsible for security. I love this. Having business, tech and security work together to produce secure products seems like a dream come true. Maybe too good to be true? Let’s investigate more and see if DevSecOps can be the silver bullet we all need in building secure products.
First, let’s talk about why we need DevSecOps. Years ago, software products followed the waterfall methodology, a linear sequential approach for developing a product that concluded with a “big-bang” release.
With the shift to cloud computing and dynamic provisioning of resources, developers have gained numerous benefits around speed, scale and cost of application development. These benefits lend themselves so nicely to the adoption of the DevOps movement. DevOps strongly advocates for automation and monitoring at all steps of the SDLC. The goal is for shorter development cycles, increased deployment frequency and more dependable releases, all aligned with business objectives. Like I said before, as a developer, I love this. But stable infrastructure and applications does not equal secure infrastructure and applications. And that worries me. In the waterfall lifecycle, security checks were put at the end before the product was released. Security was seen as a roadblock, the last gate-check, on the way to a production release. Many things have changed in regards to how applications are developed, but not how security is viewed.
These days, most teams use the agile methodology for software development. In an agile environment, the focus is on rapid delivery. By using iterative planning and feedback results, teams can continuously align product deliverables to business needs. The adaptability to changing requirements is great for delivering a meaningful product, but if you’re releasing a new version of your product every week, when do you test for security vulnerabilities? Unfortunately, traditional security processes have not kept pace in agile/DevOps environments rendering security to become a major roadblock in software development where it is usually bypassed. If it’s not bypassed, the development team rarely has enough time to address all the issues before the product goes live which means that an insecure application lives somewhere on the internet. The ironic part is that ignoring security to avoid the risk of missing a deadline actually puts more risk into the application. Security defects in the SDLC can lead to serious vulnerabilities like a breach caused by bad code. This is why we need DevSecOps.
In DevSecOps the two seemingly opposing goals, “speed of delivery” and “secure code”, are merged into one streamlined/automated process. The intent of DevSecOps is to build on the mindset that “everyone is responsible for security.” It is about pushing security left and automating core security tasks. Remember the song Irreplaceable by Beyonce? Throwback, I know, but Beyonce had the right idea when she sang “to the left, to the left.”
We want to push security to the left of the SDLC to ensure that application security starts as one codes. By shifting left, teams can quickly discover and analyze vulnerabilities and then adapt their code to mitigate against those vulnerabilities.
DevSecOps allows developers to focus on writing high quality and secure code, enabling teams to release titanium applications. The benefits are simple:
- security from the start minimizes the chance of vulnerabilities
- having automated security tools running in pipelines is that it lets security team members focus on the high-hanging fruit
- better collaboration and communication between dev and security teams
- improved operational efficiencies across security and the enterprise
However, there are challenges associated with DevSecOps. Even with security baked into a pipeline, there are still ways to circumvent security checkpoints. Lets take an example where a vulnerability scanner is being used to block a build/deployment if a certain vulnerability is found. As a developer, you know what that vulnerability is and you know your code has it, but you really need to do this release. So you find a way to hide pieces of the code that you know will fail a security scan, resulting in a successful build. Another common situation is when teams decide to break their build if there’s a presence of one or more findings of a certain severity. For example, a team may say that they do not want to break their build unless the finding is high or critical. While this certainly helps identify and address high priority issues immediately, the consequence is that medium and low findings make it to production builds.
Now that we’ve gone over the pros and cons of DevSecOps, how does one actually implement it? The traditional DevOps tools such as Jenkins and Git are a must have to build the foundation of your DevOps pipeline. There are many security tools in the marketplace ranging from open-source to proprietary solutions. Many of these can be integrated into your existing pipelines. Below is a list I’ve compiled from experience and the internet:
- Checkmarx: A SAST (Static Application Security Testing) Tool that analyzes an application’s code for flaws which are indicative of security vulnerabilities.
- WhiteSource: An open source vulnerability scanner, which runs automatically and continuously in the background, tracking the security, licensing, and quality of open source components and matching them against WhiteSource’s comprehensive database of open source repositories.
- Zaproxy: The OWASP Zed Attack Proxy (ZAP) is an easy to use integrated penetration testing tool for finding vulnerabilities in web applications.
So is DevSecOps the magical cure to all of our problems. Maybe not all of our problems, but to me and many others, it’s irreplaceable and this is one hype train I’m ready to board and take all the way.
This is my eleventh post in my "What is" tech blog series. I'll be writing more every week here and on my blog!
Top comments (3)
Very good article about DevSecOps.
I am working on this topic to bring it to some of our CI so that speaks to me. :-)
It is always good to see some security topics on dev.to and to meet some new fellow App Security Engineer. :-)
Nice article, I'm new in the DevOps world and I think security is really important. I found Snyk, this tool helps you to find the vulnerabilities that your dependencies have. Maybe you would like to check it out :D
Great post that I really appreciated reading and gaining more clarity in the DevSecOps arena.