Add "source" attribute to vulnerability records
Problem to solve
We have expanded the methods for getting vulnerability data into GitLab beyond scanners running in pipeline jobs. For instance, you can manually create records via API and soon will be able to continuously scan container registries. This means that the same type of scan (e.x. Container scanning) can have results from multiple different origins/sources. Without a way to distinguish the source, it will be less clear to the user where a given result originated. This, in turn, can make it harder to understand where a vulnerability exits and how best to remediate it.
Proposal
Add a new "origin" or "source" attribute for vulnerability records. This new attribute in combination with the existing scan type data can be used to more precisely determine exactly where a vulnerability exists/was detected. This new attribute needs to at minimum be supported by:
- All security report schemas (possibly by adding to base schema)
- The GitLab Rails monolith for schema parsing
- All relevant GraphQL queries/mutations/connections including the manual vulnerability creation mutation
- The GitLab UI:
- Vulnerability details pages
- Manual vulnerability creation form (by setting origin either automatically to "generic" or letting user chose)
- The CSV export report on the Vulnerability Reports
The new attribute should likely be an ENUM and not free text. This will help keep the "source" values consistent for future use cases like filtering in Vulnerability Reports or fetching vulnerability data via GraphQL. To start, the proposed sources are:
- Pipeline
- API
- Manual (this is the
Submit vulnerabilityform) - Registry (previously called "Continuous")
- Operational (running environment or production environment)
To make this addition backward-compatible, the new "source" field must be optional from the input side (security report schemas, and APIs). A default value of pipeline must be used at the data layer when it unspecified in the input.