root
/
gitlab-ce
mirror of https://gitlab.com/free-releases/gitlab-ce.git
1
0
Fork 0
Code Issues Actions Packages Projects Releases Wiki Activity

Add latest changes from gitlab-org/gitlab@master

This commit is contained in:
GitLab Bot 2024-06-06 03:13:25 +00:00
parent 7d4c5ba24b
commit e058af91bb
29 changed files with 402 additions and 155 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
.gitlab/CODEOWNERS
View File

@ -1561,7 +1561,7 @@ ee/lib/ee/api/entities/project.rb
/ee/spec/frontend/remote_development/
/ee/spec/frontend/**/remote_development/
[Govern::Anti-abuse] @gitlab-org/modelops/anti-abuse
[Identity Verification] @gitlab-org/modelops/anti-abuse/identity-verification-approvers
/ee/app/controllers/users/registrations_identity_verification_controller.rb
/ee/app/controllers/users/base_identity_verification_controller.rb
/ee/app/controllers/users/identity_verification_controller.rb

9
db/docs/batched_background_migrations/backfill_dast_site_profile_secret_variables_project_id.yml Normal file
View File

@ -0,0 +1,9 @@
---
migration_job_name: BackfillDastSiteProfileSecretVariablesProjectId
description: Backfills sharding key `dast_site_profile_secret_variables.project_id` from `dast_site_profiles`.
feature_category: dynamic_application_security_testing
introduced_by_url: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/155491
milestone: '17.1'
queued_migration_version: 20240605192711
finalize_after: '2024-07-22'
finalized_by: # version of the migration that finalized this BBM

1
db/docs/dast_site_profile_secret_variables.yml
View File

@ -19,3 +19,4 @@ desired_sharding_key:
table: dast_site_profiles
sharding_key: project_id
belongs_to: dast_site_profile
desired_sharding_key_migration_job_name: BackfillDastSiteProfileSecretVariablesProjectId

3
db/docs/geo_repositories_changed_events.yml
View File

@ -1,7 +1,6 @@
---
table_name: geo_repositories_changed_events
classes:
- Geo::RepositoriesChangedEvent
classes: []
feature_categories:
- geo_replication
description: Geo event for when the repositories for selective sync of a specific

9
db/migrate/20240605192707_add_project_id_to_dast_site_profile_secret_variables.rb Normal file
View File

@ -0,0 +1,9 @@
# frozen_string_literal: true
class AddProjectIdToDastSiteProfileSecretVariables < Gitlab::Database::Migration[2.2]
milestone '17.1'
def change
add_column :dast_site_profile_secret_variables, :project_id, :bigint
end
end

16
db/post_migrate/20240605192708_index_dast_site_profile_secret_variables_on_project_id.rb Normal file
View File

@ -0,0 +1,16 @@
# frozen_string_literal: true
class IndexDastSiteProfileSecretVariablesOnProjectId < Gitlab::Database::Migration[2.2]
milestone '17.1'
disable_ddl_transaction!
INDEX_NAME = 'index_dast_site_profile_secret_variables_on_project_id'
def up
add_concurrent_index :dast_site_profile_secret_variables, :project_id, name: INDEX_NAME
end
def down
remove_concurrent_index_by_name :dast_site_profile_secret_variables, INDEX_NAME
end
end

16
db/post_migrate/20240605192709_add_dast_site_profile_secret_variables_project_id_fk.rb Normal file
View File

@ -0,0 +1,16 @@
# frozen_string_literal: true
class AddDastSiteProfileSecretVariablesProjectIdFk < Gitlab::Database::Migration[2.2]
milestone '17.1'
disable_ddl_transaction!
def up
add_concurrent_foreign_key :dast_site_profile_secret_variables, :projects, column: :project_id, on_delete: :cascade
end
def down
with_lock_retries do
remove_foreign_key :dast_site_profile_secret_variables, column: :project_id
end
end
end

25
db/post_migrate/20240605192710_add_dast_site_profile_secret_variables_project_id_trigger.rb Normal file
View File

@ -0,0 +1,25 @@
# frozen_string_literal: true
class AddDastSiteProfileSecretVariablesProjectIdTrigger < Gitlab::Database::Migration[2.2]
milestone '17.1'
def up
install_sharding_key_assignment_trigger(
table: :dast_site_profile_secret_variables,
sharding_key: :project_id,
parent_table: :dast_site_profiles,
parent_sharding_key: :project_id,
foreign_key: :dast_site_profile_id
)
end
def down
remove_sharding_key_assignment_trigger(
table: :dast_site_profile_secret_variables,
sharding_key: :project_id,
parent_table: :dast_site_profiles,
parent_sharding_key: :project_id,
foreign_key: :dast_site_profile_id
)
end
end

40
db/post_migrate/20240605192711_queue_backfill_dast_site_profile_secret_variables_project_id.rb Normal file
View File

@ -0,0 +1,40 @@
# frozen_string_literal: true
class QueueBackfillDastSiteProfileSecretVariablesProjectId < Gitlab::Database::Migration[2.2]
milestone '17.1'
restrict_gitlab_migration gitlab_schema: :gitlab_main_cell
MIGRATION = "BackfillDastSiteProfileSecretVariablesProjectId"
DELAY_INTERVAL = 2.minutes
BATCH_SIZE = 1000
SUB_BATCH_SIZE = 100
def up
queue_batched_background_migration(
MIGRATION,
:dast_site_profile_secret_variables,
:id,
:project_id,
:dast_site_profiles,
:project_id,
:dast_site_profile_id,
job_interval: DELAY_INTERVAL,
batch_size: BATCH_SIZE,
sub_batch_size: SUB_BATCH_SIZE
)
end
def down
delete_batched_background_migration(
MIGRATION,
:dast_site_profile_secret_variables,
:id,
[
:project_id,
:dast_site_profiles,
:project_id,
:dast_site_profile_id
]
)
end
end

1
db/schema_migrations/20240605192707 Normal file
View File

@ -0,0 +1 @@
14bf60483286b7b4891c55d2ddbb72a8120d8a351c08dddee73af4200b2d3c9e

1
db/schema_migrations/20240605192708 Normal file
View File

@ -0,0 +1 @@
5ec73b5b1885aa8e8a632e2b3bf81cdef6b30f355f304a440f2f8d307d760a75

1
db/schema_migrations/20240605192709 Normal file
View File

@ -0,0 +1 @@
c56ed2a52e970bdb753c6aca1d1d3e2359dd71a8e2ef1210af9b467e6d4b0dcb

1
db/schema_migrations/20240605192710 Normal file
View File

@ -0,0 +1 @@
4c140d5bc6470e3151ee6127dcaedb3065a7a62dc935c98d2ad9f8f41a0b9fdd

1
db/schema_migrations/20240605192711 Normal file
View File

@ -0,0 +1 @@
289ee43651def0f825297bd57a41e66a12868546ffcbb76314e0cfe1b1364335

24
db/structure.sql
View File

@ -790,6 +790,22 @@ BEGIN
END;
$$;
CREATE FUNCTION trigger_2514245c7fc5() RETURNS trigger
LANGUAGE plpgsql
AS $$
BEGIN
IF NEW."project_id" IS NULL THEN
SELECT "project_id"
INTO NEW."project_id"
FROM "dast_site_profiles"
WHERE "dast_site_profiles"."id" = NEW."dast_site_profile_id";
END IF;
RETURN NEW;
END
$$;
CREATE FUNCTION trigger_25c44c30884f() RETURNS trigger
LANGUAGE plpgsql
AS $$
@ -8450,6 +8466,7 @@ CREATE TABLE dast_site_profile_secret_variables (
key text NOT NULL,
encrypted_value bytea NOT NULL,
encrypted_value_iv bytea NOT NULL,
project_id bigint,
CONSTRAINT check_236213f179 CHECK ((length(encrypted_value) <= 13352)),
CONSTRAINT check_8cbef204b2 CHECK ((char_length(key) <= 255)),
CONSTRAINT check_b49080abbf CHECK ((length(encrypted_value_iv) <= 17))
@ -25896,6 +25913,8 @@ CREATE UNIQUE INDEX index_dast_scanner_profiles_on_project_id_and_name ON dast_s
CREATE INDEX index_dast_scanner_profiles_tags_on_tag_id ON dast_scanner_profiles_tags USING btree (tag_id);
CREATE INDEX index_dast_site_profile_secret_variables_on_project_id ON dast_site_profile_secret_variables USING btree (project_id);
CREATE INDEX index_dast_site_profiles_on_dast_site_id ON dast_site_profiles USING btree (dast_site_id);
CREATE UNIQUE INDEX index_dast_site_profiles_on_project_id_and_name ON dast_site_profiles USING btree (project_id, name);
@ -30520,6 +30539,8 @@ CREATE TRIGGER trigger_207005e8e995 BEFORE INSERT OR UPDATE ON operations_strate
CREATE TRIGGER trigger_2428b5519042 BEFORE INSERT OR UPDATE ON vulnerability_feedback FOR EACH ROW EXECUTE FUNCTION trigger_2428b5519042();
CREATE TRIGGER trigger_2514245c7fc5 BEFORE INSERT OR UPDATE ON dast_site_profile_secret_variables FOR EACH ROW EXECUTE FUNCTION trigger_2514245c7fc5();
CREATE TRIGGER trigger_25c44c30884f BEFORE INSERT OR UPDATE ON work_item_parent_links FOR EACH ROW EXECUTE FUNCTION trigger_25c44c30884f();
CREATE TRIGGER trigger_2ac3d66ed1d3 BEFORE INSERT OR UPDATE ON vulnerability_occurrence_pipelines FOR EACH ROW EXECUTE FUNCTION trigger_2ac3d66ed1d3();
@ -31117,6 +31138,9 @@ ALTER TABLE p_ci_builds
ALTER TABLE ONLY remote_development_agent_configs
ADD CONSTRAINT fk_6a09894a0f FOREIGN KEY (project_id) REFERENCES projects(id) ON DELETE CASCADE;
ALTER TABLE ONLY dast_site_profile_secret_variables
ADD CONSTRAINT fk_6a254b170e FOREIGN KEY (project_id) REFERENCES projects(id) ON DELETE CASCADE;
ALTER TABLE ONLY merge_requests
ADD CONSTRAINT fk_6a5165a692 FOREIGN KEY (milestone_id) REFERENCES milestones(id) ON DELETE SET NULL;

2
doc/ci/pipelines/merge_trains.md
View File

@ -252,7 +252,7 @@ See [issue 12267](https://gitlab.com/gitlab-org/gitlab/-/issues/12267) for more
### Cannot retry merge train pipeline
When a merge train pipeline fails, the merge request is dropped from the train and the pipeline can't be retried.
When a merge train pipeline fails, the merge request is dropped from the train so the pipeline can't be retried after it fails.
Merge train pipelines run on the merged result of the changes in the merge request and
changes from other merge requests already on the train. If the merge request is dropped from the train,
the merged result is out of date and the pipeline can't be retried.

2
doc/user/application_security/configuration/index.md
View File

@ -60,6 +60,8 @@ You can configure the following security controls:
- Select **Configure with a merge request** to create a merge request with the changes required to
enable Container Scanning. For more details, see
[Enable Container Scanning through an automatic merge request](../container_scanning/index.md#enable-container-scanning-through-an-automatic-merge-request).
- [Continuous Container Scanning](../container_scanning/index.md)
- Continuous container scanning runs in the registry when any image or database is updated. For more details, read [Continuous container scanning](../../../user/application_security/continuous_vulnerability_scanning/index.md#continuous-vulnerability-scanning-for-container-registry).
- [Operational Container Scanning](../../clusters/agent/vulnerabilities.md)
- Can be configured by adding a configuration block to your agent configuration. For more details, read [Operational Container Scanning](../../clusters/agent/vulnerabilities.md#enable-operational-container-scanning).
- [Secret Detection](../secret_detection/pipeline/index.md)

4
doc/user/application_security/container_scanning/index.md
View File

@ -794,6 +794,10 @@ The compressed Trivy database is stored in the `/tmp` folder of the container an
To resolve this, instead of binding the `/tmp` folder, bind specific files or folders in `/tmp` (for example `/tmp/myfile.txt`).
### Resolving `context deadline exceeded` error
This error typically occurs when scanning images containing JAR files, as it takes longer to download the `trivy-java-db` vulnerability database. To resolve this, increase the `TRIVY_TIMEOUT` environment variable to a longer duration.
## Changes
Changes to the container scanning analyzer can be found in the project's

25
doc/user/application_security/continuous_vulnerability_scanning/index.md
View File

@ -86,3 +86,28 @@ Current data sources for security advisories include:
To find a vulnerability, you can search the [`GitLab Advisory Database`](https://advisories.gitlab.com/).
You can also [submit new vulnerabilities](https://gitlab.com/gitlab-org/security-products/gemnasium-db/blob/master/CONTRIBUTING.md).
## Continuous Vulnerability Scanning For Container Registry
DETAILS:
**Tier:** Ultimate
**Offering:** GitLab.com, Self-managed, GitLab Dedicated
> - [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/2340) in GitLab 17.1 [with a flag](../../../administration/feature_flags.md) named `container_scanning_for_registry`. Disabled by default.
FLAG:
The availability of this feature is controlled by a feature flag.
For more information, see the history.
Continuous Vulnerability Scanning For Container Registry identifies security vulnerabilities in Docker images stored in the [GitLab Container Registry](../../packages/container_registry/index.md), specifically those tagged as `latest`.
When an image is pushed with the `latest` tag, a container scanning job is automatically triggered against the default branch of the project.
As security advisories are added or updated, this feature actively scans the Docker images in the Container Registry, identifies any affected images, and generates vulnerabilities in the project.
By default there is a limit of `50` scans per project per day.
### Prerequisites
- Ensure that the security configuration [Container Scanning For Registry](../configuration#security-testing) is enabled.
- The project must contain a repository. Note that if you are utilizing an empty project solely for storing container images, this feature won't function as intended. As a workaround, ensure the project has an initial commit on the default branch.

27
doc/user/application_security/dependency_scanning/index.md
View File

@ -122,7 +122,6 @@ The following languages and dependency managers are supported when using the Dep
<td>
<ul>
<li><code>go.mod</code></li>
<li><code>go.sum</code></li>
</ul>
</td>
<td>Y</td>
@ -373,19 +372,19 @@ The following package managers use lockfiles that GitLab analyzers are capable o
<td>Go</td>
<td>Not applicable</td>
<td>
<a href="https://gitlab.com/gitlab-org/security-products/analyzers/gemnasium/-/blob/master/qa/fixtures/go-modules/gosum/default/go.sum">1.x</a><sup><b><a href="#notes-regarding-parsing-lockfiles-1">1</a></b></sup>
<a href="https://gitlab.com/gitlab-org/security-products/analyzers/gemnasium/-/blob/master/qa/fixtures/go-modules/gosum/default/go.sum">1.x</a>
</td>
</tr>
<tr>
<td>NuGet</td>
<td>v1, v2<sup><b><a href="#notes-regarding-parsing-lockfiles-2">2</a></b></sup></td>
<td>v1, v2<sup><b><a href="#notes-regarding-parsing-lockfiles-1">1</a></b></sup></td>
<td>
<a href="https://gitlab.com/gitlab-org/security-products/analyzers/gemnasium/-/blob/master/qa/fixtures/csharp-nuget-dotnetcore/default/src/web.api/packages.lock.json#L2">4.9</a>
</td>
</tr>
<tr>
<td>npm</td>
<td>v1, v2, v3<sup><b><a href="#notes-regarding-parsing-lockfiles-3">3</a></b></sup></td>
<td>v1, v2, v3<sup><b><a href="#notes-regarding-parsing-lockfiles-2">2</a></b></sup></td>
<td>
<a href="https://gitlab.com/gitlab-org/security-products/analyzers/gemnasium/-/blob/master/qa/fixtures/js-npm/default/package-lock.json#L4">6.x</a>,
<a href="https://gitlab.com/gitlab-org/security-products/analyzers/gemnasium/-/blob/master/qa/fixtures/js-npm/lockfileVersion2/package-lock.json#L4">7.x</a>,
@ -403,7 +402,7 @@ The following package managers use lockfiles that GitLab analyzers are capable o
</tr>
<tr>
<td>yarn</td>
<td>versions 1, 2, 3, 4<sup><b><a href="#notes-regarding-parsing-lockfiles-4">4</a></b></sup></td>
<td>versions 1, 2, 3, 4<sup><b><a href="#notes-regarding-parsing-lockfiles-3">3</a></b></sup></td>
<td>
<a href="https://gitlab.com/gitlab-org/security-products/analyzers/gemnasium/-/blob/master/qa/fixtures/js-yarn/classic/default/yarn.lock#L2">1.x</a>,
<a href="https://gitlab.com/gitlab-org/security-products/analyzers/gemnasium/-/blob/master/qa/fixtures/js-yarn/berry/v2/default/yarn.lock">2.x</a>,
@ -424,24 +423,17 @@ The following package managers use lockfiles that GitLab analyzers are capable o
<li>
<a id="notes-regarding-parsing-lockfiles-1"></a>
<p>
Dependency Scanning only parses <code>go.sum</code> if it's unable to generate the build list
used by the Go project.
Support for NuGet version 2 lock files was <a href="https://gitlab.com/gitlab-org/gitlab/-/issues/398680">introduced</a> in GitLab 16.2.
</p>
</li>
<li>
<a id="notes-regarding-parsing-lockfiles-2"></a>
<p>
Support for NuGet version 2 lock files was <a href="https://gitlab.com/gitlab-org/gitlab/-/issues/398680">introduced</a> in GitLab 16.2.
</p>
</li>
<li>
<a id="notes-regarding-parsing-lockfiles-3"></a>
<p>
Support for <code>lockfileVersion = 3</code> was <a href="https://gitlab.com/gitlab-org/gitlab/-/issues/365176">introduced</a> in GitLab 15.7.
</p>
</li>
<li>
<a id="notes-regarding-parsing-lockfiles-4"></a>
<a id="notes-regarding-parsing-lockfiles-3"></a>
<p>
Support for Yarn version 4 was <a href="https://gitlab.com/gitlab-org/gitlab/-/issues/431752">introduced</a> in GitLab 16.11.
</p>
@ -665,8 +657,9 @@ The `gemnasium` analyzer scans supports JavaScript projects for vendored librari
#### Go
Multiple files are supported. When a `go.mod` file is detected, the analyzer attempts to generate a [build list](https://go.dev/ref/mod#glos-build-list) using
[Minimal Version Selection](https://go.dev/ref/mod#glos-minimal-version-selection). If a non-fatal error is encountered, the analyzer falls back to parsing the
available `go.sum` file. The process is repeated for every detected `go.mod` and `go.sum` file.
[Minimal Version Selection](https://go.dev/ref/mod#glos-minimal-version-selection).
As a requirement, the `go.mod` file should be cleaned up using the command `go mod tidy` to ensure proper management of dependencies. The process is repeated for every detected `go.mod` file.
#### PHP, C, C++, .NET, C&#35;, Ruby, JavaScript
@ -835,7 +828,7 @@ The following variables configure the behavior of specific dependency scanning a
| `DS_REMEDIATE` | `gemnasium` | `"true"`, `"false"` in FIPS mode | Enable automatic remediation of vulnerable dependencies. Not supported in FIPS mode. |
| `DS_REMEDIATE_TIMEOUT` | `gemnasium` | `5m` | Timeout for auto-remediation. |
| `GEMNASIUM_LIBRARY_SCAN_ENABLED` | `gemnasium` | `"true"` | Enable detecting vulnerabilities in vendored JavaScript libraries (libraries which are not managed by a package manager). This functionality requires a JavaScript lockfile to be present in a commit, otherwise Dependency Scanning is not executed and vendored files are not scanned.<br>Dependency scanning uses the [Retire.js](https://github.com/RetireJS/retire.js) scanner to detect a limited set of vulnerabilities. For details of which vulnerabilities are detected, see the [Retire.js repository](https://github.com/RetireJS/retire.js/blob/master/repository/jsrepository.json). |
| `DS_INCLUDE_DEV_DEPENDENCIES` | `gemnasium` | `"true"` | When set to `"false"`, development dependencies and their vulnerabilities are not reported. Only projects using Composer, npm, pnpm, Pipenv or Poetry are supported. [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/227861) in GitLab 15.1. |
| `DS_INCLUDE_DEV_DEPENDENCIES` | `gemnasium` | `"true"` | When set to `"false"`, development dependencies and their vulnerabilities are not reported. Only projects using Composer, Maven, npm, pnpm, Pipenv or Poetry are supported. [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/227861) in GitLab 15.1. |
| `GOOS` | `gemnasium` | `"linux"` | The operating system for which to compile Go code. |
| `GOARCH` | `gemnasium` | `"amd64"` | The architecture of the processor for which to compile Go code. |
| `GOFLAGS` | `gemnasium` | | The flags passed to the `go build` tool. |

2
doc/user/application_security/secret_detection/index.md
View File

@ -21,7 +21,7 @@ Detection scanning works on all text files, regardless of the language or framew
GitLab has two methods for detecting secrets which can be used simultaneously:
- The [pipeline](pipeline/index.md) method detects secrets during the project's CI/CD pipeline. This method cannot reject pushes.
- The [secret push protection](pre_receive/index.md) method detects secrets when users push changes to the
- The [secret push protection](secret_push_protection/index.md) method detects secrets when users push changes to the
remote Git branch. This method can reject pushes if a secret is detected.
A secret detected during a secret detection scan remains in the [vulnerability report](../vulnerability_report/index.md) as "Still detected" even after the secret is removed from the scanned file. This is because a secret remains in the Git repository's history. To address a detected secret, remediate the leak, then triage the vulnerability.

136
doc/user/application_security/secret_detection/pre_receive/index.md
View File

@ -2,142 +2,16 @@
stage: Secure
group: Secret Detection
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
remove_date: '2024-09-05'
redirect_to: '../secret_push_protection/index.md'
---
# Secret push protection
# Pre-receive secret detection (removed)
DETAILS:
**Tier:** Ultimate
**Offering:** GitLab Dedicated
**Status:** Experiment
> - [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/11439) in GitLab 16.7 as an [experiment](../../../../policy/experiment-beta-support.md) for GitLab Dedicated customers.
NOTE:
This feature is an [experiment](../../../../policy/experiment-beta-support.md), available only on
GitLab Dedicated, and is subject to the
[GitLab Testing Agreement](https://handbook.gitlab.com/handbook/legal/testing-agreement/).
On GitLab.com and GitLab self-managed, use [pipeline secret detection](../index.md) instead.
Secret push protection blocks secrets such as keys and API tokens from being pushed to GitLab.
The content of each commit is checked for secrets when pushed to GitLab. If any secrets are
detected, the push is blocked. Regardless of the Git client, GitLab prompts a message when a push is
blocked, including details of:
- Commit ID containing the secret.
- Filename and line containing the secret.
- Type of secret.
For example, the following is an extract of the message returned when a push using the Git CLI is
blocked. When using other clients, including the GitLab Web IDE, the format of the message is
different but the content is the same.
```plain
remote: PUSH BLOCKED: Secrets detected in code changes
remote: Secret push protection found the following secrets in commit: 37e54de5e78c31d9e3c3821fd15f7069e3d375b6
remote:
remote: -- test.txt:2 GitLab Personal Access Token
remote:
remote: To push your changes you must remove the identified secrets.
```
## Enable secret push protection
Prerequisites:
- You must be an administrator for your GitLab Dedicated instance.
1. Sign in to your GitLab Dedicated instance as an administrator.
1. On the left sidebar, at the bottom, select **Admin Area**.
1. Select **Settings > Security and Compliance**.
1. Expand **Secret Detection**.
1. Select the **Allow secret push protection** checkbox.
## Coverage
Secret push protection checks the content of each commit when it is pushed to GitLab.
However, the following exclusions apply.
Secret push protection does not check a file in a commit when:
- The file is a binary file.
- The file is larger than 1 MiB.
- The file was renamed, deleted, or moved without changes to the content.
- The content of the file is identical to the content of another file in the source code.
- The file is contained in the initial push that created the repository.
## Resolve a blocked push
When secret push protection blocks a push, you can either:
- [Remove the secret](#remove-the-secret)
- [Skip secret push protection](#skip-secret-push-protection)
### Remove the secret
Remove a blocked secret to allow the commit to be pushed to GitLab. The method of removing the
secret depends on how recently it was committed.
If the blocked secret was added with the most recent commit on your branch:
1. Remove the secrets from the files.
1. Stage the changes with `git add <file-name>`.
1. Modify the most recent commit to include the changed files with `git commit --amend`.
1. Push your changes with `git push`.
If the blocked secret appears earlier in your Git history:
1. Identify the commit SHA from the push error message. If there are multiple, find the earliest using `git log`.
1. Use `git rebase -i <commit-sha>~1` to start an interactive rebase.
1. Mark the offending commits for editing by changing the `pick` command to `edit` in the editor.
1. Remove the secrets from the files.
1. Stage the changes with `git add <file-name>`.
1. Commit the changed files with `git commit --amend`.
1. Continue the rebase with `git rebase --continue` until all secrets are removed.
1. Push your changes with `git push`.
### Skip secret push protection
In some cases, it may be necessary to skip secret push protection. For example, a developer may need
to commit a placeholder secret for testing, or a user may want to skip secret push protection due to
a Git operation timeout.
[Audit events](../../../compliance/audit_event_types.md#secret-detection) are logged when
secret push protection is skipped. Audit event details include:
- Skip method used.
- GitLab account name.
- Date and time at which secret push protection was skipped.
- Name of project that the secret was pushed to.
If [pipeline secret detection](../pipeline/index.md) is enabled, the content of all commits are
scanned after they are pushed to the repository.
To skip secret push protection for all commits in a push, either:
- If you're using the Git CLI client, [instruct Git to skip secret push protection](#skip-when-using-the-git-cli-client).
- If you're using any other client, [add `[skip secret detection]` to one of the commit messages](#skip-when-using-the-git-cli-client).
#### Skip when using the Git CLI client
To skip secret push protection when using the Git CLI client:
- Use the [push option](../../../project/push_options.md#push-options-for-secret-push-protection).
For example, you have several commits that are blocked from being pushed because one of them
contains a secret. To skip secret push protection, you append the push option to the Git command.
```shell
git push -o secret_detection.skip_all
```
#### Skip when using any Git client
To skip secret push protection when using any Git client:
- Add `[skip secret detection]` to one of the commit messages, on either an existing line or a new
line, then push the commits.
For example, you are using the GitLab Web IDE and have several commits that are blocked from being
pushed because one of them contains a secret. To skip secret push protection, edit the latest
commit message and add `[skip secret detection]`, then push the commits.
This feature was [renamed](https://gitlab.com/gitlab-org/gitlab/-/issues/462289) to
[secret push protection](../secret_push_protection/index.md).

143
doc/user/application_security/secret_detection/secret_push_protection/index.md Normal file
View File

@ -0,0 +1,143 @@
---
stage: Secure
group: Secret Detection
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
---
# Secret push protection
DETAILS:
**Tier:** Ultimate
**Offering:** GitLab Dedicated
**Status:** Experiment
> - [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/11439) in GitLab 16.7 as an [experiment](../../../../policy/experiment-beta-support.md) for GitLab Dedicated customers.
NOTE:
This feature is an [experiment](../../../../policy/experiment-beta-support.md), available only on
GitLab Dedicated, and is subject to the
[GitLab Testing Agreement](https://handbook.gitlab.com/handbook/legal/testing-agreement/).
On GitLab.com and GitLab self-managed, use [pipeline secret detection](../index.md) instead.
Secret push protection blocks secrets such as keys and API tokens from being pushed to GitLab.
The content of each commit is checked for secrets when pushed to GitLab. If any secrets are
detected, the push is blocked. Regardless of the Git client, GitLab prompts a message when a push is
blocked, including details of:
- Commit ID containing the secret.
- Filename and line containing the secret.
- Type of secret.
For example, the following is an extract of the message returned when a push using the Git CLI is
blocked. When using other clients, including the GitLab Web IDE, the format of the message is
different but the content is the same.
```plain
remote: PUSH BLOCKED: Secrets detected in code changes
remote: Secret push protection found the following secrets in commit: 37e54de5e78c31d9e3c3821fd15f7069e3d375b6
remote:
remote: -- test.txt:2 GitLab Personal Access Token
remote:
remote: To push your changes you must remove the identified secrets.
```
## Enable secret push protection
Prerequisites:
- You must be an administrator for your GitLab Dedicated instance.
1. Sign in to your GitLab Dedicated instance as an administrator.
1. On the left sidebar, at the bottom, select **Admin Area**.
1. Select **Settings > Security and Compliance**.
1. Expand **Secret Detection**.
1. Select the **Allow secret push protection** checkbox.
## Coverage
Secret push protection checks the content of each commit when it is pushed to GitLab.
However, the following exclusions apply.
Secret push protection does not check a file in a commit when:
- The file is a binary file.
- The file is larger than 1 MiB.
- The file was renamed, deleted, or moved without changes to the content.
- The content of the file is identical to the content of another file in the source code.
- The file is contained in the initial push that created the repository.
## Resolve a blocked push
When secret push protection blocks a push, you can either:
- [Remove the secret](#remove-the-secret)
- [Skip secret push protection](#skip-secret-push-protection)
### Remove the secret
Remove a blocked secret to allow the commit to be pushed to GitLab. The method of removing the
secret depends on how recently it was committed.
If the blocked secret was added with the most recent commit on your branch:
1. Remove the secrets from the files.
1. Stage the changes with `git add <file-name>`.
1. Modify the most recent commit to include the changed files with `git commit --amend`.
1. Push your changes with `git push`.
If the blocked secret appears earlier in your Git history:
1. Identify the commit SHA from the push error message. If there are multiple, find the earliest using `git log`.
1. Use `git rebase -i <commit-sha>~1` to start an interactive rebase.
1. Mark the offending commits for editing by changing the `pick` command to `edit` in the editor.
1. Remove the secrets from the files.
1. Stage the changes with `git add <file-name>`.
1. Commit the changed files with `git commit --amend`.
1. Continue the rebase with `git rebase --continue` until all secrets are removed.
1. Push your changes with `git push`.
### Skip secret push protection
In some cases, it may be necessary to skip secret push protection. For example, a developer may need
to commit a placeholder secret for testing, or a user may want to skip secret push protection due to
a Git operation timeout.
[Audit events](../../../compliance/audit_event_types.md#secret-detection) are logged when
secret push protection is skipped. Audit event details include:
- Skip method used.
- GitLab account name.
- Date and time at which secret push protection was skipped.
- Name of project that the secret was pushed to.
If [pipeline secret detection](../pipeline/index.md) is enabled, the content of all commits are
scanned after they are pushed to the repository.
To skip secret push protection for all commits in a push, either:
- If you're using the Git CLI client, [instruct Git to skip secret push protection](#skip-when-using-the-git-cli-client).
- If you're using any other client, [add `[skip secret detection]` to one of the commit messages](#skip-when-using-the-git-cli-client).
#### Skip when using the Git CLI client
To skip secret push protection when using the Git CLI client:
- Use the [push option](../../../project/push_options.md#push-options-for-secret-push-protection).
For example, you have several commits that are blocked from being pushed because one of them
contains a secret. To skip secret push protection, you append the push option to the Git command.
```shell
git push -o secret_detection.skip_all
```
#### Skip when using any Git client
To skip secret push protection when using any Git client:
- Add `[skip secret detection]` to one of the commit messages, on either an existing line or a new
line, then push the commits.
For example, you are using the GitLab Web IDE and have several commits that are blocked from being
pushed because one of them contains a secret. To skip secret push protection, edit the latest
commit message and add `[skip secret detection]`, then push the commits.

4
doc/user/application_security/vulnerability_report/index.md
View File

@ -187,6 +187,10 @@ When a vulnerability is dismissed, the audit log includes a note of who dismisse
dismissed, and the reason it was dismissed. You cannot delete vulnerability records, so a permanent
record always remains.
Prerequisites:
- You must have at least the Maintainer role for the project. The `admin_vulnerability` permission was [removed](https://gitlab.com/gitlab-org/gitlab/-/issues/412693) from the Developer role in GitLab 17.0.
To change the status of vulnerabilities:
1. On the left sidebar, select **Search or go to** and find your project.

2
doc/user/project/integrations/git_guardian.md
View File

@ -79,7 +79,7 @@ GitLab is now ready to reject commits based on GitGuardian policies.
You can skip GitGuardian secret detection, if needed. The options to skip
secret detection for all commits in a push are identical to the options for
[Native Secret Detection](../../application_security/secret_detection/pre_receive/index.md#skip-secret-push-protection). Either:
[Native Secret Detection](../../application_security/secret_detection/secret_push_protection/index.md#skip-secret-push-protection). Either:
- Add `[skip secret detection]` to one of the commit messages.
- Use the `secret_detection.skip_all` push option.

2
doc/user/project/push_options.md
View File

@ -69,7 +69,7 @@ Git push options can perform actions for merge requests while pushing changes:
## Push options for secret push protection
You can use push options to skip [secret push protection](../application_security/secret_detection/pre_receive/index.md).
You can use push options to skip [secret push protection](../application_security/secret_detection/secret_push_protection/index.md).
| Push option | Description | Example |
|--------------------------------|-------------|---------|

10
lib/gitlab/background_migration/backfill_dast_site_profile_secret_variables_project_id.rb Normal file
View File

@ -0,0 +1,10 @@
# frozen_string_literal: true
module Gitlab
module BackgroundMigration
class BackfillDastSiteProfileSecretVariablesProjectId < BackfillDesiredShardingKeyJob
operation_name :backfill_dast_site_profile_secret_variables_project_id
feature_category :dynamic_application_security_testing
end
end
end

15
spec/lib/gitlab/background_migration/backfill_dast_site_profile_secret_variables_project_id_spec.rb Normal file
View File

@ -0,0 +1,15 @@
# frozen_string_literal: true
require 'spec_helper'
RSpec.describe Gitlab::BackgroundMigration::BackfillDastSiteProfileSecretVariablesProjectId,
feature_category: :dynamic_application_security_testing,
schema: 20240605192707 do
include_examples 'desired sharding key backfill job' do
let(:batch_table) { :dast_site_profile_secret_variables }
let(:backfill_column) { :project_id }
let(:backfill_via_table) { :dast_site_profiles }
let(:backfill_via_column) { :project_id }
let(:backfill_via_foreign_key) { :dast_site_profile_id }
end
end

33
spec/migrations/20240605192711_queue_backfill_dast_site_profile_secret_variables_project_id_spec.rb Normal file
View File

@ -0,0 +1,33 @@
# frozen_string_literal: true
require 'spec_helper'
require_migration!
RSpec.describe QueueBackfillDastSiteProfileSecretVariablesProjectId, feature_category: :dynamic_application_security_testing do
let!(:batched_migration) { described_class::MIGRATION }
it 'schedules a new batched migration' do
reversible_migration do |migration|
migration.before -> {
expect(batched_migration).not_to have_scheduled_batched_migration
}
migration.after -> {
expect(batched_migration).to have_scheduled_batched_migration(
table_name: :dast_site_profile_secret_variables,
column_name: :id,
interval: described_class::DELAY_INTERVAL,
batch_size: described_class::BATCH_SIZE,
sub_batch_size: described_class::SUB_BATCH_SIZE,
gitlab_schema: :gitlab_main_cell,
job_arguments: [
:project_id,
:dast_site_profiles,
:project_id,
:dast_site_profile_id
]
)
}
end
end
end