Checkmarx IAST is an interactive application security testing tool that instruments a running application to observe real code execution and flag vulnerabilities from inside the process, rather than analyzing static source or probing from the outside. It sits between static analysis (SAST) and dynamic testing (DAST) by watching what actually happens when traffic hits your app during functional tests. If you already run SAST and want to cut false positives by confirming which findings are genuinely reachable at runtime, IAST is the category worth understanding.
This post explains how IAST works conceptually, what Checkmarx's implementation brings, and the honest trade-offs.
How IAST Works
IAST relies on instrumentation. An agent runs inside the application's runtime, hooking into the execution path so it can trace data as it flows from an input (an HTTP parameter, a header, a form field) through the code to a sensitive sink (a database query, a file operation, a command execution). When tainted data reaches a sink without proper sanitization, the agent reports it.
The key difference from SAST is that IAST only reports vulnerabilities on code paths that actually executed. If your test suite exercises a route with a SQL query built from user input, IAST sees the concrete query and the concrete taint flow. That runtime confirmation is what drives IAST's low false-positive reputation.
The key difference from DAST is that IAST has inside knowledge. A DAST scanner sees only the HTTP responses; it guesses at internal behavior. IAST watches the internals directly, so it can point to the exact method and line where the flaw lives.
Where Checkmarx IAST Fits in the Portfolio
Checkmarx is best known for its SAST product, and its IAST offering is designed to run alongside it. The typical pattern: SAST scans source early and broadly, IAST runs during QA or integration testing to confirm which flaws are exploitable in practice, and the combination reduces the triage burden on the AppSec team.
Because IAST needs a running, instrumented application exercised by real traffic, it fits naturally into environments where you already have automated functional or integration tests. The agent observes those existing test runs; you do not necessarily write new security tests.
IAST vs SAST vs DAST
Rather than picking one, most mature programs use them for different jobs:
- SAST analyzes source or bytecode without running it. Broad coverage, catches issues early, but produces false positives because it cannot always tell which paths are reachable.
- DAST attacks a running app from the outside with no code visibility. Good for finding what an external attacker would find, weaker at pinpointing root cause. Our DAST product page covers this class in more depth.
- IAST instruments the running app to correlate inputs, code paths, and sinks. Fewer false positives, precise location, but coverage is bounded by whatever your tests actually exercise.
That last point is the honest limitation. IAST only sees code that runs. If a vulnerable path is never triggered by your test suite, IAST will not report it. So IAST complements SAST's breadth rather than replacing it.
Deployment Considerations
Running an IAST agent means adding instrumentation to your application runtime, which has practical implications:
- Performance overhead. Agents add latency. This is usually acceptable in QA but you would not typically run full IAST instrumentation against a latency-sensitive production tier.
- Language and runtime support. IAST agents are runtime-specific. Confirm the versions of Java, .NET, Node.js, or Python your services use are supported before committing.
- Test coverage dependency. Your IAST results are only as good as your functional test coverage. Thin tests mean thin IAST findings.
- CI integration. The value comes from running IAST automatically during your existing test stage and feeding results into the same triage flow as your other scanners.
What IAST Does Not Cover
IAST is an application-layer runtime tool. It does not inventory your open-source dependencies or map them to known CVEs. A vulnerable version of a third-party library is a software composition problem, and you need software composition analysis for that. IAST might observe a taint flow that happens to pass through a library, but it is not designed to tell you "this dependency has a known critical CVE, upgrade it."
That is worth stating plainly because teams sometimes assume runtime instrumentation covers dependency risk. It does not. Pair IAST with SCA and SBOM tracking to close that gap.
Building a Layered Program
A pragmatic layering for a team that already runs Checkmarx SAST:
- Keep SAST as the broad early scan on every pull request.
- Add IAST instrumentation to your QA or integration environment to confirm reachability and cut false positives.
- Run DAST against a staging deployment for an outside-in view.
- Run SCA continuously to catch vulnerable dependencies independent of code paths.
No single tool in this list is sufficient alone. IAST's specific contribution is turning "this might be exploitable" into "this executed and reached a dangerous sink," which is exactly the evidence that makes remediation prioritization defensible.
FAQ
What is the difference between Checkmarx SAST and IAST?
SAST analyzes source code statically without running the application, giving broad coverage but more false positives. IAST instruments the running application to observe actual execution, so it confirms which flaws are genuinely reachable and pinpoints their location, at the cost of only covering code your tests exercise.
Does IAST replace DAST?
No. DAST tests from the outside with no code visibility, simulating an external attacker. IAST watches from inside the runtime. They answer different questions, and many programs run both.
Does Checkmarx IAST find vulnerable open-source dependencies?
Not as its purpose. IAST focuses on application-layer flaws observed at runtime. Detecting known-vulnerable third-party libraries is the job of software composition analysis, which you should run alongside IAST.
What overhead does an IAST agent add?
An instrumentation agent adds runtime latency, which is generally acceptable in QA and test environments but is why teams usually avoid full IAST instrumentation on latency-critical production tiers. Test in a representative environment before rolling it out widely.