The dilemma of choosing a web application security scanner: DAST, SAST, IAST, RASP, and what not.
When an application is being developed, one of the most difficult questions to be answered is how it should be tested. Instead of going for endless discussions, the decision-makers should start with answering whether they want to automate vulnerability scanning for their application. Automation saves a great deal of time and money, while at the same time, the internal security team can focus on issues with critical or high–risk alert. If an application is being developed in a CI/CD environment and DevOps principles are implemented, automating a major part of security processes is a necessity in order to keep the time-to-market (TTM) as short as possible. While choosing an application scanner, there are three factors that you should consider –
Figure 1: Choosing a web application security scanner
While you are developing your application in a CI/CD environment, you require a solution which gets implemented easily. It should take a minimal amount of time to deploy and learn. It should be secure, accurate, and capable of giving useful results and capable information. If you spend a significant amount on buying a complicated tool and its training, you will be needed to spend a part of this amount again if an employee leaves your company.
If you select a SAST/RASP/IAST/HAST tool, the selection process must be based on the stack(s) your organization is using. These applications will require several configuration steps for implementation so that the scanner can be customized as per your stack(s).
With automation playing a major role, the possibilities for security testing are endless. For example, a vulnerability scanner gets integrated with your CI/CD environment in a manner that it automatically creates a ticket in your bug tracking tool when it counters a vulnerability. Once the developers mark the bug as resolved, a rescan is started automatically. 3 months down the line, if the same vulnerability is encountered, it reopens the same ticket, instead of opening a new ticket.
You must select a tool which integrates with Jenkins and Jira and minimizes human intervention in the bug tracking process while at the same time, providing appropriate details to the developers so that they can verify whether the reported vulnerability is a false positive or not.
Certain types of scanners, such as SAST, RASP, and IAST which reiterate over an application’s source code, do not interact with your applications like a real-life attacker would. In addition, SAST does not scan live applications and only analyzes the source code of an application and results of SAST tools contain many false positive alerts than their counterparts.
A business is bound to grow, and so are your applications. Hence, the selected tool should be scalable so that you don’t have to look for another tool occasionally. Along with implementation and integration considerations discussed above, the time taken for implementation of subsequent applications should decrease consistently as more and more applications are added.
DAST tools require minimum customization for scanning your applications. They scan websites or applications in their run-time environment with a lesser number of false positives. Keeping the three factors in mind, we have developed our own DAST scanning cloud platform which scans for over 1000+ vulnerabilities and generates multiple reports such as Executive Report for the board, Technical Report for the internal team, etc. Various benefits of our cloud platform are as follows –
Figure 2: Benefits of BreachLock Cloud Platform
- Application Security Testing10
- AWS Penetration Testing5
- Cloud Penetration Testing5
- DAST-Dynamic Application Security Testing10
- network penetration test1
- OSINT Penetration Testing1
- PCI DSS Compliance5
- Penetration Testing as a Service10
- Phishing as a Service5
- Service Organization Control(SOC)1
- web application security10
Automated Retest for DAST29 Jun, 2020
Automated Retest for External Infrastructure26 Jun, 2020