IAST needs three things: sensor modules added to your application, interactive activity such as automated tests or manual use to exercise the code, and an environment where the app runs. Results are only as good as the traffic that reaches the code. Check these before assuming IAST will fit your stack.
How IAST works
The OWASP DevSecOps Guideline describes IAST as testing the application while it runs, driven by an automated test, a human tester or any other activity that interacts with its functionality. The core is sensor modules, which are libraries included in the application. They watch behavior and raise an alert when they detect a vulnerability. Feedback can appear in the IDE, CI, QA or production.
Because the sensors sit inside the application, they can see code, data and control flow, configuration and back-end connections. The guideline lists hardcoded API keys, unsanitized user input and connections without SSL as examples of what can be found.
Checklist: before you pilot
- Language and runtime support. Sensors are libraries or agents for specific runtimes. Confirm your language, framework and version are supported, not just the language family.
- Deployment method. How does the sensor get into the app: a dependency, a startup flag, a container layer? Check that it fits your build and release process.
- Test coverage. IAST only observes code paths that run. If your integration tests cover 30 percent of endpoints, IAST can only speak about that 30 percent. Measure this before you start.
- Environment. Decide where it will run. QA or a dedicated test environment is the usual first step.
- Performance overhead. Instrumentation costs something. Ask the vendor for guidance and measure it on a realistic load.
- Data handling. Sensors have broad visibility into data and configuration. Ask what is collected, where it is sent and how it is protected.
- Alert routing. Decide where findings go and who owns them.
What the guideline claims, and how to read it
The guideline describes IAST feedback as near real time and contrasts it with a DAST scan estimated at 5 to 7 days, citing a Forrester figure. Treat that as the guideline's characterization, not a promise for your environment. Scan duration varies enormously with scope and configuration.
It also notes that IAST can run in production-like environments while SAST needs source access, and that DAST sees only the outside of the application. Those points are about visibility, and they are real trade-offs.
Signs IAST may not suit you yet
- Very low automated test coverage. Fix that first; it will help every kind of testing.
- Unsupported runtimes or many small languages.
- A team with no capacity to add and maintain agents.
In those cases, SAST in the pull request plus DAST against staging is easier to start with.
Quick check
Does IAST replace DAST?
Not automatically. IAST sees inside the app but only for traffic that exercises it. DAST tests from the outside with no code access. Many teams use both.
Can IAST run without tests?
It needs interaction. Without automated tests or manual use there is nothing for the sensors to observe.
Sources
Last reviewed: 19 October 2026.
