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 use Semgrep AppSec Platform's Supply Chain page to view all of the findings generated by Semgrep Supply Chain after it scans your codebase. Additionally, you can use the Supply Chain > Dependencies tab to view information about your dependencies across all onboarded repositories.
At least one repository that scans for dependencies through Semgrep Supply Chain. See Scan third-party dependencies.
View findings
To view your findings in Semgrep AppSec Platform:
- Log in to Semgrep AppSec Platform.
- In the Navigation bar, click Supply Chain.
By default, Semgrep displays your Priority findings. Priority findings 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 findings shown on the Priority tab. To do so:
- Log in to Semgrep AppSec Platform.
- In the Navigation bar, click Code. Ensure that you're viewing the Priority.
- Using the provided filters, set your parameters for priority findings.
- Click Save.
- 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 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:
| Filter | Description |
|---|---|
| Severity | The severity of a finding. Filters are based on the severity of a vulnerability. Semgrep Supply Chain rules use severity values set by the source of the rule, such as GitHub Advisory Database. |
| Reachability | The finding's exposure, or whether it is reachable. |
| EPSS probability | The finding's Exploit prediction scoring system (EPSS) probability. |
| Upgrade guidance (beta) | The impact of a dependency upgrade on your project as determined by Assistant. |
| Dependencies | The name of the dependency involved. |
| Advisory | The vulnerabilities' ID number, such as CVE, GHSA, MAL, or keyword. |
| Malicious dependency | Whether the finding is for a malicious dependency |
| Project tags | The tags associated with the project. |
| Assistant file risk level | Filter by the risk level determined by Semgrep Assistant. |
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 instruction 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 doesn't 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 Assistant:
- Safe: There are unlikely to be breaking changes.
- Breaking: Introduces breaking changes; code modifications 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 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.
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. Possible values are Code, Supply Chain, or Secrets. |
| Severity | The finding's severity. Possible values are Critical, High, Medium, or Low. |
| Status | The finding's triage status. |
| Assistant component | A descriptor, such as API, Payments processing, Infrastructure, that Assistant 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 Code scans:
| Field | Description |
|---|---|
| Confidence | The finding's confidence. Possible values are High, Medium, or Low. Only Semgrep Supply Chain and Code findings provide this field. |
| Category | The finding's category, such as best practices, security, or correctness. |
| Is pro rule | Boolean value that returns TRUE if the rule that generated the finding is a pro rule. |
| Assistant triage result | Provides Semgrep Assistant's assessment. Possible values are True positive or False positive. These values appear only if Assistant is enabled. |
| Assistant triage reason | A short AI-generated reason why Assistant thinks the finding is a true or false positive. These values appear only if Assistant is enabled. |
The following fields are exclusive to Supply Chain scans:
| Field | Description |
|---|---|
| Dependency | The name of the dependency where the findings 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. |
The following fields are exclusive to Secrets scans:
| Field | Description |
|---|---|
| Secret type | Possible values include AI-detected, Generic secret, Connection URI, and so on. |
| Validation | States whether or not the secret was validated. |
| Project visibility | States whether the project (repository) is public or private. This feature supports GitHub-hosted repositories only. It returns an Unknown value for non-GitHub SCMs. |
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 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.
- 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
- Learn more about viewing a finding's details.
- Learn how to triage and remediate Semgrep Code findings.
- Learn how to manage your Supply Chain policies
- Learn how to ignore manifest files, lockfiles, and dependencies to minimize noise in your results.
Not finding what you need in this doc? Ask questions in our Community Slack group, or see Support for other ways to get help.