| Message ID | 20241209120653.996455-2-richard@hughsie.com |
|---|---|
| State | Deferred |
| Headers | show |
| Series | Add a SBOM template in CycloneDX format | expand |
On 9 Dec 2024, at 12:05, Richard Hughes <hughsient@gmail.com> wrote: > > Improve supply chain security by including a SBOM file with substituted values. > > This will be used to construct a composite platform SBOM. > > Signed-off-by: Richard Hughes <richard@hughsie.com> > --- > docs/sbom.cdx.json | 43 +++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 43 insertions(+) > create mode 100644 docs/sbom.cdx.json > > diff --git a/docs/sbom.cdx.json b/docs/sbom.cdx.json > new file mode 100644 > index 0000000..d300807 > --- /dev/null > +++ b/docs/sbom.cdx.json > @@ -0,0 +1,43 @@ > +{ > + "bomFormat": "CycloneDX", > + "specVersion": "1.6", > + "version": 1, > + "metadata": { > + "authors": [ > + { > + "name": "@VCS_SBOM_AUTHORS@" What turns this template into the actual file? And surely this isn’t the right templating for a list here? A set of authors is not a singular author’s name. Jess > + } > + ] > + }, > + "components": [ > + { > + "type": "library", > + "bom-ref": "pkg:github/riscv-software-src/opensbi@@VCS_TAG@", > + "cpe": "cpe:2.3:a:riscv:opensbi:@VCS_TAG@:*:*:*:*:*:*:*", > + "name": "OpenSBI", > + "version": "@VCS_VERSION@", > + "description": "Open Source Supervisor Binary Interface for RISC-V", > + "authors": [ > + { > + "name": "@VCS_AUTHORS@" > + } > + ], > + "supplier": { > + "name": "RISC-V Foundation" > + }, > + "licenses": [ > + { > + "license": { > + "id": "BSD-2-Clause" > + } > + } > + ], > + "externalReferences": [ > + { > + "type": "vcs", > + "url": "https://github.com/riscv-software-src/opensbi" > + } > + ] > + } > + ] > +} > -- > 2.47.1 > > > -- > opensbi mailing list > opensbi@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/opensbi
On Monday, 9 December 2024 at 15:46, Jessica Clarke <jrtc27@jrtc27.com> wrote: > What turns this template into the actual file? And surely this isn’t > the right templating for a list here? A set of authors is not a > singular author’s name. Right, agreed. The way this works now is that we do a recursive clone of all the firmware components when building either EDK II or coreboot, and then we use a tool called uswid to "find" all the SBOM components and populate the tokenized values automatically. I've written a bit about it here: https://blogs.gnome.org/hughsie/2024/11/14/firmware-sboms-for-open-source-projects/ In the case of OpenSBI the finished component looks like this: { "type": "library", "cpe": "cpe:2.3:a:riscv:opensbi:1.5.1:*:*:*:*:*:*:*", "name": "OpenSBI", "version": "1.5.1", "description": "Open Source Supervisor Binary Interface for RISC-V", "bom-ref": "pkg:github/riscv-software-src/opensbi@1.5.1", "externalReferences": [ { "type": "vcs", "url": "https://github.com/riscv-software-src/opensbi" } ], "licenses": [ { "license": { "url": "https://spdx.org/licenses/BSD-2-Clause.html", "id": "BSD-2-Clause" } } ], "supplier": { "name": "RISC-V Foundation" }, "authors": [ { "name": "Anup Patel, Atish Patra, Bin Meng, Samuel Holland, Xiang W, Damien Le Moal, Heinrich Schuchardt, Yu Chien Peter Lin, Himanshu Chauhan, Inochi Amaoto, Alistair Francis, Andrew Jones, Clément Léger, Mayuresh Chitale, Nikita Shubin, Vivian Wang, Rahul Pathak, Ivan Orlov, Lad Prabhakar, Jessica Clarke, Xiang Wang, Abner Chang, Ben Zong-You Xie, Guo Ren, Liu Yibin, Nylon Chen, Bo Gan, Dong Du, Olof Johansson, Daniel Schaefer, Jan Remes, Nam Cao, Nick Kossifidis" } ] } Richard
On 9 Dec 2024, at 16:01, Richard Hughes <richard@hughsie.com> wrote: > > On Monday, 9 December 2024 at 15:46, Jessica Clarke <jrtc27@jrtc27.com> wrote: >> What turns this template into the actual file? And surely this isn’t >> the right templating for a list here? A set of authors is not a >> singular author’s name. > > Right, agreed. The way this works now is that we do a recursive clone of all the firmware components when building either EDK II or coreboot, and then we use a tool called uswid to "find" all the SBOM components and populate the tokenized values automatically. I've written a bit about it here: https://blogs.gnome.org/hughsie/2024/11/14/firmware-sboms-for-open-source-projects/ Should that not be part of the upstream build process for each project? > In the case of OpenSBI the finished component looks like this: > > { > "type": "library", > "cpe": "cpe:2.3:a:riscv:opensbi:1.5.1:*:*:*:*:*:*:*", > "name": "OpenSBI", > "version": "1.5.1", > "description": "Open Source Supervisor Binary Interface for RISC-V", > "bom-ref": "pkg:github/riscv-software-src/opensbi@1.5.1", > "externalReferences": [ > { > "type": "vcs", > "url": "https://github.com/riscv-software-src/opensbi" > } > ], > "licenses": [ > { > "license": { > "url": "https://spdx.org/licenses/BSD-2-Clause.html", > "id": "BSD-2-Clause" > } > } > ], > "supplier": { > "name": "RISC-V Foundation" > }, > "authors": [ > { > "name": "Anup Patel, Atish Patra, Bin Meng, Samuel Holland, Xiang W, Damien Le Moal, Heinrich Schuchardt, Yu Chien Peter Lin, Himanshu Chauhan, Inochi Amaoto, Alistair Francis, Andrew Jones, Clément Léger, Mayuresh Chitale, Nikita Shubin, Vivian Wang, Rahul Pathak, Ivan Orlov, Lad Prabhakar, Jessica Clarke, Xiang Wang, Abner Chang, Ben Zong-You Xie, Guo Ren, Liu Yibin, Nylon Chen, Bo Gan, Dong Du, Olof Johansson, Daniel Schaefer, Jan Remes, Nam Cao, Nick Kossifidis" > } > ] Should this not be: "authors:" [ { "name": "Anup Patel" }, { "name": "Atish Patra" }, ... ] ? Otherwise why is there the outer list? (But just having JSON that’s a comma-separated string wouldn’t exactly be great, so removing the outer list isn’t a real solution). Jess > } > > Richard >
On Monday, 9 December 2024 at 16:12, Jessica Clarke <jrtc27@jrtc27.com> wrote: >> then we use a tool called uswid to "find" all the SBOM components and populate the tokenized values automatically > Should that not be part of the upstream build process for each project? For coreboot, we could do that -- i.e. we'd build libpng, libhwbase (and any other deps) *then* coreboot -- and so it's perfectly fine to do this in the upstream build system. There's an example using meson in fwupd: https://github.com/fwupd/fwupd/blob/main/contrib/meson.build#L15 -- although I'd advise not doing this at this point. For EDK II the upstream submodule build system typically isn't used at all, and so we can't rely on the subproject cmake/scons/whatever generating the post-processed file which we can absorb as part of the firmware build. Shipping the template seems a pragmatic first step, and means the open source software appears accurately on the SBOM HTML page of the OEM "binary" firmware. > > "authors": [ > > { > > "name": "Anup Patel, Atish Patra, Bin Meng, Samuel Holland, Xiang W, Damien Le Moal, Heinrich Schuchardt, Yu Chien Peter Lin, Himanshu Chauhan, Inochi Amaoto, Alistair Francis, Andrew Jones, Clément Léger, Mayuresh Chitale, Nikita Shubin, Vivian Wang, Rahul Pathak, Ivan Orlov, Lad Prabhakar, Jessica Clarke, Xiang Wang, Abner Chang, Ben Zong-You Xie, Guo Ren, Liu Yibin, Nylon Chen, Bo Gan, Dong Du, Olof Johansson, Daniel Schaefer, Jan Remes, Nam Cao, Nick Kossifidis" > > } > > ] > Should this not be: > "authors:" [ > { "name": "Anup Patel" }, > { "name": "Atish Patra" }, > ... > ] It certainly *could* be. We didn't do it like this as CycloneDX < v1.6 had just a single string field for the author (and SPDX is just the same), and we wanted to maintain compatibility between the different formats. If this is a blocker for inclusion let me know and I'll write some code in uswid to accept either style. Richard.
On 9 Dec 2024, at 16:27, Richard Hughes <richard@hughsie.com> wrote: > On Monday, 9 December 2024 at 16:12, Jessica Clarke <jrtc27@jrtc27.com> wrote: >>> then we use a tool called uswid to "find" all the SBOM components and populate the tokenized values automatically >> Should that not be part of the upstream build process for each project? > > For coreboot, we could do that -- i.e. we'd build libpng, libhwbase (and any other deps) *then* coreboot -- and so it's perfectly fine to do this in the upstream build system. There's an example using meson in fwupd: https://github.com/fwupd/fwupd/blob/main/contrib/meson.build#L15 -- although I'd advise not doing this at this point. > > For EDK II the upstream submodule build system typically isn't used at all, and so we can't rely on the subproject cmake/scons/whatever generating the post-processed file which we can absorb as part of the firmware build. Shipping the template seems a pragmatic first step, and means the open source software appears accurately on the SBOM HTML page of the OEM "binary" firmware. I don’t mean you *have* to use it that way in consumers. Just that if you’re adding the file to upstream projects you should do the work to integrate it into their build systems so others can benefit. You wouldn’t add a C source file that wasn’t built by the Makefile even if your project wasn’t using the upstream Makefiles, so don’t do the same for other resources. >>> "authors": [ >>> { >>> "name": "Anup Patel, Atish Patra, Bin Meng, Samuel Holland, Xiang W, Damien Le Moal, Heinrich Schuchardt, Yu Chien Peter Lin, Himanshu Chauhan, Inochi Amaoto, Alistair Francis, Andrew Jones, Clément Léger, Mayuresh Chitale, Nikita Shubin, Vivian Wang, Rahul Pathak, Ivan Orlov, Lad Prabhakar, Jessica Clarke, Xiang Wang, Abner Chang, Ben Zong-You Xie, Guo Ren, Liu Yibin, Nylon Chen, Bo Gan, Dong Du, Olof Johansson, Daniel Schaefer, Jan Remes, Nam Cao, Nick Kossifidis" >>> } >>> ] >> Should this not be: >> "authors:" [ >> { "name": "Anup Patel" }, >> { "name": "Atish Patra" }, >> ... >> ] > > It certainly *could* be. We didn't do it like this as CycloneDX < v1.6 had just a single string field for the author (and SPDX is just the same), and we wanted to maintain compatibility between the different formats. If this is a blocker for inclusion let me know and I'll write some code in uswid to accept either style. IMO the single string field is better than this nonsense format that claims to be a list of authors but is a list of a single author (what happens when you have SBOMs that really do have lists of authors and you now interpret this as being an author called “Anup … Kossifidis”?). But better still would be doing the proper thing and having a list of author objects, so ideally extend your tooling to support the new format rather than pretend it doesn’t exist, and if you can’t do that then adopt the old format fully. Jess
On Monday, 9 December 2024 at 16:37, Jessica Clarke <jrtc27@jrtc27.com> wrote: > I don’t mean you have to use it that way in consumers. Just that if > you’re adding the file to upstream projects you should do the work to > integrate it into their build systems so others can benefit. Adding it to the upstream build system is pointless without installing or embedding the artifact somewhere. There was a murmuring of a proposal that we could install the dist'd post-processed file in something like /usr/share/sbom but the details are still being worked on and I don't think opensbi would be terribly useful in a docker image or as an rpm anyway. > IMO the single string field is better than this nonsense format Okay... > But better still would be doing the proper thing and having a list of > author objects, so ideally extend your tooling to support the new > format rather than pretend it doesn’t exist, and if you can’t do that > then adopt the old format fully. We do support multiple authors in the uSWID project, but only the SWID format and CycloneDX format >= 1.6 support it. I've attached a new patch without the authors sections, and uswid --fixup will auto-add the sections as required in the specific format. Richard
diff --git a/docs/sbom.cdx.json b/docs/sbom.cdx.json new file mode 100644 index 0000000..d300807 --- /dev/null +++ b/docs/sbom.cdx.json @@ -0,0 +1,43 @@ +{ + "bomFormat": "CycloneDX", + "specVersion": "1.6", + "version": 1, + "metadata": { + "authors": [ + { + "name": "@VCS_SBOM_AUTHORS@" + } + ] + }, + "components": [ + { + "type": "library", + "bom-ref": "pkg:github/riscv-software-src/opensbi@@VCS_TAG@", + "cpe": "cpe:2.3:a:riscv:opensbi:@VCS_TAG@:*:*:*:*:*:*:*", + "name": "OpenSBI", + "version": "@VCS_VERSION@", + "description": "Open Source Supervisor Binary Interface for RISC-V", + "authors": [ + { + "name": "@VCS_AUTHORS@" + } + ], + "supplier": { + "name": "RISC-V Foundation" + }, + "licenses": [ + { + "license": { + "id": "BSD-2-Clause" + } + } + ], + "externalReferences": [ + { + "type": "vcs", + "url": "https://github.com/riscv-software-src/opensbi" + } + ] + } + ] +}
Improve supply chain security by including a SBOM file with substituted values. This will be used to construct a composite platform SBOM. Signed-off-by: Richard Hughes <richard@hughsie.com> --- docs/sbom.cdx.json | 43 +++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 43 insertions(+) create mode 100644 docs/sbom.cdx.json