CoSWID and SWID BOM Support about transparency-exchange-api

[stevespringett]

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.
https://docs.google.com/document/d/1LPNXZ-LmF4ObzpYyAs51WdUktZuTXpOWI_ssGNOCWXQ/edit

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?

[aj-stein-nist]

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

OK I suppose I need to review the references and test it out before commenting further on it.

The use case document we're working out of didn't mention SWID, so I just added it. https://docs.google.com/document/d/1LPNXZ-LmF4ObzpYyAs51WdUktZuTXpOWI_ssGNOCWXQ/edit

I will review this document as well, thanks!

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?

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:

Potentially harmful physical equipment (e.g., power grid, traffic control, hazardous chemical processing, etc.) is connected to a network in support of critical infrastructure. The organization managing such infrastructure needs to ensure that only authorized code and users can control corresponding critical processes, and that these processes are protected from unauthorized manipulation or other threats. When a protocol operation can affect a critical system component of the infrastructure, devices attached to that critical component require some assurances depending on the security context, including assurances that a requesting device or application has not been compromised and the requesters and actors act on applicable policies. As such, remote attestation can be used to only accept commands from requesters that are within policy.

Another is network endpoint assessment during or after boot:

Network operators want trustworthy reports that include identity and version information about the hardware and software on the machines attached to their network. Examples of reports include purposes (such as inventory summaries), audit results, and anomaly notifications (which typically include the maintenance of log records or trend reports). The network operator may also want a policy by which full access is only granted to devices that meet some definition of hygiene, and so wants to get Claims about such information and verify its validity. Remote attestation is desired to prevent vulnerable or compromised devices from getting access to the network and potentially harming others.

Typically, a solution starts with a specific component (sometimes referred to as a "root of trust") that often provides a trustworthy device identity and performs a series of operations that enables trustworthiness appraisals for other components. Such components perform operations that help determine the trustworthiness of yet other components by collecting, protecting, or signing measurements. Measurements that have been signed by such components are comprised of Evidence that either supports or refutes a claim of trustworthiness when evaluated. Measurements can describe a variety of attributes of system components, such as hardware, firmware, BIOS, software, etc., and how they are hardened.