Exceptions
Last updated: Oct 7, 2026
This page describes the GitHub integration. The work on the GitLab and Azure DevOps integrations continues. The goal is the same behavior as GitHub. Refer to their own pages.
An exception permits the merge of a pull request with a vulnerability that your team accepts. You do not change the code, and the policy stays the same for all the other pull requests.
Role required: Group Manager. A developer cannot grant an exception on their own pull request.
Grant an exception
- Open the review of the pull request in the platform. The quickest way is the View details in Fluid Attacks → link in the summary comment.
- In the Vulnerabilities tab, select the unmanaged vulnerabilities that you accept.
- Click Grant exception.
- Examine the list below Vulnerabilities to except.
- Write a justification: why this pull request can merge with this vulnerability.
- Confirm.
The justification is necessary. The form does not accept an empty
justification. The form also rejects a justification that starts with a symbol
such as -, =, +, or @.
The check changes immediately. You do not push a commit, and the assistant does not scan again. The platform publishes a new check run on the same commit, and it writes the summary comment again.
What an exception covers, and for how long
| Situation | What occurs |
|---|---|
| You push a new commit to the pull request | The exception continues to apply, also when the code moves to a different line |
| You open the pull request again | The exception applies again |
| You merge or close the pull request | The exception ends |
| The same vulnerable code occurs in a different pull request | The exception does not cover it. You decide each pull request separately |
| The same block of code occurs two times in one pull request | These are two different vulnerabilities. An exception on one does not cover the other |
An exception does not move to a different pull request. If you accept a risk one time, this is not a permission for the future.
You cannot grant an exception on a pull request that is closed or merged. You also cannot grant an exception on a review whose scan did not end. The platform tells you so. Exceptions become available again after a scan ends.
You cannot select a vulnerability below the severity threshold. This vulnerability does not make the check fail, thus there is nothing to accept.
Examine the exceptions
The Exceptions tab of the pull request shows one card for each exception. The platform gives each card a number: EXC-1, EXC-2, and so on.
| Field | What it shows |
|---|---|
| Covers | The quantity of vulnerabilities, with the file and the line of each one |
| Justification | The reason that the person wrote |
| Granted by | The person who granted the exception |
| Granted on | The date of the exception |
| Age | The time from that date |
A pull request that passes with exceptions reports to GitHub the same result as a clean pull request. Thus a branch protection rule permits the merge of the two. The platform keeps the record of each exception: what, who, and why.
Related information
Functionality
How the Peer Reviewer Assistant reviews a pull request: what starts a review, what it reports, and how to read the summary comment, the check, and the diff annotations.
Review in the platform
Find the reviews of your pull requests in the DevSecOps section of a group, and read the detail of one review: its vulnerabilities, its exceptions, and its pushes.