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

CVE ID and UUID #18

Open
adulau opened this issue Jun 24, 2022 · 4 comments
Open

CVE ID and UUID #18

adulau opened this issue Jun 24, 2022 · 4 comments

Comments

@adulau
Copy link

adulau commented Jun 24, 2022

Are the CVE ID generated in a fixed way like using UUIDv5?

It seems the current script https://github.com/oasis-open/cti-stix-common-objects/blob/main/scripts/generate_common_objects.py#L123 is generating automatically the UUID which is a bit counter productive.

Especially that a CVE ID is fixed and if you know the original seed for the UUIDv5, the UUID can be looked up directly without any search.

@rpiazza
Copy link
Contributor

rpiazza commented Jun 24, 2022

@adulau - you are correct. There is some discussion about whether a Vulnerability object should be created for each CVE in the common object repository. Others have also suggested using UUIDv5, although at this point with 100K Vulnerability objects already created I'm not sure what the best way forward is.

@elemendar-syra
Copy link

@rpiazza I'd also be really keen for there to be a fixed way for generating IDs (starting at some point at least, as it's easy enough to map to the historic ones) as this would make it easy to generate CVE Vulnerability objects on the fly that can then easily match up to the OASIS ones, through a duplicate-of relationship or similar so that everything can come together nicely.

As a suggestion, from a certain point could UUIDv5 with an OASIS namespace and generating the rest based on the CVE name not easily do this? Would be a lot easier than constantly pulling down form the repository (especially when trying to map to the common objects when we're running on client sites where we don't have control of firewall rules etc)

@elemendar-syra
Copy link

@rpiazza I'm happy to implement this concept, if I can get access to create a branch and an MR for you?

@rpiazza
Copy link
Contributor

rpiazza commented Jul 1, 2024

Related issue #77

I am completely in favor of changing the way we currently generate Vulnerability objects based on CVEs. Storing them in Github has become somewhat untenable. There are several good ideas, using UUIDv5 ids based on the CVE id, using the NVD API, etc.

Using UUIDv5 ids for SDOs is not explicitly prohibited by the STIX 2.1 spec, although using them for only SCOs was the intention.

One important thing to keep in mind is what the STIX Vulnerability object should contain. Should it have all of the information in the CVE/NVD entry - which would require an extension (this is how ATTACK attack-patterns were implemented). Or is it just a link to the NVD/CVE data (which is how it is implemented now in the Common Object Repository).

Most of all, I think before anyone implements anything the TC should provide guidance.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants