This piece is part of our ‘Faculty Focus' series, an interview-style article where a member of the IANS Faculty shares firsthand, practitioner-based insights on an infosec topic. In this feature, Tanya Janca discusses how to select the right DAST
and SAST tools for your organization.
Six questions with IANS Faculty member Tanya Janca
Tanya Janca is the best-selling author of ‘Alice and Bob Learn Application Security’. She is the Director of Developer Relations and Community at Bright Security,
as well as the founder of We Hack Purple, an online learning community that revolves around teaching everyone to create secure software. Tanya has been coding and working in IT for over twenty-five years, won countless awards, and has been everywhere
from public service to tech giants, writing software, leading communities, founding companies and ‘securing all the things’. She is an award-winning public speaker, active blogger & streamer and has delivered hundreds of talks on 6
continents. She values diversity, inclusion, and kindness, which shines through in her countless initiatives.
1. Give us an overview of DAST and SAST Tools, what are some of the pros and cons of each?
Tanya: DAST stands for dynamic application security testing. These are automated tools that are run against web applications and APIs, in attempts to find as many vulnerabilities as possible. For a dynamic testing tool to work properly the code must be
running, in form of a live application, so that the tool can interact with that code and see how that it works. The automated tool will click every link, attempt to visit every page, fill out forms and submit input to the application, attempting to
find any potential security problems.
These tools have been around for a very long period and are used in many organizations. They are also often used by penetration testers and security researchers to do a fast triage of an application.
2. What Are the Drawbacks to DAST Tools?
Tanya: DAST Tools:
- Produce few false positives, but can easily find many types of vulnerabilities reliably, and then create a report which has actionable results
- Takes a few hours to complete to scan of an entire application - often somewhat slow
- Function weakly when it comes to testing JavaScript-only, single page applications (SPA), often finding 15% or less of the attack surface/pages within the app
- Work very well with legacy applications built with Java or other older programming languages, but often underwhelm when it comes to more modern applications, such as those with microservice architectures or that are mostly made of JavaScript
- Pose some risk, when they are performing fuzzing or inputting other information into your applications, occasionally they will corrupt your data, your database itself, or at worst case your entire web server
It is important to do some training and perform regular backups of the apps and data you are testing to ensure you don't accidentally make a ‘mess’ with a dynamic testing tool.
3. How do SAST Tools Work?
Tanya: SAST stands for static application security testing, which means it evaluates your written code. You don’t need to have a fully written, or ‘finished’, application when using SAST to find vulnerabilities. SAST is often also referred
to as “static analysis”. SAST tools pose zero risk to your code, application, and databases, as they don't need to put data into your application or interact with it in any way to find vulnerabilities. These tools have changed over the
past three years quite significantly, whereas there are now first generation and second generation static analysis tools.
4. How do First and Second Generation SAST Tool Differ?
Tanya: First generation static analysis tools tend to have an extremely high percentage of false positives, but they tend to find pretty much everything that could possibly be wrong with your application. This means that you need a security professional
to help you go through those results, which can be quite time consuming, however, you can have a greater assurance of security when using these tests.
Second generation SAST tools will run in seconds to minutes, as opposed to hours or days like first generation static analysis tools. They also provide a very high ratio of true positives when compared to false positives, with almost all the results they
report being correct.
That said, there are downsides. Second generation static analysis tools tend to find a lot of the things that are wrong, but not with 100% accuracy since they don't scan through every single part of the application. Due to the way they are built, it is
possible to miss some vulnerabilities.
5. What are Some Tips to Select a SAST Tool?
Tanya: When selecting first or second generation static analysis tools keep the following in mind:
It is important to decide what the level of risk your organization can tolerate.
- Does your organization require perfect security? Will there be exactly 0 known vulnerabilities in your production systems?
- Do you have the resources and budget allocated so that you can have a security professional pour over every single one of your applications for three or more weeks in order to ensure they are secure? If so, you need a first generation static analysis
tool.
- With DevOps you want to ‘move fast and break things’ so second generation might make more sense for you. If you fix the highs and criticals, but not the mediums or lows, then you want a second generation static analysis tool. Second
generation analysis will go very fast and have extremely accurate results. Again, it misses some ‘stuff’ so be ready to compromise.
In my estimation, 95% of companies do not need to be perfect, they just need to be very expensive for malicious actors to attempt to exploit. In which case, second generation SAST is most likely the right choice for you.
READ: How to Solve DAST and SAST Tool Challenges
6. What is the future of SAST and DAST Tools?
Tanya: Almost every single application security program has either static analysis, dynamic analysis, or both. That said, there are still many organizations around the world that have no application security program whatsoever. Some of them still have
these tools, but often it is the software developers that have implemented them. As of this writing, these two tools are some of the most commonly used types of application security tools. I'm not sure what the future will hold, but I would love to
see some innovation in this space.
About the IANS Faculty
Our Faculty are comprised of over 100 renowned security practitioners with deep, domain-based knowledge who understand - firsthand - the challenges faced by CISOs and their teams.
IANS connects clients with Faculty to help them make better decisions, grow professionally, save time & stay compliant. Get in touch to learn more about how we can help move your security program forward.
Although reasonable efforts will be made to ensure the completeness and accuracy of the information contained in our blog posts, no liability can be accepted by IANS or our Faculty members for the results of any actions taken by individuals or firms in
connection with such information, opinions, or advice.