7 Habits of Highly Successful DAST Super Users

Nowadays, DAST (Dynamic Application Security Testing) is a critical tool for protecting applications from ever-emerging cybersecurity threats. Yet, the true power of DAST is not just in the software itself but also in the hands of those who wield it.

If you want to stand out as a DAST super user, this article is for you. Whether you’re just starting or you’re already a seasoned security expert, understanding the seven habits of highly successful DAST users can transform your approach and elevate your impact in cybersecurity.

First of all, you need to know what you have in-house. You must thoroughly assess all the applications in your organization. From web applications to APIs, and whether they are external or internal—you should consider them all. Why? The ecosystem can be more complex than you think, and some blind spots may be overlooked just because they are unknown (like shadow-IT) or seem unimportant at first sight.

Thus, the more you understand your attack surface, the more you can effectively protect your organization against threats. If the DAST tool you’re using provides asset discovery, take advantage of it to keep an up-to-date inventory of your web apps and APIs.

After identifying your external (and internal) attack surface, you need to pinpoint the most critical applications. This way, you can strategically allocate your efforts for optimal security management. For instance, if you have a web app that deals with client information and it is attacked you will suffer a leak of very sensitive client’s information. Consequently, it will open the door for further attacks and may even incur legal proceedings. All of this can negatively impact the company's reputation and lead to potential business losses—and nobody wants that to happen.

Thus, after understanding how critical your web apps and APIs are, you can prioritize and focus on what’s most important and make it your top priority. In any case, if you feel you might be missing or overlooking something, you can consider a broader approach of scanning all your web apps and APIs in bulk, which is something a good DAST tool should provide.

Security testing can be done in many different manners and with several approaches, such as SAST (Static Application Security Testing), IAST (Interactive Application Security Testing), and penetration testing. However, the right DAST tool can save you a lot of work and time since it does not require access to the code. It is just points and shoots to the URL and the results tend to be less noisy than a SAST, for instance.

When choosing a DAST tool, there are two critical aspects you should take into consideration:

This refers to the effectiveness of a DAST tool in crawling a URL to reach all possible areas, by interacting with every element found, clicking on buttons, and filling in forms, among other things. If the crawler doesn’t reach certain areas, the scanner won’t be able to test them, and potential vulnerabilities can be missed. This is a fundamental factor in determining how well a DAST tool performs.

This refers to the tool's ability to correctly identify security vulnerabilities, which is crucial because it directly impacts the effectiveness and reliability of the DAST tool. Therefore, while choosing your DAST tool, you should:

• Analyze its rate of False Positives. False positives happen when a DAST tool incorrectly identifies a normal or benign activity as a vulnerability. High rates of false positives can make you and your team waste a lot of time investigating and addressing “issues'' that are not actual threats, and create discredit.
• Analyze the False Negatives—that’s when a DAST tool fails to detect a real vulnerability. Compare DAST tools against a vulnerable app for which you know the list of vulnerabilities. Avoid the most common vulnerability apps because DAST tools are already fine-tuned to scan those apps. Also, don’t choose an app with fake vulnerabilities for education since scanners don't deal well with that.
• See if the DAST scanner provides valuable information on the identified vulnerabilities that helps you manage and prioritize your work. For example, here’s some interesting information you should consider:
  - The generic description of the vulnerability.
  - Where it was found.
  - The risk and CVSS score.
  - The evidence that proves the vulnerability and the details of the executed request(s) and received response(s).
  - Information on how to fix the vulnerability.
• Verify if the DAST tool keeps identifying vulnerabilities that are not fixed after scanning them several times—if it does it means that the detection is consistent, which is good. Also, make sure that it stops identifying vulnerabilities once they are fixed.

Last but definitely not least, while choosing the right DAST tool, consider the type of applications it can test. This is a very relevant aspect of the scanner, because it simplifies your work greatly by using a single solution for your whole ecosystem. It all depends on the type of applications you have, but you should consider a DAST tool that tests both Application Programming Interfaces (APIs) and Web Applications.

An API is fundamentally a software interface offering a service to other pieces of software. In this case, the DAST tool does not perform crawling like in a web app, and the list of API endpoints to test for vulnerabilities is given by the OpenAPI schema or Postman Collection. You should consider a DAST tool that tests APIs and supports these formats.

Web Apps are applications we access via a web browser, which we can divide into two major types: traditional web applications and modern Single-Page Applications (SPAs).

In a traditional web application, the server creates each page separately and sends it to the browser. The DAST tool crawls the application from the starting URL to reach as many areas as possible to test for vulnerabilities.

In a Single-Page Application, the scenario is a bit different. The pages are built in Javascript and rely heavily on calls to APIs. Like traditional web apps, the DAST tool crawls the application from the starting URL, but they are more complex to test than the traditional ones. In this case, thorough testing of API endpoints is essential for the whole application’s security. The good news is that APIs are much more structured and consistent, and testing the SPA’s backing API is an excellent way to find most of the vulnerabilities for the entire SPA. Thus, you should consider a DAST tool that can also test the API in the context of the SPA to provide you with thorough and complete security testing.

Once you have settled on a DAST tool, it’s just point-and-shoot to selected web apps or APIs to get a first sense of their risk (if the DAST tool provides the feature, consider doing it in bulk). But before you start testing it is essential for you to decide on which environment you want to do it. Want to test in production, pre-production, or quality assurance?

Each environment has its own challenges:

• If you choose to test in production, it is crucial that you know your applications in depth to prevent the DAST tool from accessing critical areas and doing destructive operations such as deleting users in the admin area. While doing security testing in production, the DAST tool must provide you with a way to configure it to block access to certain critical areas and prevent destructive operations.
• If you choose to test in quality assurance or pre-production, you may face the challenge of data quality. Essentially, this means that if you have insufficient data or a set of data that does not match your real-world use cases, the DAST tool may not be able to reach certain areas and do effective testing. A typical example is the injection attacks on paginators. If you don’t have enough items to enable the paginator, the DAST tool will not see it and won’t be able to test it. Thus, make sure you have enough meaningful data to exercise the entire application and not just part of it.

Fundamentally, the production environment has the best data for testing since it reflects the real world, but you must ensure full control of the operations performed by the DAST tool to prevent damaging that data. On the other hand, quality assurance or pre-production are safer environments for testing since you can perform all sorts of operations with the DAST tool without affecting the end users. However, in this case, the data may not be as good as in production, and you should check whether the DAST tool missed testing any areas.

With the DAST tool results coming out, you must verify if they excel in the highest standards, as you should expect. For that, you should do the following:

1. Check the coverage. Create your own thorough coverage of the range of URLs/endpoints of the Web Apps and/or APIs. Then, confront it against the coverage report provided by the DAST tool and see what is missing. The scanner should cover all you expect, and if there is more, the better.
2. Check each identified vulnerability. See if they are real vulnerabilities to know if the tool’s accuracy is right on the spot. You can start with the most critical ones and then move on to the less critical ones.
3. Pay special attention to false positives. As we already mentioned in this article, false positives can lead to wasted resources and discrediting the DAST tool. However, in some situations, if you know that a reported vulnerability is not exploitable, you should probably accept the risk and not consider it a false positive.
4. Check if the DAST tool tests comply with the most important standards such as PCI-DSS, OWASP Top 10, ISO 27001, or HIPAA.

If you are confident with the DAST tool results, you can report them to your security teams to proceed with the vulnerability fixing. Since each company has its own structure and processes, you must define the most efficient way to report the results. For instance, you can share with them a security board for analysis or send the results directly to the development team to fix the vulnerabilities the DAST tool found.

The crucial point here is that the DAST tool must provide a comprehensive report with all the needed details so that when you hand it over to your teams, they can proceed autonomously and, ideally, with little or no support from your side.

When you reach a point where you, the teams, and the company are confident and happy with the DAST tool, it is time to think of shifting-left security testing. This means introducing API and Web App security testing sooner in the software development lifecycle (SDLC) through integration and automation. For that, you should be able to do the following with the DAST tool:

If your organization uses an issue tracker for the teams to manage their work (or even a vulnerability management solution to centralize all the vulnerabilities), the DAST tool should allow you to have a two-way sync with it. This means that:

• When the DAST tool identifies new vulnerabilities, it automatically creates issues in the issue tracker.
• Once the team fixes a vulnerability-related issue, the DAST tool is notified by the issue tracker, and a re-test is executed.
• If after the re-test the vulnerability is still identified, the DAST tool re-opens the issue.

Think of starting with web apps or APIs with higher risk. Focus on those teams first, and after you have things in cruise control, move on to other teams.

With this approach, you can improve the process of fixing security issues, which becomes part of the teams' development lifecycle.

Another approach is to run the DAST tool automatically in the CI/CD pipelines of the teams. If the DAST tool provides such automation, it means that security testing can be automatically triggered in different environments from development to production.

This automation allows for immediate security testing within the software lifecycle without requiring your intervention. However, it adds more steps to the CI/CD processes and may change the teams' workflow. Thus, it should be assessed with each team and involving DevOps to understand the impact and the necessary changes.

Some DAST tools allow you to schedule and run regular security tests. Depending on how your organization works, this can be a solution to consider due to its simplicity. For this to happen, the DAST tool should provide a way to schedule security tests for each web app or API individually, depending on their lifecycles and security needs. This approach can make your life easier, since security tests would run automatically in regular time intervals with no need for you to execute them on demand.

By embracing these seven habits you can transform your approach to application security. From a clear understanding of your baseline to integrating and automating, each habit described here establishes a cornerstone, which you can continuously assess, refine, and improve.

You'll find that your excellence at wielding DAST tools isn’t just about what you do, but also how consistently and effectively you do it.

If you still haven’t found the right DAST tool for your organization, why not give Probely a chance? Sign up for a risk-free 14-day trial and see what our API and Web App Vulnerability Scanner can do for you.