• Semgrep Cloud Platform
• Team & Enterprise Tier

Managing findings in Semgrep Cloud Platform

The Findings page enables you to easily manage findings. Findings are the core results of Semgrep analysis. Findings are generated when a Semgrep rule matches a piece of code.

Figure 1. Screenshot of findings page.

A finding can be categorized in two ways:

1. Finding categorization based on the issue or code it detects:

   • Anti-patterns
   • Security vulnerabilities (such as dangerous function usage)
   • Business or logic bugs
   • Matches based on your own custom rules (such as organization-specific authentication logic)

   Semgrep rules provide a metadata schema to identify these common categories. Semgrep findings include a message field that describes the security issue or bug found in matching code. Additionally, findings can provide a fix field that fixes the issue by creating a suggestion within your source code management (SCM) tool, such as GitHub, GitLab, and Bitbucket.

2. Finding categorization based on the validity of the match:

   True positive

   Rules are written to match a certain code pattern. A true positive is a genuine match. The rule is capturing the code as intended.

   False positive

   A false positive is a mismatch between the intended purpose of the rule and the code it matched. A finding is generated but does not meet the rule's intended need. Rules with a high false positivity rate are said to be noisy.

   False negative

   A false negative is a finding that should have been found by a rule, but was not. This can happen for two reasons:

   • A flaw in the rule's logic. See Reporting false negatives.
   • A bug within Semgrep itself. See the list of Semgrep issues to file a bug report.

Working with findings

After a finding is generated, developers can:

• Fix the issue detected by the finding. This is Semgrep's primary goal. In this case, the rule produces a true positive finding (such as a security issue) as intended and developers must change or address the code such that the rule no longer matches it.
• View the Semgrep rule and the matching code. For developers aiming to understand their team's security posture, Semgrep provides a top-level report view through the Dashboard and a list view of findings in the Findings page that can be filtered by repository, rule, branch, or triage action.
• Triage the finding. If the finding is not useful or important, deprioritize it through triage. Triage actions include ignoring and reopening. Triaging a finding to ignore it is one method to handle false positives without changing the rule or code. To triage a finding, see Managing finding status
• Remove the rule or code that generated the finding. There are cases where Semgrep scans a file not meant for scanning or when a rule is irrelevant. You can disable the rule from the Policies page or add the file to the ignore list. To disable a rule, see Disabling rules.

tip

• An additional method to address false positives is to improve the rule. Create test cases to ensure that the rule performs as intended.
• If a rule from Semgrep Registry is useful but also captures too many false positives, you can reach out to support@semgrep.dev. This helps rule-writing efforts and improves the quality of rules that you run.
• Additionally, you can report rules with a high false positive rate from your SCM if you have enabled Semgrep Cloud Platform to leave comments in PRs. Semgrep Cloud Platform provides a link after each comment for users to indicate if the finding is a false positive.

Understanding retention periods

The retention period of these findings are as follows:

Retention period	Tier availability
5 years retention	Team/Enterprise

Viewing data on the Findings page

Navigating to the Findings page

1. Sign in to Semgrep Cloud Platform.
2. Click Findings in the left sidebar.

Understanding the Findings page

The Findings page consists of:

• Findings filter panel: Panel which lets you filter for different findings.
• Findings information: Gives you details about findings. Each finding in the list includes rule name, Policies action column description, link to findings detail page, rule message, repository name, link to Git branch name, link to the reported file, and reported line of code.
  Figure 2. Findings information panel.

Filtering findings

Filtering allows you to easily isolate groups of findings for ease in triaging and identifying related groups of issues. The following criteria are available for filtering:

Filter	Description
Projects	Filter by repositories connected to Semgrep Cloud Platform.
Status	Filter for different findings triage states. Refer to the following table to understand triage states.
Severities	Filter by the severity of a finding. Possible values: Low Medium High
Actions	Filter by monitoring, commenting, or blocking rules in your Policies.
Confidences	Filter by indication of the rule to detect true positives. The higher the confidence the more true positives the rule may detect.
Categories	Filter by various rule categories, such as security, or best practice rules. More than one category can be selected for filtering.
Branches	Filter by findings in different Git branches.
Rules	Filter by rules or rulesets that are included in your Policies page. More than one rule can be selected for filtering.
Rulesets	Filter by name of the ruleset where rules that matched the code belong. More than one rule or ruleset can be selected for filtering.

tip

Findings categorized under Security can be easily identified by its badge. This badge is unique to Security findings for ease of triage.

You can also filter for findings reported from specific time periods. See Displaying findings reported in a specific time.

To filter through findings:

1. Click the filter criteria. The page then refreshes to reflect the additional criteria.
2. Optional: To further refine your filter, select additional filters.

Displaying findings reported in a specific time

Display and filter for findings reported only in specific time. To display findings reported in a specific time, follow these steps:

1. In Semgrep Cloud Platform, go to Findings page.
2. Click the All time button.
3. Select preferred time period for which to display findings. The following options are available:
   • All time - This is the default option.
   • Last 1 year
   • Last 1 month
   • Last 7 days
   • Last 1 day

Grouping by rule

Semgrep Cloud Platform by default groups findings by a specific rule on the Findings page.

Figure 3. Screenshot of the Findings page with findings grouped by rule.

info

In the group by rule view, the rules that reported the highest number of findings are at the top of the page. This sorting of findings helps you to easily see which rules have the highest efficiency or generate a lot of noise in your code.

Disabling grouping by rule

To disable grouping by rule, follow these steps:

1. In Semgrep Cloud Platform, go to Findings page.
2. Click the list under Group by Rule, and then select No grouping.
   Figure 4. Screenshot of the No grouping option.

info

Findings in the no grouping view are displayed by their recency. The most recent finding is at the top of the Findings page.

Triaging findings

Triaging means prioritizing a finding based on a policy or criteria set by your team or organization. While severity is a factor in triage, your organization may define additional criteria based on coding standards, business, or product goals.

Semgrep Cloud Platform uses the logic specified in the table below to automatically mark findings as either fixed or removed when a finding is no longer present in the code. You can also ignore findings in Semgrep Cloud Platform directly through triage or bulk triage.

The triage statuses are as follows:

Status	Description
Open	Findings are open by default. A finding is open if it was present the last time Semgrep scanned the code and it has not been ignored. An open finding represents a match between the code and a rule that is enabled in the repository. Open findings require action, such as rewriting the code to eliminate the detected vulnerability.
Ignored	Findings that are ignored are present in the code, but have been labeled as unimportant. Ignore findings that are false positives or deprioritized issues. Mark findings as ignored through Semgrep Cloud Platform (see Managing finding status or by adding a code comment (see nosemgrep comments.
Fixed	Fixed findings were detected in a previous scan, but are no longer detected in the most recent scan of that same branch. To change the state of a finding to fixed: Fix the code so the rule does not match it. Edit the Semgrep rule so it no longer matches the code.

Findings triaged across refs

Findings triaged (ignored, reopened) in a specific branch, PR, or MR are also triaged in all other branches, PRs, and MRs of a specific repository. In addition, if you filter for any other Git references (refs) on the Findings page, and then triage a finding, it is also automatically triaged in all other branches, PRs, MRs, and refs.

Findings can also be removed. A removed finding does not count towards the fix rate or the number of findings. The removed finding also does not appear in the Semgrep Cloud Platform. A finding is removed if it is not found in the most recent scan of the branch where it was detected due to any of the following conditions:

• The rule isn't enabled on the repository anymore.
• The file path where the finding appeared is no longer found (it was deleted, renamed, added to a .semgrepignore, added to a .gitignore or added to the list of ignored paths in Semgrep Cloud Platform).
• For GitHub organization accounts: the PR or MR where the finding was detected has been closed without merging.

Managing finding status

To manage, change, open, or ignore findings, follow the triage processes described below.
Figure 5 Findings page triage menu.

Ignoring findings

Ignoring findings in the Group by Rule view

To ignore findings in the Group by Rule view, follow these steps:

1. On the Findings page, click the Status filter, and then select Open status to see all open findings.
2. Perform one of these steps:
   • To select more findings from the same rule, click the Triage button on the card of the finding.
   • To select individual findings reported by a rule, fill in the checkboxes of the finding, and then click the Triage button on the card of the finding.
3. Optional: Write a reason to describe why the finding was ignored.
4. Click Ignore.

Ignoring findings in the No grouping view

To ignore multiple findings in the No grouping view, follow these steps:

1. On the Findings page, click the Status filter, and then select Open status to see all open findings.
2. Perform one of these steps:
   • Select all findings by clicking on the header row checkbox that states Showing X open findings. You can navigate to succeeding pages and add other results to the current selection.
   • Select more findings by clicking on their checkboxes.
3. Click the Triage button.
4. Optional: Select a reason of why you are ignoring a finding. Choose either: False positive, Acceptable risk, No time to fix
5. Select Ignored from the dropdown menu.
6. Click Save.

Ignoring individual findings in the No grouping view

To ignore individual finding in the No grouping view, follow these steps:

1. On the Semgrep Code Findings page, click the Status filter, and then select the Open status to see all open findings.
2. Next to a finding you want to ignore, click Open.
3. Optional: Select Ignore reason. Choose either: False positive, Acceptable risk, No time to fix.
4. Click Done.

Reopening findings

Reopening findings in the Group by Rule view

To reopen findings in the Group by Rule view, follow these steps:

1. On the Findings page, click the Status filter, and then select the Ignored or Fixed status to see all ignored or fixed findings.
2. Perform one of these steps:
   • To select more findings from the same rule, click the Triage button on the card of the finding.
   • To select individual findingss reported by a rule, fill in the checkboxes of the finding, and then click the Triage button on the card of the finding.
3. Optional: Write a reason to describe why the finding was ignored.
4. Click Reopen.

Reopening multiple findings in the No grouping view

To reopen findings in the No grouping view, follow these steps:

1. On the Findings page, click the Status filter, and then select the Ignored or Fixed status to see all ignored or fixed findings.
2. Perform one of these steps:
   • Select all findings by clicking on the header row checkbox that states Showing X open findings. You can navigate to succeeding pages and add other results to the current selection.
   • Select relevant findings one by one by clicking on their checkboxes.
3. Click the Triage button.
4. In the Triage state dropdown menu, select Reopened.
5. Click Save.

Reopening individual findings in the No grouping view

To reopen individual findings in the No grouping view, follow these steps:

1. On the Findings page, click the Status filter, and then select Ignored or Fixed status to see all ignored or fixed findings.
2. Next to a finding you want to ignore, click the Reopen .
3. Optional: Add a note.
4. Click Save.

Fixing a finding

To fix a finding:

1. Update, or refactor the code such that the Semgrep rule pattern no longer matches the code.

Removing rulesets

To disable a ruleset from the Policies page:

1. In Semgrep Cloud Platform, click Rules > Policies.
2. From the Ruleset drop-down box, click the ruleset to remove.
3. Click the Matching rules.
4. Click Change modes > Disabled.

info

• When you disable a rule, all previous findings generated by that rule are still retained.

You can also disable a rule through the Findings page in both Group by rule and No grouping views.

Follow these steps to remove a rule in the Group by rule view:

1. Go to the Semgrep Cloud Platform Findings page.
2. Next to a finding with status Open, click Details.
3. Click Open > Disable rule....
4. Click the Disable from policy checkbox.
5. Click Ignore.

To remove a rule in the No grouping view, perform the following steps:

1. Go to the Semgrep Cloud Platform Findings page.
2. Next to a finding with status Open, click Open > Disable rule... > Disable from policy.
3. Click Ignore.

Viewing details and adding notes to findings

To view and add notes to the activity history of a finding:

1. Log in to Semgrep Cloud Platform, and then click Code in the left panel to view your findings.
2. Select a finding where you want to view details or add notes, and then do one of the following actions:
   • If the default Group by Rule is enabled, click View details icon on the card of the finding.
     
   • If No grouping view is enabled, click the header hyperlink on the card of the finding. In the example on the screenshot below, it is the tainted-sql-string.
     You can also view the finding details directly from the findings page by clicking on the comment bubble icon if it appears on the finding card.
3. View, or add the notes in the Activity section. To add a new note, click plus New note.
   Figure 6. Finding details page.

Viewing the path of tainted data

Semgrep Code can provide you with a visualization of the path of untrusted (tainted) data in specific findings. Findings that display tainted data can help you to track the sources and sinks of the tainted data as they propagate through a body of a function or a method. For general information about taint analysis, see Taint tracking documentation.

With Semgrep Pro Engine, Semgrep Code can display findings that show the propagation of tainted data across multiple files. To get such findings, follow the required steps in Enabling Semgrep Pro Engine documentation.

This feature is also called dataflow traces, and an underlying CLI command is --dataflow-traces.

You can view dataflow traces in:

• The Findings page of Semgrep Code. For more details, see Path of tainted data in Semgrep Code.
• The PR or MR comments created by Semgrep Code running in your CI. To enable this feature, see the following documentation:
  • To see dataflow traces in GitHub PR comments, see Dataflow traces in PR comments section.
  • To see dataflow traces in GitLab MR comments, see Dataflow traces in MR comments section.

Path of tainted data in Semgrep Code

Prerequisite

Not all Semgrep rules or rulesets make use of taint tracking. Ensure that you have a ruleset, such as the default ruleset added in your Policies page. If this ruleset is not added, go to https://semgrep.dev/p/default, and then click Add to Policy. You can add rules that use taint tracking from Semgrep Registry.

To view a detailed path of tainted data with dataflow traces, follow these steps:

1. Log in to Semgrep Cloud Platform, and then click the Code in the left panel to view your findings.
2. Select a finding where Semgrep Code detected tainted data, and then do one of the following actions:
   • If the default Group by Rule is enabled, click View details icon on the card of the finding.
     
   • If No grouping view is enabled, click the header hyperlink on the card of the finding. In the example on the screenshot below, it is the tainted-sql-string.
     
3. In the Data flow section you can see the source, traces, and sink of the tainted data. The example below displays the path of tainted data across multiple files as Semgrep Pro Engine was enabled.
   

Get cross-file findings

• Get cross-file (interfile) findings in your organization. Follow the steps in Enabling Semgrep Pro Engine documentation. See Semgrep Pro Engine overview for general information about Semgrep Pro Engine.

Ignoring findings through comments

Triage your Semgrep Cloud Platform findings displayed as comments in GitHub PRs by replying with another comment.

Prerequisites

• A private GitHub.com repository. This feature is not enabled for public GitHub.com repositories or GitHub Enterprise public and private repositories.
• GitHub Semgrep Cloud Platform installed in the repository that is also added as a project in Semgrep Cloud Platform. For more information, see Getting started with Semgrep in continuous integration (CI).

To enable triage through comments, follow these steps:

1. In Semgrep Cloud Platform, go to your organization's Settings page.
2. Enable the Triage via comment toggle.

To triage a finding in GitHub, follow these steps:

1. Find an open comment created by Semgrep Cloud Platform in GitHub PR:
   Figure 7. Screenshot of Semgrep Cloud Platform comment in GitHub.
2. In the comment, reply with:

   /semgrep ignore <reason>

3. Substitute the colored placeholder <reason> with any text that can help to understand why the status of a comment is ignored.

info

Ignoring a finding through a comment in GitHub changes the status of the finding to ignored in the Semgrep Cloud Platform. See Findings page documentation for more details. The GitHub conversation itself is not automatically resolved by this process.

tip

You can also reopen a finding that was previously ignored. To do so, in step 2. of the preceding procedure, use /semgrep open. For /semgrep open the reason field is optional.

Deduplicating findings

Semgrep Cloud Platform scans are performed on both mainline (trunk) and non-mainline branches. The scope of the scan can differ depending on if Semgrep Cloud Platform is called on a mainline or non-mainline branch.

Full scan

Scans the repository in its entirety. It is recommended to perform full scans on mainline branches, such as `master` or `main`. This scan is performed on a scheduled basis.

Diff-aware scan

Diff-aware scans are performed on non-mainline branches, such as in pull requests and merge requests. Diff scans traverse the repository's files based on the commit where the branch diverged from the mainline branch (or diverged from the last commit that was fully scanned?)

Deduplicating findings in Semgrep Cloud Platform

Regardless of the scope of a scan, SCP correlates findings across branches based on their unique fingerprint, automatically deduplicating findings and making it simpler to triage.

If a finding is fixed in one branch (such as main) but open in another (such as production), and the code fixes are present in both branches, initiate a scan through your CI job or SCM tool on the branch(es) with open findings to have Semgrep mark the findings as fixed.

Deduplicating findings in Semgrep API

Semgrep API does not automatically deduplicate findings. If you are using Semgrep API to receive or pull findings data, set the dedup flag to true to deduplicate findings across refs or branches. Refer to List all findings in the Semgrep API docs for more information.

See also

• Alerts and notifications
• Policies
• Ignoring files, folders, or code

Additional references

• Writing Semgrep rules: a methodology

---

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