Skip to main content

Set rules through Policies

Increase the breadth and depth of your scan coverage or remove noise from scans through the Policies page. Block or allow merges for pull requests (PRs) or merge requests (MRs) based on the rule that detected the finding.

The Policies page displays a visual representation of the rules that Semgrep Code uses for scanning. By default, the same rules in Policies are applied to all repositories.

To learn more about rules, see Running rules.

Speed and language coverage

Semgrep Code identifies the languages used in your repositories and only runs rules applicable to those languages.

For example, adding Ruby and Python rules in your Policies does not affect the scan speed for Python-only repositories. Only Python rules are run for Python repositories.

Policies page structure

Default view of the Policies page Figure. Default view of the Policies page, known as the Group by vulnerability class view.

The Policies page consists of a header and three main panes:

Policies header
The top header consists of:
  • Policies view drop-down, which lets you choose between:
    • Grouping rules by vulnerability class
    • No grouping
  • Rule Modes button where you can view rule modes and edit notifications for each rule mode. Rule modes define what workflow actions Semgrep Code performs when a rule detects a finding. For example, setting a rule's mode to Comment means that Semgrep posts PR or MR comments from findings generated by that rule. See Blocking a PR or MR through rule modes for more information.
  • Add rules button that takes you to the Semgrep Registry where you can add rules to the Policies page and assign their initial modes.
Filter pane
Displays filters to quickly select and perform operations on rules in bulk. See Policies filter reference for more information.
Rule pane
The rule pane displays the rules that Semgrep scans use to detect findings and allows you to edit their assigned rule modes. You can make these edits either one by one or through bulk editing of many rules. You can also use the Search for rule names or ids box. See Policies filter reference for more information.

Blocking a PR or MR 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 PR or MR.
  • Leaving a PR or MR comment.
  • Notifying select channels, such as private Slack channels or webhooks.

Semgrep Code provides three rule modes:

Rule modeDescription
MonitorRules in Monitor mode display findings only in:
  • Semgrep AppSec Platform
  • 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.
CommentRules in Comment mode display findings in:
  • Developers' PRs or MRs
  • Semgrep AppSec Platform
  • User-defined notifications
Set rules that have met your performance criteria to this mode when you are ready to display findings to developers.
BlockRules in Block mode cause the scan job to fail with an exit code of 1 if Semgrep Code 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
  • User-defined notifications
These are typically high-confidence, high-severity rules.

Semgrep Code provides first-time users with the Default ruleset. These rules are initially placed in the Monitor column. As you develop confidence in these rules, you are able to change their modes to Comment or Block, ensuring that developers remain free of friction from false positives.

Adding rules

To add rules, follow these steps:

  1. On the Policies page, click Add Rules.
  2. You are redirected to the Semgrep Registry page. Explore the page, open cards of individual rules, and then click Add to Policy.
  3. Specify the workflow action of the rule that you are adding. Select either:
    • Monitor
    • Comment
    • Block

Adding custom rules to your Policies

To add custom rules, use the Semgrep Editor. See Setting code standards with the Policies page.

Disabling rules

To disable a rule, follow these steps:

  1. On the Policies page, select either:
    • The top Number Matching Rules checkbox to select all rules.
    • Select individual checkboxes next to a rule to disable rules one by one.
  2. Click (Number) Edit, and then click Disabled.

You can also select individual rules under the Mode column and disable them one by one.

Policies filter reference

This section defines the Policies page filters:

FilterDescriptionExamples or possible values
ModesFilter by the workflow action Semgrep performs when a rule detects a finding. An additional filter, Disabled, is provided for rules that you have turned off and are no longer included for scanning.See Rule modes documentation.
CategoryFilter by the type of security issue or vulnerability that the rule detects.
  • Dangerous method or function
  • SQL injection
  • Active debug code
SeveritiesThe higher the severity, the more critical the issues are that a rule detects.
  • High
  • Medium
  • Low
ConfidenceFilter by the confidence of the rule to detect true positives.
  • High
  • Medium
  • Low
SourceFilter by the origin of a rule.
  • Pro: Authored by Semgrep with cross-file (interfile) and cross-function (interprocedural) analysis capabilities, providing you with enhanced scan accuracy. For more information, see Pro rules.
  • Community: Authored by Semgrep, Inc or external contributors such as Trail of Bits.
  • Custom: Rules created within your Semgrep organization. For more information, see Private rules.
.
RulesetFilter by the name of an existing ruleset.
LanguageFilter by programming language
  • Python
  • JavaScipt
  • Ruby
Minimum count of findingsFilter by the number of findings.
  • 10
  • 100
  • 500
tip

Use Minimum count of findings to quickly catch rules generating a lot of findings. This may be an indication of false positives or noise.

Rule entry reference

This section defines the columns of the rule entries in the Policies page:

FilterDescriptionExamples or possible values
Rule nameName of the rule that Semgrep Code uses for scanning. docs-print-to-logger
LabelsMetadata describing the rule. This includes the rule's language, category (good security practices, coding standards), and more.
  • Security
  • Code injection
  • PHP
Open findingsThe number of open findings that the rule has detected across all scans.n/a
Fix rateThe percentage of findings that are fixed through changes to the code.n/a
SeverityThe higher the severity, the more critical the issues are that a rule detects.
  • High
  • Medium
  • Low
ConfidenceIndicates confidence of the rule to detect true positives.
  • High
  • Medium
  • Low
SourceIndicates the origin of a rule.
  • Pro: Authored by Semgrep with cross-file (interfile) and cross-function (interprocedural) analysis capabilities, providing you with enhanced scan accuracy. For more information, see Pro rules.
  • Community: Authored by Semgrep, Inc or external contributors such as Trail of Bits.
  • Custom: Rules created within your Semgrep organization. For more information, see Private rules.
.
RulesetRules are also organized in rulesets. Rulesets are groups of rules related through a programming language, OWASP category, or framework.
ModeSpecifies what workflow action Semgrep performs when a rule detects a finding. An additional filter, Disabled, is provided for rules that you have turned off and are no longer included for scanning.See Rule modes documentation.
tip

To change assigned modes, select either the top Matching Rules checkbox to select all rules, or select individual checkboxes next to a rule, and then click (Number) Edit or click individual rules in the Mode column.

Multiple policies

Multiple policies feature (private beta)

If you have the multiple policies feature, you can customize the rules that run on specific repositories. Currently, this beta is not accepting new participants.

The multiple policies feature enables users to customize the rules that run on specific repositories.

Users create different policies that repositories can subscribe to.

This feature makes use of a Global Policy that runs on all repositories. Repositories cannot unsubscribe from it.

You can create a policy, for example, "Custom Coding Standards Policy", with some additional rules, and add it to one or more repositories. During a scan, these repositories run all of the rules from the Global Policy as well as all the rules from your "Custom Coding Standards Policy".

Resolving workflow actions in multiple policies

If a rule is in multiple policies, then the rule is deduplicated and Semgrep prioritizes the workflow action based on the rule's mode where precedence is as follows:

  1. Block
  2. Comment
  3. Monitor

For example, if an instance of Rule A is set to Block, the scan fails for PRs with any findings from that rule, even if the same Rule A is set to Monitor in another policy applied to that repository.


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