Product identifiers with CycloneDX

[openvex]

Product identifiers with CycloneDX

[knqyf263]

"Minimum Requirements for Vulnerability Exploitability eXchange (VEX)" describes below:

The term “product” is equivalent to the SBOM framing term “primary component.”

https://www.cisa.gov/sites/default/files/2023-04/minimum-requirements-for-vex-508c.pdf

And "Framing Software Component Transparency: Establishing a Common Software Bill of Materials (SBOM)" says

An SBOM must list at least one primary component, which defines the subject of the SBOM.

https://www.ntia.gov/files/ntia/publications/ntia_sbom_framing_2nd_edition_20211021.pdf

Let's say generating SBOM for a container image. The primary component would be the container image itself like pkg:oci/debian@sha256%3A244fd47e07d10?repository_url=ghcr.io/debian&tag=bullseye. That said, the product id should be an identifier of the container image, and the subcomponent id should be an identifier of the package, right? However, the product id could be redundant as the BOM-Link includes the serial number of SBOM that the VEX is referencing.

There are so many possibilities and I find it difficult to automate consuming OpenVEX in vulnerability scanners.

1. BOM-Link/BOM-Link
   • product_id: BOM-Link to the primary component (redundant)
   • subcomponent_id: BOM-Link to the affected (non-affected) package component
2. BOM-Link/BOM-Ref
   • product_id: BOM-Link to the primary component
   • subcomponent_id: BOM-Ref to the affected (non-affected) package component
3. BOM-Link
   • product_id: BOM-Link to the affected (non-affected) package component
4. BOM-Link/PURL
   • product_id: BOM-Link to the primary component
   • subcomponent_id: PURL of the affected (non-affected) package component
5. PURL/BOM-Link
6. PURL/PURL
7. etc.

We've recently adopted No.3 in our scanner since it is the same approach as CycloneDX and it keeps implementation simple. But we can change it to something else if OpenVEX explicitly defines that.

[luhring]

This makes sense to me! I think having more precise identifiers of affected software is a great thing for the spec. And I agree this logic applies to SPDX, or any other SBOM format for that matter.

[puerco]

Hey @knqyf263 thanks a lot for raising this issue and for supporting OpenVEX, this is absolutely awesome 🎉

My first takeaway from this is that we need to update the spec to state that product should be (at least for now) any valid URI with package URL (purl) being the preferred intra-format method to link assessed elements.

Now, regarding:

the product id could be redundant as the BOM-Link includes the serial number of SBOM that the VEX is referencing

My view here is that using the BOM-Link (option 3 above) does not fulfill the product + subcomponent duplet. The reason for my reasoning is that a BOM-link is a pair of a bom identifier plus a bom-ref (pointing to an element in that doc). The first part designates the document and its version but does not necessarily imply you are referencing the root component. You may find that the VEX "product" is an element deeper in the SBOM graph and the assumption breaks down.

I think a better solution when referencing data in a CDX document would be:

• Use Option 3 to point to the product. Using only that when there is no need to specify a subcomponent
• Use Option 1 when you need to also define a subcomponent.

Now this being linked data, any of the options should be valid, right? You, of course, choose to be opinionated and start by handling a narrower scope in the beginning.

Finally regarding this:

it is the same approach as CycloneDX and it keeps implementation simple.

Keep in mind that the CycloneDX VEX implementation in 1.4 is based on frak of an early idea of VEX and does not conform yet to the minimum requirements for VEX. In particular for our discussion here, it does not support the notion of subcomponents. The vulnerability analysis has a single bom-ref which corresponds roughly to the VEX product but there is no way to specify the subcomponent (I know that there is affects but when talking vex, it could go so far as adding more products, not subcomponents). Hopefully, this will be fixed in 1.5

[knqyf263]

Now this being linked data, any of the options should be valid, right?

Yes, the above options should be valid, but too many and flexible options make implementation in scanners difficult and hard for users to understand. As you mentioned, it is preferable to have a more explicit specification and extend it as needed.

The first part designates the document and its version but does not necessarily imply you are referencing the root component.

As mentioned above, The VEX document describes

The term “product” is equivalent to the SBOM framing term “primary component.”

Do you think the VEX "product" can be an element deeper in the SBOM graph, as you pointed out?

And I know CycloneDX VEX doesn't meet the minimum requirements, but I feel like "product/subcomponent" is almost the same as "serial number+version/bom-ref" since the spec says the "product" is equivalent to the primary component.

VEX minimum requirement	BOM-Link
product (primary component)	document (serial number + version)
subcomponent	component (bom-ref)

If it is possible that the VEX "product" can be a deeper component, it is not the case, though. In that case, do we want to update the specification so that the "product" isn't necessarily the primary component?

Anyway, if you think the option 1&3 is the best, I'm ok with that. I just want to define the OpenVEX spec explicitly.