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 common DAST and SAST tool challenges facing security teams and provides tips to promote tool adoption.
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. What are common SAST and DAST Tool challenges?
Tanya: The challenges that I have seen with both SAST and DAST tools include:
- Software developers often have difficulty understanding the tool results. They need someone to help them understand which vulnerabilities need to be fixed as well as which may not.
- Some tools offer very minimal direction to the software developers on how to correct the problems that have been found.
As these tools are further developed, and as companies mature the content and advice that they provide, I fully expect this problem to keep improving yearly.
2. What are Common DAST Challenges?
Tanya:
- One problem with dynamic analysis I’ve found is that if it is in the hands of a novice, it is possible for them to corrupt the data in the database or, worst case scenario, destroy the web server completely. It’s critical to have someone
skilled in DAST who only runs these tools against non-production environments (dev, QA, UAT, pre-prod, etc.) to avoid this problem.
- Application security professionals are hard to hire currently, with many organizations reporting that it’s nearly impossible to hire a full security team. If you can convince your developers to help with this work, it will make a giant difference
for your AppSec program.
I recommend that companies get training on DAST tools before using them against any production environments. I would also advise that whenever possible, test against non-production environments to reduce any risks.
3. What are Common SAST Challenges?
Tanya:
- With static analysis, poorly configured, first-generation SAST tools can provide up to 85% false positives. That is a huge number of false positives, and for a developer this can mean a wild goose chase. It can break trust between the two teams:
security and development - something to avoid.
Often the security team is doing their best to build this trust and get buy-in from the developer teams that making time for security bug fixes is important.
- It is preferred to have a security professional review all the static analysis results first, and then only present the real results to the software developers. This will be time consuming with a first-generation static analysis tool but ensures
perfect results (especially if you can’t afford to have one single vulnerability in the application being built). Your organization should be ready to make significant investments in your tools, products and teams.
- Another challenge is that these types of tools are promoted as working well in a CI/CD pipeline, for DevOps teams. Unfortunately, most of these original-style AppSec tools have not been updated since they were developed in the early 2000s and just
don't work effectively within a CI/CD.
If the software developers have tuned their CI/CD pipeline such that it takes 8 minutes to run every single test they need vs. a DAST tool that takes 6 hours, or a SAST that takes 1.5 hours, this will cause frustration.
4. How can security teams meet these tool challenges?
Tanya:
- One way to circumnavigate this problem is to use a second-generation static analysis tool, which runs faster – generally, within a few minutes. Some tools can even run in seconds if tuned correctly. That said, you will not receive perfect
results. It’s a compromise of risk vs. speed.
- Run an automated static analysis scan across your entire code repository (version control) once a week scanning the entire code base of each app. This will catch if your pipeline missed something.
- Run DAST and first-generation SAST tools outside the pipeline, reporting after you’ve validated the results. It’s not the speed of DevOps, but you won’t be breaking builds for no reason, or slowing things down so much that your
tools end up turned off or uninstalled.
5. How can security promote automated tool adoption?
Tanya: Some best practices that work well include:
- Create a security champions program and/or a developer education program so they can not only help you run tools but understand the results as well.
- Carefully tune your tools installed in a CI/CD pipeline to provide fast, accurate results.
- Perform a proof of concept with every new tool under consideration. Include the software development teams in the purchasing decision. If the software developers don't like the tool you've chosen this will impede application security.
- Enlisting the developer’s help to choose the tool makes it their tool as well and they are significantly more likely to use it. Whenever possible, get advice and feedback from as many software developer teams as possible. It's important for
them to want to use these tools.
I want the AppSec tools to improve everyone’s daily work, so developers can perform their jobs more securely. That’s a huge win for any AppSec professional.
6. What are the benefits of automated tools for AppSec?
Tanya: Automated tools:
- Help find obvious security flaws. They are not perfect - none of them can find absolutely everything that a trained security testing professional can find. That said, if working to secure hundreds of applications, automated tools enable you to
scale your program and find more vulnerabilities faster than a single application security person could.
- Allow AppSec to focus on finding the harder bugs, training the software developers and completing bigger moves, like ensuring that every team is following the secure system development life cycle. Without automated tools, securing more than one
application at a time would be borderline impossible.
- Puts malicious actors at a disadvantage. Malicious actors buy dynamic and static analysis tools and attempt to analyze our applications. If we've already fixed all the bugs discovered by these tools it becomes extremely expensive for malicious
actors to successfully attack or exploit our organization’s applications.
I literally can't imagine doing AppSec without any automated tools to help me. It would seem like a mountain that I could never climb. I hear security professionals talk about these tools all the time. We want them to continue to mature and improve, just
like the rest of our security industry.
READ: How to Select the Right DAST and SAST Tools
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.