intel
CoSWID support
One of my colleagues at Intel expressed interest in having the SBOM reader handle SWID (XML) and CoSWID (CBOR) (https://datatracker.ietf.org/doc/draft-ietf-sacm-coswid/). @anthonyharrison 's already got SWID happening, but here's some additional information on CoSWID from my inbox:
CoSWID is interesting from a tooling perspective in that there is a formally defined schema (in CDDL - https://datatracker.ietf.org/doc/html/rfc8610). The impact to tooling is that anytime a CoSWID file is created or parsed it can be validated against the schema. This affects authoring tools and parsers mostly.
Some of our tools are providing consistency checks without the benefit of a schema. It could be strategically important to incorporate schema checking in tool chains where possible IMO. But I don’t know to what extent we do tool development as the tooling for SBOM / COSWID are works in progress.
Looks like it might be interesting for a future release, so I'm filing this issue and tagging it appropriately. Maybe a good GSoC project option?
@terriko Looks an interesting addition to the SBOM support.
The current SBOM support for cve-bin-tool is aligned with the formats desceibed in the recommendations from NTIA.
CoSWID looks like an evolution of the SWID format so it should be relatively easy to implement although I haven't found any CoSWID parsers in Python although I found one in Rust lib.rs/crates/coswid.
Certainly one to watch for a future release.
@terriko The standard seems to be still evolvling with the latest draft (version 22) being released in September 2022. It is clearly not stable as the current draft will expire in January 2023.
However, I found a Python package which MIGHT be useful once the standard has matured a bit more. I am sure that if we look at a few examples of COSWID documents, it would be relatively easy to parse the file for the small number of relevant elements (looks like it might just be software-name and software-version) which are needed for scanning (most of the information isn't of use for cve-bin-tool).
Flagging this as gsoc just so I don't forget to investigate whether it's in a good enough shape after January. I think it's probably not going to be stable enough to put a gsoc contributor on but it's worth looking at in the new year anyhow.
It's been a couple of years and no one has piped up saying they want this, and a lot of things have moved on in this space. I won't say we'd never do it, but I don't think it's too likely to happen anytime soon, so I'm going to go ahead and close this.