Since `writer.py` is the one writting the SPDX file, it should normalize
the name field and not `walker.py` which generates the SBOM components.
Signed-off-by: Thomas Gagneret <thomas.gagneret@hexploy.com>
Improve the SPDX with the current values:
- URL: extracted from `git remote`. If more than one remote, URL is not
set.
- Version: extracted from `git rev-parse` (commit id).
- PURL and CPE for Zephyr: generated from URL and version.
For zephyr, the tag is extracted, if present, and replace the commit id for
the version field.
Since official modules does not have tags, tags are not yet extracted for
modules.
To track vulnerabilities from modules dependencies, a new SBOM,
`modules-deps.spdx` was created. It contains the `external-references`
provided by the modules. It allows to easily track vulnerabilities from
these external dependencies.
Signed-off-by: Thomas Gagneret <thomas.gagneret@hexploy.com>
Minor update to existing zspdx implementation to add support for
PrimaryPackagePurpose introduced in SPDX 2.3.
Signed-off-by: Benjamin Cabé <benjamin@zephyrproject.org>
The current zephyr.spdx does not contain the modules included in the build.
This commit split the zephyr-sources package into multiple packages, one
for each modules found by zephyr_module.py.
Signed-off-by: Thomas Gagneret <tgagneret@witekio.com>
The list of files which are included in the `build.spdx` SPDX SBOM document
is based on the files recorded as build artifacts based on the CMake
file-based API metadata response.
In some situations, such as the case indicated in #42072, a build artifact
may be reported by CMake but no such file is present on the system
following the build. This results in the `build.spdx` SPDX SBOM being
invalid, as a result of trying to provide metadata for a non-existent
file (and specifically being unable to provide its checksum).
This commit fixes this bug by omitting files from `build.spdx` if they
do not exist on disk after the build is complete, even if the CMake
metadata claims that they should. The resulting SPDX document should
then be valid.
Fixes#42072
Signed-off-by: Steve Winslow <steve@swinslow.net>
This adds support to generate SPDX 2.2 tag-value documents via the
new west spdx command. The CMake file-based APIs are leveraged to
create relationships from source files to the corresponding
generated build files. SPDX-License-Identifier comments in source
files are scanned and filled into the SPDX documents.
Before `west build` is run, a specific file must be created in the
build directory so that the CMake API reply will run. This can be
done by running:
west spdx --init -d BUILD_DIR
After `west build` is run, SPDX generation is then activated by
calling `west spdx`; currently this requires passing the build
directory as a parameter again:
west spdx -d BUILD_DIR
This will generate three SPDX documents in `BUILD_DIR/spdx/`:
1) `app.spdx`: This contains the bill-of-materials for the
application source files used for the build.
2) `zephyr.spdx`: This contains the bill-of-materials for the
specific Zephyr source code files that are used for the build.
3) `build.spdx`: This contains the bill-of-materials for the built
output files.
Each file in the bill-of-materials is scanned, so that its hashes
(SHA256 and SHA1) can be recorded, along with any detected licenses
if an `SPDX-License-Identifier` appears in the file.
SPDX Relationships are created to indicate dependencies between
CMake build targets; build targets that are linked together; and
source files that are compiled to generate the built library files.
`west spdx` can be called with optional parameters for further
configuration:
* `-n PREFIX`: specifies a prefix for the Document Namespaces that
will be included in the generated SPDX documents. See SPDX spec 2.2
section 2.5 at
https://spdx.github.io/spdx-spec/2-document-creation-information/.
If -n is omitted, a default namespace will be generated according
to the default format described in section 2.5 using a random UUID.
* `-s SPDX_DIR`: specifies an alternate directory where the SPDX
documents should be written. If not specified, they will be saved
in `BUILD_DIR/spdx/`.
* `--analyze-includes`: in addition to recording the compiled
source code files (e.g. `.c`, `.S`) in the bills-of-materials, if
this flag is specified, `west spdx` will attempt to determine the
specific header files that are included for each `.c` file. This
will take longer, as it performs a dry run using the C compiler
for each `.c` file (using the same arguments that were passed to it
for the actual build).
* `--include-sdk`: if `--analyze-includes` is used, then adding
`--include-sdk` will create a fourth SPDX document, `sdk.spdx`,
which will list any header files included from the SDK.
Signed-off-by: Steve Winslow <steve@swinslow.net>
