As the security of software is becoming the top priority for more development teams worldwide, and more organizations adopt DevOps practices to manage code in production, the logistics and practicality of combining the two to automate security is on everyone’s mind. In the past, automated security testing used to be quite slow, resource intensive, and often the results were full of false positives. This led to low adoption, falsely broken builds, and frustrated DevOps engineers and security teams alike.
Today, however, there’s a fast and simple way to catch security issues for networked applications: dynamic application security testing (DAST). DAST is software that interacts with your running application, automatically sending requests and responses in efforts to find vulnerabilities in your web applications and APIs. This article will focus mostly on dynamic application security testing (DAST), for several reasons. Firstly, if your application or API lives on the internet, that means anyone can scan your application with a dynamic scanner. The DAST will interact with your application, first passively (reading requests and responses) and then actively (creating or manipulating requests, then adjusting based on responses in attempts to find vulnerabilities).
The next reason to start with DAST is it’s just so easy. Most software developers can set up a DAST within an hour, and within another hour find at least one vulnerability. While the learning curve to become a professional penetration tester is high, the curve to run an automated DAST is very low. You won’t find 100% of the vulnerabilities, but you will most certainly find many, including all the easy ones. These are the most important vulnerabilities to fix first, as a non-advanced attacker can find them too.
Ground rules for security in DevOps environments
Before we dive into specifics on setup options, let’s define the ground rules for a security team that wants to work within a DevOps environment:
- DevOps attempts to maximize the efficiency of the entire system. Especially when it comes to speed. This means our scans need to go fast.
- DevOps demands fast feedback, that gets to the right person, and is accurate. This means false positives must be few and far between.
- DevOps prioritizes taking time to improve your everyday work on a regular basis. This means our tools must be flexible—anything from swapping out a tool for a better one, reconfiguration based on which sprint you’re testing, prioritizing some tests over others, moving some automations outside of the pipeline, etc.
Traditional security work has been meticulous and slow. DevOps is the exact opposite of how security teams have been used to working with software developers. Security creates gates, slows things down, and gives feedback at the very end of the SDLC. While DevOps is an entirely new paradigm for most security teams, it presents the opportunity for everyone to get what they want faster.
Often teams and individuals dedicated to software security are called ‘Application Security’, or AppSec for short. When working to automate security activities within a DevOps environment, the work they do is sometimes called DevSecOps, which has requirements of its own. To create a decent DevSecOps program, we need the following:
- Software testing from multiple angles that happens both during the software development life cycle (SDLC) and in production.
- Good relationships and regular communication with the DevOps, development, operations, and/or SRE teams.
- Remediation of vulnerabilities, bugs, and flaws as early in the system development lifecycle as possible. This last point is part of what many refer to as ‘shifting security left’, starting security as early as possible in the system development life cycle.
DevOps is good for both the DevOps team and the security team. The DevOps folks are releasing new features faster, creating more stable builds, and receiving regular feedback to ensure they are always on the right track. The security team can have security issues fixed faster, ensure availability of the systems they protect, and get precious security feedback to project teams faster than ever before. It’s a winning combination.
Dynamic testing in practice
For a DAST application to test your application, it must be running; access to the code is not required. It can be running on a virtual machine, container, or platform as a service, served over HTTP or (ideally) HTTPS. Some dynamic scanners allow you to perform manual security testing (known as web proxies), so you can hand-craft your requests, while others perform fuzzing, which tests the limits of an application’s input validation. I’m going to focus on the pure DAST functionality of completely automated testing; extensive security expertise not required.
Although there are systems that can block some of these attacks, most internet-available sites do not employ them (due to cost, latency, and the resources required), meaning most of the web applications and APIs on the internet have had one or more scans of them. These scans return a list of potentially exploitable vulnerabilities that every organization should remediate. Because if you can scan them, so can an attacker.
Let’s talk about strategy now. If you speak to a junior salesperson, they may tell you that a DAST is ‘plug n’ play’, implying little-to-no configuration is required. This can be true if you don’t mind waiting a few hours for your results and want to run each scan manually. But we’re talking about DevOps, which means we want to go fast, and we want automation whenever possible. With this in mind, let’s ignore the no-config/manual strategy.
Next up is creating HTML Archive files (HAR) and feeding them into your DAST to focus it like a laser. If you work somewhere that creates features in sprints, and you have a quality assurance (QA) team that created HAR files to automate testing the GUI, this strategy can work very well. When a DAST receives a HAR file, it will only test whatever features and code are part of the HAR recording. If your team is releasing a new feature and your QA team is creating a HAR file to test it, you are in luck! Your test will be significantly faster, as it doesn’t need to do crawling (finding all the endpoints, links, etc.), and will only test the small part of the application they have defined. This can then all be run from the CI/CD quite quickly. That said, if you don’t work somewhere that is creating and updating HAR files already, it would be a lot of work to do on your own on top of your regular duties.
Some organizations instead prioritize only certain bugs, and only test for those. For example, say you work somewhere that has a lot of cross site scripting (XSS) in their apps, and you have concerns there may also be injection as well. Let’s say eliminating these two bugs are top priority. You could set your DAST to only do these two tests in the CI/CD, and then run a manual test outside the pipeline at a regular cadence looking for the rest of the vulnerabilities that concern you. This way, your CI/CD is quite fast, but you are still getting good testing coverage.
Another way to speed things up with your testing is to remove any technology-specific tests that just don’t apply to what you have built. This is something we should all do, but often we forget. If you have built a .Net Core application hosted in Azure with an MS SQL database attached, you do not need to run tests for MongoDB, AWS, Wordpress, and a myriad of other tests included in most DASTs. Although this might only shave off 10-20% of your scan time, every bit counts when it comes to DevOps.
If you feel that cutting down the scope of what your DAST is scanning during CI/CD means you might miss something, you are correct. For best results with a DAST tool, you should also do regular scanning intervals (weekly, monthly, or quarterly, depending upon your desired security posture) of the entire application outside the pipeline. You can run these overnight or on off hours against pre-prod or other lower systems. If you are going to run dynamic scans again production, ideally you should ensure you have disabled the fuzzing feature, as you may accidentally mess up your production data, and no one wants that. Do fuzzing in a mirror of prod, and make sure you backup your data first—just in case.
Final thoughts
Dynamic scanning will not replace a penetration test performed by a security expert in terms of depth and certainty, but it can certainly help you create a more secure application for a much lower price tag and time commitment. If you are tasked with securing several applications, using a DAST in combination with other automated security tooling such as static application security testing (SAST), software composition analysis (SCA), interactive application security testing (IAST), and secret scanning, it is a cost-effective and quicker way of increasing the overall security posture of your entire application portfolio. Quite often, companies follow this approach in addition to having a professional penetration tester conduct tests on systems critical to business function to ensure they protect their most vital software applications.