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 tests, security automation, AppSec automation, etc. are some of the terms that have seen massive popularity in the last 1-2 years. In this article, we explore whether automated penetration testing is a myth or reality.
DAST + SAST ≠ Automation
To start with, our experts have encountered many clients who believed that integrating DAST & SAST into their CI/CD pipeline means that they have 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 are yet to see an automated system which effectively deduplicates the repetitive results given by SAST and DAST tools, along with normalizing vulnerability nomenclature, identifying false positives, and arriving 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. As an alternative, 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, and accordingly, it will not have any impact on your build pipeline.
There is another preferred option where you can set up SAST tools in the build pipeline and DAST tools in a separate pipeline. This is suggested because SAST tools take a lesser amount of 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. In an automated development and testing environment, it cannot be yet cohesively integrated. 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: security automation cannot deliver the value delivered by the manual penetration testing activities. There are so many vulnerabilities that cannot be identified by tools. Moreover, many vulnerabilities and flaws are specific to each application, and their severity varies depending upon the use case. While a thorough vulnerability assessment gives wider coverage, simultaneous penetration tests bring depth, and both of them, when combined 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. To go beyond the scope of automated tools and gain in–depth insights into the organization’s security posture, manual penetration testing is the solution.
- Application Security Testing10
- AWS Penetration Testing5
- Cloud Penetration Testing5
- DAST-Dynamic Application Security Testing9
- network penetration test1
- OSINT Penetration Testing1
- PCI DSS Compliance4
- Penetration Testing as a Service10
- Phishing as a Service4
- Service Organization Control(SOC)1
- web application security10
How to test your incident response using red teaming27 May, 2020
Integrate Slack with BreachLock SaaS platform21 May, 2020
Integrate Trello with BreachLock SaaS platform21 May, 2020