Comments (4)
"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.
- BOM-Link/BOM-Link
- product_id: BOM-Link to the primary component (redundant)
- subcomponent_id: BOM-Link to the affected (non-affected) package component
- BOM-Link/BOM-Ref
- product_id: BOM-Link to the primary component
- subcomponent_id: BOM-Ref to the affected (non-affected) package component
- BOM-Link
- product_id: BOM-Link to the affected (non-affected) package component
- BOM-Link/PURL
- product_id: BOM-Link to the primary component
- subcomponent_id: PURL of the affected (non-affected) package component
- PURL/BOM-Link
- PURL/PURL
- 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.
from spec.
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.
from spec.
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
from spec.
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.
from spec.
Related Issues (20)
- Clarify timestamps HOT 2
- `Products` not listed as required HOT 4
- VEX schema/spec version should be a field in the metadata HOT 4
- Add "impact_statement" to specification HOT 2
- Version ranges in product_id/subcomponent_id HOT 3
- PURL matching with qualifiers HOT 3
- Ability to refer back to an SBOM? HOT 4
- Update Spec to point out `@id` change HOT 1
- timestamp issue HOT 2
- Modify severity HOT 6
- Consider defining an OpenVEX mediaType HOT 2
- Use Cases HOT 1
- Diagram missing from ATTESTING.md
- README.md needs to be updated to reflect v0.2.0 spec changes HOT 1
- Standard for VEX document discovery HOT 1
- Make OpenVEX extensible ?
- Storing VEX files in a dedicated directory within Git repositories HOT 8
- clarifying product identification
- Clarification on Use of @id, PURL Identifier, and Impact Statements HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from spec.