By default, Semgrep AppSec Platform collects Supply Chain findings without notifying developers, similar to the Monitor mode in Semgrep Code. This prevents developers from receiving notifications while you evaluate the tool. Once you are ready to notify developers through a comment, or potentially block them from merging a pull request or merge request (PR or MR), define a Supply Chain policy. This feature helps you manage noise and ensures that developers are only notified or potentially blocked based on the conditions you set. This feature enables you to configure the following:Documentation Index
Fetch the complete documentation index at: https://docs.semgrep.dev/llms.txt
Use this file to discover all available pages before exploring further.
- Scope: These are the projects (repositories) that are affected by the policy.
- Conditions: The conditions under which actions are performed. These conditions are typically attributes of a finding such as severity or reachability.
- Actions: Actions that are performed on the defined scope when conditions are met.
Prerequisites
This feature requires thesemgrep:latest Docker image or at least version 1.101.0 of the Semgrep CLI tool.
View your policies
Only admins can view, create, edit, or delete policies.Sign in to Semgrep AppSec Platform.
Click Supply Chain. This takes you to the Supply Chain policies tab. Your policies are arranged as cards.
- To view and edit an existing policy, click its name or the three-dot ellipsis () > Edit policy.
- View a popup of a policy’s scope (affected projects or tags) or a summary of its actions and conditions by clicking on the two summary links beside the policy name.
Create a policy
Define the scope of the policy:i. Click the drop-down box to select between All Projects, , or tag. Note that you can only select either a scope based on projects or tags, but not both.ii. For or tag values, a second drop-down box appears. Choose the projects or project tags to finish defining the scope.
Define the Conditions of the policy. See the Policy conditions section for more information. You can create more than one condition by clicking Add condition.
- For each condition, you can select multiple values by clicking on the plus sign () on the same row. The policy is applied when any of those values are met (
OR). - Each additional condition is additive. The policy is applied when all conditions are met (
AND). - You can define conditions that are exclusionary, such as When is not Transitive…
Common use cases for policies
Use the following recommendations to help you create policies. These guidelines help ensure your policies align with your business and organizational needs.Recommended conditions for blocking PRs or MRs
- Always block PRs or MRs that introduce dependencies or dependency versions identified as malicious. These represent known supply chain attacks and should never be allowed into your codebase.
- Always reachable and reachable findings with upgradeable dependencies. This provides a path to unblock the user, as Semgrep can leave a comment with the upgrade instructions.
Recommended conditions for leaving a comment
- Reachable findings without upgradeable dependencies. This makes the developer aware of the risk.
- Reachable, yet transitive findings. Depending on your organization’s policies, these may need to be flagged for risk.
- Conditionally reachable findings. The decision to show developers conditionally reachable findings may depend on weighing your compliance policies against showing developers more findings. Conditionally reachable findings typically require further investigation, manual triage, and ticketing.
- Critical and high . There is a chance of these findings being exploited regardless of reachability.
Turn off PR and MR comments
By default, Semgrep pull request (PR) and merge request (MR) comments include both Semgrep Code and Semgrep Supply Chain (SSC) findings information. However, if you would like to turn off PR or MR comments for reachable SSC findings, you can do so as follows:Sign in to Semgrep AppSec Platform.
Turning off PR/MR comments doesn’t turn off notifications regarding license policy violations.
Policy scopes
A policy’s scope can consist of tags or projects, but not both. If you need to create a policy with both tags and projects, simply make another policy. If a project or project tag that’s included in a policy scope gets deleted, it is removed from the policy scope. If all projects or all project tags are deleted for a given policy, you must edit the policy for it to be applied to a valid scope.Policy conditions
The following table lists available conditions and their values:| Condition | Values |
|---|---|
| |
| Severity |
|
| Upgrade availability |
|
| |
| |
| CVE | Manually provide a CVE ID, formatted as CVE-YYYY-NNNN+ or choose from a list of values. The values listed are generated from findings identified by Semgrep Supply Chain. |
Other operations
Edit a policy
From the Supply Chain policies tab, click the three-dot (…) button > Edit policy for the policy you want to edit. This takes you to the specific policy page.
Disable or enable a policy
From the Supply Chain policies tab, click the toggle for the policy you want to edit. You can also disable or enable a policy from the policy’s page:Delete a policy
From the Supply Chain policies tab, click the three dot (…) button > Delete policy, then click Remove. Note that:- This does not remove comments from existing PRs or MRs with findings.
- If a policy is the sole culprit for blocking a PR, deleting it and re-running a scan unblocks the PR or MR.