Triage
Triage is AISafe's AI-powered finding analysis pass. After an assessment's agents discover potential security issues, triage verifies which are proved vulnerabilities or concrete hardening notes, removes exact duplicates, consolidates repeated systemic issues, and prepares findings for human review.
What triage does
The triage pass performs several critical functions that turn raw agent output into an actionable backlog:
- Confirmation: validates that each finding represents a proved vulnerability or concrete hardening note. The triage agent re-examines the evidence and checks for mitigating factors before promotion.
- Deduplication: removes candidates that prove the same concrete issue. The finding that remains shows the source it cited itself, so each place to fix appears once instead of once for every candidate that reported it. Several distinct instances of one failed control can become one systemic finding when they share one remediation, and every instance is shown.
- Severity refinement: adjusts the initial severity rating based on exploitability, impact, and context. The triage agent might downgrade a finding that looks critical in isolation if it requires an improbable precondition, or upgrade it if the agent discovers a more serious impact.
- Impact refinement: keeps the auditor's original estimate in the audit record while narrowing the published finding to the last consequence that the proof establishes. For a hardening note, it states the current exposure and keeps later harm conditional on the exact missing premise. Triage cannot add an actor, resource, trust condition, or blast radius that the evidence does not show.
- Evidence verification: checks the supplied locations, taint flows, proof-of-concept, reproduction steps, and decisive premises. Triage does not fill gaps or invent missing candidate evidence or reproduction material; it rejects candidates that lack enough proof.
After triage, a report-writing pass turns each surviving finding into the prose you read and picks which of its source ranges the finding shows. It keeps what a developer changes and what proves the weakness is reachable, narrows a wide range to the lines that change, and leaves out code cited only for contrast. A finding always names at least one place to change.
Triage runs as the final stage of each assessment. You do not need to trigger it. By the time you open the findings list, the triage pass has completed and the findings are ready for your review.
Human-in-the-loop
Triage produces recommendations. Your team retains full control over finding status. From the dashboard, you can apply any of the following triage actions to a finding. Each action updates the finding's status and moves it through your remediation workflow:
| Action | What it means |
|---|---|
| Confirm | You agree with the triage assessment. You accept the finding as a real security issue and it stays in the active backlog for remediation. |
| False positive | You override the triage decision and mark the finding as a false positive. You must provide a reason so your team has context for the override. |
| Accepted risk | You acknowledge the vulnerability but choose not to fix it (for example, it is low impact, mitigated elsewhere, or out of scope). You must provide a reason. |
| Duplicate | You mark the finding as a duplicate of another finding and link it to the canonical one. This keeps your backlog clean and avoids double work. |
| Fixed | You mark the finding as remediated. This happens after you patch the code and verify the fix. |
The reason requirement covers findings that appear in an assessment report, where the justification is printed next to the decision. A standalone SAST scan produces no report, so its findings take False positive or Accepted risk in one click with no reason.
False positive and Accepted risk are the two decisions that also appear on the project's Suppressions page: the list of findings your team has decided about, whichever part of AISafe found them, with who decided and why. A decision there is Active while it stands. Use Active, Inactive, or All and search by finding, file, reason, person, source or review code. Inactive rows distinguish revoked, expired and awaiting-approval decisions. Tab counts show all decisions in each state.
Severity dots appear beside finding titles, and Expires shows the deadline. Select rows and use Actions to revoke or restore decisions. Select-all covers the current page; changing a filter or page clears the selection. Restoration keeps each original reason unless you enter a replacement. Managers can change assessment and scan decisions; PR decisions need an admin or owner. Open a finding to read its full details and justification.
Both false positives and accepted risks expire one year after the decision (or its approval). The deadline is fixed. Restoring or changing the decision starts a new year; a rescan or unrelated edit does not. Expiry brings an unresolved finding back for review and preserves any verified fix result.
Severity levels
AISafe assigns each finding a severity level that reflects its potential impact and exploitability. AISafe uses five severity levels:
- Critical: the vulnerability allows an attacker to execute arbitrary code, access sensitive data without authentication, or take over the application. You should remediate these first.
- High: the vulnerability has a significant impact (e.g. privilege escalation, data exposure) but requires some precondition or is harder to exploit. Prioritize these in your current sprint.
- Medium: the vulnerability has a moderate impact (e.g. information disclosure, limited injection) that an attacker could exploit under specific circumstances. Plan to remediate in a reasonable timeframe.
- Low: the vulnerability has a minor impact (e.g. verbose error messages, missing security headers) that an attacker has little chance of exploiting on its own but contributes to overall risk.
- Info: the finding is a concrete, non-exploitable security hardening note. It is not an ordinary functional bug, unreachable-code concern, or generic best-practice recommendation.
The triage agent may adjust the initial severity rating based on exploitability, impact, and context. The agent might downgrade a finding that looks critical in isolation if it requires an improbable precondition. When severity is adjusted after assessment, AISafe preserves the original AI rating, the adjusted value, the actor, and any required justification in the finding's severity history.
Use severity as a starting point for prioritization. Consider your application's specific context: threat model, exposure, and business impact when deciding what to fix first.
Triage in the dashboard
The findings list in the dashboard is your triage queue. Filter by severity or status to focus on what matters. Each finding shows the triage agent's reasoning alongside the evidence, so you can make informed decisions.
You can triage findings one at a time or in bulk. Select multiple findings and apply the same action to all of them at once. This is useful when the triage agent has flagged a cluster of duplicates or a group of low-severity issues you want to accept as risk together. The dashboard logs each action you take, so your team has an audit trail of who confirmed, rejected, or accepted each finding.
On a finding page, these controls are in Insights & Tools on desktop and under Actions on smaller screens. Both surfaces enforce the same role and finding-status rules.
You can export triaged findings to issue trackers like Jira or Linear, so remediation work flows into your engineering workflow without manual copy-paste.