Add latest changes from gitlab-org/gitlab@master
This commit is contained in:
GitLab Bot
parent
09155a460a
commit
b5cfd9e275
|
|
@ -1,5 +1,5 @@
|
|||
- title: "Container Scanning default severity threshold set to `medium`"
|
||||
removal_milestone: "Pending"
|
||||
removal_milestone: "Cancelled"
|
||||
announcement_milestone: "17.9"
|
||||
breaking_change: true
|
||||
window: 1 # Can be 1, 2, or 3 - The window when the breaking change will be deployed on GitLab.com
|
||||
|
|
|
|||
|
|
@ -8,12 +8,9 @@
|
|||
stage: Software Supply Chain Security
|
||||
issue_url: https://gitlab.com/gitlab-org/gitlab/-/issues/509578
|
||||
body: | # (required) Do not modify this line, instead modify the lines below.
|
||||
In GitLab 18.0, CI/CD job tokens will switch from a string token format to the JWT token format. This changes impacts new and existing CI/CD job tokens in all projects. If you experience issues, you can still [use the legacy format for your CI/CD tokens](https://docs.gitlab.com/ci/jobs/ci_job_token#use-legacy-format-for-cicd-tokens) until the GitLab 19.0 release.
|
||||
|
||||
In GitLab 19.0, all CI/CD job tokens must use the JWT standard. Before this release, you can temporarily revert your tokens back to the legacy job token format.
|
||||
In GitLab 19.0, CI/CD job tokens will switch from a string token format to the JWT token format. This changes impacts new and existing CI/CD job tokens in all projects. If you experience issues, you can still [use the legacy format for your CI/CD tokens](https://docs.gitlab.com/ci/jobs/ci_job_token#use-legacy-format-for-cicd-tokens) until the GitLab 20.0 release.
|
||||
|
||||
Known issues:
|
||||
|
||||
1. GitLab Runner's AWS Fargate Drive 0.5.0 and earlier is incompatible with the JWT standard. Jobs will fail with a `file name too long` error. Users of the [AWS Fargate custom executor driver](https://docs.gitlab.com/runner/configuration/runner_autoscale_aws_fargate/) must upgrade to 0.5.1 or later. For migration instructions, see [the documentation](https://gitlab.com/gitlab-org/ci-cd/custom-executor-drivers/fargate/-/tree/master/docs).
|
||||
1. The much longer JWT standard breaks the `echo $CI_JOB_TOKEN | base64` command used in some CI/CD configuration files. You can use the `echo $CI_JOB_TOKEN | base64 -w0` command instead.
|
||||
window: 2
|
||||
|
|
|
|||
|
|
@ -939,9 +939,7 @@ In other cases:
|
|||
|
||||
</div>
|
||||
|
||||
In GitLab 18.0, CI/CD job tokens will switch from a string token format to the JWT token format. This changes impacts new and existing CI/CD job tokens in all projects. If you experience issues, you can still [use the legacy format for your CI/CD tokens](https://docs.gitlab.com/ci/jobs/ci_job_token#use-legacy-format-for-cicd-tokens) until the GitLab 19.0 release.
|
||||
|
||||
In GitLab 19.0, all CI/CD job tokens must use the JWT standard. Before this release, you can temporarily revert your tokens back to the legacy job token format.
|
||||
In GitLab 19.0, CI/CD job tokens will switch from a string token format to the JWT token format. This changes impacts new and existing CI/CD job tokens in all projects. If you experience issues, you can still [use the legacy format for your CI/CD tokens](https://docs.gitlab.com/ci/jobs/ci_job_token#use-legacy-format-for-cicd-tokens) until the GitLab 20.0 release.
|
||||
|
||||
Known issues:
|
||||
|
||||
|
|
@ -7669,31 +7667,6 @@ The following changes have been removed from their original milestone and are be
|
|||
|
||||
<div class="deprecation breaking-change">
|
||||
|
||||
### Container Scanning default severity threshold set to `medium`
|
||||
|
||||
<div class="deprecation-notes">
|
||||
|
||||
- Announced in GitLab <span class="milestone">17.9</span>
|
||||
- To discuss this change or learn more, see the [deprecation issue](https://gitlab.com/gitlab-org/gitlab/-/issues/515358).
|
||||
|
||||
</div>
|
||||
{{< alert type="note" >}}
|
||||
|
||||
This change has been removed from its original milestone and is being reassessed.
|
||||
|
||||
{{< /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.
|
||||
|
||||
</div>
|
||||
|
||||
<div class="deprecation breaking-change">
|
||||
|
||||
### GitLab.com certificate-based integration with Kubernetes
|
||||
|
||||
<div class="deprecation-notes">
|
||||
|
|
@ -8073,6 +8046,31 @@ The following changes have been cancelled.
|
|||
|
||||
<div class="deprecation breaking-change">
|
||||
|
||||
### Container Scanning default severity threshold set to `medium`
|
||||
|
||||
<div class="deprecation-notes">
|
||||
|
||||
- Announced in GitLab <span class="milestone">17.9</span>
|
||||
- To discuss this change or learn more, see the [deprecation issue](https://gitlab.com/gitlab-org/gitlab/-/issues/515358).
|
||||
|
||||
</div>
|
||||
{{< 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.
|
||||
|
||||
</div>
|
||||
|
||||
<div class="deprecation breaking-change">
|
||||
|
||||
### Deprecate License Scanning CI/CD artifact report type
|
||||
|
||||
<div class="deprecation-notes">
|
||||
|
|
|
|||
|
|
@ -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:`.
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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:
|
||||
|
|
|
|||
|
|
@ -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
|
||||
Loading…
Reference in New Issue