Skip to main content
Upgrade to Unified Policies: Semgrep’s latest version of Policies unifies policies across finding types, allows you to assign different policies to different projects, and adds conditional logic. See Unified Policies for more information.
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 block them from merging a pull request or merge request (PR or MR) that introduces a security vulnerability, 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:
  • 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.
You can create as many policies as you need.

​
Prerequisites

This feature requires the semgrep: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.
1
Sign in to Semgrep AppSec Platform.
2
From the navigation bar, click Rules to expand the drop-down box, then click Policies.
3
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

1
From the Supply Chain policies tab, Click Create policy.
2
Provide a name.
3
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.
4
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…
5
Define the actions of the policy. You can choose to Leave a comment or Block and leave a comment.
6
Click Save. This brings you back to the Supply Chain policies tab.
7
After creating a policy, it is not automatically enabled. Click the toggle to enable a policy. This applies the policy to future scans.

​
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.
  • 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 . This provides a path to unblock the user, as Semgrep can leave a comment with the upgrade instructions.
  • Reachable findings without . 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 the benefits of showing them more findings. Conditionally reachable findings typically require further investigation, manual triage, and ticketing.
  • Critical and high severity findings. These findings could pose a significant risk, regardless of their reachability, and should be reviewed by a developer.

​
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:
1
Sign in to Semgrep AppSec Platform.
2
Go to Rules & Policies > Policies > Supply Chain.
3
Click Comment on reachable Supply Chain findings to turn off the SSC policy supporting comments.
Turning off PR/MR comments does not 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:

​
Other operations

​
Edit a policy

1
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.
2
Make your changes.
3
Click Save.

​
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:
1
From the Supply Chain policies tab, click the three-dot (…) button > Edit policy.
2
Turn off or on the Enable policy toggle.
3
Click Save.

​
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 reason for blocking a PR, deleting it and re-running a scan unblocks the PR or MR.