Successfully Integrating Dynamic Security Testing into Your CI/CD Pipeline

Have you ever put a DAST (Dynamic Application Security Testing) in your CI/CD pipeline, turned it on, and suddenly your pipeline processes jump from taking minutes to hours? Are you suddenly finding thousands of issues that are completely unreasonable for the type of app you are running in your pipeline? If you encounter either of these issues, just know that you are in good company. A DAST is a wonderful tool to have in your pipeline, but it can also brutally slow down the CI/CD process or flood the build with false positives. This is upsetting to developers, can cause friction among teams, and drastically slow down business results. In this article, we will discuss multiple options for adding a DAST to your CI/CD pipeline, in ways that won’t compromise speed, results, or relationships with your colleagues. For those of you unfamiliar with DAST we will define it later on in the article. 

Houston, We Have a Problem!

If you are reading this article, chances are you care about software security. You may be a QA engineer, a DevOps professional, or a developer.  You also probably care about protecting your customers and colleagues’ data. All of this isn’t possible without proper attention being paid to software security. 

A Verizon Breach Report revealed that insecure software has been the number one cause of data breaches for the past six years. Issues such as miscommunication between Security and Dev teams, confusing or incomplete tooling to guard against software security issues, or slow and clunky procedures, all cause vulnerable software to be shipped daily.

Another issue impacting the development of secure software is that you simply cannot afford to take time away from development and delay software releases to fix security issues. Instead, security needs to move at the speed of DevOps. You can’t put tools in your DevOps pipeline that help with software security but completely wreck the accuracy and speed of the software releases in the process. Some products work better in pipelines than others, but you need to do the work to find that out; the salesperson is not going to tell you. So knowing that software security is hugely important, and also being faced with the conundrum of not knowing the best tools, what do you do?

The current landscape (everyone’s doing DevOps now)

DevOps tools have specific requirements; they need to be accurate and fast. You don’t have the time or capacity to shoot false positives into your telemetry reports, and you certainly can’t afford a CI/CD process that takes hours, or even days. Lastly, you need to have automation! No one has time to do anything manually anymore, which is the beauty of having a CI/CD pipeline in the first place. DevSecOps also has its own requirements. If you want to weave security through your DevOps process, this requires a need to test your software from several angles. We will talk mainly about dynamic scanning, but there are many different angles you can take such as software composition analysis, static analysis, and making sure the infrastructure you’re using is safe. Most importantly, you need to have good relationships between teams. If you are a security professional, software developers may actually be afraid of you! If the relationship between the security team and the development team is based on fear and blame, your security testing tools are much more likely to be circumvented or even turned off entirely, leaving you vulnerable. If you, as a security professional, can collaborate with the development team early on in the process, it will be smoother for developers to adapt security tools and best practices. You can do things like threat modeling in the design phase, writing requirements that eliminate bugs in the first place, and then test, test, test in the coding phase! The sooner you start these activities in the SDLC, the better. Small bugs are cheap to fix, and the earlier you catch issues, the better. And remember, the best way to approach the relationship with your devs is this: "I’m from the security team, and I come in peace!"

Let’s talk about Dynamic Testing

So what is a DAST? DAST stands for Dynamic Application Security Testing. That’s all well and good, but what does that mean? Well, if you have a running application or API, a DAST tool interacts with it from the outside and tries to break into it. It sends requests, reads responses, and tries over and over to break into your application by exploiting common software vulnerabilities. By doing this, it can find many of the possible vulnerabilities that a malicious actor would also experience when trying to hack into your app.

But why DAST? There are three main reasons:

1. Anyone on the internet can scan your app with a DAST and find vulnerabilities. They can then use those vulnerabilities against you! Of course, this is not legal, but that isn’t going to stop a malicious actor. 
2. DASTs do not require a lot of setup time and can integrate into several stages of the software development life cycle (unit testing, CI/CD, pre-release, maintenance, etc) 
3. DAST tools don’t require advanced cybersecurity knowledge to operate. Any developer can use it, even if they do not know anything about cybersecurity.
    

So, what is DevSecOps?

If you are reading this article, you may already know what DevOps is. But do you know what DevSecOps is? If you’re curious, read on…

DevSecOps is the security component of the DevOps cycle. Anything that could be considered an AppSec activity that occurs within the DevOps cycle, falls under the umbrella of DevSecOps. This could be hiring a pentester, including a DAST or SAST tool into your CI/CD pipeline, or building education programs for your development team from a security perspective. DevSecOps also places a great deal of importance into integrating security into every aspect of the development lifecycle.

“But how can this be?” You may wonder. “Development and Security teams are often at odds…how can security integrate so well into DevOps?”

The answer to this lies in the simple fact that DevOps and Security have the same goals. They want to: 

1. Release software quickly
2. Release software reliably
3. Iterate internal processes so that the system reliably releases software in an increasingly efficient manner
4. Immediately deal with emergencies, whether they are software issues or security vulnerabilities

So, how can you integrate security into your DevOps process and begin to practice DevSecOps? One answer lies in the purpose of this article: by integrating a DAST tool into your CI/CD pipeline!

Let’s talk about the strategies for doing that now. 

Strategies for DAST in a pipeline

One strategy is to run your DAST on full blast. However, this can take a really long time, and may alienate your devs so much that they turn the tool off. We do not recommend this strategy as it can be overwhelming and disruptive.

Another strategy is to refine your scope with a .HAR file. A .HAR file is a JSON-formatted archive file that shows you a log of a web browser's interaction with a website. If you have a great QA team that is doing automated testing, you can record their interactions with a website on a particular segment that you later want to upload into a DAST, and use the .HAR file to make the scope of what you are testing smaller! 

You can also opt to only test what is worrying you at the time. You can focus on the top three issues affecting your organization at the time (something like security headers, XSS, etc). Once you have this knowledge, you can not only test for it, but you can internally ‘evangelize’ and teach the devs about what those things are and how to fix them. By the time these issues start to resolve you’ll have another whole list of new issues that you now want to tackle. Alternatively, you could also test for SQL injection one week, XSS the next, etc, eliminating issues as you go along. 

Lastly, there are technology-specific tests. For example, special tests for MongoDB, Ruby, or Wordpress. If your project is not using those technologies, turn off the tests! This may seem obvious, but it is easily overlooked. Only keep the tests that apply to you! 

A special note on APIs

Let’s briefly take a peek at testing APIs. I’ll let you in on a secret. Sometimes dynamic scanners don’t pick things up on APIs; you can get ‘perfect’ results that are…far from perfect. But that doesn’t mean DASTs are totally useless when it comes to APIs. What you can do is take your API definition file/schema (like a Swagger file), open it up, and lint it. The API definition file can be modified to take only a specific number of characters as input or indicate the types of allowed inputted characters. When you are this specific with your input validation in your API definition file, you can then give that file to the DAST scanner. Then the DAST scanner can use those expanded specifics to test the API in a way that will produce accurate results. 

A little secret

Here’s another secret. You can still be in a DevOps environment and not put every test into the CI/CD pipeline. You can get good results by putting only some tests in, such as tech specific tests or HAR file driven tests, and supplement with extra security testing outside of the CI/CD pipeline. This will let you take a good look at the attack surface of the app while taking some of the burden off of configuring the CI/CD pipeline. We will talk about those options now. 

Strategies for DAST NOT in a pipeline

Automated & scheduled scans
A solid option is to do a regular, automated scan of the entire app using a DAST on a scheduled basis. This allows for the DAST tool to update the vulnerabilities that it can find, and then you can take advantage of those updates on a regular basis. You can do a long test over the weekend, and find several new vulnerabilities that you didn’t know about when you return to work on Monday. Doesn’t that sound fun? There are some cons, though: an entire DAST scan can take significantly longer than a DAST that’s integrated into a CI/CD, delaying testing results and potentially allowing for bugs to be shipped into production in the meanwhile.

One-off testing

Another option is to do a manual, one-off full scan using a DAST. This is a great way to learn how to configure a new tool and play with it. It can let you know what you’re dealing with and build familiarity with the tool. Then later, you can integrate it into your CI/CD. The downside of this, however, is that non-pipeline scheduled scans can report things after they are shipped, and the dev team has potentially moved on to other things. This increases inertia and security technical debt, and delays having these security issues addressed. 

Pentesting

Penetration testing is a common strategy used by enterprises to find vulnerabilities in code. But it’s important to note that a pentester may not want to spend their valuable time and manual labor on finding bugs that a DAST can find right away, especially if the DAST tool is free and easy to use. So, before you hire a pentester, point a DAST at your app and fix the vulnerabilities! Then the pentesters' time can be more wisely spent finding harder to fix vulnerabilities that an automated tool like a DAST or a SAST can’t see. The downside of hiring a penetration tester is they are expensive, and most companies can only bring on pentesting services a couple of times a year at best.

Strategies for other types of application security testing

Last but definitely not least, there are other tools you should be aware of and also use on a regular basis. These tools include, but are not limited to: 

SCA (Software Composition Analysis): what is your code composed of? What are its dependencies? Are the dependencies safe and secure to use?

SAST (Static Application Security Testing): This type of tool runs security testing on static, non-running code. You can use this in your own unique code or any open source projects your work depends on. 

IAST (Interactive Application Security Testing): a newer type of technology that allows you to use instruments to monitor an application as it runs, and can give you real-time visibility into security issues in your code. 

Secret Scanning - a scan to make sure things like API keys are not exposed in your code.

Conclusion

You must do dynamic scanning. If someone else can point a DAST tool at your code and run it, you want to be able to duplicate that effort and find the easy-to-spot vulnerabilities before a malicious actor does. In addition, automation is your friend! Use it as much as you can. Dynamic testing in a pipeline must be fast and accurate, but it doesn’t mean you are ‘failing’ if you also test outside the pipeline.

Equipped with this knowledge, go forth and have fun putting some DAST in your CI/CDs!