Is automation required in security testing? Of course it is. Automation already exists in preliminary stages in the security testing cycle. For example, scans for known vulnerabilities are performed through commercial tools and open source tools.
As recently as late 2014 and 2015, the automation of security testing has taken a shift in its approach. Customers are looking for automated secure code review through the build phase, which is widely known as continuous integration. This continuous integration is possible through secure code review plug-ins, which are integrated with platforms (e.g., Jenkins CI) to produce the secure code review when the source code is built. The project owners and developers will receive the secure code review report automatically.
Another way to automate security testing is to generate the vulnerability findings report from the tool-generated report. After running the automated vulnerability scans of an application, the security tester/penetration tester would analyze the reported vulnerabilities and remove the false findings (false positives). Then, using Python-based scripting, or other scripting languages, the report can be extracted and generated using the predefined template. This is useful for the Agile-based project as report generation time is reduced.
In the future, the automation of false-positive analysis will be possible through big data analysis and real-time vulnerability data collection feeds. In security testing, false positive analysis takes more time within the context of application controls and other security controls.
Automation in security testing is feasible with new scripting languages and the availability of plug-ins from the tools. Automation helps to introduce security testing early in the software development life cycle. This will enable enterprises to securely develop their applications/product with reduced cost.
Read Sivarama Subramanian’s recent Journal article:
“Security Mysteries in the Cloud,” ISACA Journal, volume 3, 2015.