DESIGN: Manually create a Vulnerability
Problem to solve
Today, all vulnerability objects are created as a result of detections by our Secure scanners or that of an integrated 3rd-party scanner. However, this limits Vulnerability Management to only those vulnerabilities picked up by currently supported tools. To truly make our Vulnerability Management solution suitable for general-purpose use across an organization's entire SDLC (and possibly beyond), we need to provide users with the ability to manually create vulnerability objects.
Intended users
- Sasha (Software Developer) - Sasha will want to report any potential vulnerabilities discovered during development.
- Sidney (Systems Administrator) - Sidney will want to report any potential vulnerabilities discovered in the infrastructure to which GitLab is deploying applications.
- Sam (Security Analyst) - Sam will want to report potential vulnerabilities based on alerts that indicate a potential weakness being exploited.
- Alex (Security Operations Engineer) - Alex will want to report a new vulnerability based on any weaknesses exploited in detected attacks.
- Simone (Software Engineer in Test) - Simone will want to report any potential vulnerabilities discovered during testing.
User experience goal
Manually creating a vulnerability object should be simple, not unlike creating a new issue. Created vulnerability objects will appear in the appropriate Project, Group, and Instance security dashboards just like vulnerabilities from Secure scanners do. It should be easy to distinguish between a manually created vulnerability object and one created automatically from a scanner results.
It is also important that the user inputs a minimum amount of information about the vulnerability to help it be properly understood and classified by anyone else looking at it.
Proposal
Further details
We need to include public APIs sufficient to allow our users to create vulnerabilities programatically. For instance, a company may have an existing internal form where users can input details of any potential security issues. The customer could then take the output of this form and use it to create new vulnerabilities in GitLab for further evaluation and triage. An API is likely also the preferred method to pull in vulnerability reports from bug bounty programs like Hacker One.
We also need to ensure that manually-created vulnerabilities are accessible through the same APIs that the existing vulnerability objects are today. It may make sense to provide a clear way to distinguish the source of manually created vulnerabilities from those caught by scanners. For instance, the source might simply be "API". Alternatively, this could be a user-provided string value as part of the manual create API(s) above such that an organization could distinguish vulnerabilities created from different sources (e.g. an internal form versus a Slack app versus a report/feed from their bug bounty program).
Permissions and Security
Documentation
This will be net new functionality so we need to clearly document the new feature including:
- The different methods for accessing and creating (in GitLab and via API)
- General workflow, specifically what happens to a newly created vulnerability
- Suggestions on best practices such as create vulnerabilities in the proper project, provide as much information during creation as possible, etc.
Availability & Testing
What does success look like, and how can we measure that?
Our internal AppSec team is able to start managing vulnerabilities manually created inside GitLab that were previously handling outside our application.