Vulnerability Clusters page

[andymeneely]

Motivation

We should have the concept of "clusters" be more obvious in this project. The "tags" page is just too complicated and abstruse to be what we land on. Let's make a "clusters" page be one of our top-level pages.

Details

I'm envisioning something like this:

So the Clusters page is a top-level type of page.

When you go there, you'll see something like this:

Each of those "clusters" is a way of grouping Tags that is different than families in #1039. (We should rename it to "mutex family" or something).

The difference between tag clusters and tag families is that tag families are guaranteed to be mutually-exclusive. A vulnerability can only have exactly one Tag within a family.

Example clusters:

• Lessons
• Type (CWE, or we can drill down more to separate)
• Discovery Method
• Severity
• Lifetime
• Language
• Project

Every tag belongs to a Cluster, and you can learn about the cluster in general on the Clusters page, drilling down to specific examples.

Tasks for MVP

• [x] Schema: change family to mutex_family. Add tag_clusters table, and cluster_id to tags
• [x] Update all the taggers to match the new schema
• [ ] Update navbar
• [ ] Add route /clusters and controller. Add /api/clusters and /api/clusters/:cluster_slug endpoints too.
• [ ] Add /api/tags/:tag_slug/vulnerabilities endpoint.
• [ ] Add new page at /clusters
• [ ] Display example vulnerabilities for the tag within the cluster
• [ ] Add writing for each cluster
• [ ] Figure out cluster icon, color, etc.

Issue Chores

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

[andymeneely]

Closing this in favor of #990