Configuration
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.
Which pull requests the assistant reviews
The assistant reviews a pull request only when all these conditions are true. If one condition is false, the code hosting platform shows no result.
| Condition | Where you set it |
|---|---|
| The repository is inside the installation of the app | On GitHub, when you install or edit the app |
| The group has pull request review on | Integrations, SCM connections, Pull request review |
| The repository is a Git root of that group | Scope section of the group |
| That root is Active | Scope section of the group |
The assistant reviews each pull request of a repository that you registered on the platform. The branch that the pull request targets does not change this.
An inactive root does not permit the review. If you deactivate a root, the assistant stops the review of the pull requests of that repository in that group.
Exclude files from the review
Each Git root has an Exclusions field. The patterns of this field use gitignore syntax. The review obeys them: if an exclusion covers a file, the assistant does not report that file. This is true also when the pull request adds a vulnerable line to the file.
You edit the exclusions where you register the root. Refer to Exclude subpaths in Git repositories.
| Pattern | What it excludes |
|---|---|
test/fixtures/* | All the files below test/fixtures |
*.min.js | All the minified JavaScript files |
vendor/ | The vendor directory |
Set the severity threshold
The review uses the same policy as CI Gate: Minimum to break the build. You set this policy in Policies, at the level of the organization. You can also set a different value for one group. Refer to Security gates.
A vulnerability breaks the check when its score is equal to the threshold or more than the threshold:
| Threshold | Score of the vulnerability | Result |
|---|---|---|
| 8.1 | 8.1 | The check fails |
| 8.1 | 8.0 | The check does not fail |
| 8.2 | 8.1 | The check does not fail |
Only a score less than the threshold passes. A vulnerability with a score equal to the threshold breaks the check.
The assistant detects and reports a vulnerability below the threshold. The summary comment shows it, and the diff shows it as a notice. This vulnerability does not make the check fail.
If you change the threshold, ask GitHub to re-run the check. The assistant examines again the vulnerabilities that it found before. Thus the result can change, and you do not push a commit.
Block the merges that disobey your policy
To make the check necessary, you must have admin access to the repository on GitHub.
The check alone does not block a merge. To block a merge, you must make the check necessary in GitHub:
- Open a pull request and let the Peer Reviewer Assistant check report one time. GitHub shows a check in the branch protection only after the check reports.
- In the protection rule or the ruleset of the target branch, select Peer Reviewer Assistant as a required status check.
- In a ruleset, attach the check to the Fluid Attacks Platform app. Thus no other app can report the check in its place.
GitHub explains the two mechanisms in its own documentation:
- Require status checks to pass before merging, for a ruleset.
- About protected branches, for a branch protection rule.
Related information
Azure DevOps Peer Reviewer Assistant
Set up the Fluid Attacks Peer Reviewer Assistant for Azure DevOps to get automated vulnerability scanning and comments on pull requests.
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.