Yes, but IAST is deployed per service, so a microservice estate means many agents, many test suites, and many finding streams. The technique itself works fine. The effort moves to rollout, ownership, and keeping coverage meaningful across dozens of small services.
What does not change
Each service still needs an agent attached at launch and activity that exercises its code. OWASP describes IAST as sensors included in the application that monitor behavior while tests or other interaction run. A service with its own tests can be instrumented independently of the others.
What does change
- Many agents to manage. Versions drift. Fifty services can mean fifty different agent versions without a plan.
- Tests sit at the wrong level. A unit test for one service may never send the requests that reach another. Cross service flows need end to end tests, which are fewer and slower.
- Findings need an owner. A finding in a shared library used by twenty services is one problem with twenty places to fix.
- Languages vary. Each runtime may need a different agent or none at all.
A rollout plan for many services
- Inventory services by language, criticality, and test quality.
- Pick the ten that are critical, in a supported language, with decent integration tests.
- Standardize how the agent is attached, for example a shared base image or a pipeline template, so teams do not each invent their own.
- Pin agent versions centrally and update them on a schedule.
- Route findings to the owning team automatically, using a service catalog if you have one.
- Review coverage per service quarterly. See thin coverage.
Where the effort goes
| Concern | Small app | Many services |
|---|---|---|
| Agent setup | Once | Template and automation |
| Coverage | One test suite | Per service plus cross service flows |
| Triage | One queue | Routing by ownership |
| Reporting | One number | Rolled up with caveats |
Keep the roll up honest
A fleet dashboard that says "zero critical findings" is meaningless unless it also says how many services are instrumented and how much of each was exercised. Report both the findings and the instrumented share.
Mind the shared dependencies
Many microservice findings trace to a handful of shared libraries and base images. A dependency inventory shows these quickly and complements runtime testing well, because it covers every service whether or not it has an agent.
Common mistakes
Teams often instrument the easiest services first and then report fleet wide results as if every service were covered. Others skip the cross service tests entirely, so the interesting bugs that appear only when services talk to each other go unseen. A third mistake is leaving the agent version unmanaged until a vendor advisory forces a scramble. Avoid all three by writing the rollout plan down, naming an owner for the agent standard, and reviewing instrumented coverage on a calendar rather than when someone remembers.
A worked example: ten services, three tiers
Suppose a company has forty services and decides to start with ten. Four are customer facing and handle sensitive data, three are internal APIs with solid test suites, and three are shared platform services. The team builds one base image with the agent included, one pipeline template for the test stage, and one routing rule that sends findings to the owning team from the service catalog.
After a month they review. Six services produce useful results. Two produce nothing because their tests barely exercise the code, and the team schedules test work. Two use a framework the agent does not support well, and the team marks them for other methods. The honest summary to leadership: six of forty services have effective runtime testing, with a plan for the rest.
Cross service flows
A request that passes through four services is hard to cover. Each service sees only its own slice. Build a small set of end to end journeys that run in a shared test environment, and instrument the services involved. Track the journeys by name so you can say which flows are covered.
Governance in one table
| Item | Decision |
|---|---|
| Agent standard | One pinned version per language, updated on schedule |
| Ownership | Platform team owns the standard, service teams own findings |
| Reporting | Instrumented share and exercised share next to counts |
| Exceptions | Time limited, with an owner and reason |
Language and framework variety
A fleet rarely uses one stack. You may have services in several languages, some on older frameworks and some on new ones. Map each to what a vendor supports before you promise coverage. Where support is missing, record the gap and choose another method, such as static analysis or dependency scanning, instead of leaving the service unexamined. Keeping an explicit list of unsupported services prevents a false sense of fleet wide protection.
Measuring progress across the fleet
Pick three numbers and report them monthly: the share of services instrumented, the share of routes exercised on instrumented services, and the age of the oldest open high severity finding. Together they tell an honest story. If instrumentation grows but exercised routes stay flat, tests need attention. If findings age, ownership needs attention.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at how an inventory covers every component across a project regardless of whether tests ran. Across many services that breadth is the counterpart to the depth you get from runtime testing.
Quick check
Do I need IAST on every service?
Not necessarily. Start where risk and test quality are highest, and use other methods for the rest.
Can one agent cover several services?
Generally an agent lives inside one application process. Confirm the model with any vendor.
How do we avoid alert fatigue across many services?
Route findings to owners, deduplicate shared root causes, and start by gating only new high severity issues. Add more once the queue is healthy.
Safeguard's SBOM and dependency scanning covers every service you point it at, and a free scan is at gold.safeguard.sh/scan. For the method itself, see what IAST is.
Sources
- OWASP DevSecOps Guideline: Interactive Application Security Testing
- Oracle: java.lang.instrument package
Last reviewed: 19 October 2026.
