diff options
Diffstat (limited to 'doc/user/application_security')
| -rw-r--r-- | doc/user/application_security/policies/img/experimental-features-policies.png | bin | 0 -> 213749 bytes | |||
| -rw-r--r-- | doc/user/application_security/policies/scan-execution-policies.md | 24 | ||||
| -rw-r--r-- | doc/user/application_security/policies/scan-result-policies.md | 22 |
3 files changed, 12 insertions, 34 deletions
diff --git a/doc/user/application_security/policies/img/experimental-features-policies.png b/doc/user/application_security/policies/img/experimental-features-policies.png Binary files differnew file mode 100644 index 00000000000..5d1ecd0b80a --- /dev/null +++ b/doc/user/application_security/policies/img/experimental-features-policies.png diff --git a/doc/user/application_security/policies/scan-execution-policies.md b/doc/user/application_security/policies/scan-execution-policies.md index 9a6f7581876..26a98432d47 100644 --- a/doc/user/application_security/policies/scan-execution-policies.md +++ b/doc/user/application_security/policies/scan-execution-policies.md @@ -12,11 +12,6 @@ info: To determine the technical writer assigned to the Stage/Group associated w > - Support for custom CI variables in the Scan Execution Policies editor [introduced](https://gitlab.com/groups/gitlab-org/-/epics/9566) in GitLab 16.2. > - Enforcement of scan execution policies on projects with an existing GitLab CI/CD configuration [introduced](https://gitlab.com/groups/gitlab-org/-/epics/6880) in GitLab 16.2 [with a flag](../../../administration/feature_flags.md) named `scan_execution_policy_pipelines`. Feature flag `scan_execution_policy_pipelines` removed in GitLab 16.5. -FLAG: -On self-managed GitLab, this feature is enabled by default. To disable it, ask an -administrator to [disable the feature flag](../../../administration/feature_flags.md) named -`scan_execution_policy_pipelines`. On GitLab.com, this feature is enabled. - Group, subgroup, or project owners can use scan execution policies to require that security scans run on a specified schedule or with the project pipeline. The security scan runs with multiple project pipelines if you define the policy at a group or subgroup level. GitLab injects the required @@ -331,14 +326,13 @@ These experimental features have limitations: without a `.gitlab-ci.yml` is not supported. 1. The pipeline execution action cannot be used with a scheduled trigger type. -### Pipeline execution policy action +To enable these experimental features, a Group owner or administrator must toggle the experimental features by visiting `Settings > General > Permissions and group features`. -> The `custom` scan action type was [introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/126457) in GitLab 16.4 [with a flag](../../../administration/feature_flags.md) named `compliance_pipeline_in_policies`. + + +Have feedback on our experimental features? We'd love to hear it! Please share your thoughts in our [feedback issue](https://gitlab.com/gitlab-org/gitlab/-/issues/434425). -FLAG: -On self-managed GitLab, by default this feature is available. -To hide the feature, an administrator can [disable the feature flag](../../../administration/feature_flags.md) named `compliance_pipeline_in_policies`. -On GitLab.com, this feature is available. +### Pipeline execution policy action The pipeline execution policy action introduces a new scan action type into scan execution policies for creating and enforcing custom CI in your target @@ -402,14 +396,6 @@ In this example a `test job` is injected into the `test` stage of the pipeline, ### Security policy scopes -> The `policy_scope` field was [introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/135398) in GitLab 16.7 [with a flag](../../../administration/feature_flags.md) named `security_policies_policy_scope`. - -FLAG: -On self-managed GitLab, by default this feature is available. To hide the feature, -an administrator can [disable the feature flag](../../../administration/feature_flags.md) -named `security_policies_policy_scope`. -On GitLab.com, this feature is available. - Security policy enforcement depends first on establishing a link between the group, subgroup, or project on which you want to enforce policies, and the security policy project that contains the policies. For example, if you are linking policies to a group, a group owner must create the link to diff --git a/doc/user/application_security/policies/scan-result-policies.md b/doc/user/application_security/policies/scan-result-policies.md index c91b21cae69..5e1541ce536 100644 --- a/doc/user/application_security/policies/scan-result-policies.md +++ b/doc/user/application_security/policies/scan-result-policies.md @@ -361,16 +361,13 @@ We have identified in [epic 11020](https://gitlab.com/groups/gitlab-org/-/epics/ ### Security policy scopes -> The `policy_scope` field was [introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/135398) in GitLab 16.7 [with a flag](../../../administration/feature_flags.md) named `security_policies_policy_scope`. +To enable these experimental features, a Group owner or administrator must toggle the experimental features by visiting `Settings > General > Permissions and group features`. -FLAG: -On self-managed GitLab, by default this feature is available. To hide the feature, -an administrator can [disable the feature flag](../../../administration/feature_flags.md) -named `security_policies_policy_scope`. -On GitLab.com, this feature is available. + + +Have feedback on our experimental features? We'd love to hear it! Please share your thoughts in our [feedback issue](https://gitlab.com/gitlab-org/gitlab/-/issues/434425). -Security policy enforcement depends first on establishing a link between the group, subgroup, or -project on which you want to enforce policies, and the security policy project that contains the +Security policy enforcement depends first on establishing a link between the group, subgroup, or project on which you want to enforce policies, and the security policy project that contains the policies. For example, if you are linking policies to a group, a group owner must create the link to the security policy project. Then, all policies in the security policy project are inherited by all projects in the group. @@ -433,14 +430,9 @@ scan_result_policy: ### Merge request rules widget shows a scan result policy is invalid or duplicated **(ULTIMATE SELF)** -On GitLab self-managed from 15.0 to 16.4, the most likely cause is that the project was exported from a -group and imported into another, and had scan result policy rules. These rules are stored in a -separate project to the one that was exported. As a result, the project contains policy rules that -reference entities that don't exist in the imported project's group. The result is policy rules that -are invalid, duplicated, or both. +On GitLab self-managed from 15.0 to 16.4, the most likely cause is that the project was exported from a group and imported into another, and had scan result policy rules. These rules are stored in a separate project to the one that was exported. As a result, the project contains policy rules that reference entities that don't exist in the imported project's group. The result is policy rules that are invalid, duplicated, or both. -To remove all invalid scan result policy rules from a GitLab instance, an administrator can run -the following script in the [Rails console](../../../administration/operations/rails_console.md). +To remove all invalid scan result policy rules from a GitLab instance, an administrator can run the following script in the [Rails console](../../../administration/operations/rails_console.md). ```ruby Project.joins(:approval_rules).where(approval_rules: { report_type: %i[scan_finding license_scanning] }).where.not(approval_rules: { security_orchestration_policy_configuration_id: nil }).find_in_batches.flat_map do |batch| |
