Custom Rules

SourceClear Software Composition Analysis

Custom Rules

Custom rules help you take greater control of your software delivery workflow.

Rules are sets of controls to which your codebase should adhere. SourceClear has always shipped with default rules, which were previously hidden, hard-coded, and applied to all workspaces for all organizations.

The SourceClear custom rules feature exposes the controls that are used by the rules engine. It allows Enterprise organizations to edit these controls per workspace and decide what actions to take when controls are violated, ensuring that no software ships unless it meets your security requirements.

When a control is violated, you can choose to create a SourceClear issue to track a problem, break the build, or both. Set your own severity for different kinds of control violations, which will be used as the severity for SourceClear issues and as the exit code when a build is broken.

Finally, this feature contains improvements for all organizations, including recognizing ignored issues in the agent, and more granular issue severities in lists of issues.

Structure of a Rule

There is one rule per workspace. Every project in a workspace inherits the workspace rules.

Each rule is composed of one or more controls. A control checks for specific rules.

A control is structured as follows:

  • Properties
    • Control Name
    • Severity
    • Level
  • Condition
    • Resource
    • Matcher
    • Descriptor
      • Parameters for vulnerability descriptors
        • Severity
          • Check for a vulnerability of high, medium, or low risk. The level of risk that a vulnerability has is determined by its CVSS score. SourceClear supports the use of vulnerability severities based off of either CVSS v2 or CVSS v3 scores.
        • Vulnerable Method
        • Override Control Severity with CVSS Score
      • Paramater for license descriptor
        • Kind
  • Action
    • Create Issue

Properties of a Control

A control’s properties are basic fields that identify a control and its severity.

  • Control Name: a string that helps you quickly identify the control
  • Severity: a number from 0.1 (lowest) to 10.0 (highest) that lets you determine how serious a control violation is considered in this rule. If you choose to create a SourceClear issue when a control is violated, the severity of the issue is defined by the severity of the failed control. Severities appear on lists of SourceClear issues to make them easier to rank.
    • Note: Severity is different from a vulnerability risk (CVSS) score. However, if you wish to use the CVSS score as the severity for vulnerability issues, you can set that option (see Descriptorbelow).
  • Level: there are two levels
    • Error: A level of error means that a non-zero will be returned, which can be used (for example, by CI build scripts) to break a build. The exact value of the exit code depends on the severity of all controls which were violated. See note below for more details.
    • Warning: A level of warning will return an exit code of “0” which can be used to allow the build to continue.
    • Note: To determine the exit code for a scan, enter echo $? in the CLI after the scan concludes. If “0” is returned, that means no controls of level error were violated. If a number greater than “0” is returned, that means a control of level error was violated, and the number reflects the highest-severity control that was violated, rounded to the nearest integer.

Conditions of a Control

A control’s condition is a rule that should be true, such as a
library should not contain high-risk
        vulnerabilities
or a library should not contain licenses of type GPL.

A condition is made up of three parts:

  • Resource: the entity which is being inspected for certain conditions. Currently, SourceClear can inspect libraries with four dependency relationships
    • Any: a library which is either referenced in your configuration file or used by a direct dependency. Encompasses all your libraries.
    • Direct: a library which is specifically referenced in your configuration file
    • Transitive: other libraries which are used by the direct dependencies
    • Both: a library which is both referenced in your configuration file and used by a direct dependency
  • Matcher: a comparison operator that defines how the resource will be inspected. The current values are should not contain and should be.
  • Descriptor: the descriptor and its parameters define the checks performed against the resource. The current descriptors available are vulnerability, license, and library.
    • SourceClear can check that
      • A library should not contain vulnerabilities with certain parameters (goes with matcher should not contain)
      • A library should not contain licenses with certain parameters (goes with matcher should not contain)
      • A library should be the latest version (goes with matcher should be)
    • Parameters for vulnerability descriptor
      • Severity: check for a vulnerability of high, medium, or low risk
      • Vulnerable Method: check for vulnerabilities where vulnerable methods were or were not found
      • Override Control Severity with CVSS Score: For vulnerability issues only, you can choose to set the severity of the violated control to the CVSS score of that vulnerability instead of manually assigning a severity. See Properties of a Control.
    • Parameters for license descriptor
      • Kind: check for GPL licenses, multiple licenses, or no licenses.
        Note: If a single library has multiple licenses and one of those licenses is a GPL license, and your rule controls have Create Issue enabled for libraries with multiple licenses and for GPL licenses, then two issues are generated for the same library, one for each control. See Actions of a Control.

Actions of a Control

A control’s action defines what happens automatically when the condition evaluates to false.

  • Create Issue: When checked, a SourceClear issue will be created when the condition is false and the control is violated at scan time. Currently this is the only action available.
    Note: At this time, SourceClear issue creation from a rule will not automatically create issues in third party applications. However, if you have an integration to Jira or GitHub set up in SourceClear, you can manually create a Jira or GitHub issue from a SourceClear issue in the user interface
    .

Example 1

There should be no CVSS v2 high-risk vulnerabilities where vulnerable methods are found. If there are, assign a severity of 10, break the build, and create a SourceClear issue.

Example 2

There should be no CVSS v3 medium-risk vulnerabilities where vulnerable methods are not found. If there are, use the vulnerabilities’ CVSS score as the control severity, do not break the build, but do create a SourceClear issue.

Example 3

Suppose an organization is not interested in tracking low-risk vulnerabilities where no vulnerable methods were found. Simply delete any controls where Descriptor = vulnerability, Severity = low risk, and Vulnerable Method = no. Then at scan time, no SourceClear issues for this kind of vulnerability will be created.

An alternative way of accomplishing the same outcome is to deselect the Create Issue checkbox in a control where Descriptor = vulnerability, Severity = low risk, and Vulnerable Method = no. You might prefer this method if it is possible that you will want to create SourceClear issues for this control in the future, and don’t want to recreate it at that time.

Example 4

There should be no direct libraries with GPL licenses. If there are, set the severity to 9, break the build and create a SourceClear issue.

Example 5

All direct libraries should be up to date. If any are not, do not break the build, but do create a SourceClear issue with severity = 1.

What Is in the Default Rules

The controls in the default rules have not changed from previous releases. If you do not use custom rules for your workspace, there is almost no change in the issues created.

Using the default rules, issues are created when:

  • A vulnerability exists in either direct or transitive libraries
  • A direct library is out of date
  • A direct library has a GPL license

Additional controls that you can use with custom rules include:

  • A library has multiple licenses
  • A library has no license

The issue severities are set as follows:

  • Vulnerability issues, direct or transitive: the vulnerability’s CVSS score
  • Outdated library issues, direct: 3.0
  • Direct libraries with a GPL license: 9.0

When to Set Up or Modify a Custom Rule

If the SourceClear default rule above meets your needs, you do not need to modify it.

However, you may have your own tolerance to certain conditions. Perhaps you do not need an issue to be generated if a library is out of date or if a library has a low-risk vulnerability. In cases such as those, you should set up a custom rule for your workspace.

Who Can Set Up or Modify a Custom Rule

Users with the organization-level role of Organization Owner or Organization Administrator can set up or modify a custom rule in any workspace.

Workspace administrators can set up a rule in the specific workspaces they can administer.

How to View a Rule

Navigate to the workspace, open the Manage Workspace section, and click Rules.

View-only vs. Edit Mode

By default, a rule displays in view-only mode. The details of each control are initially collapsed.

Expanding and Collapsing a Control

To view the details of a control, click the right-pointing chevron.

Using the Default Rules

If you do not customize the workspace rules, SourceClear applies the default rule.s

Navigate to the workspace, open the Manage Workspace section, and click Rules. If Use default rules is selected in blue, there is no further action you need to take.

To use the default rules after setting up a custom rule, click on Use default rules. This selection makes the default rules active for any future scans in that workspace.

Setting up a Custom Rule

Navigate to the workspace, open the Manage Workspace section, and click Rules.

On the screen that displays, click Use custom rules.

You will be presented with a copy of the default rules.

Click Edit custom rules to enter edit mode.

Editing Custom Rules

Navigate to the workspace, open the Manage Workspace section, and click Rules. You will be presented with the current custom rules in effect.

Click Edit custom rules to enter edit mode. The controls change from view-only mode to edit mode. The details of each control are collapsed by default.

Make your adjustments and save. To learn how to fill out a control, please see Structure of a Rule and, Adding, Removing, and Rearranging Controls.

Once you save, the custom rules are active for any future scans in that workspace.

Resetting Custom Rules

You may want to update your custom rules by starting over from the default rules and making new customizations. To do so, click Edit custom rules to enter edit mode. Then click Reset to default rules.

This action discards any customizations, resets all controls to the default rules, and applies the changes immediately.

Adding, Removing, and Rearranging Controls

When a rule is in edit mode, you can add new controls, remove controls, and move controls up and down.

To add a new control, click the Add Control button below the last control row.



To remove a control, click the trash can icon at the far right.



To move controls up and down, use the up and down arrows next to the trash can icon.

In general, the order of controls in a rule does not affect which issues will be created, whether a build is broken or not, or the order in which controls are evaluated. It allows you to visually group controls together in an order that is meaningful to you. However, if you create two near-identical controls (e.g., high severity vulnerabilities with vulnerable methods) that only differ by a property (e.g., one control specifies “8” and another specifies “10”), the control furthest down the list takes precedence.

How Rules Work at Scan Time

At scan time, the scanner identifies open-source libraries in your code and any transitive library dependencies, generates a dependency graph and a call graph, and then sends the results of the scan to the SourceClear platform.

The SourceClear platform checks the scan results against each control in the rule. If a control fails, the specified action for that control is triggered, and the highest severity of the violated controls is returned as the exit code.

CLI Output

With the rules feature, the CLI returns a list of issues generated based on the rules: