Contributed by Steven Terrana, CDF Ambassador
CDF Newsletter – July 2020 Article
Subscribe to the Newsletter
DevSecOps: What is it?
I’ve had the opportunity to talk to hundreds of people about DevSecOps and I’ve learned one thing: no one agrees on what it actually means. With that in mind, I’m going to throw my own definition into the ring; At its core, DevSecOps means incorporating security into every step of the software development lifecycle.
Before we talk about how to do that, let’s start at the beginning.
How did we get here?
When I joined the DevOps community just four and a half years ago, the concept of DevOps was all about getting application developers and operations engineers to work together more effectively. This was being accomplished through practices like infrastructure as code, configuration management, and automated testing. By automating the build, test, and deployment processes teams could now reliably streamline their software delivery.
Unfortunately, the value in this automation was often under-realized as teams found a whole new bottleneck: the security team’s approval to release to production. Which makes sense! We spent so much time automating the validation and deployment processes we never stopped to ensure the applications we’re building are secure. This meant that the security team had to manually validate these requirements before approving a release.
While we have downgraded the giant wall between developers and operators to a picket fence, we’ve done nothing about the silo the security team often lives in. Enter DevSecOps.
We defined DevSecOps earlier as integrating security into every step of the software development lifecycle. In practice, this often means collaborating with your organization’s security teams to ensure their requirements are reflected in your CI/CD pipeline to eliminate the bottleneck stymying continuous delivery.
Building a Trusted Software Supply Chain
I once heard that all of the software industry can be represented in an analogy of a cupcake factory. Some people who specialize in building the factory (infrastructure), those who specialize in making the cake (backend APIs), those who specialize in decorating the cupcake (UI/UX), and so on. In this analogy, your DevSecOps pipeline is the factory’s assembly lining – cranking out as many cupcakes as possible without sacrificing quality or security. This assembly line ties together several different types of automated quality and security checks to ensure the application being built meets the team’s standard for these aspects.
When these security checks are all put together, they create a Trusted Software Supply Chain to production.
Application Dependency Scanning
Typically when building applications, teams will incorporate open-source, third-party dependencies to accelerate common development tasks. In our supply chain analogy, these dependencies can be thought of as the raw materials that go into building our application.
New vulnerabilities for these open-source packages are identified daily and a crucial part of maintaining your application’s security posture is continuously monitoring these vulnerabilities and patching them as they arise.
There are a couple of great tools in the industry to help you accomplish this. OWASP Dependency Check is an awesome open-source tool for accomplishing application dependency scanning. Popular artifact repository tools will also frequently have licensed integrations for performing dependency scanning. Sonatype’s Firewall and Lifecycle products accomplish this well, as does JFrog’s XRAY.
Static Code Analysis
Now that we know our “materials” aren’t compromised, let’s move on to ensuring the code itself doesn’t have inherent security vulnerabilities. Some common examples of static code vulnerabilities would be hardcoded password variables or IP addresses. On the more complex end of the spectrum, there are concepts like C++ memory corruption vulnerabilities that can be difficult to catch during a manual code review.
Some common tools to integrate into your DevSecOps pipeline for static code analysis are SonarQube or Fortify.
Container Image Scanning
With modern software delivery often comes containerization. The container image brings with it a new type of artifact that needs to be scanned for security vulnerabilities. It might seem convenient to fetch a random image from DockerHub that seems to have what you need. Unfortunately, without assessing what is actually in that container image via container image scanning tools you might as well have gotten the image from a sketchy van on the side of the road.
Kubernetes’ explosion as the de facto container orchestration tool has brought with it a seemingly endless number of tools that can help with container security and container image scanning. Some of the top tools that come to mind for container image scanning are tools like Sysdig Secure, Anchore, Clair, and OpenSCAP.
Continuous Compliance
While it’s great to make sure your supply chain is not being polluted with vulnerable dependencies (application dependencies or vulnerable base images), that’s still not enough.
Security vulnerabilities seem to come in two major “flavors”: vulnerable packages and vulnerable configurations. All the dependency scanning in the world won’t protect your application if your infrastructure is configured to allow SSH access to the public internet, or an S3 bucket policy is wide open allowing anyone to read the bucket’s contents.
Thankfully, many of the same tools that do container image scanning can also do compliance scanning to check for these types of configuration problems. There are many different guidelines out there for what infrastructure security controls should be implemented, from CIS Benchmarks to Secure Technical Implementation Guides (STIGs). These same container image scanning tools frequently offer security control profiles that compare your infrastructure configurations to the controls outlined in these various compliance matrices.
Accessibility Assurance
While talking about compliance, I would be remiss if I did not mention Accessibility Assurance or Section 508 Compliance. The applications we build should be universally inclusive for everyone to consume. Too often these validations are pushed until the end of a project when the technical debt can be insurmountable prior to release.
Incorporating accessibility compliance into your DevSecOps pipeline is a great way to ensure continuous, fast feedback on changes if they make the application difficult to consume. Some great tools to assist in scanning for accessibility compliance are Google Lighthouse and Pa11y. It’s important to note that these tools can’t tell you with 100% certainty that your application is completely compliant – but what they can do is tell you if you’re not. This feedback frees up time for those on the team that do accessibility compliance validations to focus on the more complex areas of the law and accessibility.
Dynamic Application Security Testing
So far, we’ve validated that the application’s we’re building are using secure dependencies, the code we’ve written is secure, the infrastructure we’re building is secure and compliant, and that the application we’re building is accessible for everyone. At this point, we can deploy the application and see if it’s susceptible to common exploitations. Some common examples from the OWASP Top 10 would be Injection, Broken Auth and Session Management, and Cross-Site Scripting (XSS).
Tools to scan your application for these vulnerabilities would be OWASP ZAP or Netsparker.
Conclusion
There is always more that could be done to integrate security into how we build applications. The goal rarely changes: “shift left” security validation to give developers the fastest feedback possible. Minimizing the lag between when a vulnerability is introduced and when the developer is made aware of it is the most concrete way to embed a security-first development culture, break down organizational silos, and enable true continuous delivery.
Velocity, quality, and security shouldn’t have to be the corners of a “pick two” triangle. I hope that this introduction gave you some ideas on how you can achieve all three and streamline your application’s path to production.
