Skip to main content

View findings in Semgrep AppSec Platform

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

Semgrep AppSec Platform Findings page

To access the Findings page:

  1. Log in to Semgrep AppSec Platform.
  2. Click Code to navigate to the Findings page.

Findings page structure

The Findings page consists of:

  • The filter panel, which you can use to group and filter for specific findings
  • Information about findings identified by Semgrep Code. Each finding in the list includes:
    • The name and description of the rule used to generate the finding
    • The name of the project, as well as links to the Git branch and source code, where Semgrep Code identified the finding

Group findings

By default, Semgrep groups all of the findings by the rule Semgrep used to match the code. This view is called the Group by rule view.

Semgrep sorts findings by severity. 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

Findings grouped by rule

To view findings individually, toggle Group by Rule to No grouping using the drop-down menu in the header. Findings are displayed based on the date they were found, with the most recent finding listed at the top.

Group by Rule option

Filter findings

Use filters to narrow down your results. The following criteria are available for filtering:

FilterDescription
ProjectsFilter by repositories connected to Semgrep AppSec Platform.
BranchesFilter by findings in different Git branches.
TeamsFilter for findings in projects to which the specified teams are associated with. Available only to organizations with RBAC enabled.
TagsFilter for findings based on the tags associated with the project.
StatusFilter the triage state of a finding. Refer to Triage statuses to understand triage states.
SeverityFilter by the severity of a finding. Severity is computed based on the values assigned for Likelihood and Impact by the rule's author. Possible values:
  • Low
  • Medium
  • High
ConfidenceFilter by the likelihood of the rule to detect true positives. The higher the confidence, the more true positives the rule may detect.
Pro findingsFilter for findings identified using Semgrep Pro rules. Also includes findings originating from Pro Engine analysis; if Semgrep identifies a finding as the result of Pro Engine analysis, or interfile and interprocedural analysis, it's included by this filter.
CategoryFilter by the type of security issue or vulnerability the rule detects, such as security, correctness, and maintainability. You can select more than one category at a time. See Finding categories for information on how Semgrep categorizes your findings.
ComponentFilter by Semgrep Assistant component tags. Semgrep Assistant uses GPT-4 to categorize a finding based on its function, such as payments, user authentication, and infrastructure.
RecommendationFilter by recommendation offered by Semgrep Assistant's auto-triage feature. Possible values:
  • Fix
  • Ignore
ActionFilter by monitoring, commenting, or blocking rules in your Policies.
RuleFilter by rules included in your Policies page. You can select more than one rule or ruleset for filtering.
RulesetFilter by the ruleset name where rules that match the code belong. More than one rule or ruleset can be selected for filtering.

Finding categories

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:

tip

You can identify findings categorized under Security by their badge. Screenshot of security badge

Display findings reported in a specific time frame

By default, the Findings page displays your results from all time. To display findings reported during a specific time frame, click the All time button and select the preferred period. The following options are available:

  • All time
  • Last 1 year
  • Last 1 month
  • Last 7 days
  • Last 1 day

View findings details about a specific finding

To view in-depth information about a specific finding:

  1. Select the finding whose details you want to view details:
    • If the default Group by Rule is enabled, click the Details icon on the card of the finding. Click View details if Group by Rule is enabled
    • If the 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 detected-generic-api-key. Click View details if No grouping is enabled

Add notes to findings

To add notes to the activity history of a finding:

  1. 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 Details icon on the card of the finding. Click View details if Group by Rule is enabled
    • 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 detected-generic-api-key. Click View details if No grouping is enabled
  2. View, or add the notes in the Activity section. To add a new note, click plus New note. Semgrep AppSec Platform finding details page

Dataflow traces

With dataflow traces, Semgrep Code can provide you with a visualization of the path of tainted, or untrusted, data in specific findings. This path can help you track the sources and sinks of the tainted data as they propagate through the body of a function or a method. For general information about taint analysis, see Taint tracking.

When running Semgrep Code from the command line, you can pass in the flag --dataflow-traces to use this feature.

You can view dataflow traces in:

Get cross-file findings

To get cross-file (interfile) findings in your organization, follow the steps in Perform cross-file analysis.

View dataflow traces

Prerequisite

Not all Semgrep rules or rulesets make use of dataflow traces, or 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 the detailed path of tainted data with dataflow traces:

  1. Log in to Semgrep AppSec Platform, and click Code in the left panel to view your findings.
  2. Select the finding you're interested in, 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. Click View details if Group by Rule is enabled
    • 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. Click View details if No grouping is enabled
  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 because Semgrep Pro Engine was enabled. Data flow in Finding details page

Data retention

Semgrep, Inc. retains findings data as long as an account remains active. We securely destroy data within 90 days of contract termination for our Enterprise customers.

Additionally, account owners may request data destruction at any time by contacting  support@semgrep.com.

Further reading


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