Run an IAST proof of concept on one real service for two weeks. Define success criteria first, install the agent in a test environment, drive it with your existing tests plus a dynamic scan, then measure findings, coverage, overhead, and triage effort against those criteria. Decide from the numbers you collected.
Before day one
Choose a service that is typical, not a showpiece. Pick a language the vendor supports. Name one engineer and one security reviewer who own the trial. Write down what a pass looks like. For example: the agent attaches without code changes, findings are reproducible, overhead stays inside a limit you set, and the team can triage a finding in a reasonable time.
The plan
| Days | Activity | Output |
|---|---|---|
| 1 to 2 | Install the agent in a test environment, confirm it loads | Working attach, version and flags recorded |
| 3 to 4 | Run the existing integration suite | First findings, first coverage estimate |
| 5 to 6 | Add a dynamic scan against the same instance | Findings that tests alone missed |
| 7 | Review every finding with the developers | Real, duplicate, or noise label per finding |
| 8 to 9 | Measure overhead with a repeatable load test | Before and after numbers |
| 10 | Wire into CI for one pipeline | Evidence of automation effort |
| 11 to 12 | Fix two or three real findings and rerun | Proof the finding closes |
| 13 | Compare with what your current static and dynamic tools found | Overlap and unique findings |
| 14 | Score against the criteria and write the decision | One page recommendation |
What to measure
- Attach effort. How long, how many changes to launch configuration.
- Coverage. Which routes saw traffic while the agent watched. See why thin tests give clean reports.
- Finding quality. How many findings the developers called real after review.
- Overhead. See how to measure it.
- Triage time. Minutes from finding to decision.
- Data handling. What the agent sends off the host.
Traps to avoid
- Testing only on a toy app. It proves nothing about your stack.
- Letting the vendor run the trial for you. Your team must feel the daily work.
- Counting raw finding totals as a win. More findings is not better if half are noise.
- Skipping the exit question: what would it take to run this across fifty services?
How OWASP frames the method
OWASP describes IAST as testing performed while the application is run by an automated test, a human tester, or other activity, using sensors embedded in the application. A fair trial exercises both pieces: the sensor and the activity that drives it.
A worked example: scoring a trial
Imagine your criteria are attach effort, finding quality, overhead, and triage time, each scored from one to five by the two owners. After the trial, attach effort scores four because the agent loaded on the first try and needed one launch flag. Finding quality scores three because the developers called most findings real but two were duplicates of the same root cause. Overhead scores four after the load test showed a small tail effect. Triage time scores two because the console required many clicks to see the data flow.
The total is not the point. The low score points at a specific question for the vendor, and the high scores tell you where the product is already acceptable. Write the scores and the reasons together.
Roles and rhythm
Name a trial lead who keeps the calendar and the notes. Hold a fifteen minute sync twice a week. In each, review new findings, open questions, and blockers. Keep a shared document with dated entries. When the trial ends, the document is the raw material for your report, so you do not rebuild the story from memory.
The one page decision
End with a single page that covers five things: what you tested, what you measured, what surprised you, what remains unknown, and your recommendation with conditions. A recommendation such as proceed on two critical services, with a quarterly coverage review, is more useful than a bare yes.
If the trial goes badly
A failed trial is a result. Record why: unsupported framework, heavy overhead, unreadable findings, or an unworkable data policy. Share it with the vendor so they can respond, and keep the notes for the next evaluation. Teams that document failures avoid repeating them.
What to hand the vendor before you start
Share a short brief: the runtime and framework versions, how the service is built and deployed, the test environment, and your success criteria. Ask for named support contacts during the trial and agree how quickly questions should be answered. A vendor that responds slowly during a trial is giving you a preview of support later. Keep every question and answer in writing, since they become part of your evaluation record.
Try it yourself
Click through it at your own pace, or open it full screen.
Use it to see what a dynamic scan produces against a running web app. In days five and six of your trial you pair that kind of traffic with the agent, so this shows the activity side of the pair.
Quick check
Is two weeks enough?
It is enough to judge attach effort, finding quality, and overhead on one service. It is not enough to judge fleet wide rollout, so list that as an open item.
Who should sign off?
The engineer who owns the service and the security reviewer, since one judges disruption and the other judges signal.
Do I need production data in the trial?
No, and you should avoid it. Use a test environment with realistic but non sensitive data, and confirm with your privacy lead what the agent may observe.
For vendor questions to bring to the trial, see what IAST needs to work. Safeguard's free scan at gold.safeguard.sh/scan gives you a dependency baseline to compare against.
Sources
Last reviewed: 19 October 2026.
