To triage an IAST finding, reproduce the request that triggered it, read the data flow the agent recorded, check whether a control upstream or downstream neutralizes it, rate exposure, then assign an owner and a due date. Record the verdict so the same finding is never triaged twice.
Step by step
- Read the evidence. IAST reports typically include the request, the path through the code, and the spot where it became dangerous. OWASP lists examples such as unsanitized user input, hardcoded API keys, and connections without SSL encryption.
- Reproduce it. Replay the request in a test environment. If you cannot reproduce it, note why before closing.
- Check the controls around it. Is input validated elsewhere? Is the endpoint behind authentication? Is the data actually sensitive?
- Rate exposure. Who can reach this path: the internet, logged in users, or only internal staff?
- Decide the verdict. Use the table below.
- Assign and date. One owner, one due date, one ticket.
- Retest after the fix. Rerun the same request and confirm the agent no longer reports it.
Verdicts and next actions
| Verdict | Meaning | Next action |
|---|---|---|
| Confirmed, exposed | Real and reachable by outsiders | Fix on a short clock, consider a temporary shield |
| Confirmed, internal | Real but limited audience | Fix in normal sprint order |
| Mitigated elsewhere | Real code smell, neutralized by another control | Document the control, low priority fix |
| Not reproducible | Cannot trigger it | Note attempts, revisit if it recurs |
| False positive | Sensor misjudged | Suppress with reason and reviewer name |
| Duplicate | Same root cause as another | Link to the primary ticket |
Write good suppressions
A suppression is a decision with consequences. Record who made it, when, why, and when it expires. Without an expiry, suppressions slowly become blind spots.
Look for patterns
Ten findings may share one root cause, such as a missing input helper used everywhere. Fixing that once clears many. Group by code location and by type before assigning work.
Keep an eye on what the agent could not see
A finding list tells you about the paths that ran. Add a note about coverage when you report numbers. See thin test coverage.
Time boxes that help
Triage a new high severity finding the same day, medium in the same week, and low in batches. Pick numbers that match your team and write them in your policy.
A worked example
Suppose the agent reports unsanitized input reaching a database call on a search endpoint. You replay the request and confirm it reaches the query. You check upstream and find no validation. The endpoint is public, so exposure is high. Verdict: confirmed and exposed. You open one ticket, assign the owning team, set a short due date, and ask security whether a temporary shield makes sense. After the fix you replay the request, see no report, and close the ticket with a link to the merge.
Triage roles and timing
Pair a developer with a security reviewer for the first few weeks. The developer reproduces and explains the code path, and the security reviewer judges impact and exposure. After a pattern emerges, the developer can handle routine findings alone and escalate unusual ones. Agree turnaround targets by severity and put them in the policy, so everyone knows what on time means.
Common triage mistakes
- Closing a finding as a false positive without reproducing it.
- Rating exposure by assumption, not by checking who can reach the path.
- Suppressing with no reason or expiry.
- Fixing a symptom in one place while the same pattern exists elsewhere.
- Forgetting to retest after the fix.
Feeding triage back into the tests
Every confirmed finding suggests a test. Add a regression test that sends the unsafe input and asserts safe handling. That protects against the flaw returning and also improves the coverage the agent sees on future runs. Over time the test suite becomes a record of what has gone wrong before.
A one page triage template
Give every finding the same fields: identifier, service, route, summary, evidence link, reproduction steps, controls checked, exposure, verdict, owner, due date, and retest result. A template speeds up review, makes handoffs easier, and creates a consistent record. Keep it short enough that people will actually fill it in. If a field is rarely used, remove it. A lightweight template followed by everyone is better than a thorough one that nobody completes.
Measuring triage quality
Track three things: the share of findings with a documented verdict, the median time to verdict, and the share of verdicts later reversed. If many are reversed, triage is too hasty. If time to verdict is long, the evidence view or the process needs work. If documentation is thin, add the template and review a sample monthly. Small measurements keep triage honest without heavy process.
Escalation rules
Define in advance when a finding goes to a senior engineer or an incident process: confirmed exposure of sensitive data, evidence of active exploitation, or a flaw in a core shared component. Write the rule in the policy and name the contact. Clear escalation prevents both under reaction and panic.
Try it yourself
Click through it at your own pace, or open it full screen.
Click through to see how a decision is made on a change. Your triage verdicts feed a similar decision about whether a build passes.
Quick check
Who should triage, security or developers?
Both, together at first. Developers know the code, security knows the attack. After a few weeks the developers can handle most of it.
Do I need to fix every confirmed finding?
Prioritize by exposure and impact. Document the ones you defer, with an owner and a date.
How long should triage take per finding?
Often under half an hour for routine cases once the team has practice. Complex data flows can take longer, and that is fine.
Safeguard's free scan at gold.safeguard.sh/scan shows dependency findings, and its autonomous remediation can propose fix PRs, off by default. For method background, read what IAST is.
Sources
Last reviewed: 19 October 2026.
