-
Notifications
You must be signed in to change notification settings - Fork 5
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
Host CVRF data about vulnerabilites #147
Comments
Sounds like a good idea to me. Do you have any ideas on how you'd expect the data to be available within the API? |
Looking at the Red Hat Enterprise data it can be a list of static files. It might actually be best done as part of separate project from victims-web? |
@jasinner as in outside of the API as well -- or just outside of the web ui? Slightly related: I'm keen on trying to get back to working on the API side of things if we (as in anyone who has opinions on the design of the API) is happy with with design. I'd like to replace the aging all-in-one |
We have to decide what to use as the 'vendor' in any CPE we issue. One idea proposed here is to use 'apache-maven-central' as the vendor. |
If we use |
I like the idea of using $NAME-maven-$OPTIONAL. However I'm going to close this task, and create a new project that's not part of victims-web to start working on this issue. https://github.com/jasinner/victims-cvrf |
We should host CVRF data about the vulnerablities in the database so that it can be consumed by organizations such as NIST in their NVD.
This would require mapping Maven GAVs to CPE names, and requesting new CPE names where they don't already exist.
Here is an example of CVRF data hosted by Red Hat for enterprise products.
The text was updated successfully, but these errors were encountered: