Do you have questions about IAST? We’ve got answers, explanations, and recommendations. Read our responses to audience questions from our last IAST webinar.
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 firstname.lastname@example.org if you have additional questions.
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.
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).
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.
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.
So for the best security posture, I recommend you use both SAST and IAST.
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.
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.
No, Seeker instrumentation does not require you to compile source code using a Seeker tool. It uses runtime instrumentation to perform security testing.
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.
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.
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.
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.
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.”
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.
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:
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.
Asma Zubair is a seasoned product leader with extensive experience managing and launching products and services in the application security and application protection space. At Synopsys, Asma manages Seeker, the industry’s first IAST solution with active verification and sensitive-data tracking for web-based applications. Prior to Synopsys, Asma led teams at WhiteHat Security, The Find (Facebook), and Yahoo!. Asma holds a degree in electrical engineering from IIT in India and an MBA from UC Berkeley’s Haas School of Business.