AI Triage

A scanner can flag code that looks dangerous but isn't, in context. AI Triage reads the flagged code and the code around it, works out who could actually exploit the finding and what they would gain, and rates the finding on that basis. It then keeps the finding's severity, lowers it, or dismisses the finding. It never raises a severity.

What AI Triage assesses

AI Triage answers the questions a security lead would ask, and shows the answers on the issue's attack story:

• Who would do this? - the person who would exploit it, such as anyone on the internet, a signed-in user of another organisation, or an insider. When nobody attacks and the problem happens in normal operation, it says so.
• What has to be true? - the access that person already holds, and anything else the attack needs, such as a setting being on or another person opening a link.
• What stops them? - controls on this exact path that block or limit the attack, with their location in the code.
• What is the technical impact? - the most they can read, change, or stop through this weakness, how much of it, and what that adds to the access they already have.
• What is the business impact? - who bears that harm: whose data or service it is, what kind of data, and whether customers depend on the affected feature.
• Likelihood and impact - a Low, Medium, or High rating for each, with the reason behind it. See How we determine severity.

The full assessment on the issue adds the detail behind those answers:

• Application context - what the flagged code is part of, who uses it, and where it runs.
• Attack path - the route from where input enters the application to the flagged code, including every authentication, permission, or validation check it passes.

AI Triage works from your code. Where a fact can't be established from it, such as network exposure or whether data is regulated, AI Triage says it is an assumption rather than presenting it as confirmed. It does not estimate money, reputation, or legal consequences.

How we determine severity

Every finding gets two ratings, likelihood and impact, each Low, Medium, or High. The severity comes from combining them. Each rating is shown on the issue with a plain-English reason, so you can see why a finding landed where it did.

Likelihood: how easily can this happen?

Likelihood looks at three things:

• Who can reach the code - anyone on the internet, any signed-in user, or only privileged users and internal staff.
• What else has to be true - whether the attack works every time, or needs a victim to act, an unusual configuration, or lucky timing.
• How much work it takes - a single request, or inside knowledge the attacker must obtain first.

The hardest of these sets the rating. A flaw that anyone can reach but that only works in a rare configuration is not rated as highly likely.

Impact: how bad is it if it does?

Impact starts with the worst thing the weakness allows:

• Reading data the attacker should not see, from internal details up to credentials.
• Changing data or behaviour, from internal bookkeeping up to permissions or running code.
• Stopping something from working, from a slowdown up to a full outage.

That harm is weighed against how much it covers: only the attacker's own account, one other user or record, a whole organisation, or every customer. Leaking one record is rated lower than leaking all of them.

Business context can then move impact up or down by one level. It considers the kind of data involved (personal and regulated data count for more), who is affected (your customers or only your own team), whether the code is core to your product or an internal tool, and whether the damage can be undone.

The severity matrix

Severity is read from this matrix, which follows the OWASP Risk Rating Methodology:

	Low impact	Medium impact	High impact
High likelihood	Medium	High	Critical
Medium likelihood	Low	Medium	High
Low likelihood	Low	Low	Medium

The same ratings always produce the same severity. A finding is Critical only when it is both easy to exploit and does serious, wide-reaching harm.

AI Triage applies this severity only when it is lower than the one the scan gave the finding. It never raises a severity.

What the ratings are based on

• Evidence in your code. Each rating is tied to what the code shows. When the code does not show something, such as whether data is regulated, that point is left out of the rating. It is not assumed to be the worst case.
• Harm beyond existing access. A finding is rated on what it adds to what the attacker can already do. An admin who can already delete records gains nothing from a second way to delete them.
• Your context. Dismissal notes you write become security context for later runs. See Learning from your dismissal notes.

Auto-dismissed findings

AI Triage dismisses a finding only when your code shows one of these:

• The flagged behaviour does not exist.
• It causes no security harm, such as a performance or correctness problem that exposes nothing and grants nothing.
• The attacker's existing access already achieves the same outcome.

A finding that is unlikely or low impact is not dismissed. It stays open at a lower severity.

When AI Triage dismisses a finding, its reasoning is recorded as the dismissal note, so you can see exactly why. Dismissed findings are marked in the Issues view. Other actionable sub-issues remain open.

If you disagree with an auto-dismissal, restore it the same way you restore any other dismissed sub-issue. See Triaging Sub-issues.

Learning from your dismissal notes

When you dismiss a finding with a reason and note, Dam Secure can turn that into lasting security context for the repository. Later AI Triage runs use that context alongside what they learn from the code.

This is especially valuable for controls that live outside the repository (for example, "rate limiting is enforced at the load balancer"), which Dam Secure cannot observe directly in the codebase.