Skip to content
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

Version ranges in product_id/subcomponent_id #26

Open
knqyf263 opened this issue Jun 4, 2023 · 3 comments
Open

Version ranges in product_id/subcomponent_id #26

knqyf263 opened this issue Jun 4, 2023 · 3 comments
Labels
area/product Issues and PRs related to the product field

Comments

@knqyf263
Copy link
Contributor

knqyf263 commented Jun 4, 2023

Is there any way to specify the version range in product_id and subcomponent_id?

The minimum requirements for VEX denote as below:

[product_id] and [subcomponent_id] MAY specify sets of products or components, for example:
● Every product or component owned by a supplier
● A product family or product line
● Version ranges
● A specific branch

It makes sense to use version ranges. Otherwise, VEX documents must be updated every time product or subcomponent version changes.

And the OpenVEX spec recommends PURLs.

The use of Package URLs (purls) is recommended.

"Any versions" probably can be described by omitting the version since the version is optional in PURL. e.g. pkg:maven/org.apache.xmlgraphics/batik-anim

How about version ranges? I may be missing something.

@puerco
Copy link
Member

puerco commented Jun 14, 2023

Since we are favoring the use purls across the spec, I think we should recognize and implement in our libraries the purl vers: ranges specification. It has not merged yet but it seems to have been frozen for a couple of years now and it is already baked into the CycloneDX 1.4 spec. My only worry here is that we would be producing purls that may not be universally recognized, thoughts?

@puerco puerco added the area/product Issues and PRs related to the product field label Jun 14, 2023
@michael-j-oconnor
Copy link

I'm looking for an OpenVEX-compliant way to list a CVE/vulnerability in a VEX report twice, once for a version of the product that is impacted, and once for a newer version of the same product that is Fixed. I want to show, in a single VEX report, that one version of our product is impacted and the next version is fixed.

Will the version ranges discussed here be able to address this use case?

@shanu-26
Copy link

Adding on to the question above..
For some CVE if we have information on both the impacted and the fixed version, can we specify this in the 'action_statement' field under statements? Something like "Fixed in version x.y"?
Reference to OpenVEX Specification.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/product Issues and PRs related to the product field
Projects
None yet
Development

No branches or pull requests

4 participants