Picks up per-configuration serialNumber and documentNamespace, so two
configurations of one wolfBoot version no longer share an identifier
inside a scanner. Also brings CPE/PURL build-metadata stripping,
--dep-* value validation, wolfcrypt version inheritance, and the
sbom.am host-cc macro capture.
The Makefile comment that recorded this as an open wolfGlass gap is
no longer true, so it goes.
Signed-off-by: Sameeh Jubran <sameeh@wolfssl.com>
tools/sbom/.wolfglass-rev named 1bfcf4f1a293ba09f0ff6d67904dca09ee8eb6d7,
which exists in no repository. The vendored content is wolfGlass
d34a906638444b6990218a49927bcebafc5a539b: tools/wolfglass-sync --check
against that revision reports every file identical and only the pin
itself as drift.
A bare SHA with nothing checking it is also how a 1803-line vendored
generator drifts from the copy wolfSSL controls, or carries a local
patch, without anything noticing. Add a job that checks wolfGlass out at
the pinned revision and runs its own tools/wolfglass-sync --check, which
compares every vendored file against share/ and the pin against HEAD. An
unresolvable revision now fails that job rather than sitting in the tree.
A fork PR has no token to read wolfGlass with, so the job reports a
notice and passes there; the run on wolfSSL/wolfBoot is the gate.
Signed-off-by: Sameeh Jubran <sameeh@wolfssl.com>
Re-vendor wolfGlass tip where PRODUCT_CPE marks wolfboot registered
(NVD dictionary entries created 2026-08-10). Docs drop the "no CPE yet"
wording. The main package now carries cpe:2.3🅰️wolfssl:wolfboot:<ver>.
Signed-off-by: Sameeh Jubran <sameeh@wolfssl.com>
The bootloader is built WOLFCRYPT_ONLY: include/user_settings.h defines
it for every configuration except a wolfHSM server with certificate-chain
verification, so the image carries the crypto subset of wolfSSL and no
TLS. The SBOM said nothing about that, leaving an integrator to triage
TLS advisories against a bootloader that cannot run TLS. The re-vendored
generator reads the macro out of the captured configuration and records
the subset; the wolfssl component stays, because it is the identifier NVD
maps wolfSSL advisories to and the wolfcrypt one has no CVEs mapped to it
at all. wolfcrypt is now nested inside wolfssl rather than beside it,
which is where it ships from.
wolfBoot also stopped emitting a CPE. NVD has no wolfssl:wolfboot entry,
and an unlisted CPE is indistinguishable to a scanner from a listed one
with no advisories; the submitted identifier is recorded as
wolfssl:sbom:cpe-requested until the dictionary request is published.
The CMake route passed its -D set with no settings header, so it recorded
none of the configuration user_settings.h derives from that set -- a
different document than `make sbom` produced from the same tree, and one
that could not see WOLFCRYPT_ONLY. It now passes the same SETTINGS_H and
INCLUDE_DIRS the Makefile does.
Signed-off-by: Sameeh Jubran <sameeh@wolfssl.com>
Re-vendor the wolfGlass tip that gives every dependency component a CPE
alongside its PURL, and that emits pkg:github identifiers a consumer can
actually resolve. The wolfSSL entry in a wolfBoot SBOM previously carried
a PURL only, and that PURL pointed at a git tag which does not exist
(wolfSSL releases are tagged `-stable`), so an integrator monitoring NVD
could not match wolfSSL advisories against this firmware.
The CMake route also described a different product than the Make route:
it never declared the wolfSSL dependency, so its `components` array was
empty, and it recorded wolfBoot as a GPL-3.0-only library rather than a
GPL-3.0-or-later firmware image. Both routes now emit the same component
identity for the same configuration.
wolfCrypt stays inventoried as wolfBoot's own sources. It is not a
separate NVD product; its advisories are published against
wolfssl:wolfssl, so the wolfSSL identifiers cover that code.
Signed-off-by: Sameeh Jubran <sameeh@wolfssl.com>
Re-vendor wolfGlass a54cde1 and declare what the capture needs.
wolfBoot's wolfCrypt configuration is derived rather than literal:
include/user_settings.h turns WOLFBOOT_SIGN_ECC256 into HAVE_ECC,
HAVE_ECC256, ECC_TIMING_RESISTANT and the rest. Capturing CFLAGS alone
recorded the -D set and none of what it selects, so the SBOM described a
signing bootloader with no signature algorithm. Point SBOM_SETTINGS_H at
the wolfCrypt settings header, give it SBOM_INCLUDE_DIRS, and make
include/target.h a prerequisite since user_settings.h includes it and it
carries the flash layout.
For an stm32u5 ECC256 build the configuration record now holds 151
defines, including WOLFBOOT_SIGN_ECC256, HAVE_ECC, HAVE_ECC256,
WOLFBOOT_HASH_SHA256 and IMAGE_HEADER_SIZE=256, none of which appeared
before. BOOTLOADER_PARTITION_SIZE is 65536 rather than the literal `)`
that Make's double expansion had left in its place.
Declare wolfSSL as a dependency component by default, pinned to the
submodule's version. wolfCrypt is compiled into the image rather than
linked, so its sources are listed as wolfBoot's own; recording the
dependency as well is what lets a scanner match wolfSSL advisories
against this firmware.
Record the product as firmware rather than a library, in CycloneDX
component.type and SPDX primaryPackagePurpose alike. Override the
licence to GPL-3.0-or-later: LICENSE is the verbatim GPLv3 and says
nothing about how wolfBoot licenses under it, while all 252
GPL-headered sources say "either version 3 ... or (at your option) any
later version". The per-HAL SBOM inherits the override so the two
documents cannot contradict each other.
Signed-off-by: Sameeh Jubran <sameeh@wolfssl.com>
Sync tools/sbom to wolfGlass 9bdf5b7: document --cflags -D-only
behavior, add WOLFSSL_DIR/version.h --dep-version fallback with correct
$$$$ expansion, and teach validate_sbom.py --min-properties. CI Make
path checks now require a non-empty property set so empty captures
cannot pass.
Signed-off-by: Sameeh Jubran <sameeh@wolfssl.com>
Sameeh Jubran