> ## Documentation Index
> Fetch the complete documentation index at: https://docs.semgrep.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# Triage and remediate findings

> This article shows you how to manage and triage the findings identified by Semgrep Secrets using Semgrep AppSec Platform.

## Triage findings

You can triage secrets-related findings in Semgrep AppSec Platform on the **Secrets** page. By default, all findings are displayed. A common triage workflow includes the following tasks:

<Steps>
  <Step>
    Filtering for a particular characteristic of a finding, such as its **Validation status**, **<Tooltip tip="A location, typically remote, for source code, including metadata relating to the source code. Semgrep supports Git repositories." cta="See full definition." href="/semgrep-code/glossary#repository">Repository</Tooltip> or Branch**, or **Type**.
  </Step>

  <Step>
    Analyzing if the findings are true or false positives.
  </Step>

  <Step>
    Applying a **triage state** to the filtered findings based on the analysis in step 2.

    i. Setting a finding as **Ignored** means that no action is undertaken and the finding is closed. Subsequent scans won't include this finding.

    ii. Setting or retaining a finding as **Open**, **Reviewing**, or **Fixing** means that the finding is a true positive and needs to be fixed or resolved.

      a. Optional: You can [create a ticket in Jira](/semgrep-appsec-platform/jira) to assign a developer to fix findings.
  </Step>
</Steps>

When commits are added to the PR or MR, Semgrep re-scans the PR or MR and detects if a finding is fixed, or if the secret is no longer valid. The finding changes status automatically upon scanning. Users do not need to set a finding as **Fixed** manually.

For non-historical secrets, a finding is considered fixed once it no longer appears in the code. However, this does *not* mean the underlying risk is resolved. If the secret has leaked, take the necessary remediation steps even if Semgrep marks the finding as **fixed**.

Findings for historical secrets always remain **Open**, because the secrets are identified after they've been removed from the code and Semgrep cannot determine whether it has been rotated or remediated. After you’ve addressed the issue, you can manually change the status to **Ignored**.

### Review provisionally ignored findings

If you have Semgrep Multimodal enabled, review the findings that have been **provisionally ignored**. These findings indicate that Semgrep has determined the secret to be **invalid**, which means that the secret has been revoked, was never functional, or used for a custom or private endpoint that Semgrep can't communicate with.

Findings with a status of **provisionally ignored** block pull requests and merge requests if the matching rule is included in a blocking policy. You can change the status of provisionally ignored findings to indicate the next steps in the triage process. For instance, you can set the status to **Reviewing** if you decide to manually review the finding.

## Common filtering use cases

You can find and perform bulk operations through filtering; [all filter operations](/semgrep-secrets/findings#filter-findings) are available to you on the **Secrets** page.

| Task                                                                                    | Steps                                                                                                                                      |
| --------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------ |
| Viewing valid findings                                                                  | Under **Validation**, click **⚠️Confirmed valid**.                                                                                         |
| View findings in a specific project or branch                                           | 1. Under **Projects**, select a repository from the drop-down menu. <br /> 2. Under **Branches**, select a branch from the drop-down menu. |
| View findings of a specific type of secret, such as **personal token** or **password**. | Under **Type**, select a type of secret.                                                                                                   |
| View findings of a specific severity                                                    | Under **Severity**, select a value.                                                                                                        |

You can triage findings in bulk by performing the following steps:

<Steps>
  <Step>
    Begin by ensuring that you display all **Open** findings.
  </Step>

  <Step>
    Apply filters with as much specificity as possible. You may have to perform bulk triage several times. By starting with the most specific cases, and closing the findings from those specific cases, you are able to narrow down findings as you work from specific to broad filter criteria.
  </Step>

  <Step>
    Click the bulk select check box.
  </Step>

  <Step>
    Click **Triage**, then your selected triage state, such as **Reviewing** or **Ignored**.
  </Step>

  <Step>
    Optional: Repeat this procedure to triage all open findings.
  </Step>
</Steps>

## Triage findings through PR and MR comments

In addition to viewing your results in Semgrep AppSec Platform, you can set up PR or MR comments from Semgrep, which allows you to view findings-related information directly in your pull requests and merge requests.

To receive PR or MR comments, ensure that:

* You have set up [comments](/category/pr-or-mr-comments) as part of your core deployment.
* You have defined which rules and validation states should be in Allow, Comment, or Block mode in the [Policies](/semgrep-secrets/policies) page.

<Note>
  **INFO**

  Define which rules and validation states should be in Allow, Comment, or Block mode in the [Policies](/semgrep-secrets/policies) page.
</Note>

## Default Secrets page view and branch logic

In Semgrep, a **single** finding may appear in several branches. These appearances are called **instances** of a finding. In Semgrep Secrets, the **latest instance**, or the finding from the most recent branch scanned, is displayed by default. This is because, if a Secrets finding is present in **any branch**, even a non-primary (default) branch, it is considered [valid](/semgrep-secrets/conceptual-overview#validate-secrets).