Export

The result of the CVE analysis can be exported to one or multiple export files.

For each component listed in the SBOM, the sbom-cve-check tool searches for applicable CVEs, which may or may not be vulnerable. Then the results of this analysis can be exported, which include the following items:

  • CVE information, including the description.

  • CVE assessment for each CVE associated with a SBOM component.

  • CVSS (Common Vulnerability Scoring System) information.

  • External references: URLs to external resources.

  • Obsolete assessments, if it is enabled.

To specify an export file, the following mandatory flags need to be used:

  • --export-type: As argument the export format. One of the formats listed in the table below.

  • --export-path: As argument, the path to the exported “file”. Depending on the export format, the path could point to a file, an archive or a directory.

These option flags can be specified multiple times in order to generate multiple export files.

Export formats

The following exporters are provided:

Name

Generate

csv

A CSV file: one line by CVE

spdx3

An SPDX v3.0 with CVE and associated assessments

summary

A plain text file listing the vulnerable CVEs

yocto-cve-check-manifest

A JSON file, with a format similar to cve-check

The export format can be specified by using the --export-type flag.

CSV format

This export, selected with csv type, generates a CSV file with a comma-separated field.

The generated file contains a header with the column names, followed by a line for each CVE identifier.

The CSV has the following columns:

  • build: The build script name (recipe name) used to build the package. There may be several recipe names if the packages share the same CPE and the same version. If there are multiple names, they are separated by a semicolon.

  • package names: The package names are separated by a semicolon. There may be several package names for split packages: the packages share the same CPE and the same version.

  • version: The package version

  • vendor-product: A part of the CPE, which includes, if available, the vendor and the product name, separated by a colon. If there are multiple CPE, they are separated by a semicolon.

  • cve-id: CVE identifier

  • scorev2: CVSS v2 score, if not available no value is specified (empty).

  • scorev3: CVSS v3 score. Same as CVSS v2 score.

  • scorev4: CVSS v4 score. Same as CVSS v2 score.

  • status: VEX assessment status, which can be either:

    • under_investigation: CVE is considered vulnerable

    • affected: CVE is vulnerable

    • not_affected: CVE does not affect the component, for example because the component compiled files do not include CVE affected files.

    • fixed: CVE was fixed, it is not vulnerable

  • statement: VEX assessment statement, filed if the status is affected or not_affected.

  • notes: Additional notes about the VEX assessment.

  • obsolete assessments: If an annotation is considered obsolete, a message indicating that will be added in this field.

SPDX3 format

This export, selected with spdx3 type, generates a SPDX v3.0.1 JSON-LD file. For now this is only supported if the input SBOM file is also a SPDX v3.0 file.

For each component, and for each applicable CVE, the following information will be added to the SPDX file:

  • CVE information with description

  • CVSS (Common Vulnerability Scoring System) metrics, which include the score, the vector and the severity.

  • External references

  • VEX assessment

Summary format

This export, selected with the summary type, generates a plain-text file listing all the vulnerabilities in each component, in a style similar to the console output from the Yocto Project’s cve-check class.

It is possible to generate this “summary” to the console (stdout) by passing as filename -. This can be done by adding these arguments:

--export-type summary --export-path -

Yocto Project cve-check format

This export, selected with yocto-cve-check-manifest type, generates a JSON file in a format very similar to the cve-check output generated via Yocto Project’s cve-check.bbclass.

There are various differences and limitations:

  • In each package object, an additional key is specified: cpes. This key provides an array of CPE.

  • The layer key is set to an empty string, since this information cannot be retrieved from the SBOM.

  • cvesInRecord is set to Yes for all products if there is at least one CVE associated with this package.

For more details on the cve-check export format, see the Yocto Project Developer Manual on vulnerabilities.

Export options

The following export options allow only certain information to be exported:

  • --export-filter-vex-status: Only export CVEs that match specified VEX status. Multiple statuses separated by a space can be specified.

  • --export-filter-vulnerable: Only export vulnerable CVE. This option is equivalent to specifying:

    --export-filter-vex-status under_investigation affected

  • --export-filter-without-cvss-score: If set, do not add CVEs without CVSS score.

  • --export-filter-min-cvss-score: Only export CVEs with a minimum CVSS score specified as argument. If only using this flag, and if a CVE does not have a CVSS score, the CVE will be exported. See the previous flag for that.

  • export-filter-without-vers-ranges: If set, do not export CVE which does not contain valid version information. Without vulnerable version ranges, this is not possible to know if the component is actually vulnerable.

  • --export-add-kernel-modules-annotations: By default, this tool does not add annotations for Linux kernel modules, mainly for reducing export file size. This option allows the export of all annotations, even for Linux kernel modules. Without this flag, the CVE information for the kernel image is still exported.

  • --export-list-rejected-vuln: By default, this tool does not export CVEs marked as rejected. This option allows to do that.

  • --export-process-native: Configures whether the vulnerability analysis is done on native components, target components, or on both. By default, only target components are analyzed. If no argument is provided, both native and target components are processed (equivalent to passing both as the argument). Accepted arguments:

    • native: Analyze only native components.

    • target: Analyze only target components.

    • both: Analyze both native and target components.

  • --export-spdx-pkg-include-vex: For SPDX 3 export, this flag links VEX information directly to the binary (install) package outputs. If omitted, VEX information is linked only to the common recipe that generates the binary packages, provided the SPDX 3 document includes such an object (specification package). Enabling this flag ensures VEX data is also linked to the generated binary packages. By default, this is disabled to prevent the SPDX output from becoming excessively large, as the same information can be inferred by tracing the “generates” relationship back to the recipe. Use this flag if your downstream tools cannot trace back to the recipe to locate VEX information.

Reproducible output

To generate a reproducible export file, the SOURCE_DATE_EPOCH environment variable must be set to the number of seconds elapsed since the Unix epoch, as described in reproducible-builds documentation.

For the export file to be fully reproducible, it is also necessary to set the various CVE and annotation databases to a fixed version.

It is possible to generate a configuration file that captures all the settings used during the current execution of the tool, which includes the database version. The generation of this configuration file is described in the configuration section.