Peer Reviewer Assistant

Last updated: Oct 8, 2026

The Peer Reviewer Assistant reviews the code changes of a pull request or a merge request (PR/MR). It reports the vulnerabilities that the change introduces in your code hosting platform.

The assistant covers the branch where the work occurs. A feature branch has a short life, and you do not register it on the platform. Without the assistant, you find its vulnerabilities only after the merge.

To connect your platform, refer to its own page: GitHub, GitLab, or Azure DevOps. When a PR/MR gets no review, refer to Troubleshooting.

The Peer Reviewer Assistant is available to groups on the Essential and Advanced plans.

Available only for cloud-hosted repositories. On-premises installations (GitLab, Azure DevOps, and GitHub Enterprise Server) are not supported.

Availability in each platform

Function	GitHub	GitLab	Azure DevOps
Review of the lines that the change adds	Available	Available	Available
Comment in the PR/MR	Available	Available	Available
Review of each new commit	Available	On the roadmap	On the roadmap
Status check on the commit	Available	On the roadmap	On the roadmap
Severity threshold of your policy	Available	On the roadmap	On the roadmap
Exclusions of the root	Available	On the roadmap	On the roadmap
Exceptions	Available	On the roadmap	On the roadmap
Record in the DevSecOps section	Available	On the roadmap	On the roadmap
Block the merge	Available	On the roadmap	On the roadmap

Fluid Attacks develops the functions that GitLab and Azure DevOps do not have yet. The goal is the same behavior in the three platforms.

What the assistant reviews

The assistant compares the PR/MR against the merge base of the branch that the change targets. It reports only the vulnerabilities on the lines that the change adds.

The assistant does not report a line that the change does not add. This is true also when a scanner finds a vulnerability on that line. Thus a PR/MR that changes a file with known vulnerabilities reports nothing. The author does not receive the history of the file.

The assistant runs these Fluid Attacks scanners on the code changes:

Scanner	What it detects
SAST	Vulnerabilities that the change introduces in the code
SCA	Vulnerabilities in the dependencies that the change affects
SS (Secret Scanning)	Secrets and credentials that the change introduces

The assistant does not run DAST, MAST, or CSPM analysis.

What starts a review

Action on the PR/MR	GitHub	GitLab	Azure DevOps
You open it	Yes	Yes	Yes
You push a new commit	Yes	No	No
You open it again	Yes	No	No
You ask for a re-run of the check	Yes	—	—
You close or merge it	No. The platform closes the review	No	No
You change the target branch	No	No	No
You mark it as Ready for review	No	—	—

In GitLab and Azure DevOps, only the first review occurs. A new commit does not start a new review. To get the review of the corrected code, open a new merge request or a new pull request.

In GitHub, the assistant reviews a draft pull request in the usual manner. The mark Ready for review does not start a new review, because the assistant reviewed each push to the draft.

A re-run does a new scan. It is not only a new judgement of the result. Thus a re-run obeys the exclusions and the threshold that the root has at that moment.

The classes of vulnerability

Class	What it means	Effect on the check
Unmanaged	The score is equal to the threshold or more, and it has no exception	The check fails
Allowed	An exception in the platform covers it	The check does not fail
Below threshold	The score is less than the severity threshold	The check does not fail

The severity labels obey the CVSS 4.0 score:

Label	Score
Critical	9.0 and more
High	7.0 to 8.9
Medium	4.0 to 6.9
Low	Less than 4.0

The summary comment

The assistant keeps one comment in each pull request. It edits this comment at each review. Thus the conversation stays clear.

The heading of the comment is Fluid Attacks security analysis. Below the heading, a headline gives the result:

Headline	When
`Failed · 2 unmanaged vulnerabilities`	There is one unmanaged vulnerability or more
`Passed · No vulnerabilities found`	The assistant reported nothing
`Passed (accepted risk) · 3 vulnerabilities allowed in Fluid Attacks`	An exception covers each vulnerability
`Passed · 1 vulnerability below the severity threshold`	All the vulnerabilities are below the threshold
`Incomplete · The security scan could not complete`	The scan did not end

Below the headline, the comment has these parts:

A count line, 2 Unmanaged · 1 Allowed, when there is an unmanaged vulnerability or an allowed vulnerability.
A table with the three most severe vulnerabilities. The table shows the severity, the weakness, and the location of each one.
The line +57 more in Fluid Attacks, when the review found more than three.
The line Not failing the check: 1 vulnerability below the threshold., when some vulnerabilities are below the threshold and some are not.
A last line that attaches the result to a commit: PR #18 · commit ea65c74 · scanned 2026-10-07 00:39 UTC.
The link View details in Fluid Attacks →. This link opens the review of that pull request in the platform.

Summary comment of the Peer Reviewer Assistant with the Failed result

When every vulnerability is below the severity threshold, the headline says Passed:

Summary comment with the Passed result and a vulnerability below the severity threshold

If you push a newer commit during the scan, the assistant does not write the old result in the comment. The comment always agrees with the commit that it names.

The status check

Available in: GitHub. On the roadmap for GitLab and Azure DevOps.

The name of the check is Peer Reviewer Assistant. GitHub shows it as Fluid Attacks Platform / Peer Reviewer Assistant, because GitHub puts the name of the app before the name of the check. Use this name when you make the check necessary in the branch protection.

Result	The check reports
Passed	Success
Passed (accepted risk)	Success
Failed	Failure
Incomplete	Failure

The check alone does not block a merge. It blocks a merge only when you make it necessary in your branch protection rule or in your ruleset. Refer to GitHub.

Annotations in the diff

The assistant writes an annotation on the line of each vulnerability:

An unmanaged vulnerability has an annotation of the type failure.
A vulnerability below the threshold has an annotation of the type notice.

Checks tab of a pull request with the annotations of the assistant in the diff

The assistant writes a maximum of 50 annotations. When the review finds more than 50, the summary of the check ends with The first 50 are annotated. The platform shows the full list.

The severity threshold

Available in: GitHub. On the roadmap for GitLab and Azure DevOps.

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.

Minimum to break the build field in the DevSecOps policies of the group

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 does a new scan and applies the new threshold. Thus you do not push a commit.

Exclude files from the review

Available in: GitHub. On the roadmap for GitLab and Azure DevOps.

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 change adds a vulnerable line to the file.

You edit the exclusions where you register the root. Refer to Exclude subpaths in Git repositories.

Exclusions field of a Git root in the Scope section of the group

Pattern	What it excludes
`*.min.js`	All the minified JavaScript files
`node_modules/`	The `node_modules` directory and all its content
`test/fixtures/*`	All the files below `test/fixtures`
`src/legacy/`	The `src/legacy` directory
`config/local.*`	`config/local.yaml`, `config/local.json`, and so on

Fluid Attacks recommends that you do not exclude parts of your repository. An exclusion can hide a vulnerability that puts your security in danger.

In the platform, the patterns belong to the root, and not to a branch. To edit them, you must have the permission to update the exclusions of a root.

The obsolete exclusion files of the repository

Two files in the root directory of the repository still exclude files today:

.fluidattacksignore
fluidattacks-exclude.txt

These two files are obsolete. They operate today, but the assistant will not read them in the future. Move their patterns to the Exclusions of the root. When a review finds one of these files, the summary comment tells you that the file is obsolete.

To move the patterns:

Open the file and copy its patterns.
Go to the Scope section of the group.
Open the Git root of that repository.
Add the patterns in the Exclusions field.
Delete the file from the repository.

Until you delete a file, the assistant obeys these rules:

If the repository has the two files, the assistant uses .fluidattacksignore.
A line that starts with # is a comment.
The assistant ignores an empty line.

Exceptions

Available in: GitHub. On the roadmap for GitLab and Azure DevOps.

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.

Vulnerabilities tab with two unmanaged vulnerabilities selected

The Grant exception window lists what you accept, and it asks for the justification:

Grant exception window with the list of vulnerabilities and the justification field

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.

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.

Review in the platform

Available in: GitHub. On the roadmap for GitLab and Azure DevOps.

You find each review of a pull request in the DevSecOps section of the group. A row with the Type Peer Reviewer Assistant is a review of a pull request.

Column	What it shows for a pull request
Identifier	`PR #18 · ea65c74`, with the source branch below
Type	Peer Reviewer Assistant
Status	In progress, Passed, Passed (accepted risk), Failed, or Incomplete
Vulnerabilities	The total, with N unmanaged · M allowed below. A dash while the scan continues
Breaks build	Yes or No. A dash while the scan continues
Strictness	Strict. One unmanaged vulnerability makes the check fail
Technique	SAST · SCA · SS
Git repository	The nickname of the root
Executed date	The date when the review ended

DevSecOps table of the group with the reviews of the Peer Reviewer Assistant

The platform does not count a vulnerability below the severity threshold as unmanaged, and it does not count it as allowed. Thus this column shows no quantity for a review that found only these vulnerabilities. The detail of the review shows them.

The detail of one review

Click the identifier of the row to open the review. The View details in Fluid Attacks → link in the summary comment opens the same page.

The header shows the number and the title of the pull request, its status, and six fields:

Field	What it shows
Git repository	The nickname of the root
Branch	The source branch and the target branch
Commit	The commit of the review
Pull request	The number of the pull request
Author	The person who opened the pull request
Executed date	The date when the review ended

Copy link gives you the address of the review. Send it to a person who can grant an exception. Open in SCM opens the pull request again.

The review has three tabs.

Vulnerabilities

This tab shows each vulnerability of the review, with its weakness, its file, its line, its technique, and its score. The Gate column shows Unmanaged, Allowed, or Below threshold. An allowed vulnerability also shows which exception covers it. Click Export CSV to get the list as a file. You also grant the exceptions in this tab.

Exceptions

This tab shows one card for each exception, with its justification, the person who granted it, and the date.

Pushes

This tab shows one row for each commit of the review, the newest first, with the result of that review and the quantity of unmanaged vulnerabilities. It is the history of how the pull request arrived at its current state.

If the Peer Reviewer Assistant did not review a pull request, the platform tells you so. It does not show an empty review.

What to do with each result

Result	What you must do
Failed	Correct the unmanaged vulnerabilities. If you cannot, ask your group manager for an exception in Fluid Attacks
Passed (accepted risk)	Nothing. The platform keeps the record of each allowed vulnerability
Passed, with vulnerabilities below the threshold	Nothing is necessary. But it is better to correct them
Incomplete	Push a new commit, or ask for a re-run of the check

An Incomplete result means that the scan did not end, thus some vulnerabilities can be absent. It is not a result about your code. The check reports a failure, because Fluid Attacks cannot tell you that your change is safe.

Peer Reviewer Assistant

On this page