The frustration behind DAST

‍

Security teams introduce dynamic application security testing (DAST) due to the many benefits these tools provide. Low false positives, the ability to test across any language and detecting runtime issues should provide clear value. But this isn’t always the case.

‍

A challenge with introducing DAST into DevOps is speed. For example, there’s often an expectation that DAST can keep up with CI pipelines that take just seconds or minutes. But the reality is that DAST tools can take hours or days to run in their default configuration. Leading to disrupted workflows and frustration within DevOps teams. 

‍

However, there are ways we can manage this to get the most effective results out of DAST.

‍

‍1) Focus testing

‍

Running SAST (Static Application Security Testing) and DAST alongside each other to focus the area for testing can hugely speed up time to detection. For example, we know that SAST have a pool of vulnerabilities that they aren’t able to detect. If DAST is focussed specifically on this pool of vulnerabilities, it’s able to complete much faster than if it were detecting all vulnerabilities. 

‍

Giving DAST tools a focus as a preliminary stage removes any unnecessary testing that slows down results. 

‍

2) Proactive testing cadence

‍

An effective way to utilise DAST scans is to set a regular cadence of scans using development change data. This way you’re proactively scanning the areas of change and catching vulnerabilities earlier in the workflow. For example, feeding development change data from different change management systems into DAST catches vulnerabilities before they go into production. 

‍

Utilising DAST results earlier in the workflow in this way can be hugely beneficial in the whole development lifecycle processes by shortening the gap between vulnerability detection and remediation. 

‍

For more information on how else to prioritise change-based testing, check out how Cytix conducts full Continuous Testing Orchestration.

‍