19 lines
1.5 KiB
YAML
19 lines
1.5 KiB
YAML
|
- name: "Vulnerability Check"
|
||
|
|
announcement_milestone: "14.8"
|
||
|
|
announcement_date: "2022-02-22"
|
||
|
|
removal_milestone: "15.0"
|
||
|
|
removal_date: "2022-05-22"
|
||
|
|
breaking_change: true
|
||
|
|
reporter: sam.white
|
||
|
|
body: | # Do not modify this line, instead modify the lines below.
|
||
|
|
The vulnerability check feature is deprecated in GitLab 14.8 and scheduled for removal in GitLab 15.0. We encourage you to migrate to the new security approvals feature instead. You can do so by navigating to **Security & Compliance > Policies** and creating a new Scan Result Policy.
|
||
|
|
|
||
|
|
The new security approvals feature is similar to vulnerability check. For example, both can require approvals for MRs that contain security vulnerabilities. However, security approvals improve the previous experience in several ways:
|
||
|
|
|
||
|
|
- Users can choose who is allowed to edit security approval rules. An independent security or compliance team can therefore manage rules in a way that prevents development project maintainers from modifying the rules.
|
||
|
|
- Multiple rules can be created and chained together to allow for filtering on different severity thresholds for each scanner type.
|
||
|
|
- A two-step approval process can be enforced for any desired changes to security approval rules.
|
||
|
|
- A single set of security policies can be applied to multiple development projects to allow for ease in maintaining a single, centralized ruleset.
|
||
|
|
# The following items are not published on the docs page, but may be used in the future.
|
||
|
|
stage: "Protect"
|