Q&A: Interactive application security testing (IAST) and Seeker

Kimm and I would like to thank everyone who attended the AppSec Hype or Reality? Demystifying IAST webinar. We had an engaging session and some great questions. Since we ran out of time and couldn’t answer everyone’s questions, we’re publishing our answers in this blog post. We’ve categorized all questions in two broad categories: general IAST questions and Seeker-specific questions. Read on and feel free to reach out to us at sig-info@synopsys.com if you have additional questions.

Questions about IAST

Can IAST replace DAST?

IAST performs application security testing, just like DAST, but more efficiently. So IAST can replace DAST in many scenarios. Let me explain the differences between IAST and DAST so that you can determine which tool would work best for you:

DAST performs black box security testing. It detects vulnerabilities by sending requests and analyzing application responses. On the upside, DAST generally doesn’t depend on the language or framework. It works for all types of web applications regardless of the technology stack used to build them. Also, DAST can scan applications and doesn’t require users to drive/test applications to perform security testing.

On the downside, DAST requires you to scan applications for security testing. DAST also requires extensive configuration on an ongoing basis to enable the scanner to access pages behind log-in and other forms. This makes DAST more difficult to configure and use. As a result, DAST has considerable overhead in terms of time and resources needed to complete security testing.

IAST, on the other hand, typically requires you to install an agent inside the application to monitor behavior and report vulnerabilities. It performs security testing concurrently during functional testing, without requiring application or source code scanning. That means IAST doesn’t require any additional time for security testing. Instead, it converts functional testing to security testing. To get the maximum value out of an IAST solution, you need a robust functional testing process (preferably automated) to exercise all parts of the application.

If you’re performing DAST in a QA environment, you have a good functional testing process, and your application is in a language that your IAST tool supports, you can easily replace DAST with IAST to save costs and resources, shorten time to market, and improve your security posture.
 

Does IAST meet PCI testing guidelines?

Yes, IAST meets the requirements for application security testing as specified in Section 6.5 of PCI DSS. IAST also works for the new PCI Software Security Framework, which requires you to test applications using a variety of security testing tools and techniques, such as static analysis (SAST), DAST, IAST, and software composition analysis (SCA).
 

What happens if we don’t test some code using IAST?

If you don’t test part of an application, IAST won’t detect vulnerabilities there. But the same applies to any software testing process: If you don’t test an application in its entirety, you risk leaving bugs. Similarly, when using IAST, if you don’t test an application in its entirety, you risk leaving vulnerabilities in the parts you don’t test.
 

Can an IAST tool find every vulnerability that a SAST tool finds?

We don’t believe that IAST can replace a SAST tool. Do you agree?

IAST can find all OWASP Top 10 vulnerabilities and more. But you should choose a tool based on your needs. I’ll explain the differences between the two and let you decide what would work best for you.

• Operations. IAST doesn’t have any operational overhead, because it doesn’t require source code or application scanning. It essentially converts functional testing into security testing (with an agent that monitors application behavior to report vulnerabilities). SAST requires source code scanning, which takes time. So from an operational perspective, IAST is the better choice.
• Runtime testing. IAST performs runtime security testing and finds vulnerabilities in all parts of the application executed at runtime. By contrast, SAST finds vulnerabilities in all parts of the application, including those that would never be executed at runtime. Do you want to find these types of vulnerabilities?
• Secure coding. SAST is a good choice if you want developers to follow secure coding practices while they are writing code. IAST is a good choice for dynamic security testing.
• Types of vulnerabilities. There are certain types of vulnerabilities that only IAST can find. An example is vulnerabilities related to sensitive-data leakage. IAST can see values at runtime and look for patterns in values to detect sensitive-data leakage. SAST can detect sensitive-data leakage only by looking at static code. It has no visibility into runtime values. As a result, it can miss some vulnerabilities. There are many other types of vulnerabilities that only IAST can find—for example, information disclosure via HTTP headers, or weak crypto used in SSL. Many such vulnerabilities can be detected at runtime only.

So for the best security posture, I recommend you use both SAST and IAST.
 

Does IAST work with microservices?

How does IAST know what input validation is done in an app that has 20 separate microservices, each in its own Java virtual machine?

Seeker detects and verifies vulnerabilities in the context of each JVM/microservice.