diff options
Diffstat (limited to 'doc/user/application_security/index.md')
-rw-r--r-- | doc/user/application_security/index.md | 43 |
1 files changed, 34 insertions, 9 deletions
diff --git a/doc/user/application_security/index.md b/doc/user/application_security/index.md index 0e52496ec43..e9f5898950e 100644 --- a/doc/user/application_security/index.md +++ b/doc/user/application_security/index.md @@ -57,7 +57,7 @@ This workflow comes with some drawbacks and there's a ## Interacting with the vulnerabilities -> Introduced in [GitLab Ultimate](https://about.gitlab.com/pricing) 10.8. +> Introduced in [GitLab Ultimate](https://about.gitlab.com/pricing/) 10.8. CAUTION: **Warning:** This feature is currently [Alpha](https://about.gitlab.com/handbook/product/#alpha-beta-ga) and while you can start using it, it may receive important changes in the future. @@ -84,13 +84,15 @@ If you wish to undo this dismissal, you can click the **Undo dismiss** button. #### Adding a dismissal reason -> Introduced in [GitLab Ultimate](https://about.gitlab.com/pricing) 12.0. +> Introduced in [GitLab Ultimate](https://about.gitlab.com/pricing/) 12.0. When dismissing a vulnerability, it's often helpful to provide a reason for doing so. -If you press the comment button next to **Dismiss vulnerability** in the modal, a text box will appear, allowing you to add a comment with your dismissal. -This comment can not currently be edited or removed, but [future versions](https://gitlab.com/gitlab-org/gitlab/issues/11721) will add this functionality. +If you press the comment button next to **Dismiss vulnerability** in the modal, +a text box will appear, allowing you to add a comment with your dismissal. +Once added, you can edit it or delete it. This allows you to add and update +context for a vulnerability as you learn more over time. -![Dismissed vulnerability comment](img/dismissed_info.png) +![Dismissed vulnerability comment](img/dismissed_info_v12_3.png) ### Creating an issue for a vulnerability @@ -110,7 +112,7 @@ the vulnerability will now have an associated issue next to the name. ### Solutions for vulnerabilities (auto-remediation) -> [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/5656) in [GitLab Ultimate](https://about.gitlab.com/pricing) 11.7. +> [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/5656) in [GitLab Ultimate](https://about.gitlab.com/pricing/) 11.7. Some vulnerabilities can be fixed by applying the solution that GitLab automatically generates. The following scanners are supported: @@ -134,7 +136,7 @@ generated by GitLab. To apply the fix: #### Creating a merge request from a vulnerability -> [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/9224) in [GitLab Ultimate](https://about.gitlab.com/pricing) 11.9. +> [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/9224) in [GitLab Ultimate](https://about.gitlab.com/pricing/) 11.9. In certain cases, GitLab will allow you to create a merge request that will automatically remediate the vulnerability. Any vulnerability that has a @@ -148,10 +150,10 @@ Clicking on this button will create a merge request to apply the solution onto t ## Security approvals in merge requests **(ULTIMATE)** -> [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/9928) in [GitLab Ultimate](https://about.gitlab.com/pricing) 12.2. +> [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/9928) in [GitLab Ultimate](https://about.gitlab.com/pricing/) 12.2. Merge Request Approvals can be configured to require approval from a member -of your security team when a vulnerability would be introduced by a merge request. +of your security team when a vulnerability, or a software license compliance violation would be introduced by a merge request. This threshold is defined as `high`, `critical`, or `unknown` severity. When any vulnerabilities are present within a merge request, an @@ -178,6 +180,29 @@ An approval will be optional when a security report: - Contains no new vulnerabilities. - Contains only new vulnerabilities of `low` or `medium` severity. +### Enabling License Approvals within a project + +To enable License Approvals, a [project approval rule](../project/merge_requests/merge_request_approvals.md#multiple-approval-rules-premium) +must be created with the case-sensitive name `License-Check`. This approval +group must be set with an "Approvals required" count greater than zero. + +Once this group has been added to your project, the approval rule will be enabled +for all Merge Requests. To configure how this rule behaves, you can choose which +licenses to `approve` or `blacklist` in the +[project policies for License Compliance](license_compliance/index.md#project-policies-for-license-compliance) section. + +Any code changes made will cause the count of approvals required to reset. + +An approval will be required when a license report: + +- Contains a dependency that includes a software license that is `blacklisted`. +- Is not generated during pipeline execution. + +An approval will be optional when a license report: + +- Contains no software license violations. +- Contains only new licenses that are `approved` or unknown. + <!-- ## Troubleshooting Include any troubleshooting steps that you can foresee. If you know beforehand what issues |