Start the service with the IAST agent attached in a dedicated CI stage, run your integration tests against it, collect the findings when the tests end, and fail the build only on new, confirmed issues. The tests are what give the agent something to observe.
Why integration tests are the natural fit
OWASP describes IAST as testing the application while it is run by an automated test, a human tester, or any activity interacting with its functionality, with feedback available in the IDE, CI environment, QA, or production. A CI stage that already runs integration tests meets the requirement for activity without new tooling.
The pipeline shape
- Build the service as usual.
- Start it in a test container with the agent configured at launch.
- Verify the agent loaded. Run a check that fails the stage if the agent is missing, since a quiet agent produces a quiet report.
- Run the integration suite against the instance.
- Collect findings from the vendor console or API after the suite finishes.
- Gate on the result according to your policy.
- Publish results to the pull request so the author sees them.
Designing the gate
A gate that blocks on every finding will be switched off within a month. A better design is staged.
| Stage | Behavior |
|---|---|
| Weeks 1 to 4 | Report only, no blocking |
| Weeks 5 to 8 | Block on new high severity findings in changed code |
| Later | Add categories as the team's false positive rate allows |
Treat existing findings as a baseline with an owner and a date, and block only on what a pull request introduces. That keeps the gate fair.
A worked example: a pull request that adds an endpoint
A developer adds a new export endpoint and writes two integration tests for it. The pipeline builds the image, starts the service with the agent, and runs the suite. The agent reports a new finding on the export endpoint: a parameter reaches a file path without checking. The gate sees a new high severity finding in changed code and fails the stage.
The pull request comment names the endpoint, the parameter, and a link to the data flow. The developer fixes the check, pushes, and the stage passes. Total elapsed time is a few builds, and the flaw never reaches the main branch. This is the loop you want: fast, specific, and fair.
Handling flaky and slow stages
Treat the IAST stage like any test stage. If it fails for infrastructure reasons, fix the infrastructure, because a stage that fails randomly will be ignored. If it is slow, consider running it on merges to the main branch instead of every push, or running a focused subset on pull requests and the full suite nightly. Publish the stage duration where the team can see it.
Baseline and ownership
| Item | Approach |
|---|---|
| Existing findings | Baseline them with owners and dates |
| New findings in changed code | Block by policy |
| Suppressions | Reason, reviewer, expiry |
| Gate exceptions | Time limited, approved by security |
This arrangement keeps the gate credible while the backlog shrinks at its own pace.
Choosing what the pipeline stores
Decide what to keep from each run: the findings export, the agent version, the commit, the test results, and the coverage note. Store them with the build record so you can answer questions months later. Avoid storing raw request data that may contain sensitive values. If the vendor console already retains history, record where and for how long, and add a link in your pipeline output. Good records turn the pipeline into evidence of a repeatable process, and help when you need to show how a result was produced or why a build was allowed to proceed.
Rolling it out team by team
Pick one friendly team first, one with solid tests and an engineer who enjoys tooling. Run the stage in report only mode for a month, gather their feedback, and fix the rough edges. Then write a short guide with the real steps, the real pitfalls, and a contact for help. Invite the next team and repeat. Teams adopt tools faster when they hear from peers that the stage is fair and quick, and slower when a mandate arrives before the experience is smooth.
Try it yourself
Click through it at your own pace, or open it full screen.
Watch how a policy decides pass or fail on a change. Your IAST gate can follow the same pattern.
Pitfalls
- Parallel test runs. Several suites against one instance can blur which test caused a finding. Tag runs where the product allows.
- Flaky environments. A test stage that fails randomly trains developers to ignore it.
- Slow stages. Agent overhead lengthens the run. Measure it, see overhead.
- Thin tests. Coverage limits what the agent can find. See thin test coverage.
Reporting results to developers
Findings only change behavior if developers see them where they work. Post a short summary on the pull request with the count of new findings, the top item, and a link to the detail. Keep the comment brief, and avoid pasting full traces into the thread. If the stage fails, say exactly why and what to do next, such as fixing the code or requesting a time limited exception. A failure message that explains itself saves a round of questions to the security team and keeps trust in the gate.
Quick check
Should the IAST stage run on every commit?
Start on pull requests or on merges to the main branch, then widen if the stage is fast enough. Pick the cadence your team will tolerate.
Do I still need static analysis in CI?
They answer different questions. See how the methods compose.
What if the build has no integration tests?
Start by writing a few for your most important routes, or pair the agent with a dynamic scan. Without activity, the agent has nothing to observe.
Safeguard supports policies, gates, and guardrails on pull requests for dependency risk, and a free scan is at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
