Skip to main content

How to check community information

During the analysis process, the Spectra Assure platform identifies components and dependencies of your software packages, representing their relationships in the analysis reports. These components and dependencies are most commonly open source packages.

Working on a software project with many open source dependencies can make component identification, compliance, and overall software protection significantly challenging.

For this reason, rl-secure lets you configure minimum values for options such as number of downloads, popularity, and other information that is also available in ReversingLabs own risk assessment catalogue of open source software packages, developer tools, and dependencies - Spectra Assure Community. Any open source components and dependencies detected in your software package whose values are lower than the configured minimum will trigger specific Threat hunting policies.

Change community thresholds​

In this example, our project contains software components and dependencies that are new to the public package repository, some that have a low number of downloads, and some that have a low number of dependents. This means that before policy configuration change, rl-secure marks three community-related policies (TH30105, TH30106, and TH30107) as violated.

With the policy configuration update, we want to exclude specific software components and dependencies for which policies have been triggered, based on specific criteria. More precisely, the number of downloads, package popularity, and number of days since the package has been published.

This guide configures the values based on the information available at the bottom of the Overview report section of each package on the official Spectra Assure Community page.

The example in this guide 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. Modify project policy settings​

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

2) In the .repository_policy.info file, add or modify the community section to edit the minimum threshold values for open source components and dependencies.

Example community configuration
policies {

    profile "repository_profile" {

        inherit_rules "sdlc_default"

        community
        {
            package_downloads  100
            package_popularity 100
            publish_threshold  3         
        }
    }
}

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.

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 the community details on each component and dependency detected in the analyzed package.

Check the CLI output​

Use the find command to search for the violated policies by their ID in the project for which the configuration was modified. 

rl-secure find TH301* --purl=pkg:rl/my-project/armando-app

The output should be similar to the following example. It indicates the policy that was triggered and the details about the detected issue. Because of the configuration change, the Community-related policies that have previously been marked as "Violated" (TH30105 and TH30106) should not be shown in the output.

Example output
[ MATCHED ] my-project/my-package@1.0
[ TH30107 ] [ L5:PASS ] <P1> / [M] Severity [H] Effort / (x1)
            Detected presence of software components that are rarely included 
            by other public software packages.
Root Cause ---------------------------------------------------------------------
            ( COMPLEX ) Threat hunting policy was triggered by a heuristic signature
Violations ---------------------------------------------------------------------
     1) community_policies/0744c8936cc6617a4ef2d9c4b53d4ec9a144003d/unpacked_files/0

Check the SAFE report​

  • In the SAFE report, select Policies from the left sidebar.
  • Use the Filter by assessment category dropdown to find Tampering.
  • If the configuration change has been successfully applied, only the TH30107 policy will be marked as "Violated".