View, triage, and remediate Supply Chain findings
At least one repository that scans for dependencies through Semgrep Supply Chain. See Scan third-party dependencies.
Once Semgrep Supply Chain successfully scans your repository, you can view, triage, and remediate the findings presented in Semgrep AppSec Platform using the Supply Chain page.
Figure. Semgrep Supply Chain Vulnerabilities page.
The Supply Chain page displays relevant scan data using four tabs:
- The Vulnerabilities tab enables you to:
- View reachable vulnerabilities in your repositories through links to specific lines of code.
- Filter vulnerabilities by severity, reachability, status, transitivity, and other attributes.
- Understand how to remediate vulnerabilities by providing versions to upgrade to.
- Track the process of resolving vulnerabilities by adding links to Jira issues and pull requests.
- The Advisories tab displays the latest Common Vulnerabilities and Exposures (CVEs) covered by Semgrep Supply Chain rules. Use this tab to see all the CVEs that Semgrep Supply Chain can detect and view the code pattern that the Advisory detects. The Advisories tab displays all rules, regardless of whether they support reachability analysis.
- The Dependencies tab displays information about your dependencies across all onboarded repositories.
- The License configuration tab allows you to explicitly allow or disallow (block) a package's use in your repository based on its license.
View the latest findings
To view the latest Semgrep Supply Chain findings, click Supply Chain. You can view findings individually or grouped by the rule that identified the finding. 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.
Figure. A single vulnerability entry in Semgrep Supply Chain.
You can also view the findings individually by clicking the drop-down box on the header and clicking No grouping.
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.
Export findings
You can export findings to a CSV file. Semgrep can export up to 10,000 most recent findings. For findings greater than 10,000, 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 time filters.
Figure. The download findings CSV button.
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. |
Filter your findings
Use filters to narrow down your results. The following criteria are available for filtering:
| Filter | Description |
|---|---|
| Projects and branches | The repositories connected to your Semgrep account and findings in different Git branches. |
| Tags | The tags associated with the project. |
| Status | The triage state of a finding. |
| 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 GitHub Advisory Database. |
| Transitivity | The transitivity of the finding. |
| EPSS probability | The finding's Exploit prediction scoring system (EPSS) probability. |
| Reachability | The finding's exposure, or whether it is reachable. |
| Component | Filter by Semgrep Assistant component tags. Semgrep Assistant uses AI to categorize the file where the finding was identified based on its function, such as payments, user authentication, and infrastructure. Available only for findings that are reachable. |
| Dependencies | The name of the dependency involved. |
| Rules | The rule that generated the finding. |
Status
The triage state of the finding:
- 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.
- Fixing: Findings for which you have decided to fix. Commonly used to indicate that these findings are tracked in Jira or assigned to developers for further work.
- 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.
- Fixed: 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.
You can set the Fixing and Reviewing statuses only if you are a Jira beta participant.
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.
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 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.
- 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: A finding is unreachable if you don't use the vulnerable piece of code of the imported library or package.
Triage and remediate findings
Once you have viewed the Supply Chain findings, you can triage them for further work by your AppSec team, including remediation. Semgrep Supply Chain provides the following methods to help you assess your findings:
| Assessment action | Method |
|---|---|
| View the dependency paths for a transitive dependency. | Visible on the vulnerability entry. |
| View specific pattern matches in your codebase. | Click the link provided in the vulnerability entry to see where the issue appears in the source code. |
| View specific CVE entries in cve.org. | Click the vulnerability's CVE badge. |
| View safe versions to upgrade your dependencies. | Visible on the vulnerability entry. |
| Filter vulnerabilities. | Click any of the filters available. Refer to the following table for filtering information. |
Remediate true positives
Remediate (or resolve) true positives in Semgrep Supply Chain through the following methods:
- Update the dependency to a safe version that does not contain the vulnerability.
- Remove the dependency and refactor all usages in the codebase.
Remove the dependency and refactor the code
Removing the dependency and refactoring the code is another method to remediate vulnerabilities. Upon merging any dependency removals, Semgrep Supply Chain scans the PR or MR, detects the changes in your lockfile, and updates the status to Fixed.
Ignore findings
The Vulnerabilities tab allows you to identify the reachable, true positives so that you can fix or resolve the related issues. However, you can ignore any false positives, acceptable risks, or deprioritized findings due to some factor. To do this:
- Select one or more findings.
- Click Triage.
- Select Ignore and click Continue.
- Select an Ignore reason, provide a optional comment, and click Ignore.
Not finding what you need in this doc? Ask questions in our Community Slack group, or see Support for other ways to get help.