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 the toolkit to integrate SBOM data ingestion with your CI/CD pipeline.
- Upload using the API.
- Upload from the Concert UI.
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
- Back-level - This type of risk indicates that the package version is outdated, presenting potential security risks that may be addressed with newer versions.
- Vulnerability - This type of risk 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 - This type of risk indicates that there may be an issue with the existence, compliance, restrictions, or comparability with the licenses associated with each package. Concert checks the name of the licenses that are identified for the package against the list of licenses in Concert's settings as approved for the enterprise deployment.
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.