Skip to main content

Triage and remediate findings

This article shows you how to manage and triage the findings identified by Semgrep Secrets using Semgrep AppSec Platform. The specific actions available to you when managing your findings include:

Local scans

Findings from local scans are differentiated from their remote counterparts through their slugs. Remote repositories are identified as ACCOUNT_NAME/REPOSITORY_NAME, while local repositories are identified as local_scan/REPOSITORY_NAME.

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:

  1. Filtering for a particular characteristic of a finding, such as its Validation status, Repository or Branch, or Type.
  2. Analyzing if the findings are true or false positives.
  3. Applying a triage state to the filtered findings based on the analysis in step 2.
    1. Setting a finding as Ignored means that no action is undertaken and the finding is closed. Subsequent scans won't include this finding.
    2. 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.
      1. Optional: You can create a ticket in Jira to assign a developer to fix findings.

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.

Review provisionally ignored findings

If you have Semgrep Assistant 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 are available to you on the Secrets page.

TaskSteps
Viewing valid findingsUnder Validation, click ⚠️Confirmed valid.
View findings in a specific project or branch1. Under Projects, select a repository from the drop-down menu.
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 severityUnder Severity, select a value.

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

  1. Begin by ensuring that you display all Open findings.
  2. 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.
  3. Click the bulk select check box.
  4. Click Triage, then your selected triage state, such as Reviewing or Ignored.
  5. Optional: Repeat this procedure to triage all open findings.

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 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 page.
info

Define which rules and validation states should be in Allow, Comment, or Block mode in the Policies page.

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.


Not finding what you need in this doc? Ask questions in our Community Slack group, or see Support for other ways to get help.