# Resolve findings in your pull request or merge request

Source: https://semgrep.dev/docs/for-developers/resolve-findings-through-comments

- [](/docs/)- [For developers](/docs/for-developers/overview)- Resolve findings- Resolve findings in your pull request or merge request**On this page- [Developer education](/docs/tags/developer-education)Resolve findings in your pull request or merge request
Findings resolution involves the assessment of a finding, then either fixing or ignoring it. You can fix or triage findings from your source code manager (SCM); fixing or triaging (ignoring) does **not** require a Semgrep AppSec Platform account.

Findings are primarily presented to developers through **pull request (PR) or merge request (MR) comments**. These findings are generated from rules that your AppSec team has vetted or approved.

Findings from these rules are meant to be **fixed** or **remediated** rather than ignored unless the finding is a false positive.

In **typical coding workflows**, it is recommended to fix or ignore findings as part of your **code review** process; the results of triage or remediation in your SCM are synchronized with Semgrep AppSec Platform.

However, if you have accumulated many findings to ignore, it may be faster to perform bulk triage actions in Semgrep AppSec Platform. See [Resolve findings through the Semgrep web app](/docs/for-developers/resolve-findings-through-app).

## Prerequisites and optional features[​](#prerequisites-and-optional-features)

- The procedures described in this guide rely on PR or MR comments. Ensure that your security team has enabled this feature.
- To receive AI-assisted remediation, your security team must enable the **Semgrep Assistant** feature.

Your SCM is the most common environment in which to fix findings. Semgrep provides several features to help you fix findings quickly.

## Parts of a PR or MR comment[​](#parts-of-a-pr-or-mr-comment)
Semgrep findings are typically posted in your PR or MR. The following image displays the parts of a Semgrep PR comment in GitHub; this example appears in a similar form in GitLab and other SCMs:

*
***Figure**. An example of a PR comment with various sections annotated.*

A - Block indicatorThis appears if a finding fails the CI job. Organizations typically block PRs or MRs with failed jobs.B - Finding descriptionA human-written description always appears in a PR or MR comment, describing why your code is flagged. **References** may also be included to help you learn more about the finding.C - Dataflow graphSome Code findings have a dataflow graph, which indicates that the finding was detected through [taint analysis](/docs/writing-rules/glossary#taint-analysis). The dataflow graph provides the lines of code identifying sources, sinks, and traces of unsanitized data flowing through your program. You can click the links on the boxes to take you to the lines of code.D - Resolution or remediation sectionVarious options are provided to help your resolve the finding. Depending on the [type of finding](#type-of-findings-by-resolution), resolution options may vary.E - Ignore instructionsClick to view instructions about how to ignore the finding by replying to the comment.
## Resolve findings[​](#resolve-findings)
Different types of findings require different remediations. The following sections describe how Semgrep can help you resolve a finding.

### Autofix[​](#autofix)
Some Semgrep Code findings provide an **autofix**, which can be human-written or generated by Semgrep Assistant. The fix can be committed directly, such as by clicking **Commit suggestion** in GitHub repositories. This is the fastest way to fix a finding.

All Semgrep-supported SCMs provide this feature.

***Figure**. GitHub enables you to commit the suggestion from Semgrep directly, fixing the finding.*

infoIf a line of code contains several findings, Semgrep does not provide the autofix or **Commit suggestion** feature to prevent fixes from conflicting.

### Semgrep Assistant remediations[​](#semgrep-assistant-remediations)
Semgrep Assistant provides the following AI-powered security recommendations:

- Step-by-step instructions.
- AI-written code fixes if a human-written autofix is not available and a code fix can resolve the finding.
- &quot;Safe to ignore&quot; suggestions.

***Figure**. PR comment with an AI-written fix and step-by-step instructions.*

***Figure**. Semgrep Assistant suggesting that a finding is safe to ignore.*

## Ignore findings[​](#ignore-findings)
If the finding is a false positive, acceptable risk, or similar, you can choose to ignore the finding. You can ignore findings directly from your SCM by **replying** to the finding comment.

- 
Find an open comment created by Semgrep AppSec Platform in your pull request or merge request:

- 
In a subsequent comment, reply with the action you want to take. You must provide a **reason** to help the reader understand why the finding has been triaged as **ignored**:

CommentDescription`/fp &lt;REASON&gt;`Triage a finding as **Ignored** with the triage reason **false positive**.`/ar &lt;REASON&gt;`Triage a finding as **Ignored** with the triage reason **acceptable risk**.`/other &lt;REASON&gt;`Triage a finding as **Ignored** without specifying the reason; the triage reason value is set to **No triage reason**.`/open &lt;REASON&gt;`Reopen a finding that has been triaged as **Ignored**. The comment is optional.

***Figure**. A completed triage flow.*

### Re-run a job or workflow[​](#re-run-a-job-or-workflow)
After resolving or triaging the findings in your PR or MR, you must re-run the Semgrep job or workflow. See the following list for a link to your CI provider&#x27;s documentation:

- [* Re-run a job in GitHub Actions](https://docs.github.com/en/actions/managing-workflow-runs-and-deployments/managing-workflow-runs/re-running-workflows-and-jobs)
- [** View pipelines in GitLab CI/CD](https://docs.gitlab.com/ee/ci/pipelines/#view-pipelines)
- [** View your pipeline in Bitbucket Pipelines](https://support.atlassian.com/bitbucket-cloud/docs/view-your-pipeline/#Viewyourpipeline-CI_RerunStep)
- [** Re-run a single stage in Azure DevOps](https://learn.microsoft.com/en-us/azure/devops/release-notes/2024/pipelines/sprint-235-update)
- [** Restarting or rerunning a pipeline in Jenkins](https://www.jenkins.io/doc/book/pipeline/running-pipelines/#restarting-or-rerunning-a-pipeline)
- [** Re-run a job in CircleCI](https://circleci.com/docs/rerun-failed-tests/)
- [** **Retry a job**](https://buildkite.com/resources/changelog/231-retry-failed-jobs-while-builds-are-running/) from the [**Dashboard &gt; Build view**](https://buildkite.com/docs/pipelines/dashboard-walkthrough) in Buildkite.

## Appendix: triage statuses[​](#appendix-triage-statuses)
Click to view all triage statuses.StatusDescription**Open**Findings are open by default. A finding is open if it was present the last time Semgrep scanned the code and has not been ignored. An open finding represents a match between the code and a rule enabled in the repository. Open findings require action, such as rewriting the code to eliminate the detected vulnerability.**Reviewing**Indicates that the finding requires investigation to determine what the next steps in the triage process should be.**Provisionally ignored**Findings that Semgrep Assistant has flagged as false positives. You can change the status to **Ignored** if you agree with Assistant&#x27;s assement. Otherwise, you can change the status to **To fix** if you disagree.**To fix**Findings that you have decided to fix. Commonly used to indicate that these findings are tracked in Jira or assigned to developers for further work.**Fixed**Fixed findings were detected in a previous scan but are no longer detected in the most recent scan of that same branch due to changes in the code.**Ignored**Findings marked as ignored are present in the code but have been labeled unimportant. Ignore false positives or deprioritized issues. Mark findings as [ignored through Semgrep AppSec Platform](/docs/semgrep-code/triage-remediation) or by adding a [nosemgrep code comment](/docs/ignoring-files-folders-code#reference-summary). You can also provide a reason for ignoring a finding: **False positive**, **Acceptable risk**, **No time to fix**.**Closed**Vulnerabilities that are no longer detected after a scan. This can be due to changes in the underlying rule or the code.
### Removed findings[​](#removed-findings)
Findings can also be **removed**. Semgrep considers a finding removed if it is not found in the most recent scan of the branch where Semgrep initially detected it due to any of the following conditions:

- The rule that detected the finding isn&#x27;t enabled in the policy anymore.
- The rule that detected the finding was updated in a way that it no longer detects the finding.
- The file path where the finding appeared is no longer found. The file path was deleted, renamed, added to a `.semgrepignore` file, added to a `.gitignore` file, or added to the list of ignored paths in Semgrep AppSec Platform.
- For GitHub organization accounts: the pull request or merge request where the finding was detected has been closed without merging.

Your removed findings do not count toward the fix rate or the number of findings. The removed findings also do not appear in Semgrep AppSec Platform.

### Triage behavior across refs and branches[​](#triage-behavior-across-refs-and-branches)

- When you triage a finding as ignored, reviewing, fixing, or reopened, Semgrep always triages across other branches and [Git references](https://git-scm.com/book/en/v2/Git-Internals-Git-References) (refs).
- At scan time, there&#x27;s automatic triaging that occurs in specific cases, and the behavior changes depending on the type of scan:

**Full scans**: if the current branch includes a finding that was

Previously introduced in another branch ***and***
- Triaged to a specific state
**Then** the finding in the current branch is triaged to that same state.

- **Diff-aware scan**: findings introduced in a diff-aware scan are **not** automatically triaged at scan time, even if there are other instances of that finding on branches that have been triaged.

Not finding what you need in this doc? Ask questions in our [Community Slack group](https://go.semgrep.dev/slack), or see [Support](/docs/support/) for other ways to get help.

Tags:**- [Developer education](/docs/tags/developer-education)[Edit this page](https://github.com/semgrep/semgrep-docs/edit/main/docs/for-developers/resolve-findings-through-comments.md)Last updated on **Sep 3, 2025**