View findings in Semgrep AppSec Platform

Semgrep Supply Chain generates a finding when a rule matches a piece of code in your codebase. You can view these findings in Semgrep AppSec Platform’s Supply Chain page.

​

View findings

To view your findings in Semgrep AppSec Platform: By default, Semgrep displays Priority findings, which are defined as findings that:

• Have a severity level of critical or high
• Are reachable

You can switch to the All tab at any point to view all findings identified by Semgrep Supply Chain. Both the Priority findings view and the All findings view display high-level information about your findings.

​

Custom Priority tab

Semgrep admins can create a custom priority definition to change the criteria for the findings shown on the Priority tab: This change applies to the entire Semgrep organization. You cannot have separate priority definitions for individual users or teams.

​

Filter findings

There are multiple grouping and filtering options available to you regardless of whether you use the Priority findings view or the All findings view.

​

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 both Last triaged and Status Open, 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 Project 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, which are the triage states of the findings:

• Open: Findings for which there have been no triage or remediation action.
• Reviewing: Findings that require more investigation to determine what the next steps should be.
• To fix: Findings that you have decided to fix. Commonly used to indicate that these findings are tracked in Jira or assigned to developers for further work.
• Provisionally ignored: Unreachable findings.
• Ignored: Vulnerabilities that have been triaged as Ignored by the user. You can filter findings with a status of Ignored further by reason: False positive, Acceptable risk, No time to fix, or No triage reason.
• Closed: Vulnerabilities that are no longer detected after a scan. This typically means that the dependency containing the vulnerability has been updated. Semgrep Supply Chain automatically checks if the dependency has been updated and sets the vulnerability’s status as Fixed.

​

Additional filters

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

​

EPSS probability

The Exploit prediction scoring system (EPSS) probability represents the likelihood that the vulnerability will be exploited in the wild in the next 30 days. Its values range from 0% to 100%. The higher the score, the greater the probability the vulnerability will be exploited. Semgrep groups probabilities as follows:

• High: 50 - 100%
• Medium: 10 - <50%
• Low: <10%

​

Reachability

The finding’s exposure to potential attacks, or whether it is reachable.

• Reachable: A finding is reachable if there’s a vulnerable function call or vulnerable package in use. The finding should be addressed as soon as possible.
  • Malicious dependency: A finding that indicates the use of a dangerous package, or dangerous version of a package, that are designed to compromise systems.
  • Reachable in code: A finding is reachable in code if there’s a code pattern in the codebase that matches the vulnerability definition.
  • Always reachable: A finding is always reachable if it’s something Semgrep recommends fixing, regardless of what’s in the code.
• Needs review: A finding that requires manual triage and review. Follow the instructions provided.
  • Conditionally reachable: A finding is conditionally reachable if Semgrep finds a way to reach it when scanning your code when certain conditions are met.
  • No Reachability Analysis: A finding that Semgrep does not scan for reachability.
• Unreachable: No vulnerable function call found. This finding can be deprioritized.

​

Transitivity

The transitivity of the finding:

• Direct: Your project depends directly on the dependency.
• Transitive: Your project’s dependency depends on a vulnerable dependency.
• Undetermined: Semgrep had no transitivity information for the dependency as it relates to your project.

​

Upgrade guidance (beta)

The impact of a dependency upgrade on your project as determined by Semgrep Multimodal:

• Safe: There are unlikely to be breaking changes introduced by the dependency upgrade.
• Breaking: The dependency upgrade likely introduces breaking changes, so code modifications are required.

​

Group and sort findings

You can view findings individually or grouped by the rule that identified the finding. 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. A specific finding in the code is called a usage. Vulnerability entries are sorted as cards by severity from critical to low, then from oldest to newest.

​

Export findings

You can export findings to a CSV file. Semgrep can export the 10,000 most recent findings when you request the report in Semgrep AppSec Platform: Semgrep filters do not apply to exports. The 10,000 most recent findings are exported to the CSV file regardless of the filters you apply on the Findings page. To export more than 10,000 findings, you must use the Semgrep API’s List code, supply chain, or AI-powered scan findings endpoint.

Click to view a description of fields included in the CSV.

Field	Description
Id	The unique ID number of the finding.
Rule name	The name of the rule.
Product	The Semgrep product.
Severity	The finding’s severity. Possible values are Critical, High, Medium, or Low.
Status	The finding’s triage status.
Confidence	Filter by the likelihood of the rule to detect true positives. The higher the confidence, the more true positives the rule may detect.
Multimodal component	A descriptor, such as API, Payments processing, Infrastructure, that Multimodal tags the finding with, based on the code’s context.
Repository name	The name of the repository where Semgrep found the finding.
Repository URL	The repository URL.
Line of code URL	The URL to the specific line of code where the finding match began. A finding may be several lines long.
Semgrep platform link	A link to the finding’s Details page in Semgrep AppSec Platform.
Created at	The time the finding was created in your timezone.
Last Opened at	The time the finding was last opened.
Branch	The name of the branch where the finding was detected.
Triaged at	The most recent time that the finding was triaged.
Triage comment	A triage comment created by the user.
Triage reason	The reason why the finding was triaged, created by the user.
Rule description	The description of the rule. This is the same as the rule’s message key.

The following fields are exclusive to Supply Chain scans:

Field	Description
Dependency	The name of the dependency where the finding was found.
Reachability	The reachability status of the finding, such as Reachable, No Reachability Analysis, or Unreachable.
Transitivity	States whether the finding originates from a direct or transitive dependency.
CVE	The CVE number that the finding is assigned to.
EPSS	The EPSS score, which estimates the likelihood that a software vulnerability can be exploited in the wild.

​

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.

​

How Semgrep displays findings present 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 Supply Chain 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.