Skip to main content

How to respond

When a PR opens, AISafe posts review comments on the specific lines of the diff, similar to a human code reviewer. Each comment includes:

  • The vulnerability type and severity.
  • A brief explanation of the issue.
  • A suggested fix, with a code snippet where applicable.

What developers do​

Treat the inline comments like feedback from a human reviewer. Check that you agree with the assessment, apply the suggested fix or a better one that resolves the issue, and push the change. AISafe also reviews PR updates, so a corrected PR is checked again.

Every finding in the review summary links to its own page in AISafe. Each finding has a code you can quote in a ticket, such as PR-ACME-XQV-003, which is the review's own code followed by the finding's position in that review. The page is at /projects/{project}/pr-reviews/PR-ACME-XQV/findings/PR-ACME-XQV-003. It shows the finding, the review it came from, and a link to the exact line in your repository. The link keeps working after a rebase, because AISafe tracks a finding by the code it flags rather than by the line it was on.

If you are not going to change the code behind a finding, record that decision on the finding's page so you do not have to dispute the finding on every push. See Disagreeing with a finding.

Retry review appears on a review that failed, and asks for the same commit to be reviewed again without pushing anything. A review that completed already has a result, so it does not have this button. To get another review, push a change and AISafe reviews it, or comment @aisafe review to have the same commit reviewed again. The earlier review stays as history, and a second review costs the same as any review.

Asking for a review​

Anyone with write access to the repository can ask for a review by commenting @aisafe review on the pull request — on an outside contributor's pull request, or on one AISafe skipped. /aisafe review works too, as does mentioning the app by its own name. AISafe adds a 👀 to your comment and reviews the commit it was made on, and reviews that commit again if it has already been reviewed.

A comment from somebody without write access does not start a review. This stops an outside contributor from spending your review allowance.

Disagreeing with a finding​

Available on plans with the Suppressions feature; ask your workspace owner if you do not see it.

Open the finding — from its link in the summary comment, or from the project's PR Reviews tab — and record the decision there: Mark false positive when the reviewed code is not affected, or Accept risk when it is a real issue you are choosing not to fix yet. In both cases AISafe stops posting that finding on later reviews instead of raising it again on every push. The decision appears on the project's Suppressions page, which lists the findings your team has made a decision about, with who decided and why.

Both decisions expire one year after they become active. A new approval or a restored decision starts a new year; later reviews keep the original deadline. Use the project's Suppressions table to see expiry dates and select several decisions to revoke or restore together.

AISafe does not delete a suppressed finding. The finding stays in the summary comment, in its own collapsed section that names the decision that suppressed it and whether the team accepted the risk or called it a false positive. It no longer appears as an inline comment and no longer fails the check. The review page in AISafe shows the same thing. Its count covers only the findings the review still reports, and the findings that a decision suppressed are named beside it. A review whose findings are all suppressed is shown as clean, with the reason. Reopen on the finding's own page undoes the decision, and AISafe posts the finding again on the next review of that pull request.

A decision applies to the issue itself, even when its code moves to another line. AISafe gives every review the decisions your team has already made (the finding, where it was, and the reason you gave), and the review compares each new finding against them. This means that moving the code, renaming the handler or reformatting the file does not bring an accepted issue back. If the change makes an accepted issue materially worse, or weakens the reason you gave, the review reports that.

Accepting a risk always requires a date. When the date passes, the decision comes back for review, so it does not stand for ever. A critical finding can only be accepted as a risk; it can never be marked a false positive.

Recording a decision needs an admin or owner role, and the Suppressions feature on your plan.

For a deeper look at the capability, see PR Review: how it works.

Why a review missed a PR​

If a PR did not get a review, open the project's Source tab. The delivery log shows whether AISafe received the pull-request or push event and why it was ignored. Common reasons shown include no project bound to the repository, a branch filter mismatch, PR review disabled, or insufficient credits.

Two reasons concern who opened the pull request or asked for the review, rather than the pull request itself:

  • Waiting for a maintainer to ask. The pull request came from somebody without write access, and Pull requests from people without write access is on its default. Comment @aisafe review on it, or set that to Review automatically.
  • The person who asked has no write access. A @aisafe review comment from an outside contributor does not start a review. Somebody on the team needs to comment instead.

A third reason is that AISafe could not check the person's access, because the provider would not say what access they have. Nothing was charged. Try again, and check the repository connection if it keeps happening.

Two more reasons are about the code itself:

  • The provider refused access to the repository. The connection is no longer allowed to read that code — the app was uninstalled, its access was narrowed, or the repository moved. Reconnect the integration on the Integrations page, or grant it access to this repository, then push a commit or comment @aisafe review.
  • The provider could not be reached. GitHub or GitLab did not respond, and still did not respond while AISafe retried over the next few hours. Nothing on your side is wrong and nothing was charged. AISafe reviews the next push to the pull request normally.

Why a review ran but nothing appeared on the pull request​

A review can finish and the provider can still refuse to accept it. In that case the review in AISafe shows Not delivered and names the four things that cause this:

  • the AISafe app no longer has write access to the repository;
  • a branch rule rejects its check;
  • the pull request closed while the review was running;
  • the review is larger than one comment the provider will accept.

The findings are on that review, so you can read them there. Nothing was charged. Once the cause is fixed, re-run the review or push a commit, and AISafe posts the review on the pull request as usual.

Next steps​