Sonatype Lifecycle analysis supports the CycloneDX standard, the industry’s most advanced software bill of materials (SBOM) format.
An SBOM is a list of parts (packages and libraries) included in the application. Just as a manufacturing bill of materials includes all sub-assemblies, the SBOM also includes the direct and transitive dependencies along with any internal components made by your organization.
Analyzing an SBOM
Any Sonatype scanner and most of the integrations will analyze SBOMs found in the root context of the application scan target when using the naming format listed below in the Identification Source section.
Any application scan may be exported as an SBOM in the CycloneDX and SPDX formats. Learn about more SBOM use cases from our SBOM guide.
CycloneDX provides many native application scanners on its repository. Find a complete list at the CycloneDX Tool Center.
Identification Source
The CycloneDX format is used as an identification source in the Application Composition Report. The prefix of the file name is used as the source. Third Party is used as the identification source when no source is provided through the API or using the filename prefix.
bom.xml
-bom.xml
-bom.json
.cdx.<json|xml>
Sonatype scanners use the above naming formats to identify and analyze SBOMs within archives. Make sure your SBOM names follow this format when outputting them through third-party tools.
Component Identifiers, Package-URL, and SHA-1 Hash
For libraries declared in the SBOM, Lifecycle uses the following priority when identifying components. An example of each is included below. When a component is found more than once in the sbom, only the data of the first component will be processed/shown. Hashes included in the exported CycloneDX report will consist of a truncated (first 20 digits) SHA-1 rather than the full hash.
The CycloneDX 1.4+ format includes dependency graph information on the direct and transitive relationships between dependencies. The Lifecycle scanners include this information in the scan report and for the application dependency tree.
Components at the first level of listed dependencies in the SBOM are identified during an analysis. SBOMs with nested components will pass validation; however, nested components are not supported and are ignored during the analysis.
Innersource Components
CycloneDX can be used to identify Innersource producers as well as when they are consumed by other applications as dependencies. Similarly, this can be used to identify proprietary components. When processing the report, Lifecycle will use the identity information provided in the CycloneDX file when the component is unknown; greatly reducing the number of component unknown violations. This would include in the report any security and license data provided in the SBOM.
Sonatype properties in SBOMs
Software Bill of Materials generated by Sonatype includes Sonatype-specific metadata under the Sonatype namespace taxonomy.
Property
Description
sonatype:identification_sources
The source of the identity information for the component. This is either sonatype or some other source typically from the original bill of materials.
sonatype:match_state
Verify when the comparison of a component to known components is or is not a match in one of the following ways: exact, similar, or unknown
sonatype:match_filenames
The filename where the identified component is found
sonatype:truncated_sha1
An internal identifier used by Sonatype made from the first 20 chars of either the component's sha1 hash or a synthetic hash of the component's coordinates.
sonatype:original_purl
Preserves the original package URL (purl) from the ingested SBOM when exporting CycloneDX SBOMs from Sonatype products. Use this to maintain consistent component tracking across different tools in your software supply chain.
Application Reports
In conjunction with using CycloneDX to do the application analysis, you can also export any application report in Lifecycle to the CycloneDX format.
The CycloneDX 1.4+ format includes analysis information of the vulnerabilities. Sonatype imports the vulnerability analysis found in this section to include in the scan report.
The Sonatype Data Services team frequently evaluates vulnerabilities that enter our systems for accuracy and repeatability. They may determine a vulnerability is not applicable and therefore do not report the vulnerability against the component in our products. For these reasons, we favor reporting data coming from Sonatype Data Services over content reported from third-party sources to reduce the noise reported to development teams and used for enforcement.
The SBOM uses our vulnerability data for every known component in the Sonatype Data Services. Imported vulnerability data is not included.
For components not found in the Sonatype Data Services, the vulnerability and license details are sourced from the originally imported SBOM.
The CycloneDX maven plugin may be used to generate an SBOM to include when analyzing your application. Following is a sample request to make the BOM and set the name of the bom using the outputName.
This will generate cyclonedx-bom.xml and cyclonedx-bom.json which are compatible with the Lifecycle scanners.
The CycloneDX output may be included directly in the project pom.xml to be picked up by the Lifecycle Analysis automatically.
This example includes the CycloneDX generation in the pom.xml plugins. Note the outputName is used in the project.artifactId to generate the name of the BOM file.