Scanning · IAST

IAST — Interactive application security testing

IAST instruments a running service with an in-process agent, tracks tainted input from the HTTP request all the way to the sink, and reports vulnerabilities with the exact request, the code path and the stack trace. Every finding was observed under real traffic — not inferred.

Early access — JVM first IAST is in early access with a Java / JVM agent first; other runtimes follow. Enterprise customers can join the early-access programme from the contact page. Everything below describes the module as it is designed to work.

What IAST is (and when to use it)

IAST sits between static and dynamic testing. SAST reads your code from the inside but never runs it; DAST attacks the running app from the outside but can't see the code. IAST does both at once: an agent runs inside the application process while it handles requests, so it sees the real code path a real input took. It answers the question neither can on its own: “What is actually vulnerable under real traffic?”

Use IAST when you already exercise your application — a test suite in CI, a DAST scan, or real traffic in staging — and you want runtime confirmation with very low false positives, without uploading source or standing up a proxy.

Where it fits

	SAST	DAST	IAST
Vantage point	Inside the code, not running	Outside the running app	Inside the running app
Needs source?	Yes (a `.zip`)	No	No — just the agent
Needs it running?	No	Yes	Yes
Evidence	Dataflow trace	Request / response	Request + code path + stack trace
False positives	Scored & reviewed	Low	Very low — it was observed

How it works

Attach the agent
Add the agent to your JVM service in CI or staging with a per-project token. No source upload, no proxy, and no changes to your build.
Exercise the app
Run your test suite, point a DAST scan at it, or send real traffic. The agent observes every request as it's handled.
Findings stream in
Confirmed vulnerabilities appear with the triggering request, the code path and the stack trace as they're observed — live, while the traffic runs.
Fix and verify
Patch the sink and re-run the traffic; a fixed sink simply stops reporting. No re-upload, no re-scan.

Attaching the agent

The agent attaches with a single -javaagent flag and a project token — the same way you'd attach any JVM agent. Nothing about your build or your packaging changes.

java -javaagent:codesguard-iast.jar=token=YOUR_PROJECT_TOKEN \
     -jar your-application.jar

Illustrative — your exact flag, collector endpoint and token are shown on the IAST project page in the app.

You keep the runtime The agent runs on your side, in your environment, and reports to an authenticated collector using the per-project token. You can revoke that token at any time, which immediately cuts the agent off. CodesGuard never needs access to your running service.

Runtime taint tracking

The agent watches data cross from an untrusted source to a sensitive sink as the request is handled. Because it's inside the process, it sees the actual values and the actual path — not a model of them.

Sources (untrusted input)	Sinks (sensitive operations)
HTTP parameters, form fields, headers, cookies and body	SQL and other database queries
	Operating-system command execution
	File-system access
	Object deserialization
	The HTTP response (reflected output)

Proof on every finding

An IAST finding is the hybrid of SAST's inside view and DAST's live conditions. Each one carries:

The request that triggered it: The exact HTTP request that drove the tainted value in.
The code path it took: How the value travelled from source to sink through your code.
The stack trace at the sink: Where it landed, down to the line — so a developer can go straight to it.

Route coverage

Because the agent sees every request, it also tells you what your testing actually touched. The project page shows which routes were:

discovered exercised never reached

A route that's never reached is a blind spot in your tests, not a clean bill of health — IAST makes that distinction explicit.

Request → agent (in-process) → source → code path → sink → finding, with the stack trace captured at the sink.

The agent follows a tainted value from the HTTP request to the sink, inside the running process.

Same findings queue

IAST findings land next to SAST, SCA, DAST and AI Pentest results in the unified Findings view — the same severities, the same workflow and the same roll-up into your dashboard security posture. A SQL-injection sink confirmed at runtime by IAST correlates with the same weakness flagged in code by SAST.

Access & plans

IAST is part of the Enterprise plan and is currently in early access with the JVM agent. To enrol, talk to the team from the contact page. See Billing & plans for how modules map to plans.

FAQ

When is IAST available?: IAST is in early access with a Java / JVM agent first. Enterprise customers can join from the contact page; other runtimes follow.
Does it slow my application down?: The agent is designed for CI and staging environments and batches its reports. Production-deployment guidance ships with the agent.
Do I need to upload source code?: No. IAST needs only the agent and a project token. It observes your running service directly — no source upload and no proxy.
How is this different from DAST?: DAST attacks from the outside and infers what happened from responses. IAST watches from inside the process, so it confirms the vulnerable code path with a stack trace and almost no false positives.