IAST can only analyze code paths that execute while it watches. If your tests or traffic never call an endpoint, the agent never sees it, so a clean report may only mean the code was not exercised. Measure what ran before you trust the silence.
The dependency on activity
OWASP defines IAST as testing the application while it is run by an automated test, a human tester, or any activity interacting with the application functionality. That definition carries the limit: no interaction, no observation. Static analysis reads all the code it can reach. IAST reads what happens.
This is why a team can install an agent, run a small smoke test, and see zero findings. The agent worked. The tests were simply narrow.
How to tell a quiet report from a covered one
- List the routes, handlers, and jobs your application exposes. Your router configuration or API definition is a good start.
- During a test run, collect which of them received requests. Access logs or the vendor console may show this.
- Compare the two lists. The gap is your blind spot.
- Pay attention to the unusual paths: admin pages, file uploads, webhooks, and error handlers. They tend to be least tested and most interesting to attackers.
- Add tests for the gaps, then rerun.
Ways to widen what the agent sees
| Approach | Strength | Caveat |
|---|---|---|
| Existing unit and integration tests | Cheap, already in CI | Often skip security-relevant inputs |
| Functional QA scripts | Realistic user journeys | Happy path heavy |
| A dynamic scan run against the same instance | Sends hostile inputs | Needs its own setup |
| Manual testing by a person | Finds odd paths | Does not scale |
Pairing the agent with a dynamic scan is a common idea, since the scan generates the hostile requests and the agent watches how the code handles them. That is a general pattern, so confirm with a vendor how their product supports it.
A worked example: ten endpoints, four exercised
Picture a service with ten endpoints: login, search, profile update, file upload, report export, admin settings, a webhook receiver, a health check, a password reset, and an internal batch trigger. The integration suite calls login, search, profile update, and the health check. The IAST report shows two findings, both in search.
A reader might conclude that the service is nearly clean. A careful reader lists the endpoints and notices that six, including upload, export, admin, and webhook, never ran. Those are often the riskiest. The accurate summary is two findings across four exercised endpoints, with six unexamined. That changes the priority from reporting good news to writing tests.
Writing tests that help the agent
Good security oriented tests do not need to be elaborate. For each untested endpoint, add one test with normal input and one with awkward input: very long strings, unusual characters, empty values, and values of the wrong type. For upload endpoints, try files with surprising names and types. For report exports, try filters that include special characters. The aim is not to attack the service. It is to make the code handle the kinds of input that expose weakness, while the agent watches.
Keep these tests in the normal suite so they run on every build, and label them so people know why they exist.
Measuring coverage over time
Track the share of routes exercised in the IAST run and plot it monthly. A rising line shows genuine progress. A flat line with falling finding counts is a warning sign, because it suggests the tool is seeing less, not that the code is getting safer. Pair the coverage figure with the finding count whenever you report.
Questions to ask when the report is empty
Start with the agent: was it loaded, and did it report from every instance? Next, the tests: which routes received requests, and with what kinds of input? Then the environment: did the run use realistic configuration, or a stripped down setup that disables the features that matter? Finally, the tool: does it support the framework in use, or might it be blind to parts of the stack? Work through these in order, because each answer narrows the cause. Most empty reports trace back to one of the first two. Write the answers in the run record so the next person does not repeat the investigation, and so a reviewer can see that silence was explained, not assumed.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at how a dynamic scan discovers pages and sends inputs. That is the kind of traffic that gives any runtime tool something to observe.
What to report upward
When you summarize IAST results, include the coverage number you measured next to the finding count. Zero findings across ten percent of routes tells leadership something very different from zero findings across ninety percent.
A reporting template
Add two lines to every IAST summary. First, instrumented services and the share of routes exercised in the last run. Second, the three least exercised areas and the plan to cover them. Those two lines make the report honest and give the team a built in improvement list. Over a few quarters you should see the coverage figure rise and the unexplored areas shrink, which is a better measure of progress than raw finding counts.
Quick check
Does a clean IAST report mean the app is secure?
No. It means nothing detectable happened on the paths that ran. Check what was exercised.
What is the cheapest way to improve IAST results?
Improve the tests that run while the agent is attached, especially those that send unusual or hostile input.
How much coverage is enough?
There is no universal number. Aim to exercise every externally reachable route, and treat the least tested areas as your next work items.
See also DAST, SAST, IAST and SCA compared. Safeguard's free scan at gold.safeguard.sh/scan covers a different layer, your dependencies, with SBOM and dependency scanning.
Sources
Last reviewed: 19 October 2026.
