:information_source: Epic moved to https://gitlab.com/groups/gitlab-org/-/epics/16629+ ## Problem Vulnerabilities (the ones reported by [our analyzers](https://docs.gitlab.com/ee/user/application_security/)) are stored in the GitLab database, like other resources (Issues, Incidents, ...). There have been events in the past that [generated very large amounts of Vulnerabilities](https://gitlab.com/gitlab-com/gl-security/appsec/appsec-team/-/issues/125 "Vulnerability reports are getting out of control"), and we were [not able to delete them](https://gitlab.com/gitlab-org/gitlab/-/issues/325888#note_550081030). Vulnerabilities are the only resource at GitLab accumulating at an alarming rate without any data retention policy. Among others, we can mention: * **Jobs Artifacts** have an [expiration date](https://docs.gitlab.com/ee/ci/yaml/index.html#artifactsexpire_in). * **Container Registry Images** are [cleaned-up](https://docs.gitlab.com/ee/user/packages/container_registry/#delete-images-by-using-a-cleanup-policy) It's common in the software industry to have a data retention policy, to avoid accumulating useless data. Sentry, for example, has a [90-day retention policy](https://sentry.io/security/#data-retention). Today, there is no retention policy for GitLab vulnerabilities. At the current growth rate, we are expecting billions of vulnerability records by December 2025. <details> <summary>Current Growth Rate</summary> Refer to the internal comment [here](https://gitlab.com/groups/gitlab-org/-/epics/12114#note_1749261540) </details> ### What are the benefits of a retention policy? Adding a retention policy will reduce the size of vulnerability data which will: - Save cost on storage - Reduce query space - Minimize the need for complicated performance improvements ## Proposed Solution Create a retention policy for GitLab Vulnerabilities. - By default the retention policy is **_1 year_/12 months** - When vulnerability data has not changed within the last 12 months, it will go into cold storage/the archive. - Users have the option to configure their retention policy up to x amount of time, where 12 months is the limit for .com users to still have performant vulnerability reports on the project, group. The limit can be larger for self managed users but we will also need to consider that they will have the vulnerability report at the organization level too. - A vulnerability archive is in place and stores vulnerability data for **3 years/36 months**, which gives users the option to backup their records for auditing purposes. Users will be able to export and archive the specific vulnerabilities that have met the retention period. Vulnerability metadata (state transitions, comments, linked issues, linked MRs, etc.) will all be included in the export. - Users are alerted or notified that vulnerability records are going to be deleted. This includes a full list of what will be removed. - Vulnerabilities that have exceeded their retention period are archived on a **monthly basis**. Records are removed from the archive on a _monthly_ basis. ## How soon could we implement a retention policy? * 18.0 ## What vulnerabilities will be retained via the retention policy: - Vulnerabilities that are older than 12 months (since their initial detection/generation) but which have been updated within the past 12 months will remain in hot storage. - Vulnerabilities that are older than 12 months and which have not received any updates in the last 12 months will be archived. - Vulnerabilities in the archive will be purged after 36 months since they entered the archive.