Skip to main content

Override policies

In the context of rl-secure policy configuration, overrides refer to policy behavior changes that apply on a global level (to all analyzed files in the package store, project, or package version).

This means that overrides do not allow you to define selective criteria like filters do. Instead, overrides are more similar to an on-off toggle that controls whether the policy is used or not.

Filters and overrides​

In most cases, you will want to use filters rather than overrides because of their flexibility. The most common reason for modifying policy configuration is to create exceptions for issues you don't want to fix in your own code, or for issues in third-party components that you cannot fix. Such exceptions can only be created with filters. Because of that, filters are more suitable for making policy configuration changes on the lower levels of the package store hierarchy (projects and package versions).

On the other hand, overrides usually reflect higher-level decisions by AppSec leaders in your organization or team. The most common example is when a team does not want to use a policy at all in any of its projects. In that case, overrides are configured for the whole package store.

1. Modify package store policy settings​

In the following examples, our development team has decided to disable a policy for all projects in the package store.

When a policy is disabled, it does not have any impact on the analysis result. Issues that would be detected by a disabled policy do not get reported at all. However, Spectra Assure products may still indicate that the policy was disabled during analysis.

Examples in this section show how to modify the policy configuration for existing projects and packages in a previously created package store. If you haven't yet created any projects and packages, follow the instructions in the quick start guide.

1) In the rl-secure package store, navigate to the policy configuration file in the root directory and open it in a text editor. In this example, the full path to the file we're editing is /home/armando/my-repository/.repository_policy.info.

2) In the .repository_policy.info file, add or modify the overrides section to disable a specific policy by its ID.

  • To prevent the policy from being used to analyze files, set enabled to false.
  • The audit information about the author, date and time, and reason for the policy configuration change is mandatory in the overrides section.
  • You can add multiple policies to the overrides section as individual entries, or target a range of policies in just one entry with wildcard characters (e.g. SQ341*).
Example override
policies 
{
    profile "repository_profile" 
    {
        inherit_rules "sdlc_default"
  
        overrides
        {
            SQ34109
            {
                enabled   false

                author    "Spectra Assure"
                timestamp "2023-01-01T12:00:00+00:00"
                reason    "Relaxing the default scanning policy"
            }
        }        
    }
}

3) Save changes to the file and close it.

2. Apply and verify configuration changes​

1) To apply your policy configuration changes, run the following command in your package store:

rl-secure sync

The command automatically detects which packages in the package store require synchronization. Using the sync command does not count towards the monthly analysis capacity.

This action may take a long time if the entire package store needs to be synchronized.

2) To make sure the new policy configuration is reflected in analysis reports, you have to regenerate them for all applicable package versions:

rl-secure report all --purl=pkg:rl/my-project/my-package@1.0 --bundle=report.zip

3) To confirm that the policy configuration change has been successfully applied, check the rl-secure output or the SAFE report (rl-html) for details about modified policies.

Check the CLI output​

Use the list command to confirm that the number of disabled policies displayed in the SAFE assessment card correctly reflects the configured overrides.

rl-secure list --risks

The output should be similar to the following example. It indicates that 2 policies were disabled (not evaluated during analysis).

Example output
  / my-project .......................................... Packages: 2     
      / my-package ......................................... Versions: 1     
         @ [ CI:FAIL ] 1             <P0> [H] 8       [M] 3       [L] 15    
           [ Licenses        o No restricted license inclusions           ]
           [ Secrets         o No sensitive information found             ]
           [ Vulnerabilities x 1 actively exploited vulnerabilities       ]
           [ Hardening       x 1 critical code linking issues             ]
           [ Tampering       --- LICENSING: Entitlement restriction ---   ]
           [ Malware         x 2 malicious components found               ]
           ----------------------------------------------------------------
           ( 2 policies were not evaluated during analysis               )

If your policy override makes the current SAFE Levels settings more relaxed, the output will reflect that. The policy status information will show how the configuration change affected the SAFE Levels configuration (for example, 2 policies required for level 2 attainment were disabled).

Check the SAFE report​

  • In the SAFE report, select Policies from the left sidebar.
  • On the page that opens, use the Filter by Policy State dropdown to show only Disabled policies.
  • If the configuration change has been successfully applied, the policy you disabled should be displayed in the list. You can further filter the list of disabled policies by using the With Audit toggle. When the toggle is active, the page only shows disabled policies that have user-provided audit information.