SCA workspace rule controls
There is one rule for each SCA agent workspace. Every project in a workspace inherits the workspace rules.
Each rule consists of one or more controls. A control checks if the project meets specific parameters.
Structure
Each control has the following structure:
- Properties
- Control Name
- Severity
- Level
- Conditions
- 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. Veracode SCA supports the use of vulnerability severities based off of either CVSS v2 or CVSS v3 scores.
- Vulnerable Method
- Override Control Severity with CVSS Score
- Severity
- Parameters for license descriptor
- Kind
- Check for specific licenses by name or select a risk rating.
- Including
- If you select License by name, select the licenses to include in the rule.
- Excluding
- If you select a risk rating, select the licenses to exclude from the rule.
- Kind
- Parameters for vulnerability descriptors
- Action
- Create Issue
Properties
The properties of a control 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 an issue when a control is violated, the severity of the failed control defines the severity of the issue. Severities appear on lists of issues to make them easier to rank.
- 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
Descriptor.
- 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
- Level: there are two levels
- Error: a level of
errormeans that a non-zero will be returned, which can be used to break a build. For example, include this property in a CI build script. 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
warningwill return an exit code of0, which can be used to allow the build to continue. - To determine the exit code for a scan, enter
echo $?in the CLI after the scan concludes. If0is returned, that means no controls of levelerrorwere violated. If a number greater than0is returned, that means a control of levelerrorwas violated, and the number reflects the highest-severity control that was violated, rounded to the nearest integer.
- Error: a level of
Conditions
A control condition is a rule to enforce, such as library should not contain high-risk vulnerabilities.
A condition contains the following parts:
Resource
The resource is the entity being inspected for certain conditions. SCA agents 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
The matcher is a comparison operator that defines how the resource is inspected. The 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.
- SCA Agent-based Scan can check that:
- A library should not contain vulnerabilities with certain parameters. This check uses the
should not containmatcher. - A library should not contain licenses with certain parameters. This check uses the
should not containmatcher. - A library should be the latest version. This check uses the
should bematcher.
- A library should not contain vulnerabilities with certain parameters. This check uses the
- 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, set the severity of the violated control to the CVSS score of that vulnerability instead of manually assigning a severity. See Properties of the control.
- Parameters for license descriptor
- Kind: check for specific licenses by name or check for licenses with a selected risk rating. You can exclude specific licenses by name from the risk rating parameter.
Actions
The action for a control defines what happens automatically when the condition evaluates to false.
If you select Create Issue, Veracode creates an issue when the condition is false and the control is violated at scan time.
Creating an issue from a rule does not automatically create issues in third-party applications. However, if you have an SCA agent integration to Jira or GitHub, you can manually create a Jira or GitHub issue from an SCA issue in the Veracode Platform.
Manage controls
When a rule is in edit mode, you can add new controls, remove controls, and move controls up and down in the Veracode Platform.
To add a new control, select the Add Control button below the last control row.
To remove a control, select 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.
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. You order the controls to visually group them in an order that is meaningful to you. However, if you create two nearly identical controls that only differ by a property, such as a different severity rating, the control furthest down the list takes precedence.