Triage findings
Filter the Security page, expand a finding, dismiss or reopen it, split a wrong grouping, and choose which branch opens findings.
Availability
Who can use this: see Roles.
- Triage security findings: Security and Org admin.
- Manage tracked branches: Security and Org admin.
Finding and filtering
- Search: in the Findings view, matches CVE, GHSA and CWE IDs. In the Scan results view, matches other fields as well.
- Filters: click Filters to pick one or more Severity, Status, Source and Repository values. Active filters show as chips; click the x on a chip to remove it or Clear filters to remove all.
Expanding a finding
For findings with public vulnerability IDs, the details can also show advisory CVSS, CISA KEV and EPSS data. See Vulnerability intelligence for what these values mean and how they update.
Click a finding to expand it in place. The details show the full description, "Deduplicated from N scan results across M sources" when the finding groups more than one scan result, then every scan result with its scanner, state, severity, location, package, and a link to view it on its source.
The repository in each row links to the repository on GitHub, GitLab, Bitbucket or Azure Repos. A scan result's location links to the file and lines at the commit it was found at, and the branch and commit are shown and linked when the report or alert recorded them. Without a commit, the file opens on that branch, or on the default branch. Branch and commit are recorded for scan results reported from now on; older ones keep what they had. Each scan result also shows why it was grouped into this finding, for example "GHSA-... is an alias of CVE-... (OSV)".
A scan result from a SARIF report also shows its Rule when the report described the rule: the rule's name, its short and full descriptions, its help text, and a link to the rule's documentation (https links only). Prodgator keeps each rule description once per organization, from the reports you upload, and never the matched code or a result's message. A rule the report did not describe shows nothing extra.
Dismissing a finding
Security and Org admins can click Dismiss on an open finding. Prodgator asks for a reason and an optional comment of up to 280 characters:
| Finding kind | Reasons |
|---|---|
| Dependency vulnerability | False positive, Fix started, Not affected, Tolerable risk, Used in tests, Won't fix |
| Code scanning | False positive, Fix started, Not affected, Tolerable risk, Used in tests, Won't fix |
| Secret | False positive, Fix started, Not affected, Revoked, Tolerable risk, Used in tests, Won't fix |
| License | False positive, Fix started, Not affected, Tolerable risk, Used in tests, Won't fix |
Dismissing a finding:
- Marks it Dismissed in Prodgator and records who, when, the reason and the comment.
- Removes it from the open counts.
- For GitHub alert members: also dismisses them on GitHub with the corresponding reason (the mapping varies by alert type). If GitHub refuses one source (for example, the Prodgator GitHub App lacks a permission), the response says "Dismissed 2 of 3 sources" and explains why.
- For members from uploaded reports: Prodgator dismisses them in Prodgator only. There is nowhere to write the dismissal back to.
- Scan results that join a dismissed finding later are dismissed in Prodgator too.
Prodgator to GitHub reason mapping
When dismissing a GitHub alert, Prodgator uses the following GitHub reasons:
| Prodgator reason | Dependency | Code scanning | Secret |
|---|---|---|---|
| False positive | inaccurate | false positive | false_positive |
| Fix started | fix_started | won't fix | wont_fix |
| Not affected | not_used | false positive | false_positive |
| Revoked | (N/A) | (N/A) | revoked |
| Tolerable risk | tolerable_risk | won't fix | wont_fix |
| Used in tests | not_used | used in tests | used_in_tests |
| Won't fix | no_bandwidth | won't fix | wont_fix |
Security and Org admins can reopen a dismissed finding. A GitHub member is reopened on GitHub too. Reopening an alert on GitHub reopens the finding in Prodgator.
Dismissals and reopens made on GitHub show in Prodgator with the GitHub user who made them. A dismissal that only exists in Prodgator stays while the finding is open at its sources.
Splitting and rejoining a finding
If a finding grouped scan results incorrectly, Security and Org admins can click Split and move one or more scan results to a new finding. The split is recorded in the audit log.
Click Rejoin to undo a split, moving scan results back to the original finding. The rejoin is also recorded in the audit log.
Tracked branches
Each repository has one tracked branch, by default its default branch on GitHub (which Prodgator reads during the security sync). Only scan results on the tracked branch open findings. Scan results from other branches are kept in the Scan results view.
Members who manage security settings change the tracked branch under Security > Settings > Tracked branches. The change regroups existing findings within a few minutes. Tracked branches are per provider: a GitLab, Bitbucket or Azure DevOps repository with the same name as a GitHub one has its own setting, and the list names its provider, for example .
Repositories Prodgator has not yet seen on GitHub use or as the tracked branch until someone sets one. When you upload a report, you can mark it tracked to open findings whatever its branch.
Findings from a pull request scan can also reach the tracked branch when the pull request merges. See Findings from pull requests.