DAST

Dynamic Analysis Security Testing takes centre stage in the third instalment of our Web Application Security series with Tim Armstrong.

OUR EXPERT

Tim Armstrong is a former Lead Engineer turned Developer Advocate specialising in networking, software development, and security. You can find him on Twitter as @omatachyru or via his website at www.plaintextnerds.com.

The battle between developers and malicious hackers is one that developers have been losing. A lot of the time, it comes down to mentality and company priorities. Hackers, like burglars, only need to find a single open window or unlocked door to get in. You wouldn’t check that you’ve locked your door only once every few months, yet this is the exact approach many companies take to security.

Dynamic Analysis Security Testing (DAST) is perhaps the most overlooked stage of any security pipeline, frequently relegated to a check-up every six months by an outside consultancy that does an automated scan with Burp Suite or Zed Attack Proxy (ZAP) and provides you with a (hopefully short) report and an invoice in the range of £3,000-30,000, mostly depending on the scope. In most cases, the consultants don’t go further than the automated scan because at that point they already have enough to write a multi-page report.

But here’s the thing: when malicious actors (aka hackers) attack your web app, site or API, they aren’t checking if your code is neatly formatted, they’re essentially doing dynamic analysis. They’re looking for a place where you’ve not validated the input, an endpoint that you’ve forgotten to protect, cookie slack, a vulnerable login system, leaked credentials and hundreds of other things that are very difficult to detect statically. If you’re relying on a spot test every six months then odds are you’ve got security holes that you’re not aware of.

Building DAST into your CI/CD only takes a few minutes and gives you effectively that same information that you’d get from a pen-test where all they did was run an automated scanner. The main difference is that instead of it only occurring every six months, the scan happens every time someone merges a PR to the main branch – meaning you find out about the vulnerability when it gets merged. Ultimately this means that when you do bring in the external consultants for the six-month check-up, you actually get your money’s worth!

In this tutorial, you’ll be adding DAST to the GitLab CI/CD pipeline that you’ve built over the course of this series. If you haven’t read the earlier instalments yet it’s a good idea to check those out first, but if you just want to dive in at this point, then you can pick up a copy of the progress so far at https://gitlab.com/plaintextnerds/web-app-security-tutorial2-lxf280.