Scan exceptions
Describe, in plain language, situations in your repository that scans should not report.
A scan exception is a sentence describing something intentional in your code, so pre-commit and pull request scans stop reporting it. Write it as you'd explain it to a new teammate:
/loginis public by design and needs no authentication.
The
internal/metricsservice only listens on localhost, so its endpoints don't check permissions.
When a scan finds something an exception describes, it doesn't report it. It isn't counted and never blocks.
Repository exceptions
Open the repository and go to Settings › Exceptions. You can add, edit, turn on or off, and delete exceptions. Team exceptions are listed read-only under From team settings.
Team exceptions
For something true across all your repositories, a team admin adds it under Settings › Exceptions. For example: "All services run behind an authenticating gateway, which sets the X-User-Id header. Services can trust it."
Writing a good exception
| Do | Why |
|---|---|
| Name the route, file, service, or header. | "Admin routes are fine" is too vague to apply safely. |
| Say why it's safe. | The reason helps the scan tell your situation apart from a real problem next to it. |
| Cover one situation per exception. | Two short exceptions are applied more accurately than one long one. |
Limits: 500 characters per exception, 100 per repository, and 50 per team.
How exceptions are applied
- A scan uses the exceptions that were on when it started. Changes affect future scans only.
- Each exception shows how many times it's been used and where it came from, such as From a finding when it was created while marking a false positive.
- If an exception hides something it shouldn't, turn it off or make it more specific.