Vulnerability Database information page
Problem to solve
It is difficult for users and GitLab staff to understand what is and is not currently inside the Vulnerability Database and information about how often this information is updated.
It is difficult for users to understand when a new vulnerability is announced, if GitLab is already scanning for it or if they are potentially exposed to it.
When users don't understand what we are scanning for and if it is current, they become fearful and have doubts. If they can't get the answer to the questions they have, they either have to live with that fear or engage with GitLab field staff.
Intended users
- Sam (Security Analyst)
- Parker (Product Manager)
- Rachel (Release Manager)
- Delaney (Development Team Lead)
Further details
There have been several customers conversations along the lines of "I heard about CVE XYZ - am I protected against it?" that this is intended to help address. This has come from non-security engineers, such as PMs, release managers, or CXOs.
Proposal
Create a new page inside GitLab.com that allows viewers to:
-
See how many vulnerabilities are currently in the Vulnerability Database- This requirement was removed since it requires a large amount of context for the numbers to be meaningful beyond a vanity metric. We anticipate many users will not have this context when viewing the screen so it is not helpful. We will consider re-adding it in a new issue if we get feedback that the raw number would be helpful.
- The last time the database was updated
- What our current mean time-to-merge is
- Search for a specific CVE and see if we currently scan for it.
- Domain must be inside GitLab.com and not part of the Handbook
Note: This page does not need to be part of a self-hosted installation - there can be a single copy hosted on GitLab.com.
Consider re-using the work done at https://caneldem.gitlab.io/vuln-pages/, https://about.gitlab.com/handbook/engineering/development/performance-indicators/#cve-issue-to-update, and the Security Advisories dashboard for this.
Permissions and Security
Should be publicly visible on GitLab.com
Documentation
Documentation should be updated to reference the new page.
What does success look like, and how can we measure that?
- Field staff can confidently answer customers that a given vulnerability they are concerned about is being scanned for. => Canvas field staff that they get value out of the page
- Customers can directly access vulnerability information to understand what we scan for. => Measure page views