• Semgrep Secrets
• Semgrep AppSec Platform

Manage Semgrep Secrets rules using the policies page

To access the policies page for Semgrep Secrets, sign in to Semgrep AppSec Platform and navigate to Rules & policies > Policies > Secrets.

Validation state policies

Validation state policies allow you to define the rules Semgrep Secrets uses to scan your code, how to handle invalid findings, including those that have been revoked or were never functional, and how to handle validation errors when attempting to determine if a secret is a legitimate credential that can be used to access a resource.

Global rule behavior

The Global rule behavior tab allows you to view and manage the rules Semgrep Secrets uses for scanning. This page consists of the following elements:

• The Filters pane displays the filters you can use to select and perform operations on rules in bulk. See Filters for more information.
• The Rules pane displays the rules that Semgrep scans use to detect leaked secrets and allows you to edit their assigned rule modes. You can make these edits on individual rules or through the bulk editing of many rules. You can also use the Search for rule names or ids box. See Rules list for more information.

Filters

The Filters pane displays the filters you can use to select and perform operations on rules in bulk.

Available filters

Filter	Description
Modes	Filter by the workflow action Semgrep performs when a rule detects a finding. An additional filter, Disabled, is provided for rules you have turned off and are no longer included for scanning.
Validation	Filter by whether the rule includes a validator or not.
Type	Filter by the type of secret the rule addresses. Examples: AWS, Adobe, DigitalOcean, GitHub, GitLab.
Severities	Filter by the severity level of the secret: Low: low privilege; for example, write-only access like a webhook Medium: may have read and write access depending on what scope the account has High and Critical: has access to critical resources or full account access
Confidence	The confidence of the rule to detect true positives.
Source	Filter by Pro rules (authored by Semgrep) or by custom rules (rules created by your organization).
Analysis method	Filter based on whether Semgrep used Semantic or Generic analysis.
Ruleset	The name of the ruleset the rule belongs to.
Language	The project language for which the Secret can be used.

Rules list

The following columns appear on the rule entries list:

Rules list columns

Column	Description
Rule name	Name of the rule Semgrep Secret uses for scanning.
Labels	Metadata describing the rule, including the service for which the rule is applicable.
Open findings	The number of open findings the rule detected across all scans.
Fix rate	The percentage of findings that are fixed through changes to the code.
Severity	The higher the severity, the more critical the issues that a rule detects.
Confidence	Indicates confidence of the rule to detect true positives.
Source	Indicates the origin of a rule. Pro: Authored by Semgrep. Custom: Rules created within your Semgrep organization.
Ruleset	The name of the ruleset the rule belongs to.
Mode	Specifies what workflow action Semgrep performs when a rule detects a finding. An additional filter, Disabled, is provided for rules you have turned off and are no longer included for scanning. See Rule modes.

Rule modes

Semgrep Secrets provides three rule modes. These can be used to trigger workflow options whenever Semgrep Secrets identifies a finding based on the rule.

Rule mode	Description
Monitor	Rules in Monitor mode display findings only in: Semgrep AppSec Platform For Semgrep Code and Supply Chain: User-defined notifications Set rules to this mode to evaluate their true positive rate and other criteria you may have. By keeping rules in Monitor, developers do not receive potentially noisy findings in their PRs or MRs.
Comment	Rules in Comment mode display findings in: Developers' PRs or MRs Semgrep AppSec Platform For Semgrep Code and Supply Chain: User-defined notifications Set rules that have met your performance criteria to this mode when you are ready to display findings to developers.
Block	Rules in Block mode cause the scan job to fail with an exit code of 1 if Semgrep Secrets detects a finding from these rules. You can use this result to enforce a block on the PR or MR. For example, GitHub users can enable branch protection and set the PR to fail if the Semgrep step fails. These rules display findings in: Developers' PRs or MRs Semgrep AppSec Platform For Semgrep Code and Supply Chain: User-defined notifications These are typically high-confidence, high-severity rules.

Manage rules

Turn off rules

1. In Semgrep AppSec Platform, go to Rules & policies > Policies > Secrets.
2. Select either:
   • The top Number Matching Rules checkbox to select all rules.
   • Individual checkboxes next to rules.
3. Click Change modes(Number), then click Disabled.

You can also select individual rules under the Mode column and turn them off individually.

Add custom rules

To add custom rules, use the Semgrep Editor. See Semgrep Secrets rule structure and sample.

Invalid findings

You can define how Semgrep handles findings that it categorizes as invalid. Invalid findings include secrets that, during validation, were identified as revoked or were never functional.

When Semgrep identifies an invalid finding, you can choose to view the finding in Semgrep AppSec Platform, have Semgrep leave a comment in the pull request or merge request, or have the Semgrep scan fail with an exit code of 1.

See Rule modes for more information on the modes available.

Validation errors

You can define how Semgrep handles validation errors that occur when there are difficulties reaching the secrets provider or when Semgrep receives an unexpected response from the API.

When Semgrep encounters a validation error, you can choose to view the associated finding in Semgrep AppSec Platform, have Semgrep leave a comment in the pull request or merge request, or have the Semgrep scan fail with an exit code of 1.

See Rule modes for more information on the modes available.

Slack notification policies

If you are an admin for your Semgrep organization, you can view, create, edit, or delete Slack notification policies. These policies allow you to notify developers of Secrets findings on Slack while managing noise and ensuring that developers are only notified based on the conditions you set. You can 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 validation.
• Actions: Actions that are performed on the defined scope when conditions are met.

You can create as many policies as necessary.

Prerequisites

This feature requires either the:

• semgrep:latest Docker image
• Semgrep CLI version 1.101.0 and later

Create a policy

1. In Semgrep AppSec Platform, go to Rules & policies > Policies > Secrets.
2. Click Create policy.
3. Provide a Policy name.
4. Define the Scope of the policy:
   1. Click the drop-down box to select between All Projects, Project, or Project tag.
   2. If you select Project or Project tag, a second drop-down box appears. Choose the projects or project tags to finish defining the scope.
5. Define the conditions of the policy. See Policy conditions 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).
6. Define the actions of the policy, and select which channels should receive notifications when the policy is triggered. This list is populated by the channels you have subscribed to. To change this list, follow the steps listed in Receive Slack notifications.
7. Click Create.
8. Enable the policy by clicking the toggle to enable a policy. This applies the policy to future scans.

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, you must 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	Critical High Medium Low
Validation	Confirmed valid Confirmed invalid Validation error No validator
Repository Visibility	Public Private Unknown Note: Repository Visibility is only available for GitHub repositories.
Secret type	Manually provide a Secret type or choose from a list of values. The values listed are generated from findings identified by Semgrep Secrets.

View your policy

1. In Semgrep AppSec Platform, go to Rules & policies > Policies > Secrets.
2. Under Slack notification policies, click the name of your policy or the three-dot ellipsis () > Edit policy to see additional details.

You can also view a dialog showinga policy's scope, or the projects and tags affected by the policy, and a summary of its actions and conditions by clicking on the two summary links beside the policy name.

Edit a policy

1. Go to Rules & Policies > Policies > Secrets, and find the policy you want to edit.
2. Click the three-dot (...) button > Edit policy for the policy. This takes you to the policy definition page.
3. Make your changes.
4. Click Save.

Turn on or off a policy

1. Go to Rules & Policies > Policies > Secrets, and find the policy you want to turn on or off.
2. Turn off or on the Enable policy toggle.
3. Click Save.

Delete a policy

1. Go to Rules & Policies > Policies > Secrets, and find the policy you want to delete.
2. Click the three-dot (...) button > Delete policy.
3. Click Remove to confirm..

Note: deleting a policy does not remove existing notifications.

Block a pull request or merge request through rule modes

Semgrep enables you to set a workflow action based on the presence of a finding. Workflow actions include:

• Failing a CI job. Semgrep returns exit code 1, and you can use this result to set up additional checks to enforce a block on a pull request (PR) or merge request (MR).
• Leaving a PR or MR comment.
• Notifying select channels, such as private Slack channels or webhooks.

You can trigger these actions based on the rule mode set for the rule.

Troubleshooting: no pull request or merge request comments for Semgrep Secrets

If you're encountering issues getting PR comments for Semgrep Secrets:

• Make sure the rule is in Comment or Block mode
• Review the PR or MR comments guide for your SCM
• Explore other reasons you may not see PR or MR comments

---

Not finding what you need in this doc? Ask questions in our Community Slack group, or see Support for other ways to get help.