-
-
Notifications
You must be signed in to change notification settings - Fork 6
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
CoSWID and SWID BOM Support #13
Comments
SWID isnt really an SBOM format, although it can be misused as one. For software identity however, SWID is great. CycloneDX supports SWID natively. Any component in a CycloneDX BOM can have its identity represented as a SWID tag. Refer to https://cyclonedx.org/docs/1.5/json/#components_items_swid. If you see any shortcomings with the SWID support of CycloneDX, I'd encourage you to create an issue in the specification repo so we can flush it out. In addition to the native SWID support of CycloneDX, Package URL also supports SWID tags. This is applicable to both CycloneDX and SPDX. Refer to https://github.com/package-url/purl-spec/blob/master/PURL-TYPES.rst#swid The use case document we're working out of didn't mention SWID, so I just added it. In the case of CoSWID, I honestly do not know anything about it. Without having to reat the IETF spec, is there a use case document that outlines what problems CoSWID solves and how it solve them? |
OK I suppose I need to review the references and test it out before commenting further on it.
I will review this document as well, thanks!
I guess this will be hard to condense but I will try. CoSWID takes the SWID data model and encodes it into CBOR (so we don't have to read a lot) for use on devices where XML and JSON parsing is difficult or beyond what is possible with constrainted resources (hence the Co, for Concise, meaning CBOR), so IoT and embedded systems. So, the actual use case you are asking about? There are a few in the current RATS standard RFC 9334. If you look at these examples below, there are a few choices for where you could store data out side the devices being remotely assessed and aggregate because you are not storing it N>1 of those devices for some definition of network but you will likely want to cross-reference. This is high level, from the arch there are many more details, but I am trying to keep it to the point to not making it a bigger reading exercise for now. So apologies, I inline quoted some relevant use cases for your convenience. Let me know if this is unclear. One is critical infra hardware protection:
Another is network endpoint assessment during or after boot:
|
Thank you for your feedback. The current work on the API is quite agnostic to the types of artefacts. We have a discussion on how to declare a type on them in another issue. Further work with what we call the "insights" will depend on a server implementation being able to parse BOMs and produce answers to queries. We'll certainly bring coswid along. |
Hello 👋. I have quickly reviewed the spec draft here and noticed that only CycloneDX and SPDX are identified. Is SWID, more specifically the compact CBOR alterntive in IETF RFC9393 supported? If not, would you open to contributions to align identifiers and other metadata from this other BOM format in this API spec?
The text was updated successfully, but these errors were encountered: