The GitLab vulnerability report is a consolidated list of findings from successful security scan jobs on the default branch, at project or group level. You triage by setting each item to confirmed, dismissed or resolved. It is an Ultimate tier feature.
What lands in it
Scanner findings on feature branches appear in merge requests first. They become vulnerabilities in the report after merging to the default branch. That is why a report can look empty while a branch is full of findings.
Statuses
| Status | Meaning |
|---|---|
| Needs triage | New, nobody has looked yet (exports call it "detected") |
| Confirmed | Real and accepted as a problem |
| Dismissed | Not acting on it, with an optional reason |
| Resolved | Fixed or no longer present |
Filters and groupings
You can filter by status, severity, report type, scanner, activity, identifier, reachability, validity check, malware, tracked ref and policy violation. Some of these need advanced vulnerability management. Multiple filters combine with AND. You can group by status, severity, report type, scanner and OWASP Top 10 categories, with the newer OWASP groupings needing advanced management.
Actions you can take
- Change status, with a required comment when dismissing.
- Change or override severity, with a required reason.
- Link findings to an existing or new issue.
- Export all vulnerabilities as CSV. Filters do not apply to the export.
- Manually add a vulnerability on a project.
Viewing needs the Security Manager, Developer, Maintainer or Owner role. Changing status needs Security Manager, Maintainer or Owner, or a custom role with the admin_vulnerability permission.
Details that surprise people
Counts above 1000 display as "1000+". On GitLab.com, vulnerabilities are archived one year after their last update. A project tracks up to four contexts, meaning the default branch plus three branches or tags.
A 20 minute weekly triage
- Filter to Needs triage and the highest severity.
- Check whether a fix is available and whether the item is reachable, where that filter applies.
- Confirm and file an issue for items you will fix this sprint.
- Dismiss with a written reason for anything you accept, so the next person understands.
- Export a CSV monthly for audit evidence.
Where a dedicated scanner fits
A separate platform helps if findings come from many hosts and you want one queue and one risk score. Safeguard provides vulnerability management with reachability analysis and a free scan at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen.
Try sorting and changing a status to see how a triage queue shrinks.
Quick check
Why is my vulnerability report empty?
Findings become vulnerabilities after merge to the default branch, and other jobs failing in a pipeline can hide scanner output.
Can I dismiss without explaining?
No. Dismissing requires a comment, and the reason field is optional.
Sources
Last reviewed: 19 October 2026.
