Skip to main content
Semgrep Code generates a finding when a rule matches a piece of code in your codebase. You can use Semgrep AppSec Platform’s Code page to view all of the findings generated by Semgrep Code after it scans your codebase.

View findings

To view your findings in Semgrep AppSec Platform:
2
In the Navigation bar, click Code.
By default, Semgrep displays your Priority findings. Priority findings are defined as findings that:
  • Are categorized as Security findings. You can identify findings categorized under Security using the badge.
  • Are flagged with a severity level of critical or high
  • Are flagged with a confidence level of high
  • Are flagged by Semgrep Multimodal as likely being a true positive or has not been analyzed by Multimodal yet
You can switch to the All tab at any point to view all findings identified by Semgrep Code. Both the Priority findings view and the All findings view display high-level information about your findings.
LOCAL SCANSFindings 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.

Custom Priority tab

Semgrep admins can create a custom priority definition to change the findings shown on the Priority tab. To do so:
2
In the Navigation bar, click Code. Ensure that you’re viewing the Priority.
3
Using the provided filters, set your parameters for priority findings.
4
Click Save.
5
You’ll see a dialog window asking you to confirm that you want the changes saved for everyone. Click Save to proceed.
This change applies to the entire Semgrep organization. You cannot have separate priority definitions for individual users or teams.

Filter findings

Regardless of whether you use the Priority findings view or the All findings view, there are multiple grouping and filtering options available to you.

Time period

The time period filters allow you to see which vulnerabilities were opened, fixed, or triaged during a certain period of time. The time period filter is not additive; it is a filter operation that precedes other filters on the page. For example, if you select Last triaged and select the status Status Open filter, no findings appear because, by definition, there are no triaged findings that are also open. The following filters are available:
  • Triage state update action:
    • Opened in
    • Triaged in
    • Fixed in
  • Time period:
    • Last day
    • Last 7 days
    • Last 30 days
    • Last 3 months
    • Last 6 months
    • Last year
    • All time

Project

The filter allows you to search for findings associated with the selected projects.

Status

The Status filter allows you to search for findings in the selected statuses. See Triage status for additional information.

Additional filters

Semgrep offers additional filters that you can use to narrow down your results. The following filters are available:

Finding categories

A finding can be categorized in two ways:
  1. 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. 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:
      1. A flaw in the rule’s logic. See Reporting false negatives.
      2. A bug within Semgrep itself. See the list of Semgrep issues to file a bug report.

Group and sort findings

By default, Semgrep displays your findings using the Group by Rule view. This view shows your findings grouped by the rule Semgrep used to match the code. Your findings are shown sorted by severity, but you can opt to sort by number of findings for a given rule. For a given severity, Semgrep further sorts findings as follows:
  1. Findings generated by custom rules
  2. Findings generated by Pro rules
  3. Issue count in descending order
  4. Findings ID in ascending order
To view findings individually, click Group & sort > No grouping. Findings are displayed based on the date they were found, with the most recent finding listed at the top.

Export findings

You can export findings to a CSV file. Semgrep can export up to 10,000 most recent findings. To export more than 10,000 findings, you must use the API. Semgrep exports all findings to the CSV file regardless of the filters you apply on the page. Export findings by navigating to the product page and clicking the icon near the Group & Sort filters.
The following fields are exclusive to Code scans:The following fields are exclusive to Supply Chain scans:The following fields are exclusive to Secrets scans:

View details about a specific finding

To view in-depth information about a specific finding, select the finding whose details you want to view. Then:
  • If the default Group by Rule is enabled, click the Details icon on the card of the finding.
  • If the No grouping view is enabled, click the header hyperlink on the card of the finding.
The finding’s details page displays in-depth information about the finding. It also allows you to perform actions such as updating the finding’s status as needed, viewing links to any integrations available, such as associated Jira tickets, and communicating with your team regarding the finding. For example, you can add notes to the finding that anyone with access to the finding can see. See View findings’ details for more information.

How Semgrep displays findings on multiple branches

A single finding may appear in several branches. These appearances are called instances of a finding. Several instances of the same finding may differ in which line of code (LOC) they are on or in their triage state. For example, on production the finding may be on line 20, but the same finding was moved further to line 26 in feature-branch-a. Semgrep automatically recognizes that they are fundamentally the same finding and deduplicates these instances so that you do not get an inflated count of findings per ref that the finding is present in. By default, the Code page displays findings from the primary branches of all repositories (projects), arranged by most recent scan. You are viewing the primary branch’s instance of that finding, so you may see variations in LOC or triage state when comparing the finding across branches. When filtering by primary branch and triage status, the filters are applied based on the triage status of the finding on the primary branch. This means that on some feature branches, the instance may already be Fixed, but on the primary branch, the finding is still Open. The finding status on the primary branch is updated when the PR or MR is merged and Semgrep has scanned the code.
TIP
  • If you do not see any findings, or there are zero findings after a scan has concluded, check the Projects page to view the findings count, if any, and to set a primary branch, if it is not already set.
  • The total count of findings in the Projects page is based on the primary branch.

Next steps