search

espressif / esp-idf-sbom

ESP-IDF Software Bill of Materials Generation Tool
Apache License 2.0
12 stars 3 forks source link

SBOM data for tools? (IDFGH-11317) #5

Closed fpgax closed 11 months ago

fpgax commented 12 months ago

Hi!

I was looking at the example SBOM created in an earlier issue and it seems to include tooling, for example xtensa-esp32-elf toolchain and app_trace. This is not part of the generated firmware, but rather used for creating the firmware or analyzing memory dumps or similar.

This doesn't seem correct to me. Shouldn't the SBOM just specify such components that end up in the firmware?

fhrbata commented 12 months ago

Hello @fpgax ,

the toolchain contains e.g. libc.a which is linked into the final binary, so IMHO it's correct to have a direct dependency on it.

The generated SBOM also by default contains all components, which were part of the build process, even though they are not part of the final binary. These are not directly linked to the project's SPDX package, meaning it has no dependency on them. The goal is to have all the information in sbom, but link the project PSPDX package only with components, which contribute to the final binary.

Thank you

andyn-ff commented 12 months ago

I am interested in this question too. @fhrbata in your answer you make a distinction between the "project PSPDX package" and the sbom and I would like to understand this better. I thought the SPDX is the sbom in a particular standardised format for exchange with other tools - is that incorrect?

fhrbata commented 12 months ago

Hello @fpgax,

you are correct, SPDX is one of the formats used to represent SBOM. SPDX format contains a root Document Creation Information ,SPDX packages and other elements. The Document Creation Information points(DESCRIBES) one or more SPDX Packages, which are connected with SPDX relationships. In SPDX generated by esp-idf-sbom the Document Creation Information points to SPDX package for the final binary e.g. hello_world.bin, which in turn has relationships(DEPENDS_ON) with other SPDX packages. These represent components/tools/libs included in the final binary. So it's a tree of SPDX packages, where the root is the Document Creation Information pointing to the SPDX package representing the whole project e.g. hello_world.bin.

There could be other SPDX packages for tools or components not directly linked into the final binary, But these are not linked with relationships to the root SDPX package for the project. Note that you can remove them with the --rem-unused option. So following the connections from the root package should give you all SPDX packages, which are somehow part of the final binary. For example the check command does this and by default checks only packages with CPE information within this tree. You can use --check-all-packages to check packages not linked into this tree.

The SPDX layout used by esp-idf-sbom should be briefly described in the README.

For more information you can take a look at the SPDX specification.

Hopefully this answers your question or at least provides some links where to look for more information.

Thank you for your feedback!

fhrbata commented 11 months ago

Hello @fpgax , does the above comment answer your question(address your concern)? Thank you

fpgax commented 11 months ago

I see your point regarding both libc and the compiler tooling itself. They are of course relevant.

Then the next interesting question for me is whether they have or should have a CPE. In this case they probably do our should have one, since I believe it's a 3rd party component. That part of the discussion can be continued in the other issue (https://github.com/espressif/esp-idf-sbom/issues/6).

Feel free to close, unless you want to add something.

fhrbata commented 11 months ago

Hello @fpgax,

thank you for your input! I left my comment in #6 and we can discuss things there. I'm closing this, but feel free to re-open if necessary.