Create security_project_refs table
In order to track vulnerabilities across multiple refs, we need to be able to store the name of the ref in the git repository that we should be tracking vulnerabilities for so that we can associate vulnerabilities for it and manage the number of refs a project is tracking.
Additionally, we need a way to limit this number by the organisation quota to avoid programmatic creation of projects and tracked refs overwhelming GitLab.com's infrastructure.
This table needs to:
- be aware of the project it is associated with
- store the context name (with a size restriction),
- store if the context is a branch or tag (as one can exist of both with the same name), or a different kind of context altogether (such as job_logs, job artifacts, environments, or something else)
- store if that ref is the default ref(branch) for the project, as this should not be removable.
The proposed schema for this table is as follows:
CREATE TABLE security_project_tracked_contexts (
id bigint NOT NULL,
project_id bigint NOT NULL,
ref_name varchar(100) NOT NULL,
context_type smallint NOT NULL default 1,
is_default bool NOT NULL default FALSE,
tracked bool NOT NULL default FALSE
);
Validations for this model are:
- Ensure that the number of tracked refs for the project do not exceed the defined constant.
- Currently we expect to set this value to 16 (the default branch plus 15 refs) based on our storage projects to ensure stability.
- Ensure that this record does not exceed the organization tracked branch quota stored in #556004
Naming
The name is security_project_refs because it may refer to refs that are not being actively tracked, but for some reason may have vulnerabilities associated with it, such a vulnerabilities created to support issue/merge request relationships.
Additionally, the tracking in this table will also define whether or not sbom dependency tracking will be done for the given ref, hence why we are not using vulnerabilities as it's top level namespace.