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

Do you have questions about IAST? We’ve got answers, explanations, and recommendations. Read our responses to audience questions from our last IAST webinar.

IAST questions, answers, and recommendations

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.

Watch the webinar

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.

Questions about Seeker

What languages does Seeker support?

See the Seeker datasheet for more information about the languages Seeker supports. We’re always working to add new languages, so you can expect new additions on a regular basis.

Do we have to compile the source code using a Seeker tool?

No, Seeker instrumentation does not require you to compile source code using a Seeker tool. It uses runtime instrumentation to perform security testing.

You referred to a “source code plan.” How is that captured?

Seeker acquires source code information from application binaries, which usually include this information by default. So you don’t need to do anything special to your application binaries to instrument or test them with Seeker.

How can the Seeker agent find a vulnerability not in source code?

Can it find vulnerabilities if the source code is compiled at runtime (i.e., if the vulnerability isn’t in readable code)?

Seeker detects vulnerabilities at runtime by monitoring application behavior. It uses an automated verification engine at runtime to verify vulnerabilities. Seeker does not need source code to verify vulnerabilities, so it doesn’t require source code scanning for application security testing.

Does Seeker integrate with any IDEs?

At the moment, Seeker does not have an out-of-the-box integration with any IDEs. But we plan to create IDE plugins for Seeker in the future.

Is Seeker for developers or just for security teams?

We designed Seeker to meet the needs of both developers and security teams.

Security teams can monitor application security test results in Seeker using compliance reports (for standards such as OWASP Top 10, PCI DSS, CWE/SANS Top 25, and GDPR), vulnerability reports aggregated by severity, or the CAPEC (Common Attack Pattern Enumeration and Classification) taxonomy for a comprehensive overview of security posture.

For developers, Seeker provides the full context for vulnerabilities (source code, line number, URL, and runtime parameters), so it’s easy for developers to reproduce and fix vulnerabilities. In addition, Seeker integrates with developer tools (such as Jira, Jenkins, Slack, and email), so it fits well into developer workflows.

Seeker also has an automated verification engine to verify results and minimize false positives. That means developers can focus their efforts on development instead of chasing false positives, and security teams can get a view of an application’s true security posture.

What is a “verified vulnerability”?

A verified vulnerability means that Seeker has performed verification on it, and it is a real vulnerability. During the verification step, Seeker replays requests with tampered input to verify or invalidate vulnerabilities. “Verified” implies “confirmed.”

Can Seeker verify findings from other tools?

My development team has issues with the noise generated from Fortify. Can Seeker validate those findings or at least help filter out some false positives?

Yes, Seeker would certainly help because it has a unique verification engine to verify vulnerabilities automatically in real time. Automated verification minimizes false positives to a near-zero false-positive rate.

Is the integrated eLearning in Seeker video-based or just text?

Our eLearning platform offers a mix of text, audio, and video, with assessments to test the learner’s knowledge and comprehension. The eLearning integration with Seeker provides on-demand access to this immersive and intuitive learning platform, which includes:

  • Real-world case studies
  • Knowledge checks and assessments
  • Interactive exercises
  • Technical deep dives
  • And more

Can we integrate Seeker with SCA tools from other vendors?

For example, can Seeker integrate with Sonatype Nexus Lifecycle (IQ Server) instead of Black Duck?

Seeker is already integrated with the best-of-breed Black Duck Binary Analysis engine to identify vulnerabilities in open source and third-party components. And we provide comprehensive APIs to import Seeker results (including SCA) into any tool of your choice. Seeker does not offer out-of-the-box integration with any SCA tools other than Black Duck Binary Analysis.

Learn more about Seeker interactive application security testing


*** This is a Security Bloggers Network syndicated blog from Software Integrity Blog authored by Asma Zubair. Read the original post at: https://www.synopsys.com/blogs/software-security/iast-questions-answers-recommendations/