Closed jasinner closed 7 years ago
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 victims-web
for backend stuff.
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. This seems like a good idea for dependencies from Maven Central. However since we are incorporating data from other Maven repositories, we should allow the vendor field to reflect other repositories.
If we use apache-maven-central
as the vendor we could use $NAME-maven-$OPTIONAL
as a pattern for other maven CPE vendors. Does that seem reasonable?
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.