Skip to content

Managing Policies

Creating and Managing policies includes 3 aspects:

Creating and managing a policy

Creating and managing a policy involves defining rules that match finding labels, severity, and/or confidence and assigning actions to be taken when they are triggered. To get started, navigate to the policy view by clicking the policy icon in the left-hand menu:

Policy View

Once in there, select the Policies section to load the current policies in the panel to the right.

Policy View

The policies view lists all the policies that exist in the account. The first time you access the policies view there will be only one policy named Default Policy which is a built-in Boostsecurity provided default policy that is always present in every account.

In the case where a code repository is scanned, but no explicit policy was created, the default policy is applied. The default policy provides a default policy rules ensuring any findings are reported on the dashboard's findings view.

In order to create a new policy, go ahead and select the New Policy button on the top right.

New Policy

The policy designer then opens:

Policy Designer

The policy designer includes 2 sections:

  • Policy Editor : Enables adding or editing policy rules, specifying labels, severity and confidence and their associated actions.
  • Scanners configuration : Enables configuring which scanners rules are enabled / disabled

The first step in creating a policy is to add policy rules using the Policy Editor. Once that's done, and if required, the scanners rules can be tuned using the Scanners configuration

Policy Editor

The policy editor guides you in designing your policy. When creating a new policy there are 3 parts that are mandatory:

  1. The policy name: the policy name has to be unique, ie there shouldn't be another policy that has the same name
  2. The description: the description will be displayed in the main policy view, with the list of policies.
  3. Policy rules: there needs to be at least one rule in the policy

The policy editor supports a default action to be set, i.e. the action that triggers if none of the rules in the policy match. The default action counts as the "at least one rule", therefore a policy could just be that, a default action. Note that the default action is mandatory.

At this point, set the default action:

Default Action

The default action, i.e. for any other types of findings can be any of the actions defined in Policy Actions.

Once the default action is selected and added to the policy, the selected action will trigger for any finding that does not have a more specific rule.

In order to add specific actions to be taken depending on the finding label, severity or confidence, policy rules can be added to the policy. A rule is a mapping of finding severity and confidence to an action, for a finding label. To learn about what finding labels are, refer to Learning about finding labels.

To add a rule, select the Add Rule button. A rules selector appears:

Rules Selector

A policy rule requires 3 parts: * The findings label to which the rule applies * One or more severity and confidence tuple along with the action * The default action for findings of the specified label

Multiple severity, confidence and action tuples can be included in a policy rule. Use the Add Action button to add a severity, confidence, action tuple in a policy rule.

Add Action

Likewise, multiple policy rules can be added to a policy, by selecting the Add Rule to add more rules.

Take the following policy as an example:

Policy Example

That policy would result into the following behaviour:

  • For all findings with label SQL Injection:
    • If the Severity is Critical, insert comments in PRs or commits and fail the check, regardless of the Confidence value
    • If the Severity is Warning, insert comments in PRs, but don't fail the check, regardless of the Confidence value
    • For all other Severity and Confidence values, notify security, but don't insert comments in PRs.
  • For all findings with label Command Injection:
    • If the Severity is Critical, insert comments in PRs or commits and fail the check, regardless of the Confidence value
    • For all other Severity and Confidence values, notify security, but don't insert comments in PRs.
  • For all findings with different label values than SQL Injection or Command Injection, drop the findings

Policy Actions

Several actions can be selected when implementing the policies. The actions and their behaviour are described below.

  • Fail Build and Notify:
    • Comments associated with new violations are inserted as PR comments, or text check for the default branch
    • The check associated with the Boostsecurity scanners are marked as failed
    • If the scan is for the default branch, send slack message (if configured)
  • Notify Developer and Security:
    • Comments associated with new violations are inserted as PR comments, or text check for the default branch
    • The check associated with the Boostsecurity scanners are marked as success
    • If the scan is for the default branch, send slack message (if configured)
  • Notify Security Only:
    • If the scan is for the default branch, send slack message (if configured)
  • Drop:
    • Discards the findings

Learning about finding labels

Each scanner's rule that can be triggered, have one or more labels associated with it which are selected from the list of labels curated by Boostsecurity. For example OWASP Top 10, SQL Injection and CWE Top 25.

A scanner raises a finding when a rule triggered. The finding includes all the labels that are associated with the rule. By creating policies with policy rules matching labels, the policies are always valid regardless of which scanner is used, given labels are not specific to a scanner, but rather valid across scanners.

Configuring the scanners rules

Scanners configured to run on your code repositories, generate findings based on the rules that triggered. When creating and defining a policy, it might be required to disable some rules that don't apply or generate false positives for your code repository. To disable scanner rules for a given policy, in the policy designer, select the Scanners tab.

Scanners Configuration

The scanner configuration has 3 levels:

  • The scanner name
  • The rule type
  • The rule

The rule type groups together rules of the same type. Rules can be disabled by unselecting them individually, for all rules in a rule type, or all rules in a scanner.

Assigning the policy to a resource

Once a policy has been created, it needs to be applied to a code repository to take effect. To configure policy for the code repositories, go to the Policy > Resources view. From the view, the list of resources to protect is listed, with the following hierarchy:

  • Account
  • Organizations
  • Repositories

Policy Assignment

Policies are inherited in the resources hierarchy. For example, if a policy is applied to an organization, all repositories in that organization that don't have a policy applied, inherit the policy applied to the organization. By default the Default Policy is applied to the Account, which means also that by default, Default Policy is inherited by all organizations and repositories.

To apply an existing policy to a resource, select the menu tripple dots on the resource to add policy to.

Assignment Menu

From the menu, select Apply. The existing policies are listed in the Select Policy menu, select the required policy, then select Apply. The policy is then applied to the resource.