Workflow: Assessing package risk and reliability

The Software composition dimension helps you understand the quality, reliability, and risk associated with your software packages and their associated licenses. After generating and uploading a package SBOM file in CycloneDX format, Concert assesses the risk and calculates a aggregate reliability score to help you prioritize action.

The following steps outline the workflow for analyzing package SBOM data through the Software composition dimension.

Step 1: Generate a package SBOM

Refer to Generating a package SBOM (CycloneDX) for instructions on generating a package SBOM in CycloneDX format. Alternatively, you can use the Concert toolkit to generate, validate, and upload package SBOM data.

Step 2: Upload the package SBOM file

Use one of the following methods to upload the package SBOM to Concert:

Step 3: Review the reliability score for each package

Concert retrieves a set of checks defined in the OpenSSF scorecard to each package contained in the package SBOM. These checks ensure the security and integrity of the software supply chain and provide a standardized way to assess the risk and compliance of package components. Concert uses these checks to generate a reliability score for each package, making it easy to identify areas in your software composition that require more immediate action than others. Refer to Understanding reliability score for details.

With this information, an engineering manager can filter the list to see packages with low or no aggregate reliability scores which can inform the open-source projects your developers use. Security analysts might look for projects that "should" have good scores, but have no score or a low score, which often indicates an "imposter project," as in one that uses a package name that is similar to a well-known package.

Step 4: Review package risks and recommendations

In addition to calculating a reliability score for each package, Concert identifies risks present in each package, including:
  • Installed version - displays the current version installed package has.
  • Published - shows the year in which current package version was published.
  • Latest version - displays the available latest version of package.
  • Vulnerabilities - indicates that the package contains one or more known vulnerabilities that have been patched in more recent versions, leaving system components subject to exploitation.
  • License - shows the licenses associated with a package. If a package has multiple licenses Concert displays a +1 and displays license names.

If you click on the package you want to inspect in detail, you get an Overview sub-navigation with additional details, recommendations for package and reliability checks when available. In Referenced in sub-navigation you can see all references of the package. And under Impact view, you can see visual representation of relationships a package has with SBOM's, applications, environments, and private access points.

Based on the type of risk identified in the package, Concert provides a recommended action to resolve the issue. Refer to Viewing package-related risk and recommendations

Step 5: Create tickets based on recommended actions

After establishing a connection with your organization's third-party ticketing system, you can create tickets from the Concert UI to address package-related issues based on the recommendations. Refer to Creating tickets to address risks in packages for details and instructions.