+### Container Scanning default severity threshold set to `medium`
+
+
+
+- Announced in GitLab 17.9
+- To discuss this change or learn more, see the [deprecation issue](https://gitlab.com/gitlab-org/gitlab/-/issues/515358).
+
+
+{{< alert type="note" >}}
+
+This change has been cancelled.
+
+{{< /alert >}}
+
+The Container Scanning security feature generates a lot of security findings and this volume is often difficult for engineering teams to manage.
+By changing the severity threshold to `medium`, we provide a more reasonable default to our users, where any findings with a severity below `medium` are not reported.
+Starting with GitLab 18.0, the default value for the `CS_SEVERITY_THRESHOLD` environment variable is set to `medium` instead of `unknown`. As a result, the security findings with the `low` and `unknown`
+severity levels will no longer be reported by default. Consequently, any vulnerablity with these severities that were previously reported on the default branch will be marked as no longer detected
+upon the next execution of Container Scanning.
+To continue showing these findings, you must configure the `CS_SEVERITY_THRESHOLD` variable to the desired level.
+
+
+
### Deprecate License Scanning CI/CD artifact report type
diff --git a/doc/user/emoji_reactions.md b/doc/user/emoji_reactions.md
index 8d54cf9b885..d0f96736486 100644
--- a/doc/user/emoji_reactions.md
+++ b/doc/user/emoji_reactions.md
@@ -30,7 +30,7 @@ and thumbs-ups. React with emoji on:
- [Objectives and key results](okrs.md).
- Anywhere else you can have a comment thread.
-
+
Emoji reactions make it much easier to give and receive feedback without a long
comment thread.
@@ -72,7 +72,7 @@ To add an emoji reaction to a comment or description:
1. Select the GitLab logo ({{< icon name="tanuki" >}}) or scroll down to the **Custom** section.
1. Select an emoji from the emoji picker.
-
+
To use them in a text box, type the filename between two colons.
For example, `:thank-you:`.
diff --git a/lib/gitlab/ci/templates/Jobs/Container-Scanning.gitlab-ci.yml b/lib/gitlab/ci/templates/Jobs/Container-Scanning.gitlab-ci.yml
index 5d2d6359fc7..46ca80da812 100644
--- a/lib/gitlab/ci/templates/Jobs/Container-Scanning.gitlab-ci.yml
+++ b/lib/gitlab/ci/templates/Jobs/Container-Scanning.gitlab-ci.yml
@@ -48,34 +48,9 @@ container_scanning:
rules:
- if: $CONTAINER_SCANNING_DISABLED == 'true' || $CONTAINER_SCANNING_DISABLED == '1'
when: never
-
- # The following 3 blocks of rules define whether the job runs in a an *MR pipeline* or a *branch pipeline*
- # when an MR exists. If the job has additional rules to observe they should be added in the blocks 1 and 3
- # to cover both the *MR pipeline* and the *branch pipeline* workflows.
-
- # 1. Run the job in an *MR pipeline* if MR pipelines for AST are enabled and there's an open merge request.
- ## When FIPS mode is enabled, use the FIPS compatible image
- - if: $AST_ENABLE_MR_PIPELINES == "true" &&
- $CI_PIPELINE_SOURCE == "merge_request_event" &&
- $CI_GITLAB_FIPS_MODE == "true" &&
- $CS_ANALYZER_IMAGE !~ /-(fips|ubi)\z/
- variables:
- CS_IMAGE_SUFFIX: -fips
- ## When FIPS mode is not enabled, use the regular image
- - if: $AST_ENABLE_MR_PIPELINES == "true" &&
- $CI_PIPELINE_SOURCE == "merge_request_event"
-
- # 2. Don't run the job in a *branch pipeline* if *MR pipelines* for AST are enabled and there's an open merge request.
- - if: $AST_ENABLE_MR_PIPELINES == "true" &&
- $CI_OPEN_MERGE_REQUESTS
- when: never
-
- # 3. Finally, run the job in a *branch pipeline* (When MR pipelines are disabled for AST, or it is enabled but no open MRs exist for the branch).
- ## When FIPS mode is enabled, use the FIPS compatible image
- if: $CI_COMMIT_BRANCH &&
$CI_GITLAB_FIPS_MODE == "true" &&
$CS_ANALYZER_IMAGE !~ /-(fips|ubi)\z/
variables:
CS_IMAGE_SUFFIX: -fips
- ## When FIPS mode is not enabled, use the regular image
- if: $CI_COMMIT_BRANCH
diff --git a/lib/gitlab/ci/templates/Jobs/Container-Scanning.latest.gitlab-ci.yml b/lib/gitlab/ci/templates/Jobs/Container-Scanning.latest.gitlab-ci.yml
index cdbf372638b..55902c66f2a 100644
--- a/lib/gitlab/ci/templates/Jobs/Container-Scanning.latest.gitlab-ci.yml
+++ b/lib/gitlab/ci/templates/Jobs/Container-Scanning.latest.gitlab-ci.yml
@@ -26,10 +26,6 @@
# List of available variables: https://docs.gitlab.com/ee/user/application_security/container_scanning/#available-variables
variables:
- # Setting this variable affects all Security templates
- # (SAST, Dependency Scanning, ...)
- AST_ENABLE_MR_PIPELINES: "true"
- #
CS_ANALYZER_IMAGE: "$CI_TEMPLATE_REGISTRY_HOST/security-products/container-scanning:7"
CS_SCHEMA_MODEL: 15
@@ -58,35 +54,24 @@ variables:
- if: $CONTAINER_SCANNING_DISABLED == 'true' || $CONTAINER_SCANNING_DISABLED == '1'
when: never
- # The following 3 blocks of rules define whether the job runs in a an *MR pipeline* or a *branch pipeline*
- # when an MR exists. If the job has additional rules to observe they should be added in the blocks 1 and 3
- # to cover both the *MR pipeline* and the *branch pipeline* workflows.
-
- # 1. Run the job in an *MR pipeline* if MR pipelines for AST are enabled and there's an open merge request.
- ## When FIPS mode is enabled, use the FIPS compatible image
- - if: $AST_ENABLE_MR_PIPELINES == "true" &&
- $CI_PIPELINE_SOURCE == "merge_request_event" &&
+ # Add the job to merge request pipelines if there's an open merge request.
+ - if: $CI_PIPELINE_SOURCE == "merge_request_event" &&
$CI_GITLAB_FIPS_MODE == "true" &&
$CS_ANALYZER_IMAGE !~ /-(fips|ubi)\z/
variables:
CS_IMAGE_SUFFIX: -fips
- ## When FIPS mode is not enabled, use the regular image
- - if: $AST_ENABLE_MR_PIPELINES == "true" &&
- $CI_PIPELINE_SOURCE == "merge_request_event"
+ - if: $CI_PIPELINE_SOURCE == "merge_request_event"
- # 2. Don't run the job in a *branch pipeline* if *MR pipelines* for AST are enabled and there's an open merge request.
- - if: $AST_ENABLE_MR_PIPELINES == "true" &&
- $CI_OPEN_MERGE_REQUESTS
+ # Don't add it to a *branch* pipeline if it's already in a merge request pipeline.
+ - if: $CI_OPEN_MERGE_REQUESTS
when: never
- # 3. Finally, run the job in a *branch pipeline* (When MR pipelines are disabled for AST, or it is enabled but no open MRs exist for the branch).
- ## When FIPS mode is enabled, use the FIPS compatible image
+ # Add the job to branch pipelines.
- if: $CI_COMMIT_BRANCH &&
$CI_GITLAB_FIPS_MODE == "true" &&
$CS_ANALYZER_IMAGE !~ /-(fips|ubi)\z/
variables:
CS_IMAGE_SUFFIX: -fips
- ## When FIPS mode is not enabled, use the regular image
- if: $CI_COMMIT_BRANCH
container_scanning:
diff --git a/spec/support/shared_examples/lib/gitlab/template/ast_templates_shared_examples.rb b/spec/support/shared_examples/lib/gitlab/template/ast_templates_shared_examples.rb
deleted file mode 100644
index a4a1fdf0f31..00000000000
--- a/spec/support/shared_examples/lib/gitlab/template/ast_templates_shared_examples.rb
+++ /dev/null
@@ -1,131 +0,0 @@
-# frozen_string_literal: true
-
-require 'spec_helper'
-
-# These shared_contexts and shared_examples are used to test the # CI/CD templates
-# powering the Application Security Testing (AST) features.
-# There is a lot of repitition across these templates and the setup for these
-# specs is expensive.
-#
-# Usually, each template will have its behavior tested in these 3 different pipelines types:
-# - default branch pipeline
-# - feature branch pipeline
-# - MR pipeline
-#
-# Additionally, some templates have CI jobs using rules:exists which involves setting up
-# a project with a repository that contains specific files. To improve speed and
-# efficiency, the setup steps are extracted into shared_context that use let_it_be and
-# before(:context). This ensures to create the project only once per scenario.
-# Though these contexts assume a particular usage which reduces flexibility.
-# Please check existing specs for examples.
-
-RSpec.shared_context 'with CI variables' do |variables|
- before do
- variables.each do |(key, value)|
- create(:ci_variable, project: project, key: key, value: value)
- end
- end
-end
-
-RSpec.shared_context 'with default branch pipeline setup' do
- let_it_be(:pipeline_branch) { default_branch }
- let_it_be(:service) { Ci::CreatePipelineService.new(project, user, ref: pipeline_branch) }
-end
-
-RSpec.shared_context 'with feature branch pipeline setup' do
- let_it_be(:pipeline_branch) { feature_branch }
- let_it_be(:service) { Ci::CreatePipelineService.new(project, user, ref: pipeline_branch) }
-
- before(:context) do
- project.repository.create_file(
- project.creator,
- 'branch.patch',
- '',
- message: "Add file to feature branch",
- branch_name: pipeline_branch,
- # Ensure new branch includes expected project files from default branch.
- start_branch_name: default_branch)
- end
-end
-
-RSpec.shared_context 'with MR pipeline setup' do
- let_it_be(:pipeline_branch) { 'mr_branch' }
- let_it_be(:service) { MergeRequests::CreatePipelineService.new(project: project, current_user: user) }
-
- let(:pipeline) { service.execute(merge_request).payload }
-
- let_it_be(:merge_request) do
- # Ensure MR has at least one commit otherwise MR pipeline won't be triggered.
- # This also seems to be required to happen before the MR creation.
- project.repository.create_file(
- project.creator,
- 'MR.patch',
- '',
- message: "Add patch to MR branch",
- branch_name: pipeline_branch,
- # Ensure new branch includes expected project files from default branch.
- start_branch_name: default_branch)
-
- create(:merge_request,
- source_project: project,
- source_branch: pipeline_branch,
- target_project: project,
- target_branch: default_branch)
- end
-end
-
-RSpec.shared_examples 'has expected jobs' do |jobs|
- it 'includes jobs', if: jobs.any? do
- expect(pipeline.builds.pluck(:name)).to match_array(jobs)
- # TODO: Failing for DAST related templates with error:
- # "Insufficient permissions for dast_configuration keyword"
- # expect(pipeline.errors.full_messages).to be_empty unless ignore_errors
- end
-
- it 'includes no jobs', if: jobs.empty? do
- expect(pipeline.builds.pluck(:name)).to be_empty
- expect(pipeline.errors.full_messages).to match_array(
- [sanitize_message(Ci::Pipeline.rules_failure_message)])
- end
-end
-
-RSpec.shared_examples 'has FIPS compatible jobs' do |variable, jobs|
- context 'when CI_GITLAB_FIPS_MODE=false', fips_mode: false do
- jobs.each do |job|
- it "sets #{variable} to '' for job #{job}" do
- build = pipeline.builds.find_by(name: job)
- expect(String(build.variables.to_hash[variable])).to eql('')
- end
- end
- end
-
- context 'when CI_GITLAB_FIPS_MODE=true', :fips_mode do
- jobs.each do |job|
- it "sets #{variable} to '-fips' for job #{job}" do
- build = pipeline.builds.find_by(name: job)
- expect(String(build.variables.to_hash[variable])).to eql('-fips')
- end
- end
- end
-end
-
-RSpec.shared_examples 'has jobs that can be disabled' do |key, disabled_values, jobs|
- disabled_values.each do |disabled_value|
- context "when #{key} is set to '#{disabled_value}'" do
- before do
- create(:ci_variable, project: project, key: key, value: disabled_value)
- end
-
- include_examples 'has expected jobs', []
- end
- end
-
- # This ensures we don't accidentally disable jobs when user sets the variable to 'false'.
- context "when #{key} is set to 'false'" do
- before do
- create(:ci_variable, project: project, key: key, value: 'false')
- end
-
- include_examples 'has expected jobs', jobs
- end
-end