"Find me a CVE to curate" feature

[andymeneely]

Motivation

It would be nice if people could be given a vulnerability that is ripe for curating at random.

At the moment in the 331 class, I do all this with spreadsheets and scripts. I basically load in YMLs that have fixes and VCCs found and then I assign everyone a different CVE. This works great for a class-type situation, but it would be nice if we could streamline it a bit and make it more web-based.

Feature

You hit a button and VHP randomly chooses a CVE that needs curating. It makes it very clear what we know and don't know about the vulnerability right now, and what you can do to help make it better. This would lead into a curate instructions/tool described in #965.

A few key things we need to preserve:

• Random subsample. I've always had the curation selection process to be a random process. This is of scientific importance to me because I want all of our results to be a representative subset of all the vulnerabilities in VHP. We'll never curate all the vulnerabilities, but we should choose them at random
• Double-assigning. I don't want to have VHP accounts for curators... ever. But I also don't want to double-assign CVEs. I suppose if the choice is random and the number of vulnerabilities is large enough, the chances of that are low. But still, I don't want to double-assign curations. I have some ideas for this, see below.
  • We could have the API update a CVE's database entry with the current timestamp, then have a 24-hour cooldown. That way, no two CVEs would get assigned within 24 hours. There might be issues with this, but it's an idea.
  • We could hit GitHub's API for any open issues or pull requests with the CVE in the title. And then don't assign ones that have an open PR or issue.
  • We could just take the "ostrich algorithm" - stick our heads in the sand and hope for the best.
• Finding ones that are "ready". Some vulnerabilities are not ready to curate because we don't have enough info about them yet. Specifically, we need at least one fix and one vcc to get started. The API behind this should filter out those.

Check the following:

• I have checked the VHP backlog for something similar: https://github.com/VulnerabilityHistoryProject/vulnerability-history/issues
• I have checked if this should also be part of a Github Project: https://github.com/VulnerabilityHistoryProject/vulnerability-history/projects?type=beta
• I have checked that this might need dev infrastructure or refactor labels