Export component list in SBOM format

[terriko]

Should we make it possible to export a list of components in SBOM format using CVE-bin-tool?

We've had this discussion in the past and decided that was outside the scope of what we're trying to build, but we've grown a lot, have over 100 binary checkers and several package parsing utilities. While I still wouldn't say we can reliably identify every component of interest to someone, I think it's safe to say that we can reliably identify enough to get someone started on building a more comprehensive SBOM. (I'm also not adverse to supplementing what we understand by using other tools if appropriate.)

In particular, I think we might want to generate SBOMs that include {vendor, product} pair information for easier lookup into NVD (and potentially give multiple vendor, product options if they're needed, since we know those aren't always a one-to-one mapping?). This means that you could do with SBOM what we can already do with other formats: do the binary scan once and then re-scan the output regularly without incurring the cost of package finding.

Looking at SPDX specifically, there's also an annotations functionality where we could potentially store things like CVE information, which might also be incredibly useful to folk. It looks like there's also the ability to link to their SBOM entries so if we don't want to shoehorn a whole format into the comments field, we could produce our own JSON that just included links as well.

I suspect @anthonyharrison will be interested, but... is this potentially interesting to anyone else?

[anthonyharrison]

@terriko This would make a great addition to the capability of the tool. The next evolution of the SPDX SBOM standard is likely to have options to include security information within the SBOM (including CVE references) so this would seem to be well aligned with the idea.

The generation of the SBOM will need to contain additional information in addition to the product/vendor/version information to conform with the standards but these can in most cases be set to default values.

The SBOM would need to contain all of the components and not just those components for which vulnerabilities have been found. This would mean we would need to maintain a list of all components which have been scanned - this would actually be a good enhancement to add an option to report which components have no reported vulnerabilities.

A SBOM needs to have relationships between componants. For a single module/component this is typically its libraries which are required. However one of the big challenges is determining the granulatiry of the SBOM. As it isn't sensible to have a single SBOM for a whole scan (unless it is a single file), we would probably generate multiple SBOMs during a scan (e.g. a single SBOM for each archive).

Obviously cve-bin-tool only identifies and reports the components it has checkers for etc. We might need to consider if there are components which can be identified which don't have a checker (there is some information which could be gleaned from ELF file headers which might help)

I will start sketching out some ideas - we probably need a package to hold and manage a SBOM data model as well as an enhancement to the output engine to generate an SBOM in one or more formats. There probably also needs to be some consideration given to see if there are other tools which could be loosely integrated with cve-bin-tool.

[terriko]

I closed #475 in favour of this issue. If anyone spots any other duplicate open issues where we discussed this idea (it's come up a few times!) feel free to let me know so I can clean them up too.

[terriko]

Also, I hear rumours that SPDX is considering adding CVE information explicitly into the next version of the spec. I haven't gone to verify, but that would be handy for us, and we might want to go look at and contribute to discussions there before it's finalized.

[terriko]

Relevant link to the spec github: https://github.com/spdx/spdx-spec

[anthonyharrison]

I was on a Spdx call last night and there are a number of options being considered for including defect information as part of the 3.0 release. I will be looking at how these could be supported by cve-bin-tool; we already have a VEX document being produced so I think it shouldn't be too difficult to support other formats.

…

On Thu, 16 Jun 2022, 21:08 Terri Oda, ***@***.***> wrote: Relevant link to the spec github: https://github.com/spdx/spdx-spec — Reply to this email directly, view it on GitHub <#1697 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACAID233CXD3LPYQSQM5QC3VPOCUVANCNFSM5YLV2C2A> . You are receiving this because you were mentioned.Message ID: ***@***.***>