• Semgrep Cloud Platform
• Community Tier
• Team & Enterprise Tier

Managing findings in Semgrep Cloud Platform

Finding page enables you to easily manage findings. Findings are the core results of Semgrep analysis. The 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 common categories such as the above. 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 semgrep shouldafound.
   • 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 Rule board 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 Semgrep Cloud Platform Findings page displays findings across all projects connected to Semgrep Cloud Platform. It is updated after every scan. Scans are initiated through your CI/CD pipeline, such as GitHub actions. The retention period of these findings varies based on your organization’s tier:

Retention period	Tier availability
30-day findings retention	Community (Free)
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, Rule Board 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 Rule Board.
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 Rule Board. 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.

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 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 the triage processes described below.
Figure 5 Findings page triage menu.

Ignoring findings

Ignoring multiple findings

To ignore multiple findings, 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

To ignore individual findings, follow these steps:

1. On the Semgrep Cloud Platform Findings page, click the Status filter, and then select Open status to see all open findings.
2. Next to a finding you want to ignore, click the Ignore .
3. Optional: Select a reason of why you are ignoring a finding. Choose either: False positive, Acceptable risk, No time to fix
4. Click Save.
5. Optional: Select whether you want to ignore all findings in Just this file, This directory, or Parent directory. This step is accessible only with permission to modify policies or repository settings.
6. Optional: Enable the checkbox to: Remove this rule from Rule board. This removes the related rule that matched the finding.
7. Click Done.

note

If you ignore all findings in Just this file, This directory, or Parent directory in the fifth step of the procedure above, these files or directories are added to .semgrepignore file. For more information, see Ignoring files, folders, or parts of code.

Reopening findings

Reopening multiple findings

To open findings, 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. 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

To open individual findings, 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 remove a ruleset from the Rule board:

1. In Semgrep Cloud Platform, click Rule board.
2. Click the ruleset that contains the rule.
3. Click the Remove ruleset icon next to the rule you're deleting.
4. Click Save.

info

• Individual rules within rulesets can only be disabled, not remvoed from the Rule board. To disable an individual rule in Rule board, click the toggle to disable the rule. See also Disabling rules.
• When you remove a rule from the Rule Board, all associated findings on Findings page and Dashboard page are removed also.

You can also remove a rule on the Findings page, to do so, follow these steps:

1. Go to the Semgrep Cloud Platform Findings page.
2. Next to a finding with status Open, click the Ignore .
3. Optional: Select a reason of why you are ignoring a finding. Choose either: False positive, Acceptable risk, No time to fix
4. Click Save.
5. Optional: Select whether you want to ignore all findings in Just this file, This directory, or Parent directory.
6. Enable the checkbox to: Remove this rule from Rule board. This removes the related rule that matched the finding.

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 Rule Board. If this ruleset is not added, go to https://semgrep.dev/p/default, and then click Add to Rule Board. 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 interfile findings

• Get 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 procedure above, 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. Semgrep Cloud Platform generates findings on a per-branch basis. Duplicate findings arise due to scans occurring on the same code in different branches.

There are two types of scans:

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?)

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.

See also

• Alerts and notifications
• Rule Board
• Ignoring files, folders, or code

Additional references

• Writing Semgrep rules: a methodology

---

Find what you needed in this doc? Join the Semgrep Community Slack group to ask the maintainers and the community if you need help.