Skip to main content

SPDX SBOM generator for ESP-IDF projects

Project description

ESP-IDF SBOM Tool (esp-idf-sbom)

:warning: This is experimental implementation, which is subject to change without prior notice and no backward compatibility is guaranteed.

The esp-idf-sbom tool creates Software bill of materials (SBOM) files in the Software Package Data Exchange (SPDX) format for applications generated by the Espressif IoT Development Framework (ESP-IDF). It also allows to check generated SBOM files for know vulnerabilities against the National Vulnerability Database (NVD) based on the Common Platform Enumeration (CPE) provided in the SBOM.

SPDX SBOM layout

The SBOM file is created based on application sources, build artefacts, information provided by the ESP-IDF build system and SBOM manifest files. The resulting SBOM file contains SPDX packages for the final project application, used toolchain, components used during build and git submodules. Packages are linked together with SPDX DEPENDS_ON relationships with the project package as the root package. By default packages for configuration only components and components not linked into the application are present in SBOM, but are not linked through SPDX relationships. In other worlds dependencies on such packages are removed. This behaviour can be altered with --add-config-deps and --add-unused-deps command line options.

Manifest file

During SBOM generation the esp-idf-sbom tool is looking for sbom.yml manifest files. The manifest file may be present at root of project, component or submodule. It is used as a source of information for the corresponding SPDX package in the SBOM file as described above.

It's a simple yaml file, which may contain the following entries.

  • version: Package version.
  • description: Short package description.
  • repository: Link to git repository.
  • url: Link to package download location.
  • cpe: CPE used for vulnerabilities check against NVD.
  • supplier: Package supplier. Person or organization distributing the package. Should be prefixed with Person: or Organization: as described in SPDX specification.
  • originator: Package originator. If the package comes from another person or organization that has been identified as a supplier. For example if a component is based on 3rd party code with some modifications, the originator is the 3rd party code author, but the supplier is the person or organization distributing the final component. For more detailed information please see the SPDX specification. As for supplier, Person: or Organization: prefix should be used for originator value.

Example of the sbom.yml manifest file for the ESP-IDF blink example.

version: 0.1.0
description: Blink application example
url: https://blink.org/blink-0.1.0.tar.gz # non-existing package download URL example
cpe: cpe:2.3:a:hrbata:blink:{}:*:*:*:*:*:*:* # non-existing CPE example
supplier: 'Person: Frantisek Hrbata (frantisek.hrbata@espressif.com)'
originator: 'Organization: Espressif Systems (Shanghai) CO LTD'

Example of the sbom.yml manifest file for the blink's main component.

version: 0.1.0
description: Main component for blink application
repository: https://github.com/espressif/esp-idf.git@dc016f59877d13e6e7d4fc193aa5aa764547f16d#examples/get-started/blink
supplier: 'Organization: Espressif Systems (Shanghai) CO LTD'

Information from the sbom.yml file are mapped to the following SPDX tags.

manifest SPDX
version PackageVersion
description PackageSummary
repository ExternalRef OTHER repository
url PackageDownloadLocation
cpe ExternalRef cpe23Type
supplier PackageSupplier
originator PackageOriginator

Even though the sbom.yml file is the primary source of information, the esp-idf-sbom tool is also looking at other places if it's not present. The version, description and url information from the idf_component.yml manifest file is used for components managed by the component manager. Component version may be guessed based on git-describe and Espressif as a default supplier may be guessed based on git repository or package URL. The guessing may be dissabled by using the '--no-guess' option. For submodules, the .gitmodules file is also checked for additional submodule information.

Installation

Currently esp-idf-sbom is not integrated into ESP-IDF and needs to by installed separately from Python Package Index (PyPI) with

pip install esp-idf-sbom

After installation the esp-idf-sbom command should be available or the esp_idf_sbom python module can be used with

python -m esp_idf_sbom

Creating SBOM

The application has to be built before the SBOM file can be created. This step should not be required in the future once esp-idf-sbom is integrated into ESP-IDF.

The SBOM file can be created with

esp-idf-sbom create <project description file>

The project description file is a path to the project_description.json file, which is by default created by the ESP-IDF build system in the project's build directory. The generated SBOM file is printed to the standard output stream by default or can be saved in a file if the --output-file option is used.

Checking vulnerabilities

Vulnerabilities are checked based on the Common Platform Enumeration (CPE) information included in the SBOM file for SPDX packages. While checking for vulnerabilities, only packages with direct or indirect relationship to the project package are examined. For example if mbedtls component is compiled, due to component dependecies, but it's actually not linked into the final binary, it will be by default presented in the SBOM file, but it will not be reachable from the root project package and hence it will not be checked for vulnerabilities. The reason for this is to avoid possible false possitives, because such packages have no direct impact on the resulting application. This can be changed with the --all option. If used, all packages in the SBOM file will be checked for possible vulnerabilities regardless their relationships to the application binary.

SBOM file generated by the esp-idf-sbom tool can be checked for known vulnerabilities with

esp-idf-sbom check [SBOM file]

If SBOM file is not provided, the stardard input stream is used.

Usage example

This is an example of basic usage for the blink project, which is part of the ESP-IDF. The two sbom.yml files for project and main component showed above were added. It's expected that ESP-IDF is installed and set.

$ cd examples/get-started/blink/ # In esp-idf directory go to the blink example
$ idf.py build                   # Project has to be built first
$ esp-idf-sbom create -o blink.spdx build/project_description.json
$ esp-idf-sbom check blink.spdx
$ esp-idf-sbom create build/project_description.json | esp-idf-sbom check

The resulting blink.spdx sbom file can be found in the examples directory.

Project details


Download files

Download the file for your platform. If you're not sure which to choose, learn more about installing packages.

Source Distribution

esp-idf-sbom-0.2.0.tar.gz (25.7 kB view details)

Uploaded Source

Built Distribution

esp_idf_sbom-0.2.0-py3-none-any.whl (26.6 kB view details)

Uploaded Python 3

File details

Details for the file esp-idf-sbom-0.2.0.tar.gz.

File metadata

  • Download URL: esp-idf-sbom-0.2.0.tar.gz
  • Upload date:
  • Size: 25.7 kB
  • Tags: Source
  • Uploaded using Trusted Publishing? No
  • Uploaded via: twine/4.0.2 CPython/3.7.17

File hashes

Hashes for esp-idf-sbom-0.2.0.tar.gz
Algorithm Hash digest
SHA256 916a9b93a25e108e3e3640b7e22ad43a12f7a820eef4ab19a100c45303fb0fe0
MD5 59bded7f4850a0da854a21820ee9c83e
BLAKE2b-256 802ae16a3ccdb09d9ec5f3c3619d4d1320a611f505c14a320fa1f33d09700143

See more details on using hashes here.

File details

Details for the file esp_idf_sbom-0.2.0-py3-none-any.whl.

File metadata

  • Download URL: esp_idf_sbom-0.2.0-py3-none-any.whl
  • Upload date:
  • Size: 26.6 kB
  • Tags: Python 3
  • Uploaded using Trusted Publishing? No
  • Uploaded via: twine/4.0.2 CPython/3.7.17

File hashes

Hashes for esp_idf_sbom-0.2.0-py3-none-any.whl
Algorithm Hash digest
SHA256 b6d3b607d4b0bd37663113f724adff30e5a9eba1cbf4484b0e9692e9319021cd
MD5 6d8cfced0a5c86b4f2941749e0105583
BLAKE2b-256 be6aa1761c8dabac4be5dadc054a15137b6dccc7cf9e506dbe7d60137bf66504

See more details on using hashes here.

Supported by

AWS AWS Cloud computing and Security Sponsor Datadog Datadog Monitoring Fastly Fastly CDN Google Google Download Analytics Microsoft Microsoft PSF Sponsor Pingdom Pingdom Monitoring Sentry Sentry Error logging StatusPage StatusPage Status page