AI security triage
Group and prioritize your open GitHub security alerts with AI, with false positives pointed out for you to check.
Availability
Security triage reads your open security alerts, groups the ones that share a cause or a fix, puts the groups in priority order and explains each one. It has its own Triage tab on the Security page, next to Findings and Scan results ( opens it). The tab shows only when your plan includes security triage and it is turned on for your organization.
Running a triage
Nothing runs on its own. Click Analyze on the Triage tab to triage the whole organization, or pick one repository in the Scope menu first to triage that repository only. The scope is the same as the Repository filter on the other tabs: one repository selected there is the triage's scope too. A triage costs 3 AI credits.
Prodgator keeps the result. Opening the page again shows it at no cost. When findings were detected after the triage was written, the tab says how many ("3 new findings since this triage") next to Reanalyze, which always writes a new one. Reanalyze is also offered when a run failed.
A triage usually takes under a minute. If it takes longer than four minutes it stops and the tab says it took too long; select one repository and try again. A run that has not finished after ten minutes is shown as not finished, with Reanalyze.
What is read
A triage covers the open GitHub security alerts Prodgator has synced (Dependabot, code scanning and secret scanning) within your plan's data retention. Findings from uploaded reports and connectors are not part of it.
Prodgator reads up to the 500 most severe open findings, ordered critical, high, medium, low and newest first within each severity, and combines findings with the same cause into one entry: the same package and advisory across repositories, or the same rule in the same file. The model gets up to 120 entries, most severe first. When findings are left out, the tab says so ("Triaged the 200 most severe of 340 open findings"). For each entry it gets the number of findings, the title, up to five repositories and file paths, package and versions, CVE id, code scanning rule, and the first 300 characters of the description.
Secret scanning alerts are different: only the type, repository, rule and file path are sent, never the description or the matched value.
Everything is passed to the model as data: instructions written inside a finding's title or description are ignored, and the tab notes when one looked like an instruction.
What you get
- Summary: a few sentences on the state of the findings.
- Groups: a table with one row per group of findings that share a package, rule or file. Each row shows the priority, the group, how many findings it holds, their severities and whether a fix is available. Click a row to see why it matters, the recommended action and its findings; each finding links to the alert (in the Scan results tab, or on the provider).
- Might be false positives: a second table of findings that look like test fixtures, example keys, dev-only dependencies or unreachable code, each with the reason.
Under the tables are the sources the triage read, when it was generated, and Helpful / Not helpful buttons.
Priorities mean:
| Priority | Meaning |
|---|---|
| P1 | Fix now: exploitable, reachable, in production |
| P2 | This sprint |
| P3 | Planned |
| P4 | Accept or monitor |
Findings the model did not place in any group are listed under Not grouped, with the priority of the most severe one among them.
What triage never does
The suggestions are advisory. Nothing is dismissed, reopened or changed by the triage: check each suggested false positive yourself and dismiss it on the Security page or in the provider if you agree.
Output language
A triage is shared by everyone in the organization, so it is written in the organization's AI output language (Admin Console > AI), the same as failure explanations and release risk summaries.