Vulnerabilities: find injection risks in normal traffic (passive IAST)

Passive IAST (interactive application security testing) uses the hooks runtime protection already has. While your app serves normal traffic, in QA, staging or production, it notices when a request input reaches a dangerous call verbatim, in a place the app did not parameterize. That happens even when the value is harmless and nobody attacked.

You get findings such as:

GET /api/orders/:id builds SQL from query.email (src/routes/orders.ts:42)

so developers can fix the code before anyone exploits it. Passive IAST never blocks.

Turn it on

Passive IAST is off by default. Runtime protection must be on, so the kill switch stops IAST too.

In Shield360: open WAF & RASP → RASP, choose the app, and turn on Report vulnerabilities (passive IAST). The setting reaches the app in its signed config.
In the app: rasp: { iast: true } (or the language’s equivalent), or the environment variable SHIELD360_IAST=on.
SHIELD360_IAST=off on the app always wins.

Sampling. By default every check is examined outside production and 10% in production. Change it with SHIELD360_IAST_SAMPLE_RATE, the signed config, or the local sampleRate option.

IAST works whatever the attack modes are. An attack type set to off still gets findings.

What it finds

Rule	A request input…
`vuln.sql_concat`	sits inside a SQL string literal, is a whole number or identifier, or is a run of whole tokens such as a sort list (`created_at desc`)
`vuln.cmd_shell`	sits inside one word of a shell command
`vuln.cmd_arg`	is an argument (not the program) of a process started without a shell
`vuln.path_from_input`	forms whole path segments, such as `/data/<input>.json`
`vuln.ssrf_host`	is the host of an outbound URL, or a base URL
`vuln.code_eval`	is inside code passed to `eval` or similar
`vuln.include_from_input`	is part of a module path that gets loaded
`vuln.deser_input`	is passed to an unsafe deserializer
`vuln.xml_external`	is XML passed to a parser that resolves external entities

To keep findings precise, very short or plain values don’t count: inputs under 3 characters, true/false/null, asc/desc, letters-only values under 8 characters, numbers under 4 digits, and punctuation only. Only request inputs count, never model output. A call that is also an attack is reported as the attack, not as a vulnerability.

Review findings

Open Protect → Application security → Vulnerabilities. The tiles show open, fixed, accepted and seen again after a fix. Filter by app and status.

Each finding shows the rule and how to fix it, the method and route, the input and the sink it reached (query.email → pg.query), the line of code, the apps and environments it was seen in, and how often.

Set a finding’s status to Open, Fixed or Accepted risk, with an optional note. A finding marked fixed that is reported again shows under seen again after a fix.

What is sent

The input is named by where it came from (query.email), never its value. No snippet is ever sent, even when snippets are on for attacks.
The code location is the first frame in your own code, as a path relative to the working directory.
Each finding is reported at most once an hour per process, with a count. Findings follow your runtime protection retention (Settings → Data retention → Runtime protection data).

Permissions and audit

Viewing findings needs View data protection events, and is recorded as data access. Changing a status needs Manage agent policies. Each status change is recorded in the audit log.

Limits

NoSQL, XSS and virtual patches have no IAST rule.
The thresholds trade recall for precision, so some real issues are missed: short names ('Smith'), short numbers, and input inside part of a path segment (user_<id>.png).
Code that never runs in the traffic you observe is never checked.

Next steps

Runtime protection
Decision queue and learning mode, which uses these findings to avoid suggesting allow entries for risky routes
Command center