Automated Penetration Testing: A myth or reality?

Automation is a buzzword in many industries these days. If you have been following the cybersecurity industry lately, automated penetration testing, security automation, AppSec automation, etc., are some terms that have seen massive popularity in the last 1-2 years. This article explores whether automated penetration testing is a myth or a reality.

DAST + SAST ≠ Automation

First, our experts have encountered many clients who believed that integrating DAST & SAST into their CI/CD pipeline meant that they had automated security testing in their development environment. At the core, DAST & SAST tools are scanners, and as of now, scanners tend to generate a significant amount of noise, i.e., false positives. In an ideal automated system, these false-positive alerts will be raised as high or critical priority bugs in the connected bug tracking system. With noisy data in play, it will become impossible for the development team to address the genuine bugs in the system. We have yet to see an automated system that effectively deduplicates the repetitive results given by SAST and DAST tools, normalizes vulnerability nomenclature, identifies false positives, and arrives at the correct results.

Automation & TTM

There is no doubt in accepting the fact that security tests will have an impact on your time-to-market, but this impact can be substantially minimized depending upon your build pipeline. Alternatively, a separate security pipeline can be set up to run as a parallel process. This dedicated pipeline should be configured to run scans on a set frequency; accordingly, it will not impact your build pipeline.

Another preferred option is to set up SAST tools in the build pipeline and DAST tools in a separate pipeline. This is suggested because SAST tools take less time to execute, and hence, they will have a minimum impact on your pipeline.

Automated penetration testing replaces manual penetration testing.

Mostly, penetration testing is still a manual process. It cannot yet be cohesively integrated in an automated development and testing environment. Unlike popular beliefs, using tools to run scans or only using tools to conduct various tests does not construe a full-fledged penetration test. A penetration testing activity starts with vulnerability assessment and concludes with manual exploitation.

So, the bottom line is that security automation cannot deliver the value delivered by manual penetration testing activities. There are so many vulnerabilities that tools cannot identify. Moreover, many vulnerabilities and flaws are specific to each application, and their severity varies depending on the use case. While a thorough vulnerability assessment gives more expansive coverage, simultaneous penetration testing as a service brings depth, and both give a comprehensive security assessment for your assets.
To conclude, if penetration testing exercises are being conducted, then automated tests using tools can only help an organization to an extent. Manual penetration testing is the solution to go beyond the scope of automated means and gain in-depth insights into the organization’s security posture.

Consider your organization’s specific needs and requirements. What systems, applications, or data do you need to test? What are your goals and objectives for conducting penetration testing? Schedule a call today to learn more about BreachLock penetration testing as a service.

Author

Ann Chesbrough