dist/tools: add SBOM creation
Contribution description
This contribution is an attempt to provide a start for the creation of SBOMs for RIOT based applications. While touching the topic, it quickly got clear that different output file formats and limited performance of existing tooling required a tailored solution. As we already have the requirement for a custom output format in our company, the current solution is designed as a plugin pipeline for dynamically loaded plugins.
This PR
- adapts a few package license declarations
- adds an info target to the makefile system for extracting information relevant for the SBOM generation
- adds a python package with command line interface for executing traced builds, aggregation of information for the files and packages in the build and generation of output
Testing procedure
Assuming that you have a recent version of poetry for python installed, you can set up the package with:
cd dist/tools/sbom
poetry install --no-root
poetry build
poetry install
$(poetry env activate)
If that succeeded, the package should be available. You can try it via
riot-sbom --list-plugins
To create an spdx (tag-value) SBOM file, try
riot-sbom --app-dir ../../../tests/net/nanocoap_cli \
--output-file-prefix /tmp/app_info.pkl \
--plugin-pipeline copyrights-scanner authors-scanner spdx-identifiers-scanner \
system-package-provider infer-file-data-from-package spdx-generator
Issues/PRs references
This PR does not aim to replace SPDX identifier adoption as moved forward by #21516
Murdock results
:heavy_check_mark: PASSED
8b1228eba2570428bdda12a825050c6c419c3376 makefiles/info.inc.mk: improve json output
| Success | Failures | Total | Runtime |
|---|---|---|---|
| 10560 | 0 | 10560 | 12m:00s |
Artifacts
Is this ready for review? It's still in draft stage.
I did not mean to signal that this PR is ready. I just wanted to have more people aware of the ongoing work here as the concern behind SBOM generation has become pretty high profile due to EU legislation.
Is this ready for review? It's still in draft stage.
I just decided to publish for review. There are still a few deficits in this PR but I think some general opinions would be great if some people have their current focus on this subject.
I wonder if this tool wouldn't be more at home in a separate repository tbh. We could create RIOT-OS/SBOM for it and then only have a small Makefile in dist/tools that fetches the tool from that repository.
I wonder if this tool wouldn't be more at home in a separate repository tbh. We could create
RIOT-OS/SBOMfor it and then only have a smallMakefileindist/toolsthat fetches the tool from that repository.
Would make sense for me as this is kind of orthogonal on the main project. My current PR is also for probing whether there is any interest in providing tooling for SBOM generation. If not, we can also just host the project at ML!PA github but I'd prefer it here.
The current design of the tool is tailored towards our needs within the company. A cut-down version might just be gathering the basic information from the build, e.g.
- RIOT packages with available information (license, copyright, download URL, version, supplier, originator, ...)
- external modules & board
- trace of files from the build
and put it into a serialization format suitable for follow-up processing into an SBOM, significantly reducing the complexity of this contribution. I am not sure however whether I can take the time for a full rewrite anytime soon.
@DanielLockau-MLPA @crasbe voilà https://github.com/RIOT-OS/riot-sbom
Closing. Will open a new PR to fix make info-build-json, required for the sbom utility to work.