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 2025-03-04 00:11:02 +00:00
parent 110fa7ec9a
commit 26fa455204
37 changed files with 1101 additions and 836 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
app/assets/javascripts/integrations/constants.js
View File

@ -37,6 +37,7 @@ export const integrationFormSections = {
GOOGLE_PLAY: 'google_play',
GOOGLE_ARTIFACT_MANAGEMENT: 'google_artifact_management',
GOOGLE_CLOUD_IAM: 'google_cloud_iam',
AMAZON_Q: 'amazon_q',
};
export const integrationFormSectionComponents = {
@ -51,6 +52,7 @@ export const integrationFormSectionComponents = {
[integrationFormSections.GOOGLE_ARTIFACT_MANAGEMENT]:
'IntegrationSectionGoogleArtifactManagement',
[integrationFormSections.GOOGLE_CLOUD_IAM]: 'IntegrationSectionGoogleCloudIAM',
[integrationFormSections.AMAZON_Q]: 'IntegrationSectionAmazonQ',
};
export const integrationTriggerEvents = {

4
app/assets/javascripts/integrations/edit/components/integration_forms/section.vue
View File

@ -51,6 +51,10 @@ export default {
import(
/* webpackChunkName: 'IntegrationSectionGoogleCloudIAM' */ 'ee_component/integrations/edit/components/sections/google_cloud_iam.vue'
),
IntegrationSectionAmazonQ: () =>
import(
/* webpackChunkName: 'IntegrationSectionAmazonQ' */ 'ee_component/integrations/edit/components/sections/amazon_q.vue'
),
},
directives: {
SafeHtml,

18
app/assets/javascripts/integrations/edit/index.js
View File

@ -43,6 +43,13 @@ function parseDatasetToProps(data) {
workloadIdentityFederationProjectNumber,
workloadIdentityPoolId,
wlifIssuer,
amazonQSubmitUrl,
amazonQDisconnectUrl,
amazonQRoleArn,
amazonQAvailability,
amazonQInstanceUid,
amazonQAwsProviderUrl,
amazonQAwsAudience,
jwtClaims,
redirectTo,
upgradeSlackUrl,
@ -64,6 +71,7 @@ function parseDatasetToProps(data) {
enableJiraVulnerabilities,
shouldUpgradeSlack,
customizeJiraIssueEnabled,
amazonQReady,
} = parseBooleanInData(booleanAttributes);
return {
@ -102,6 +110,16 @@ function parseDatasetToProps(data) {
workloadIdentityFederationProjectNumber,
workloadIdentityPoolId,
},
amazonQProps: {
amazonQSubmitUrl,
amazonQDisconnectUrl,
amazonQReady,
amazonQRoleArn,
amazonQAvailability,
amazonQInstanceUid,
amazonQAwsProviderUrl,
amazonQAwsAudience,
},
learnMorePath,
aboutPricingUrl,
triggerEvents: JSON.parse(triggerEvents),

14
app/graphql/types/work_item_type.rb
View File

@ -60,7 +60,19 @@ module Types
field :widgets,
[Types::WorkItems::WidgetInterface],
null: true,
description: 'Collection of widgets that belong to the work item.'
description: 'Collection of widgets that belong to the work item.' do
argument :except_types, [::Types::WorkItems::WidgetTypeEnum],
required: false,
default_value: nil,
description: 'Except widgets of the given types.'
argument :only_types, [::Types::WorkItems::WidgetTypeEnum],
required: false,
default_value: nil,
description: 'Only widgets of the given types.'
validates mutually_exclusive: %i[except_types only_types]
end
field :work_item_type, Types::WorkItems::TypeType, null: false,
description: 'Type assigned to the work item.'

31
app/models/work_item.rb
View File

@ -146,10 +146,17 @@ class WorkItem < Issue
%w[Issue WorkItem]
end
def widgets
strong_memoize(:widgets) do
work_item_type.widgets(resource_parent).map do |widget_definition|
widget_definition.widget_class.new(self, widget_definition: widget_definition)
def widgets(except_types: [], only_types: nil)
raise ArgumentError, 'Only one filter is allowed' if only_types.present? && except_types.present?
strong_memoize_with(:widgets, only_types, except_types) do
except_types = Array.wrap(except_types)
widget_definitions.keys.filter_map do |type|
next if except_types.include?(type)
next if only_types&.exclude?(type)
get_widget(type)
end
end
end
@ -157,13 +164,21 @@ class WorkItem < Issue
# Returns widget object if available
# type parameter can be a symbol, for example, `:description`.
def get_widget(type)
widgets.find do |widget|
widget.instance_of?(WorkItems::Widgets.const_get(type.to_s.camelize, false))
strong_memoize_with(type) do
break unless widget_definitions.key?(type.to_sym)
widget_definitions[type].build_widget(self)
end
rescue NameError
nil
end
def widget_definitions
work_item_type
.widgets(resource_parent)
.index_by(&:widget_type)
.symbolize_keys
end
strong_memoize_attr :widget_definitions
def ancestors
hierarchy.ancestors(hierarchy_order: :asc)
end

4
app/models/work_items/widget_definition.rb
View File

@ -69,5 +69,9 @@ module WorkItems
rescue NameError
nil
end
def build_widget(work_item)
widget_class.new(work_item, widget_definition: self)
end
end
end

9
config/feature_flags/beta/summarize_merge_request_claude_3_7_sonnet.yml Normal file
View File

@ -0,0 +1,9 @@
---
name: summarize_merge_request_claude_3_7_sonnet
feature_issue_url: https://gitlab.com/gitlab-org/gitlab/-/issues/521400
introduced_by_url: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/182958
rollout_issue_url: https://gitlab.com/gitlab-org/gitlab/-/issues/521699
milestone: '17.10'
group: group::code review
type: beta
default_enabled: false

4
config/gitlab_loose_foreign_keys.yml
View File

@ -320,6 +320,10 @@ external_pull_requests:
- table: projects
column: project_id
on_delete: async_delete
fork_networks:
- table: organizations
column: organization_id
on_delete: async_delete
group_security_exclusions:
- table: namespaces
column: group_id

12
db/docs/merge_request_reviewers.yml
View File

@ -8,14 +8,6 @@ description: Store allocated reviewers for merge requests
introduced_by_url: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/40358
milestone: '13.4'
gitlab_schema: gitlab_main_cell
desired_sharding_key:
project_id:
references: projects
backfill_via:
parent:
foreign_key: merge_request_id
table: merge_requests
sharding_key: target_project_id
belongs_to: merge_request
desired_sharding_key_migration_job_name: BackfillMergeRequestReviewersProjectId
table_size: medium
sharding_key:
project_id: projects

11
db/migrate/20250227095537_add_organization_id_to_fork_networks.rb Normal file
View File

@ -0,0 +1,11 @@
# frozen_string_literal: true
class AddOrganizationIdToForkNetworks < Gitlab::Database::Migration[2.2]
milestone '17.10'
enable_lock_retries!
def change
add_column :fork_networks, :organization_id, :bigint, null: true
end
end

13
db/post_migrate/20250225075411_validate_merge_request_reviewers_project_id_not_null.rb Normal file
View File

@ -0,0 +1,13 @@
# frozen_string_literal: true
class ValidateMergeRequestReviewersProjectIdNotNull < Gitlab::Database::Migration[2.2]
milestone '17.10'
def up
validate_not_null_constraint :merge_request_reviewers, :project_id, constraint_name: 'check_fb72c99774'
end
def down
# no-op
end
end

18
db/post_migrate/20250227102407_add_index_for_organization_id_on_fork_networks.rb Normal file
View File

@ -0,0 +1,18 @@
# frozen_string_literal: true
class AddIndexForOrganizationIdOnForkNetworks < Gitlab::Database::Migration[2.2]
milestone '17.10'
disable_ddl_transaction!
TABLE_NAME = :fork_networks
INDEX_NAME = 'index_fork_networks_on_organization_id'
def up
add_concurrent_index TABLE_NAME, :organization_id, name: INDEX_NAME
end
def down
remove_concurrent_index_by_name TABLE_NAME, INDEX_NAME
end
end

1
db/schema_migrations/20250225075411 Normal file
View File

@ -0,0 +1 @@
35a1734f39a9083879dd1850b1b7b77e4c5993d40ce5c52ad4ed26fe83ca74cc

1
db/schema_migrations/20250227095537 Normal file
View File

@ -0,0 +1 @@
d211433f7c46ddcf0a85d912b4dbab58af583174415e0a16705087b4d55732f0

1
db/schema_migrations/20250227102407 Normal file
View File

@ -0,0 +1 @@
87839950df3e95155710d1572c04ff199557d3feffb6ff9d172521ad9fd7572d

11
db/structure.sql
View File

@ -13822,7 +13822,8 @@ ALTER SEQUENCE fork_network_members_id_seq OWNED BY fork_network_members.id;
CREATE TABLE fork_networks (
id bigint NOT NULL,
root_project_id bigint,
deleted_root_project_name character varying
deleted_root_project_name character varying,
organization_id bigint
);
CREATE SEQUENCE fork_networks_id_seq
@ -16286,7 +16287,8 @@ CREATE TABLE merge_request_reviewers (
merge_request_id bigint NOT NULL,
created_at timestamp with time zone NOT NULL,
state smallint DEFAULT 0 NOT NULL,
project_id bigint
project_id bigint,
CONSTRAINT check_fb72c99774 CHECK ((project_id IS NOT NULL))
);
CREATE SEQUENCE merge_request_reviewers_id_seq
@ -27415,9 +27417,6 @@ ALTER TABLE web_hook_logs
ALTER TABLE projects
ADD CONSTRAINT check_fa75869cb1 CHECK ((project_namespace_id IS NOT NULL)) NOT VALID;
ALTER TABLE merge_request_reviewers
ADD CONSTRAINT check_fb72c99774 CHECK ((project_id IS NOT NULL)) NOT VALID;
ALTER TABLE ONLY ci_build_needs
ADD CONSTRAINT ci_build_needs_pkey PRIMARY KEY (id);
@ -33125,6 +33124,8 @@ CREATE INDEX index_fork_network_members_on_forked_from_project_id ON fork_networ
CREATE UNIQUE INDEX index_fork_network_members_on_project_id ON fork_network_members USING btree (project_id);
CREATE INDEX index_fork_networks_on_organization_id ON fork_networks USING btree (organization_id);
CREATE UNIQUE INDEX index_fork_networks_on_root_project_id ON fork_networks USING btree (root_project_id);
CREATE INDEX index_geo_event_log_on_cache_invalidation_event_id ON geo_event_log USING btree (cache_invalidation_event_id) WHERE (cache_invalidation_event_id IS NOT NULL);

14
doc/api/graphql/reference/_index.md
View File

@ -39583,7 +39583,6 @@ four standard [pagination arguments](#pagination-arguments):
| <a id="workitemuserdiscussionscount"></a>`userDiscussionsCount` | [`Int!`](#int) | Number of user discussions in the work item. |
| <a id="workitemuserpermissions"></a>`userPermissions` | [`WorkItemPermissions!`](#workitempermissions) | Permissions for the current user on the resource. |
| <a id="workitemweburl"></a>`webUrl` | [`String`](#string) | URL of this object. |
| <a id="workitemwidgets"></a>`widgets` | [`[WorkItemWidget!]`](#workitemwidget) | Collection of widgets that belong to the work item. |
| <a id="workitemworkitemtype"></a>`workItemType` | [`WorkItemType!`](#workitemtype) | Type assigned to the work item. |
#### Fields with arguments
@ -39600,6 +39599,19 @@ Returns [`String!`](#string).
| ---- | ---- | ----------- |
| <a id="workitemreferencefull"></a>`full` | [`Boolean`](#boolean) | Boolean option specifying whether the reference should be returned in full. |
##### `WorkItem.widgets`
Collection of widgets that belong to the work item.
Returns [`[WorkItemWidget!]`](#workitemwidget).
###### Arguments
| Name | Type | Description |
| ---- | ---- | ----------- |
| <a id="workitemwidgetsexcepttypes"></a>`exceptTypes` | [`[WorkItemWidgetType!]`](#workitemwidgettype) | Except widgets of the given types. |
| <a id="workitemwidgetsonlytypes"></a>`onlyTypes` | [`[WorkItemWidgetType!]`](#workitemwidgettype) | Only widgets of the given types. |
### `WorkItemClosingMergeRequest`
#### Fields

2
doc/development/features_inside_dot_gitlab.md
View File

@ -16,5 +16,5 @@ When implementing new features, refer to these existing features to avoid confli
- [Customize Auto DevOps Helm Values](../topics/autodevops/customize.md#customize-helm-chart-values): `.gitlab/auto-deploy-values.yaml`.
- [Insights](../user/project/insights/_index.md#configure-project-insights): `.gitlab/insights.yml`.
- [Service Desk Templates](../user/project/service_desk/configure.md#customize-emails-sent-to-external-participants): `.gitlab/service_desk_templates/`.
- [Secret Detection Custom Rulesets](../user/application_security/secret_detection/pipeline/_index.md#customize-analyzer-rulesets): `.gitlab/secret-detection-ruleset.toml`
- [Secret Detection Custom Rulesets](../user/application_security/secret_detection/pipeline/configure.md#customize-analyzer-rulesets): `.gitlab/secret-detection-ruleset.toml`
- [Static Analysis Custom Rulesets](../user/application_security/sast/customize_rulesets.md#create-the-configuration-file): `.gitlab/sast-ruleset.toml`

2
doc/solutions/components/secret_detection.md
View File

@ -113,7 +113,7 @@ To run secret detection automatically in the pipeline as the enforced global pol
```
The UI configuration is shown in this screen: ![Security Dashboard](img/secret_detection_policy_v17_9.png)
For detailed information about this CI variable, see [this document for details](../../user/application_security/secret_detection/pipeline/_index.md#with-a-remote-ruleset).
For detailed information about this CI variable, see [this document for details](../../user/application_security/secret_detection/pipeline/configure.md#with-a-remote-ruleset).
1. Click **Create policy**.

1
doc/tutorials/build_application.md
View File

@ -24,6 +24,7 @@ Use CI/CD pipelines to automatically build, test, and deploy your code.
| [Use Auto DevOps to deploy an application](../topics/autodevops/cloud_deployments/auto_devops_with_gke.md) | Deploy an application to Google Kubernetes Engine (GKE). | |
| [Using Buildah in a rootless container with GitLab Runner Operator on OpenShift](../ci/docker/buildah_rootless_tutorial.md) | Learn how to set up GitLab Runner Operator on OpenShift to build Docker images with Buildah in a rootless container | |
| [Automatically build and publish packages with CI/CD](../user/packages/pypi_repository/auto_publish_tutorial.md) | Learn how to automatically build, test, and publish a PyPI package to the package registry. | |
| [Structure the package registry for enterprise scale](../user/packages/package_registry/enterprise_structure_tutorial.md) | Set up your organization to upload, manage, and consume packages at scale. | |
| [Set up CI/CD steps](setup_steps/_index.md) | Learn how to set up the steps component and configure a CI/CD pipeline to use the step in a job. | |
| [Build and sign Python packages with GitLab CI/CD](../user/packages/package_registry/pypi_cosign_tutorial.md) | Learn how to build a secure pipeline for Python packages using GitLab CI/CD and Sigstore Cosign. | |

2
doc/user/application_security/_index.md
View File

@ -49,7 +49,7 @@ The following vulnerability scanners and their databases are regularly updated:
| [Container Scanning](container_scanning/_index.md) | A job runs on a daily basis to build new images with the latest vulnerability database updates from the upstream scanner. GitLab monitors this job through an internal alert that tells the engineering team when the database becomes more than 48 hours old. For more information, see the [Vulnerabilities database update](container_scanning/_index.md#vulnerabilities-database). |
| [Dependency Scanning](dependency_scanning/_index.md) | Relies on the [GitLab Advisory Database](gitlab_advisory_database/_index.md) which is updated on a daily basis using data from the National Vulnerability Database (NVD) and the GitHub Advisory Database. |
| [Dynamic Application Security Testing (DAST)](dast/_index.md) | [DAST](dast/browser/_index.md) analyzer is updated on a periodic basis. |
| [Secret Detection](secret_detection/pipeline/_index.md#detected-secrets) | GitLab maintains the [detection rules](secret_detection/pipeline/_index.md#detected-secrets) and [accepts community contributions](secret_detection/pipeline/_index.md#add-new-patterns). The scanning engine is updated at least once per month if a relevant update is available. |
| [Secret Detection](secret_detection/pipeline/_index.md#detected-secrets) | GitLab maintains the [detection rules](secret_detection/pipeline/_index.md#detected-secrets) and [accepts community contributions](secret_detection/pipeline/configure.md#add-new-patterns). The scanning engine is updated at least once per month if a relevant update is available. |
| [Static Application Security Testing (SAST)](sast/_index.md) | The source of scan rules depends on which [analyzer](sast/analyzers.md) is used for each [supported programming language](sast/_index.md#supported-languages-and-frameworks). GitLab maintains a ruleset for the Semgrep-based analyzer and updates it regularly based on internal research and user feedback. For other analyzers, the ruleset is sourced from the upstream open-source scanner. Each analyzer is updated at least once per month if a relevant update is available. |
In versions of GitLab that use the same major version of the analyzer, you do not have to update

2
doc/user/application_security/detect/roll_out_security_scanning.md
View File

@ -180,7 +180,7 @@ For more information about overriding security jobs, see:
- [Overriding SAST jobs](../sast/_index.md#overriding-sast-jobs).
- [Overriding Dependency Scanning jobs](../dependency_scanning/_index.md#overriding-dependency-scanning-jobs).
- [Overriding Container Scanning jobs](../container_scanning/_index.md#overriding-the-container-scanning-template).
- [Overriding Secret Detection jobs](../secret_detection/pipeline/_index.md#configuration).
- [Overriding Secret Detection jobs](../secret_detection/pipeline/configure.md).
- [Overriding DAST jobs](../dast/browser/_index.md).
All the security scanning tools define their stage, so this error can occur with all of them.

2
doc/user/application_security/get-started-security.md
View File

@ -71,7 +71,7 @@ even if the vulnerability already exists on the default branch.
For more information, see:
- [Enable Secret Detection](secret_detection/pipeline/_index.md#enable-the-analyzer)
- [Secret Detection settings](secret_detection/pipeline/_index.md#configuration)
- [Secret Detection settings](secret_detection/pipeline/configure.md)
- [Enable Dependency Scanning](dependency_scanning/_index.md#configuration)
- [Dependency Scanning settings](dependency_scanning/_index.md#available-cicd-variables)

2
doc/user/application_security/offline_deployments/_index.md
View File

@ -98,7 +98,7 @@ above. You can find more information at each of the pages below:
- [Container scanning offline directions](../container_scanning/_index.md#running-container-scanning-in-an-offline-environment)
- [SAST offline directions](../sast/_index.md#running-sast-in-an-offline-environment)
- [Secret Detection offline directions](../secret_detection/pipeline/_index.md#offline-configuration)
- [Secret Detection offline directions](../secret_detection/pipeline/configure.md#offline-configuration)
- [DAST offline directions](../dast/browser/configuration/offline_configuration.md)
- [API Fuzzing offline directions](../api_fuzzing/configuration/offline_configuration.md)
- [License Scanning offline directions](../../compliance/license_scanning_of_cyclonedx_files/_index.md#running-in-an-offline-environment)

8
doc/user/application_security/policies/scan_execution_policies.md
View File

@ -379,10 +379,10 @@ scan.
[files supported by SAST)](../sast/_index.md#supported-languages-and-frameworks).
- Secret detection:
- Only rules with the default ruleset are supported.
[Custom rulesets](../secret_detection/pipeline/_index.md#customize-analyzer-rulesets) are not
supported. Instead, you can configure a
[remote configuration file](../secret_detection/pipeline/_index.md#with-a-remote-ruleset) and set
the `SECRET_DETECTION_RULESET_GIT_REFERENCE` variable.
[Replacing](../secret_detection/pipeline/configure.md#replace-the-default-ruleset) or [extending](../secret_detection/pipeline/configure.md#extend-the-default-ruleset)
the default ruleset is not supported. Instead, you can configure a
[remote configuration file](../secret_detection/pipeline/configure.md#with-a-remote-ruleset) to override
or disable a rule from the default ruleset using the `SECRET_DETECTION_RULESET_GIT_REFERENCE` variable.
- For `scheduled` scan execution policies, secret detection by default runs first in `historic`
mode (`SECRET_DETECTION_HISTORIC_SCAN` = `true`). All subsequent scheduled scans run in default
mode with `SECRET_DETECTION_LOG_OPTIONS` set to the commit range between last run and current

784
doc/user/application_security/secret_detection/pipeline/_index.md
View File

@ -39,7 +39,7 @@ With GitLab Ultimate, pipeline secret detection results are also processed so yo
Pipeline secret detection scans the repository's content for specific patterns. Each pattern matches
a specific type of secret and is specified in a rule by using a TOML syntax. The default set of
rules is maintained by GitLab. In the Ultimate tier, you can customize the default ruleset to suit
your needs. For details, see [Customize analyzer rulesets](#customize-analyzer-rulesets). To confirm
your needs. For details, see [Customize analyzer rulesets](configure.md#customize-analyzer-rulesets). To confirm
which secrets are detected by pipeline secret detection, see
[Detected secrets](../detected_secrets.md). To provide reliable, high-confidence results, pipeline
secret detection only looks for passwords or other unstructured secrets in specific contexts like
@ -131,18 +131,10 @@ For more information, see the confidential project `https://gitlab.com/gitlab-or
- For some rule types, such as cryptographic keys, pipeline secret detection identifies leaks by matching prefix of the secret rather than the entire secret value. In this scenario, the algorithm consolidates different secrets of the same rule type in a file into a single finding, rather than treating each distinct secret as a separate finding. For example, the [SSH Private Key rule type](https://gitlab.com/gitlab-org/security-products/analyzers/secrets/-/blob/d2919f65f1d8001755015b5d790af620676b97ea/gitleaks.toml#L138) matches only the `-----BEGIN OPENSSH PRIVATE KEY-----` prefix of a value to confirm the presence of a SSH private key. If there are two distinct SSH Private Keys within the same file, the algorithm considers both values as identical and reports only one finding instead of two.
- The algorithm's scope is limited to a per-file basis, meaning that the same secret appearing in two different files is treated as two distinct findings.
## Output
## Enable the analyzer
Pipeline secret detection outputs the file `gl-secret-detection-report.json` as a job artifact. The file contains detected secrets. You can [download](../../../../ci/jobs/job_artifacts.md#download-job-artifacts) the file for processing outside GitLab.
For more information, see:
- [Report file schema](https://gitlab.com/gitlab-org/security-products/security-report-schemas/-/blob/master/dist/secret-detection-report-format.json)
- [Example report file](https://gitlab.com/gitlab-org/security-products/analyzers/secrets/-/blob/master/qa/expect/secrets/gl-secret-detection-report.json)
## Configuration
### Requirements
Enable the analyzer to use pipeline secret detection.
After you enable it, you can [customize the analyzer settings](configure.md).
Prerequisites:
@ -153,32 +145,14 @@ Prerequisites:
- CPU architectures other than amd64 are not supported.
- GitLab CI/CD configuration (`.gitlab-ci.yml`) must include the `test` stage.
Different features are available in different [GitLab tiers](https://about.gitlab.com/pricing/).
| Capability | In Free & Premium | In Ultimate |
|:-----------------------------------------------------------------------------------------------------|:-----------------------|:-----------------------|
| [Enable the analyzer](#enable-the-analyzer) | {{< icon name="check-circle" >}} Yes | {{< icon name="check-circle" >}} Yes |
| [Customize analyzer settings](#customize-analyzer-settings) | {{< icon name="check-circle" >}} Yes | {{< icon name="check-circle" >}} Yes |
| Download [output](#output) | {{< icon name="check-circle" >}} Yes | {{< icon name="check-circle" >}} Yes |
| See new findings in the merge request widget | {{< icon name="dotted-circle" >}} No | {{< icon name="check-circle" >}} Yes |
| View identified secrets in the pipelines' **Security** tab | {{< icon name="dotted-circle" >}} No | {{< icon name="check-circle" >}} Yes |
| [Manage vulnerabilities](../../vulnerability_report/_index.md) | {{< icon name="dotted-circle" >}} No | {{< icon name="check-circle" >}} Yes |
| [Access the Security Dashboard](../../security_dashboard/_index.md) | {{< icon name="dotted-circle" >}} No | {{< icon name="check-circle" >}} Yes |
| [Customize analyzer rulesets](#customize-analyzer-rulesets) | {{< icon name="dotted-circle" >}} No | {{< icon name="check-circle" >}} Yes |
| [Enable security policies](../../policies/_index.md) | {{< icon name="dotted-circle" >}} No | {{< icon name="check-circle" >}} Yes |
### Enable the analyzer
To enable pipeline secret detection, either:
- Enable [Auto DevOps](../../../../topics/autodevops/_index.md), which includes [Auto Secret Detection](../../../../topics/autodevops/stages.md#auto-secret-detection).
- [Edit the `.gitlab-ci.yml` file manually](#edit-the-gitlab-ciyml-file-manually). Use this method
if your `.gitlab-ci.yml` file is complex.
- [Use an automatically configured merge request](#use-an-automatically-configured-merge-request).
#### Edit the `.gitlab-ci.yml` file manually
### Edit the `.gitlab-ci.yml` file manually
This method requires you to manually edit the existing `.gitlab-ci.yml` file. Use this method if
your GitLab CI/CD configuration file is complex.
@ -201,7 +175,7 @@ your GitLab CI/CD configuration file is complex.
Pipelines now include a pipeline secret detection job.
#### Use an automatically configured merge request
### Use an automatically configured merge request
{{< history >}}
@ -232,750 +206,14 @@ To enable pipeline secret detection:
Pipelines now include a pipeline secret detection job.
### Customize analyzer settings
## Output
The pipeline secret detection scan settings can be changed through [CI/CD variables](#available-cicd-variables)
by using the [`variables`](../../../../ci/yaml/_index.md#variables) parameter in `.gitlab-ci.yml`.
Pipeline secret detection outputs the file `gl-secret-detection-report.json` as a job artifact. The file contains detected secrets. You can [download](../../../../ci/jobs/job_artifacts.md#download-job-artifacts) the file for processing outside GitLab.
{{< alert type="warning" >}}
For more information, see:
All configuration of GitLab security scanning tools should be tested in a merge request before
merging these changes to the default branch. Failure to do so can give unexpected results,
including a large number of false positives.
{{< /alert >}}
#### Add new patterns
To search for other types of secrets in your repositories, you can [customize analyzer rulesets](#customize-analyzer-rulesets).
To propose a new detection rule for all users of pipeline secret detection, [see our single source of truth for our rules](https://gitlab.com/gitlab-org/security-products/secret-detection/secret-detection-rules/-/blob/main/README.md) and follow the guidance to create a merge request.
If you operate a cloud or SaaS product and you're interested in partnering with GitLab to better protect your users, learn more about our [partner program for leaked credential notifications](../automatic_response.md#partner-program-for-leaked-credential-notifications).
#### Pin to specific analyzer version
The GitLab-managed CI/CD template specifies a major version and automatically pulls the latest analyzer release within that major version.
In some cases, you may need to use a specific version.
For example, you might need to avoid a regression in a later release.
To override the automatic update behavior, set the `SECRETS_ANALYZER_VERSION` CI/CD variable
in your CI/CD configuration file after you include the [`Secret-Detection.gitlab-ci.yml` template](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Jobs/Secret-Detection.gitlab-ci.yml).
You can set the tag to:
- A major version, like `4`. Your pipelines use any minor or patch updates that are released within this major version.
- A minor version, like `4.5`. Your pipelines use any patch updates that are released within this minor version.
- A patch version, like `4.5.0`. Your pipelines don't receive any updates.
This example uses a specific minor version of the analyzer:
```yaml
include:
- template: Jobs/Secret-Detection.gitlab-ci.yml
secret_detection:
variables:
SECRETS_ANALYZER_VERSION: "4.5"
```
#### Enable full history scan
To enable full history scan, set the variable `SECRET_DETECTION_HISTORIC_SCAN` to `true` in your `.gitlab-ci.yml` file.
#### Run jobs in merge request pipelines
See [Use security scanning tools with merge request pipelines](../../detect/roll_out_security_scanning.md#use-security-scanning-tools-with-merge-request-pipelines).
#### Override the analyzer jobs
To override a job definition, (for example, change properties like `variables` or `dependencies`),
declare a job with the same name as the `secret_detection` job to override. Place this new job after
the template inclusion and specify any additional keys under it.
In the following example _extract_ of a `.gitlab-ci.yml` file:
- The `Jobs/Secret-Detection` CI template is [included](../../../../ci/yaml/_index.md#include).
- In the `secret_detection` job, the CI/CD variable `SECRET_DETECTION_HISTORIC_SCAN` is set to
`true`. Because the template is evaluated before the pipeline configuration, the last mention of
the variable takes precedence, so an historic scan is performed.
```yaml
include:
- template: Jobs/Secret-Detection.gitlab-ci.yml
secret_detection:
variables:
SECRET_DETECTION_HISTORIC_SCAN: "true"
```
### Customize analyzer rulesets
{{< details >}}
- Tier: Ultimate
{{< /details >}}
{{< history >}}
- [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/211387) in GitLab 13.5.
- Expanded to include additional passthrough types of `file` and `raw` in GitLab 14.6.
- [Enabled](https://gitlab.com/gitlab-org/gitlab/-/issues/235359) support for overriding rules in GitLab 14.8.
- [Enabled](https://gitlab.com/gitlab-org/gitlab/-/issues/336395) support for passthrough chains and included additional passthrough types of `git` and `url` in GitLab 17.2.
{{< /history >}}
You can customize the behavior of pipeline secret detection by [creating a ruleset configuration file](#create-a-ruleset-configuration-file),
either in the repository being scanned or a remote repository. Customization enables you to modify, replace, or extend the default ruleset.
There are multiple kinds of customizations available:
- Modify the behavior of **rules predefined in the default ruleset**. This includes:
- [Override a rule from the default ruleset](#override-a-rule).
- [Disable a rule from the default ruleset](#disable-a-rule).
- [Disable or override a rule with a remote ruleset](#with-a-remote-ruleset).
- Replace the default ruleset with a custom ruleset using passthroughs. This includes:
- [Use configuration from an inline ruleset](#with-an-inline-ruleset).
- [Use configuration from a local ruleset](#with-a-local-ruleset).
- [Use configuration from a remote ruleset](#with-a-remote-ruleset-1).
- [Use configuration from a private remote ruleset](#with-a-private-remote-ruleset)
- Extend the behavior of the default ruleset using passthroughs. This includes:
- [Use configuration from a local ruleset](#with-a-local-ruleset-1).
- [Use configuration from a remote ruleset](#with-a-remote-ruleset-2).
- Ignore secrets and paths using Gitleaks-native functionality. This includes:
- Use [`Gitleaks' [allowlist] directive`](https://github.com/gitleaks/gitleaks#configuration) to [ignore patterns and paths](#ignore-patterns-and-paths).
- Use `gitleaks:allow` comment to [ignore secrets inline](#ignore-secrets-inline).
#### Create a ruleset configuration file
To create a ruleset configuration file:
1. Create a `.gitlab` directory at the root of your project, if one doesn’t already exist.
1. Create a file named `secret-detection-ruleset.toml` in the `.gitlab` directory.
#### Modify rules from the default ruleset
You can modify rules predefined in the [default ruleset](../detected_secrets.md).
Modifying rules can help you adapt pipeline secret detection to an existing workflow or tool. For example you may want to override the severity of a detected secret or disable a rule from being detected at all.
You can also use a ruleset configuration file stored remotely (that is, a remote Git repository or website) to modify predefined rules. New rules must use the [custom rule format](custom_rulesets_schema.md#custom-rule-format).
##### Disable a rule
{{< history >}}
- Ability to disable a rule with a remote ruleset was [enabled](https://gitlab.com/gitlab-org/gitlab/-/issues/425251) in GitLab 16.0 and later.
{{< /history >}}
You can disable rules that you don't want active. To disable rules from the analyzer default ruleset:
1. [Create a ruleset configuration file](#create-a-ruleset-configuration-file), if one doesn't exist already.
1. Set the `disabled` flag to `true` in the context of a [`ruleset` section](../pipeline/custom_rulesets_schema.md#the-secretsruleset-section).
1. In one or more `ruleset.identifier` subsections, list the rules to disable. Every
[`ruleset.identifier` section](../pipeline/custom_rulesets_schema.md#the-secretsrulesetidentifier-section) has:
- A `type` field for the predefined rule identifier.
- A `value` field for the rule name.
In the following example `secret-detection-ruleset.toml` file, the disabled rules are matched by the `type` and `value` of identifiers:
```toml
[secrets]
[[secrets.ruleset]]
disable = true
[secrets.ruleset.identifier]
type = "gitleaks_rule_id"
value = "RSA private key"
```
##### Override a rule
{{< history >}}
- Ability to override a rule with a remote ruleset was [enabled](https://gitlab.com/gitlab-org/gitlab/-/issues/425251) in GitLab 16.0 and later.
{{< /history >}}
If there are specific rules to customize, you can override them. For example, you may increase the severity of a specific type of secret because leaking it would have a higher impact on your workflow.
To override rules from the analyzer default ruleset:
1. [Create a ruleset configuration file](#create-a-ruleset-configuration-file), if one doesn't exist already.
1. In one or more `ruleset.identifier` subsections, list the rules to override. Every
[`ruleset.identifier` section](../pipeline/custom_rulesets_schema.md#the-secretsrulesetidentifier-section) has:
- A `type` field for the predefined rule identifier.
- A `value` field for the rule name.
1. In the [`ruleset.override` context](../pipeline/custom_rulesets_schema.md#the-secretsrulesetoverride-section) of a [`ruleset` section](../pipeline/custom_rulesets_schema.md#the-secretsruleset-section), provide the keys to override. Any combination of keys can be overridden. Valid keys are:
- `description`
- `message`
- `name`
- `severity` (valid options are: `Critical`, `High`, `Medium`, `Low`, `Unknown`, `Info`)
In the following `secret-detection-ruleset.toml` file, rules are matched by the `type` and `value` of identifiers and then overridden:
```toml
[secrets]
[[secrets.ruleset]]
[secrets.ruleset.identifier]
type = "gitleaks_rule_id"
value = "RSA private key"
[secrets.ruleset.override]
description = "OVERRIDDEN description"
message = "OVERRIDDEN message"
name = "OVERRIDDEN name"
severity = "Info"
```
##### With a remote ruleset
A **remote ruleset is a configuration file stored outside the current repository**. It can be used to modify rules across multiple projects.
To modify a predefined rule with a remote ruleset, you can use the `SECRET_DETECTION_RULESET_GIT_REFERENCE` [CI/CD variable](../../../../ci/variables/_index.md):
```yaml
include:
- template: Jobs/Secret-Detection.gitlab-ci.yml
variables:
SECRET_DETECTION_RULESET_GIT_REFERENCE: "gitlab.com/example-group/remote-ruleset-project"
```
Pipeline secret detection assumes the configuration is defined in `.gitlab/secret-detection-ruleset.toml` file in the repository referenced by the CI variable where the remote ruleset is stored. If that file doesn't exist, please make sure to [create one](#create-a-ruleset-configuration-file) and follow the steps to [override](#override-a-rule) or [disable](#disable-a-rule) a predefined rule as outlined above.
{{< alert type="note" >}}
A local `.gitlab/secret-detection-ruleset.toml` file in the project takes precedence over `SECRET_DETECTION_RULESET_GIT_REFERENCE` by default because `SECURE_ENABLE_LOCAL_CONFIGURATION` is set to `true`.
If you set `SECURE_ENABLE_LOCAL_CONFIGURATION` to `false`, the local file is ignored and the default configuration or `SECRET_DETECTION_RULESET_GIT_REFERENCE` (if set) is used.
{{< /alert >}}
The `SECRET_DETECTION_RULESET_GIT_REFERENCE` variable uses a format similar to [Git URLs](https://git-scm.com/docs/git-clone#_git_urls) for specifying a URI, optional authentication, and optional Git SHA. The variable uses the following format:
```plaintext
<AUTH_USER>:<AUTH_PASSWORD>@<PROJECT_PATH>@<GIT_SHA>
```
If the configuration file is stored in a private project that requires authentication, you may use a [Group Access Token](../../../group/settings/group_access_tokens.md) securely stored in a CI variable to load the remote ruleset:
```yaml
include:
- template: Jobs/Secret-Detection.gitlab-ci.yml
variables:
SECRET_DETECTION_RULESET_GIT_REFERENCE: "group_2504721_bot_7c9311ffb83f2850e794d478ccee36f5:$GROUP_ACCESS_TOKEN@gitlab.com/example-group/remote-ruleset-project"
```
The group access token must have the `read_repository` scope and at least the Reporter role. For details, see [Repository permissions](../../../permissions.md#repository).
See [bot users for groups](../../../group/settings/group_access_tokens.md#bot-users-for-groups) to learn how to find the username associated with a group access token.
#### Replace the default ruleset
You can replace the default ruleset configuration using a number of [customizations](../pipeline/custom_rulesets_schema.md). Those can be combined using [passthroughs](../pipeline/custom_rulesets_schema.md#passthrough-types) into a single configuration.
Using passthroughs, you can:
- Chain up to [20 passthroughs](../pipeline/custom_rulesets_schema.md#the-secretspassthrough-section) into a single configuration to replace or extend predefined rules.
- Include [environment variables in passthroughs](../pipeline/custom_rulesets_schema.md#interpolate).
- Set a [timeout](../pipeline/custom_rulesets_schema.md#the-secrets-configuration-section) for evaluating passthroughs.
- [Validate](../pipeline/custom_rulesets_schema.md#the-secrets-configuration-section) TOML syntax used in each defined passthrough.
##### With an inline ruleset
You can use [`raw` passthrough](../pipeline/custom_rulesets_schema.md#passthrough-types) to replace default ruleset with configuration provided inline.
To do so, add the following in the `.gitlab/secret-detection-ruleset.toml` configuration file stored in the same repository, and adjust the rule defined under `[[rules]]` as appropriate:
```toml
[secrets]
[[secrets.passthrough]]
type = "raw"
target = "gitleaks.toml"
value = """
title = "replace default ruleset with a raw passthrough"
[[rules]]
description = "Test for Raw Custom Rulesets"
regex = '''Custom Raw Ruleset T[est]{3}'''
"""
```
The above example replaces the default ruleset with a rule that checks for the regex defined - `Custom Raw Ruleset T` with a suffix of 3 characters from either one of `e`, `s`, or `t` letters.
For more information on the passthrough syntax to use, see [Schema](../pipeline/custom_rulesets_schema.md#schema).
##### With a local ruleset
You can use [`file` passthrough](../pipeline/custom_rulesets_schema.md#passthrough-types) to replace the default ruleset with another file committed to the current repository.
To do so, add the following in the `.gitlab/secret-detection-ruleset.toml` configuration file stored in the same repository and adjust the `value` as appropriate to point to the path of the file with the local ruleset configuration:
```toml
[secrets]
[[secrets.passthrough]]
type = "file"
target = "gitleaks.toml"
value = "config/gitleaks.toml"
```
This would replace the default ruleset with the configuration defined in `config/gitleaks.toml` file.
For more information on the passthrough syntax to use, see [Schema](../pipeline/custom_rulesets_schema.md#schema).
##### With a remote ruleset
You can replace the default ruleset with configuration defined in a remote Git repository or a file stored somewhere online using the `git` and `url` passthroughs, respectively.
A remote ruleset can be used across multiple projects. For example, you may want to apply the same
ruleset to a number of projects in one of your namespaces, in such case, you may use either type of
passthrough to load up that remote ruleset and have it used by multiple projects. It also enables
centralized management of a ruleset, with only authorized people able to edit.
To use `git` passthrough, add the following to the `.gitlab/secret-detection-ruleset.toml` configuration file stored in a repository and adjust the `value` to point to the address of the Git repository:
```toml
# .gitlab/secret-detection-ruleset.toml in https://gitlab.com/user_group/basic_repository
[secrets]
[[secrets.passthrough]]
type = "git"
ref = "main"
subdir = "config"
value = "https://gitlab.com/user_group/central_repository_with_shared_ruleset"
```
In this configuration the analyzer loads the ruleset from the `gitleaks.toml` file inside the `config` directory in the `main` branch of the repository stored at `user_group/central_repository_with_shared_ruleset`. You can then proceed to include the same configuration in projects other than `user_group/basic_repository`.
Alternatively, you may use the `url` passthrough to replace the default ruleset with a remote ruleset configuration.
To use the `url` passthrough, add the following to the `.gitlab/secret-detection-ruleset.toml` configuration file stored in a repository and adjust the `value` to point to the address of the remote file:
```toml
# .gitlab/secret-detection-ruleset.toml in https://gitlab.com/user_group/basic_repository
[secrets]
[[secrets.passthrough]]
type = "url"
target = "gitleaks.toml"
value = "https://example.com/gitleaks.toml"
```
In this configuration the analyzer loads the ruleset configuration from `gitleaks.toml` file stored at the address provided.
For more information on the passthrough syntax to use, see [Schema](../pipeline/custom_rulesets_schema.md#schema).
##### With a private remote ruleset
If a ruleset configuration is stored in a private repository you must provide the credentials to access the repository by using the passthrough's [`auth` setting](../pipeline/custom_rulesets_schema.md#the-secretspassthrough-section).
{{< alert type="note" >}}
The `auth` setting only works with `git` passthrough.
{{< /alert >}}
To use a remote ruleset stored in a private repository, add the following to the `.gitlab/secret-detection-ruleset.toml` configuration file stored in a repository, adjust the `value` to point to the address of the Git repository, and update `auth` to use the appropriate credentials:
```toml
[secrets]
[[secrets.passthrough]]
type = "git"
ref = "main"
auth = "USERNAME:PASSWORD" # replace USERNAME and PASSWORD as appropriate
subdir = "config"
value = "https://gitlab.com/user_group/central_repository_with_shared_ruleset"
```
{{< alert type="warning" >}}
Beware of leaking credentials when using this feature. Check [this section](../pipeline/custom_rulesets_schema.md#interpolate) for an example on how to use environment variables to minimize the risk.
{{< /alert >}}
For more information on the passthrough syntax to use, see [Schema](../pipeline/custom_rulesets_schema.md#schema).
#### Extend the default ruleset
You can also extend the [default ruleset](../detected_secrets.md) configuration with additional rules as appropriate. This can be helpful when you would still like to benefit from the high-confidence predefined rules maintained by GitLab in the default ruleset, but also want to add rules for types of secrets that may be used in your own projects and namespaces. New rules must follow the [custom rule format](custom_rulesets_schema.md#custom-rule-format).
##### With a local ruleset
You can use a `file` passthrough to extend the default ruleset to add additional rules.
Add the following to the `.gitlab/secret-detection-ruleset.toml` configuration file stored in the same repository, and adjust the `value` as appropriate to point to the path of the extended configuration file:
```toml
# .gitlab/secret-detection-ruleset.toml
[secrets]
[[secrets.passthrough]]
type = "file"
target = "gitleaks.toml"
value = "extended-gitleaks-config.toml"
```
The extended configuration stored in `extended-gitleaks-config.toml` is included in the configuration used by the analyzer
in the CI/CD pipeline.
In the example below, we add a couple of new `[[rules]]` sections that define a number of regular expressions to be detected:
```toml
# extended-gitleaks-config.toml
[extend]
# Extends default packaged ruleset, NOTE: do not change the path.
path = "/gitleaks.toml"
[[rules]]
id = "example_api_key"
description = "Example Service API Key"
regex = '''example_api_key'''
[[rules]]
id = "example_api_secret"
description = "Example Service API Secret"
regex = '''example_api_secret'''
```
With this ruleset configuration the analyzer detects any strings matching with those two defined regex patterns.
For more information on the passthrough syntax to use, see [Schema](../pipeline/custom_rulesets_schema.md#schema).
##### With a remote ruleset
Similar to how you can replace the default ruleset with a remote ruleset, you can also extend the default ruleset with configuration stored in a remote Git repository or file stored external to the repository in which you have the `.gitlab/secret-detection-ruleset.toml` configuration file.
This can be achieved by using either of the `git` or `url` passthroughs as discussed previously.
To do that with a `git` passthrough, add the following to `.gitlab/secret-detection-ruleset.toml` configuration file stored in the same repository, and adjust the `value`, `ref`, and `subdir` as appropriate to point to the path of the extended configuration file:
```toml
# .gitlab/secret-detection-ruleset.toml in https://gitlab.com/user_group/basic_repository
[secrets]
[[secrets.passthrough]]
type = "git"
ref = "main"
subdir = "config"
value = "https://gitlab.com/user_group/central_repository_with_shared_ruleset"
```
Pipeline secret detection assumes the remote ruleset configuration file is called `gitleaks.toml`, and is stored in `config` directory on the `main` branch of the referenced repository.
To extend the default ruleset, the `gitleaks.toml` file should use `[extend]` directive similar to the example above:
```toml
# https://gitlab.com/user_group/central_repository_with_shared_ruleset/-/raw/main/config/gitleaks.toml
[extend]
# Extends default packaged ruleset, NOTE: do not change the path.
path = "/gitleaks.toml"
[[rules]]
id = "example_api_key"
description = "Example Service API Key"
regex = '''example_api_key'''
[[rules]]
id = "example_api_secret"
description = "Example Service API Secret"
regex = '''example_api_secret'''
```
To use a `url` passthrough, add the following to `.gitlab/secret-detection-ruleset.toml` configuration file stored in the same repository, and adjust the `value` as appropriate to point to the path of the extended configuration file
```toml
# .gitlab/secret-detection-ruleset.toml in https://gitlab.com/user_group/basic_repository
[secrets]
[[secrets.passthrough]]
type = "url"
target = "gitleaks.toml"
value = "https://example.com/gitleaks.toml"
```
For more information on the passthrough syntax to use, see [Schema](../pipeline/custom_rulesets_schema.md#schema).
#### Ignore patterns and paths
There may be situations in which you need to ignore a certain pattern or path from being detected by pipeline secret detection. For example, you may have a file including fake secrets to be used in a test suite.
In that case, you can utilize [Gitleaks' native `[allowlist]`](https://github.com/gitleaks/gitleaks#configuration) directive to ignore specific patterns or paths.
{{< alert type="note" >}}
This feature works regardless of whether you're using a local or a remote ruleset configuration file. The examples below utilizes a local ruleset using `file` passthrough though.
{{< /alert >}}
To ignore a pattern, add the following to the `.gitlab/secret-detection-ruleset.toml` configuration file stored in the same repository, and adjust the `value` as appropriate to point to the path of the extended configuration file:
```toml
# .gitlab/secret-detection-ruleset.toml
[secrets]
[[secrets.passthrough]]
type = "file"
target = "gitleaks.toml"
value = "extended-gitleaks-config.toml"
```
The extended configuration stored in `extended-gitleaks-config.toml` will be included in the configuration used by the analyzer.
In the example below, we add an `[allowlist]` directive that defines a regex that matches the secret to be ignored ("allowed"):
```toml
# extended-gitleaks-config.toml
[extend]
# Extends default packaged ruleset, NOTE: do not change the path.
path = "/gitleaks.toml"
[allowlist]
description = "allowlist of patterns to ignore in detection"
regexTarget = "match"
regexes = [
'''glpat-[0-9a-zA-Z_\\-]{20}'''
]
```
This ignores any string matching `glpat-` with a suffix of 20 characters of digits and letters.
Similarly, you can exclude specific paths from being scanned. In the example below, we define an array of paths to ignore under the `[allowlist]` directive. A path could either be a regular expression, or a specific file path:
```toml
# extended-gitleaks-config.toml
[extend]
# Extends default packaged ruleset, NOTE: do not change the path.
path = "/gitleaks.toml"
[allowlist]
description = "allowlist of patterns to ignore in detection"
paths = [
'''/gitleaks.toml''',
'''(.*?)(jpg|gif|doc|pdf|bin|svg|socket)'''
]
```
This ignores any secrets detected in either `/gitleaks.toml` file or any file ending with one of the specified extensions.
For more information on the passthrough syntax to use, see [Schema](../pipeline/custom_rulesets_schema.md#schema).
#### Ignore secrets inline
In some instances, you might want to ignore a secret inline. For example, you may have a fake secret in an example or a test suite. In these instances, you will want to ignore the secret instead of having it reported as a vulnerability.
To ignore a secret, add `gitleaks:allow` as a comment to the line that contains the secret.
For example:
```ruby
"A personal token for GitLab will look like glpat-JUST20LETTERSANDNUMB" # gitleaks:allow
```
#### Detecting complex strings
The [default ruleset](#detected-secrets) provides patterns to detect structured strings with a low rate of false positives.
However, you might want to detect more complex strings like passwords. Because [Gitleaks doesn't support lookahead or lookbehind](https://github.com/google/re2/issues/411),
writing a high-confidence, general rule to detect unstructured strings is not possible.
Although you can't detect every complex string, you can extend your ruleset to meet specific use cases.
For example, this rule modifies the [`generic-api-key` rule](https://github.com/gitleaks/gitleaks/blob/4e43d1109303568509596ef5ef576fbdc0509891/config/gitleaks.toml#L507-L514) from the Gitleaks default ruleset:
```regex
(?i)(?:pwd|passwd|password)(?:[0-9a-z\-_\t .]{0,20})(?:[\s|']|[\s|"]){0,3}(?:=|>|=:|:{1,3}=|\|\|:|<=|=>|:|\?=)(?:'|\"|\s|=|\x60){0,5}([0-9a-z\-_.=\S_]{3,50})(?:['|\"|\n|\r|\s|\x60|;]|$)
```
This regular expression matches:
1. A case-insensitive identifier that starts with `pwd`, or `passwd` or `password`. You can adjust this with other variations like `secret` or `key`.
1. A suffix that follows the identifier. The suffix is a combination of digits, letters, and symbols, and is between zero and 23 characters long.
1. Commonly used assignment operators, like `=`, `:=`, `:`, or `=>`.
1. A secret prefix, often used as a boundary to help with detecting the secret.
1. A string of digits, letters, and symbols, which is between three and 50 characters long. This is the secret itself. If you expect longer strings, you can adjust the length.
1. A secret suffix, often used as a boundary. This matches common endings like ticks, line breaks, and new lines.
Here are example strings which are matched by this regular expression:
```plaintext
pwd = password1234
passwd = 'p@ssW0rd1234'
password = thisismyverylongpassword
password => mypassword
password := mypassword
password: password1234
"password" = "p%ssward1234"
'password': 'p@ssW0rd1234'
```
To use this regex, extend your ruleset with one of the methods documented on this page.
For example, imagine you wish to extend the default ruleset [with a local ruleset](#with-a-local-ruleset-1) that includes this rule.
Add the following to a `.gitlab/secret-detection-ruleset.toml` configuration file stored in the same repository. Adjust the `value` to point to the path of the extended configuration file:
```toml
# .gitlab/secret-detection-ruleset.toml
[secrets]
[[secrets.passthrough]]
type = "file"
target = "gitleaks.toml"
value = "extended-gitleaks-config.toml"
```
In `extended-gitleaks-config.toml` file, add a new `[[rules]]` section with the regular expression you want to use:
```toml
# extended-gitleaks-config.toml
[extend]
# Extends default packaged ruleset, NOTE: do not change the path.
path = "/gitleaks.toml"
[[rules]]
description = "Generic Password Rule"
id = "generic-password"
regex = '''(?i)(?:pwd|passwd|password)(?:[0-9a-z\-_\t .]{0,20})(?:[\s|']|[\s|"]){0,3}(?:=|>|=:|:{1,3}=|\|\|:|<=|=>|:|\?=)(?:'|\"|\s|=|\x60){0,5}([0-9a-z\-_.=\S_]{3,50})(?:['|\"|\n|\r|\s|\x60|;]|$)'''
entropy = 3.5
keywords = ["pwd", "passwd", "password"]
```
{{< alert type="note" >}}
This example configuration is provided only for convenience, and might not work
for all use cases. If you configure your ruleset to detect complex strings, you might
create a large number of false positives, or fail to capture certain patterns.
{{< /alert >}}
### Available CI/CD variables
Pipeline secret detection can be customized by defining available CI/CD variables:
| CI/CD variable | Default value | Description |
|-----------------------------------|---------------|-------------|
| `SECRET_DETECTION_EXCLUDED_PATHS` | "" | Exclude vulnerabilities from output based on the paths. The paths are a comma-separated list of patterns. Patterns can be globs (see [`doublestar.Match`](https://pkg.go.dev/github.com/bmatcuk/doublestar/v4@v4.0.2#Match) for supported patterns), or file or folder paths (for example, `doc,spec` ). Parent directories also match patterns. Detected secrets previously added to the vulnerability report are not removed. [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/225273) in GitLab 13.3. |
| `SECRET_DETECTION_HISTORIC_SCAN` | false | Flag to enable a historic Gitleaks scan. |
| `SECRET_DETECTION_IMAGE_SUFFIX` | "" | Suffix added to the image name. If set to `-fips`, `FIPS-enabled` images are used for scan. See [Use FIPS-enabled images](#fips-enabled-images) for more details. [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/355519) in GitLab 14.10. |
| `SECRET_DETECTION_LOG_OPTIONS` | "" | [`git log`](https://git-scm.com/docs/git-log) options used to define commit ranges. [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/350660) in GitLab 15.1.|
In previous GitLab versions, the following variables were also available:
| CI/CD variable | Default value | Description |
|-----------------------------------|---------------|-------------|
| `SECRET_DETECTION_COMMIT_FROM` | - | The commit a Gitleaks scan starts at. [Removed](https://gitlab.com/gitlab-org/gitlab/-/issues/243564) in GitLab 13.5. Replaced with `SECRET_DETECTION_COMMITS`. |
| `SECRET_DETECTION_COMMIT_TO` | - | The commit a Gitleaks scan ends at. [Removed](https://gitlab.com/gitlab-org/gitlab/-/issues/243564) in GitLab 13.5. Replaced with `SECRET_DETECTION_COMMITS`. |
| `SECRET_DETECTION_COMMITS` | - | The list of commits that Gitleaks should scan. [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/243564) in GitLab 13.5. [Removed](https://gitlab.com/gitlab-org/gitlab/-/issues/352565) in GitLab 15.0. |
### Offline configuration
{{< details >}}
- Tier: Premium, Ultimate
- Offering: GitLab Self-Managed
{{< /details >}}
An offline environment has limited, restricted, or intermittent access to external resources through
the internet. For instances in such an environment, pipeline secret detection requires
some configuration changes. The instructions in this section must be completed together with the
instructions detailed in [offline environments](../../offline_deployments/_index.md).
#### Configure GitLab Runner
By default, a runner tries to pull Docker images from the GitLab container registry even if a local
copy is available. You should use this default setting, to ensure Docker images remain current.
However, if no network connectivity is available, you must change the default GitLab Runner
`pull_policy` variable.
Configure the GitLab Runner CI/CD variable `pull_policy` to
[`if-not-present`](https://docs.gitlab.com/runner/executors/docker.html#using-the-if-not-present-pull-policy).
#### Use local pipeline secret detection analyzer image
Use a local pipeline secret detection analyzer image if you want to obtain the image from a local Docker
registry instead of the GitLab container registry.
Prerequisites:
- Importing Docker images into a local offline Docker registry depends on your
network security policy. Consult your IT staff to find an accepted and approved process
to import or temporarily access external resources.
1. Import the default pipeline secret detection analyzer image from `registry.gitlab.com` into your
[local Docker container registry](../../../packages/container_registry/_index.md):
```plaintext
registry.gitlab.com/security-products/secrets:6
```
The pipeline secret detection analyzer's image is [periodically updated](../../_index.md#vulnerability-scanner-maintenance)
so you should periodically update the local copy.
1. Set the CI/CD variable `SECURE_ANALYZERS_PREFIX` to the local Docker container registry.
```yaml
include:
- template: Jobs/Secret-Detection.gitlab-ci.yml
variables:
SECURE_ANALYZERS_PREFIX: "localhost:5000/analyzers"
```
The pipeline secret detection job should now use the local copy of the analyzer Docker image,
without requiring internet access.
### Using a custom SSL CA certificate authority
To trust a custom Certificate Authority, set the `ADDITIONAL_CA_CERT_BUNDLE` variable to the bundle
of CA certificates that you trust. Do this either in the `.gitlab-ci.yml` file, in a file
variable, or as a CI/CD variable.
- In the `.gitlab-ci.yml` file, the `ADDITIONAL_CA_CERT_BUNDLE` value must contain the
[text representation of the X.509 PEM public-key certificate](https://www.rfc-editor.org/rfc/rfc7468#section-5.1).
For example:
```yaml
variables:
ADDITIONAL_CA_CERT_BUNDLE: |
-----BEGIN CERTIFICATE-----
MIIGqTCCBJGgAwIBAgIQI7AVxxVwg2kch4d56XNdDjANBgkqhkiG9w0BAQsFADCB
...
jWgmPqF3vUbZE0EyScetPJquRFRKIesyJuBFMAs=
-----END CERTIFICATE-----
```
- If using a file variable, set the value of `ADDITIONAL_CA_CERT_BUNDLE` to the path to the
certificate.
- If using a variable, set the value of `ADDITIONAL_CA_CERT_BUNDLE` to the text
representation of the certificate.
### Demos
There are [demonstration projects](https://gitlab.com/gitlab-org/security-products/demos/analyzer-configurations/secret-detection) that illustrate some of these configuration options.
Below is a table with the demonstration projects and their associated workflows:
| Action/Workflow | Applies to/via | With inline or local ruleset | With remote ruleset |
| ----------------------- | -------------- | ------------------ | ------------------- |
| Disable a rule | Predefined rules | [Local Ruleset](https://gitlab.com/gitlab-org/security-products/demos/analyzer-configurations/secret-detection/modify-default-ruleset/local-ruleset/disable-rule-project/-/blob/main/.gitlab/secret-detection-ruleset.toml?ref_type=heads) / [Project](https://gitlab.com/gitlab-org/security-products/demos/analyzer-configurations/secret-detection/modify-default-ruleset/local-ruleset/disable-rule-project) | [Remote Ruleset](https://gitlab.com/gitlab-org/security-products/demos/analyzer-configurations/secret-detection/modify-default-ruleset/remote-ruleset/disable-rule-ruleset) / [Project](https://gitlab.com/gitlab-org/security-products/demos/analyzer-configurations/secret-detection/modify-default-ruleset/remote-ruleset/disable-rule-project) |
| Override a rule | Predefined rules | [Local Ruleset](https://gitlab.com/gitlab-org/security-products/demos/analyzer-configurations/secret-detection/modify-default-ruleset/local-ruleset/override-rule-project/-/blob/main/.gitlab/secret-detection-ruleset.toml?ref_type=heads) / [Project](https://gitlab.com/gitlab-org/security-products/demos/analyzer-configurations/secret-detection/modify-default-ruleset/local-ruleset/override-rule-project) | [Remote Ruleset](https://gitlab.com/gitlab-org/security-products/demos/analyzer-configurations/secret-detection/modify-default-ruleset/remote-ruleset/override-rule-ruleset) / [Project](https://gitlab.com/gitlab-org/security-products/demos/analyzer-configurations/secret-detection/modify-default-ruleset/remote-ruleset/override-rule-project) |
| Replace default ruleset | File Passthrough | [Local Ruleset](https://gitlab.com/gitlab-org/security-products/demos/analyzer-configurations/secret-detection/replace-default-ruleset/file-passthrough/-/blob/main/config/gitleaks.toml) / [Project](https://gitlab.com/gitlab-org/security-products/demos/analyzer-configurations/secret-detection/replace-default-ruleset/file-passthrough) | Not applicable |
| Replace default ruleset | Raw Passthrough | [Inline Ruleset](https://gitlab.com/gitlab-org/security-products/demos/analyzer-configurations/secret-detection/replace-default-ruleset/raw-passthrough/-/blob/main/.gitlab/secret-detection-ruleset.toml?ref_type=heads) / [Project](https://gitlab.com/gitlab-org/security-products/demos/analyzer-configurations/secret-detection/replace-default-ruleset/raw-passthrough) | Not applicable |
| Replace default ruleset | Git Passthrough | Not applicable | [Remote Ruleset](https://gitlab.com/gitlab-org/security-products/tests/secrets-passthrough-git-and-url-test/-/blob/config-demos-replace/config/gitleaks.toml) / [Project](https://gitlab.com/gitlab-org/security-products/demos/analyzer-configurations/secret-detection/replace-default-ruleset/git-passthrough) |
| Replace default ruleset | URL Passthrough | Not applicable | [Remote Ruleset](https://gitlab.com/gitlab-org/security-products/tests/secrets-passthrough-git-and-url-test/-/blob/config-demos-replace/config/gitleaks.toml) / [Project](https://gitlab.com/gitlab-org/security-products/demos/analyzer-configurations/secret-detection/replace-default-ruleset/url-passthrough) |
| Extend default ruleset | File Passthrough | [Local Ruleset](https://gitlab.com/gitlab-org/security-products/demos/analyzer-configurations/secret-detection/extend-default-ruleset/file-passthrough/-/blob/main/config/extended-gitleaks-config.toml) / [Project](https://gitlab.com/gitlab-org/security-products/demos/analyzer-configurations/secret-detection/extend-default-ruleset/file-passthrough) | Not applicable |
| Extend default ruleset | Git Passthrough | Not applicable | [Remote Ruleset](https://gitlab.com/gitlab-org/security-products/tests/secrets-passthrough-git-and-url-test/-/blob/config-demos-extend/config/gitleaks.toml) / [Project](https://gitlab.com/gitlab-org/security-products/demos/analyzer-configurations/secret-detection/extend-default-ruleset/git-passthrough) |
| Extend default ruleset | URL Passthrough | Not applicable | [Remote Ruleset](https://gitlab.com/gitlab-org/security-products/tests/secrets-passthrough-git-and-url-test/-/blob/config-demos-extend/config/gitleaks.toml) / [Project](https://gitlab.com/gitlab-org/security-products/demos/analyzer-configurations/secret-detection/extend-default-ruleset/url-passthrough) |
| Ignore paths | File Passthrough | [Local Ruleset](https://gitlab.com/gitlab-org/security-products/demos/analyzer-configurations/secret-detection/ignore-paths/file-passthrough/-/blob/main/config/extended-gitleaks-config.toml) / [Project](https://gitlab.com/gitlab-org/security-products/demos/analyzer-configurations/secret-detection/ignore-paths/file-passthrough) | Not applicable |
| Ignore paths | Git Passthrough | Not applicable | [Remote Ruleset](https://gitlab.com/gitlab-org/security-products/tests/secrets-passthrough-git-and-url-test/-/blob/config-demos-ignore-paths/config/gitleaks.toml) / [Project](https://gitlab.com/gitlab-org/security-products/demos/analyzer-configurations/secret-detection/ignore-paths/git-passthrough) |
| Ignore paths | URL Passthrough | Not applicable | [Remote Ruleset](https://gitlab.com/gitlab-org/security-products/tests/secrets-passthrough-git-and-url-test/-/blob/config-demos-ignore-paths/config/gitleaks.toml) / [Project](https://gitlab.com/gitlab-org/security-products/demos/analyzer-configurations/secret-detection/ignore-paths/url-passthrough) |
| Ignore patterns | File Passthrough | [Local Ruleset](https://gitlab.com/gitlab-org/security-products/demos/analyzer-configurations/secret-detection/ignore-patterns/file-passthrough/-/blob/main/config/extended-gitleaks-config.toml) / [Project](https://gitlab.com/gitlab-org/security-products/demos/analyzer-configurations/secret-detection/ignore-patterns/file-passthrough) | Not applicable |
| Ignore patterns | Git Passthrough | Not applicable | [Remote Ruleset](https://gitlab.com/gitlab-org/security-products/tests/secrets-passthrough-git-and-url-test/-/blob/config-demos-ignore-patterns/config/gitleaks.toml) / [Project](https://gitlab.com/gitlab-org/security-products/demos/analyzer-configurations/secret-detection/ignore-patterns/git-passthrough) |
| Ignore patterns | URL Passthrough | Not applicable | [Remote Ruleset](https://gitlab.com/gitlab-org/security-products/tests/secrets-passthrough-git-and-url-test/-/blob/config-demos-ignore-patterns/config/gitleaks.toml) / [Project](https://gitlab.com/gitlab-org/security-products/demos/analyzer-configurations/secret-detection/ignore-patterns/url-passthrough) |
| Ignore values | File Passthrough | [Local Ruleset](https://gitlab.com/gitlab-org/security-products/demos/analyzer-configurations/secret-detection/ignore-values/file-passthrough/-/blob/main/config/extended-gitleaks-config.toml) / [Project](https://gitlab.com/gitlab-org/security-products/demos/analyzer-configurations/secret-detection/ignore-values/file-passthrough) | Not applicable |
| Ignore values | Git Passthrough | Not applicable | [Remote Ruleset](https://gitlab.com/gitlab-org/security-products/tests/secrets-passthrough-git-and-url-test/-/blob/config-demos-ignore-values/config/gitleaks.toml) / [Project](https://gitlab.com/gitlab-org/security-products/demos/analyzer-configurations/secret-detection/ignore-values/git-passthrough) |
| Ignore values | URL Passthrough | Not applicable | [Remote Ruleset](https://gitlab.com/gitlab-org/security-products/tests/secrets-passthrough-git-and-url-test/-/blob/config-demos-ignore-values/config/gitleaks.toml) / [Project](https://gitlab.com/gitlab-org/security-products/demos/analyzer-configurations/secret-detection/ignore-values/url-passthrough) |
There are also some video demonstrations walking through setting up remote rulesets:
- [Secret detection with local and remote ruleset](https://youtu.be/rsN1iDug5GU)
- [Report file schema](https://gitlab.com/gitlab-org/security-products/security-report-schemas/-/blob/master/dist/secret-detection-report-format.json)
- [Example report file](https://gitlab.com/gitlab-org/security-products/analyzers/secrets/-/blob/master/qa/expect/secrets/gl-secret-detection-report.json)
## FIPS-enabled images

777
doc/user/application_security/secret_detection/pipeline/configure.md Normal file
View File

@ -0,0 +1,777 @@
---
stage: Application Security Testing
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
title: Customize pipeline secret detection
---
<!-- markdownlint-disable MD025 -->
{{< details >}}
- Tier: Free, Premium, Ultimate
- Offering: GitLab.com, GitLab Self-Managed, GitLab Dedicated
{{< /details >}}
Depending on your subscription tier and configuration method, you can change how pipeline secret detection works.
## Availability
Different features are available in different [GitLab tiers](https://about.gitlab.com/pricing/).
| Capability | In Free & Premium | In Ultimate |
|:-----------------------------------------------------------------------------------------------------|:-----------------------|:-----------------------|
| [Customize analyzer settings](#customize-analyzer-settings) | {{< icon name="check-circle" >}} Yes | {{< icon name="check-circle" >}} Yes |
| Download [output](_index.md#output) | {{< icon name="check-circle" >}} Yes | {{< icon name="check-circle" >}} Yes |
| See new findings in the merge request widget | {{< icon name="dotted-circle" >}} No | {{< icon name="check-circle" >}} Yes |
| View identified secrets in the pipelines' **Security** tab | {{< icon name="dotted-circle" >}} No | {{< icon name="check-circle" >}} Yes |
| [Manage vulnerabilities](../../vulnerability_report/_index.md) | {{< icon name="dotted-circle" >}} No | {{< icon name="check-circle" >}} Yes |
| [Access the Security Dashboard](../../security_dashboard/_index.md) | {{< icon name="dotted-circle" >}} No | {{< icon name="check-circle" >}} Yes |
| [Customize analyzer rulesets](#customize-analyzer-rulesets) | {{< icon name="dotted-circle" >}} No | {{< icon name="check-circle" >}} Yes |
| [Enable security policies](../../policies/_index.md) | {{< icon name="dotted-circle" >}} No | {{< icon name="check-circle" >}} Yes |
## Customize analyzer settings
The pipeline secret detection scan settings can be changed through [CI/CD variables](#available-cicd-variables)
by using the [`variables`](../../../../ci/yaml/_index.md#variables) parameter in `.gitlab-ci.yml`.
{{< alert type="warning" >}}
All configuration of GitLab security scanning tools should be tested in a merge request before
merging these changes to the default branch. Failure to do so can give unexpected results,
including a large number of false positives.
{{< /alert >}}
### Add new patterns
To search for other types of secrets in your repositories, you can [customize analyzer rulesets](#customize-analyzer-rulesets).
To propose a new detection rule for all users of pipeline secret detection, [see our single source of truth for our rules](https://gitlab.com/gitlab-org/security-products/secret-detection/secret-detection-rules/-/blob/main/README.md) and follow the guidance to create a merge request.
If you operate a cloud or SaaS product and you're interested in partnering with GitLab to better protect your users, learn more about our [partner program for leaked credential notifications](../automatic_response.md#partner-program-for-leaked-credential-notifications).
### Pin to specific analyzer version
The GitLab-managed CI/CD template specifies a major version and automatically pulls the latest analyzer release within that major version.
In some cases, you may need to use a specific version.
For example, you might need to avoid a regression in a later release.
To override the automatic update behavior, set the `SECRETS_ANALYZER_VERSION` CI/CD variable
in your CI/CD configuration file after you include the [`Secret-Detection.gitlab-ci.yml` template](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Jobs/Secret-Detection.gitlab-ci.yml).
You can set the tag to:
- A major version, like `4`. Your pipelines use any minor or patch updates that are released within this major version.
- A minor version, like `4.5`. Your pipelines use any patch updates that are released within this minor version.
- A patch version, like `4.5.0`. Your pipelines don't receive any updates.
This example uses a specific minor version of the analyzer:
```yaml
include:
- template: Jobs/Secret-Detection.gitlab-ci.yml
secret_detection:
variables:
SECRETS_ANALYZER_VERSION: "4.5"
```
### Enable full history scan
To enable full history scan, set the variable `SECRET_DETECTION_HISTORIC_SCAN` to `true` in your `.gitlab-ci.yml` file.
### Run jobs in merge request pipelines
See [Use security scanning tools with merge request pipelines](../../detect/roll_out_security_scanning.md#use-security-scanning-tools-with-merge-request-pipelines).
### Override the analyzer jobs
To override a job definition, (for example, change properties like `variables` or `dependencies`),
declare a job with the same name as the `secret_detection` job to override. Place this new job after
the template inclusion and specify any additional keys under it.
In the following example _extract_ of a `.gitlab-ci.yml` file:
- The `Jobs/Secret-Detection` CI template is [included](../../../../ci/yaml/_index.md#include).
- In the `secret_detection` job, the CI/CD variable `SECRET_DETECTION_HISTORIC_SCAN` is set to
`true`. Because the template is evaluated before the pipeline configuration, the last mention of
the variable takes precedence, so an historic scan is performed.
```yaml
include:
- template: Jobs/Secret-Detection.gitlab-ci.yml
secret_detection:
variables:
SECRET_DETECTION_HISTORIC_SCAN: "true"
```
## Customize analyzer rulesets
{{< details >}}
- Tier: Ultimate
{{< /details >}}
{{< history >}}
- [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/211387) in GitLab 13.5.
- Expanded to include additional passthrough types of `file` and `raw` in GitLab 14.6.
- [Enabled](https://gitlab.com/gitlab-org/gitlab/-/issues/235359) support for overriding rules in GitLab 14.8.
- [Enabled](https://gitlab.com/gitlab-org/gitlab/-/issues/336395) support for passthrough chains and included additional passthrough types of `git` and `url` in GitLab 17.2.
{{< /history >}}
You can customize the behavior of pipeline secret detection by [creating a ruleset configuration file](#create-a-ruleset-configuration-file),
either in the repository being scanned or a remote repository. Customization enables you to modify, replace, or extend the default ruleset.
There are multiple kinds of customizations available:
- Modify the behavior of **rules predefined in the default ruleset**. This includes:
- [Override a rule from the default ruleset](#override-a-rule).
- [Disable a rule from the default ruleset](#disable-a-rule).
- [Disable or override a rule with a remote ruleset](#with-a-remote-ruleset).
- Replace the default ruleset with a custom ruleset using passthroughs. This includes:
- [Use configuration from an inline ruleset](#with-an-inline-ruleset).
- [Use configuration from a local ruleset](#with-a-local-ruleset).
- [Use configuration from a remote ruleset](#with-a-remote-ruleset-1).
- [Use configuration from a private remote ruleset](#with-a-private-remote-ruleset)
- Extend the behavior of the default ruleset using passthroughs. This includes:
- [Use configuration from a local ruleset](#with-a-local-ruleset-1).
- [Use configuration from a remote ruleset](#with-a-remote-ruleset-2).
- Ignore secrets and paths using Gitleaks-native functionality. This includes:
- Use [`Gitleaks' [allowlist] directive`](https://github.com/gitleaks/gitleaks#configuration) to [ignore patterns and paths](#ignore-patterns-and-paths).
- Use `gitleaks:allow` comment to [ignore secrets inline](#ignore-secrets-inline).
### Create a ruleset configuration file
To create a ruleset configuration file:
1. Create a `.gitlab` directory at the root of your project, if one doesn’t already exist.
1. Create a file named `secret-detection-ruleset.toml` in the `.gitlab` directory.
### Modify rules from the default ruleset
You can modify rules predefined in the [default ruleset](../detected_secrets.md).
Modifying rules can help you adapt pipeline secret detection to an existing workflow or tool. For example you may want to override the severity of a detected secret or disable a rule from being detected at all.
You can also use a ruleset configuration file stored remotely (that is, a remote Git repository or website) to modify predefined rules. New rules must use the [custom rule format](custom_rulesets_schema.md#custom-rule-format).
#### Disable a rule
{{< history >}}
- Ability to disable a rule with a remote ruleset was [enabled](https://gitlab.com/gitlab-org/gitlab/-/issues/425251) in GitLab 16.0 and later.
{{< /history >}}
You can disable rules that you don't want active. To disable rules from the analyzer default ruleset:
1. [Create a ruleset configuration file](#create-a-ruleset-configuration-file), if one doesn't exist already.
1. Set the `disabled` flag to `true` in the context of a [`ruleset` section](../pipeline/custom_rulesets_schema.md#the-secretsruleset-section).
1. In one or more `ruleset.identifier` subsections, list the rules to disable. Every
[`ruleset.identifier` section](../pipeline/custom_rulesets_schema.md#the-secretsrulesetidentifier-section) has:
- A `type` field for the predefined rule identifier.
- A `value` field for the rule name.
In the following example `secret-detection-ruleset.toml` file, the disabled rules are matched by the `type` and `value` of identifiers:
```toml
[secrets]
[[secrets.ruleset]]
disable = true
[secrets.ruleset.identifier]
type = "gitleaks_rule_id"
value = "RSA private key"
```
#### Override a rule
{{< history >}}
- Ability to override a rule with a remote ruleset was [enabled](https://gitlab.com/gitlab-org/gitlab/-/issues/425251) in GitLab 16.0 and later.
{{< /history >}}
If there are specific rules to customize, you can override them. For example, you may increase the severity of a specific type of secret because leaking it would have a higher impact on your workflow.
To override rules from the analyzer default ruleset:
1. [Create a ruleset configuration file](#create-a-ruleset-configuration-file), if one doesn't exist already.
1. In one or more `ruleset.identifier` subsections, list the rules to override. Every
[`ruleset.identifier` section](../pipeline/custom_rulesets_schema.md#the-secretsrulesetidentifier-section) has:
- A `type` field for the predefined rule identifier.
- A `value` field for the rule name.
1. In the [`ruleset.override` context](../pipeline/custom_rulesets_schema.md#the-secretsrulesetoverride-section) of a [`ruleset` section](../pipeline/custom_rulesets_schema.md#the-secretsruleset-section), provide the keys to override. Any combination of keys can be overridden. Valid keys are:
- `description`
- `message`
- `name`
- `severity` (valid options are: `Critical`, `High`, `Medium`, `Low`, `Unknown`, `Info`)
In the following `secret-detection-ruleset.toml` file, rules are matched by the `type` and `value` of identifiers and then overridden:
```toml
[secrets]
[[secrets.ruleset]]
[secrets.ruleset.identifier]
type = "gitleaks_rule_id"
value = "RSA private key"
[secrets.ruleset.override]
description = "OVERRIDDEN description"
message = "OVERRIDDEN message"
name = "OVERRIDDEN name"
severity = "Info"
```
#### With a remote ruleset
A **remote ruleset is a configuration file stored outside the current repository**. It can be used to modify rules across multiple projects.
To modify a predefined rule with a remote ruleset, you can use the `SECRET_DETECTION_RULESET_GIT_REFERENCE` [CI/CD variable](../../../../ci/variables/_index.md):
```yaml
include:
- template: Jobs/Secret-Detection.gitlab-ci.yml
variables:
SECRET_DETECTION_RULESET_GIT_REFERENCE: "gitlab.com/example-group/remote-ruleset-project"
```
Pipeline secret detection assumes the configuration is defined in `.gitlab/secret-detection-ruleset.toml` file in the repository referenced by the CI variable where the remote ruleset is stored. If that file doesn't exist, please make sure to [create one](#create-a-ruleset-configuration-file) and follow the steps to [override](#override-a-rule) or [disable](#disable-a-rule) a predefined rule as outlined above.
{{< alert type="note" >}}
A local `.gitlab/secret-detection-ruleset.toml` file in the project takes precedence over `SECRET_DETECTION_RULESET_GIT_REFERENCE` by default because `SECURE_ENABLE_LOCAL_CONFIGURATION` is set to `true`.
If you set `SECURE_ENABLE_LOCAL_CONFIGURATION` to `false`, the local file is ignored and the default configuration or `SECRET_DETECTION_RULESET_GIT_REFERENCE` (if set) is used.
{{< /alert >}}
The `SECRET_DETECTION_RULESET_GIT_REFERENCE` variable uses a format similar to [Git URLs](https://git-scm.com/docs/git-clone#_git_urls) for specifying a URI, optional authentication, and optional Git SHA. The variable uses the following format:
```plaintext
<AUTH_USER>:<AUTH_PASSWORD>@<PROJECT_PATH>@<GIT_SHA>
```
If the configuration file is stored in a private project that requires authentication, you may use a [Group Access Token](../../../group/settings/group_access_tokens.md) securely stored in a CI variable to load the remote ruleset:
```yaml
include:
- template: Jobs/Secret-Detection.gitlab-ci.yml
variables:
SECRET_DETECTION_RULESET_GIT_REFERENCE: "group_2504721_bot_7c9311ffb83f2850e794d478ccee36f5:$GROUP_ACCESS_TOKEN@gitlab.com/example-group/remote-ruleset-project"
```
The group access token must have the `read_repository` scope and at least the Reporter role. For details, see [Repository permissions](../../../permissions.md#repository).
See [bot users for groups](../../../group/settings/group_access_tokens.md#bot-users-for-groups) to learn how to find the username associated with a group access token.
### Replace the default ruleset
You can replace the default ruleset configuration using a number of [customizations](../pipeline/custom_rulesets_schema.md). Those can be combined using [passthroughs](../pipeline/custom_rulesets_schema.md#passthrough-types) into a single configuration.
Using passthroughs, you can:
- Chain up to [20 passthroughs](../pipeline/custom_rulesets_schema.md#the-secretspassthrough-section) into a single configuration to replace or extend predefined rules.
- Include [environment variables in passthroughs](../pipeline/custom_rulesets_schema.md#interpolate).
- Set a [timeout](../pipeline/custom_rulesets_schema.md#the-secrets-configuration-section) for evaluating passthroughs.
- [Validate](../pipeline/custom_rulesets_schema.md#the-secrets-configuration-section) TOML syntax used in each defined passthrough.
#### With an inline ruleset
You can use [`raw` passthrough](../pipeline/custom_rulesets_schema.md#passthrough-types) to replace default ruleset with configuration provided inline.
To do so, add the following in the `.gitlab/secret-detection-ruleset.toml` configuration file stored in the same repository, and adjust the rule defined under `[[rules]]` as appropriate:
```toml
[secrets]
[[secrets.passthrough]]
type = "raw"
target = "gitleaks.toml"
value = """
title = "replace default ruleset with a raw passthrough"
[[rules]]
description = "Test for Raw Custom Rulesets"
regex = '''Custom Raw Ruleset T[est]{3}'''
"""
```
The above example replaces the default ruleset with a rule that checks for the regex defined - `Custom Raw Ruleset T` with a suffix of 3 characters from either one of `e`, `s`, or `t` letters.
For more information on the passthrough syntax to use, see [Schema](../pipeline/custom_rulesets_schema.md#schema).
#### With a local ruleset
You can use [`file` passthrough](../pipeline/custom_rulesets_schema.md#passthrough-types) to replace the default ruleset with another file committed to the current repository.
To do so, add the following in the `.gitlab/secret-detection-ruleset.toml` configuration file stored in the same repository and adjust the `value` as appropriate to point to the path of the file with the local ruleset configuration:
```toml
[secrets]
[[secrets.passthrough]]
type = "file"
target = "gitleaks.toml"
value = "config/gitleaks.toml"
```
This would replace the default ruleset with the configuration defined in `config/gitleaks.toml` file.
For more information on the passthrough syntax to use, see [Schema](../pipeline/custom_rulesets_schema.md#schema).
#### With a remote ruleset
You can replace the default ruleset with configuration defined in a remote Git repository or a file stored somewhere online using the `git` and `url` passthroughs, respectively.
A remote ruleset can be used across multiple projects. For example, you may want to apply the same
ruleset to a number of projects in one of your namespaces, in such case, you may use either type of
passthrough to load up that remote ruleset and have it used by multiple projects. It also enables
centralized management of a ruleset, with only authorized people able to edit.
To use `git` passthrough, add the following to the `.gitlab/secret-detection-ruleset.toml` configuration file stored in a repository and adjust the `value` to point to the address of the Git repository:
```toml
# .gitlab/secret-detection-ruleset.toml in https://gitlab.com/user_group/basic_repository
[secrets]
[[secrets.passthrough]]
type = "git"
ref = "main"
subdir = "config"
value = "https://gitlab.com/user_group/central_repository_with_shared_ruleset"
```
In this configuration the analyzer loads the ruleset from the `gitleaks.toml` file inside the `config` directory in the `main` branch of the repository stored at `user_group/central_repository_with_shared_ruleset`. You can then proceed to include the same configuration in projects other than `user_group/basic_repository`.
Alternatively, you may use the `url` passthrough to replace the default ruleset with a remote ruleset configuration.
To use the `url` passthrough, add the following to the `.gitlab/secret-detection-ruleset.toml` configuration file stored in a repository and adjust the `value` to point to the address of the remote file:
```toml
# .gitlab/secret-detection-ruleset.toml in https://gitlab.com/user_group/basic_repository
[secrets]
[[secrets.passthrough]]
type = "url"
target = "gitleaks.toml"
value = "https://example.com/gitleaks.toml"
```
In this configuration the analyzer loads the ruleset configuration from `gitleaks.toml` file stored at the address provided.
For more information on the passthrough syntax to use, see [Schema](../pipeline/custom_rulesets_schema.md#schema).
#### With a private remote ruleset
If a ruleset configuration is stored in a private repository you must provide the credentials to access the repository by using the passthrough's [`auth` setting](../pipeline/custom_rulesets_schema.md#the-secretspassthrough-section).
{{< alert type="note" >}}
The `auth` setting only works with `git` passthrough.
{{< /alert >}}
To use a remote ruleset stored in a private repository, add the following to the `.gitlab/secret-detection-ruleset.toml` configuration file stored in a repository, adjust the `value` to point to the address of the Git repository, and update `auth` to use the appropriate credentials:
```toml
[secrets]
[[secrets.passthrough]]
type = "git"
ref = "main"
auth = "USERNAME:PASSWORD" # replace USERNAME and PASSWORD as appropriate
subdir = "config"
value = "https://gitlab.com/user_group/central_repository_with_shared_ruleset"
```
{{< alert type="warning" >}}
Beware of leaking credentials when using this feature. Check [this section](../pipeline/custom_rulesets_schema.md#interpolate) for an example on how to use environment variables to minimize the risk.
{{< /alert >}}
For more information on the passthrough syntax to use, see [Schema](../pipeline/custom_rulesets_schema.md#schema).
### Extend the default ruleset
You can also extend the [default ruleset](../detected_secrets.md) configuration with additional rules as appropriate. This can be helpful when you would still like to benefit from the high-confidence predefined rules maintained by GitLab in the default ruleset, but also want to add rules for types of secrets that may be used in your own projects and namespaces. New rules must follow the [custom rule format](custom_rulesets_schema.md#custom-rule-format).
#### With a local ruleset
You can use a `file` passthrough to extend the default ruleset to add additional rules.
Add the following to the `.gitlab/secret-detection-ruleset.toml` configuration file stored in the same repository, and adjust the `value` as appropriate to point to the path of the extended configuration file:
```toml
# .gitlab/secret-detection-ruleset.toml
[secrets]
[[secrets.passthrough]]
type = "file"
target = "gitleaks.toml"
value = "extended-gitleaks-config.toml"
```
The extended configuration stored in `extended-gitleaks-config.toml` is included in the configuration used by the analyzer
in the CI/CD pipeline.
In the example below, we add a couple of new `[[rules]]` sections that define a number of regular expressions to be detected:
```toml
# extended-gitleaks-config.toml
[extend]
# Extends default packaged ruleset, NOTE: do not change the path.
path = "/gitleaks.toml"
[[rules]]
id = "example_api_key"
description = "Example Service API Key"
regex = '''example_api_key'''
[[rules]]
id = "example_api_secret"
description = "Example Service API Secret"
regex = '''example_api_secret'''
```
With this ruleset configuration the analyzer detects any strings matching with those two defined regex patterns.
For more information on the passthrough syntax to use, see [Schema](../pipeline/custom_rulesets_schema.md#schema).
#### With a remote ruleset
Similar to how you can replace the default ruleset with a remote ruleset, you can also extend the default ruleset with configuration stored in a remote Git repository or file stored external to the repository in which you have the `.gitlab/secret-detection-ruleset.toml` configuration file.
This can be achieved by using either of the `git` or `url` passthroughs as discussed previously.
To do that with a `git` passthrough, add the following to `.gitlab/secret-detection-ruleset.toml` configuration file stored in the same repository, and adjust the `value`, `ref`, and `subdir` as appropriate to point to the path of the extended configuration file:
```toml
# .gitlab/secret-detection-ruleset.toml in https://gitlab.com/user_group/basic_repository
[secrets]
[[secrets.passthrough]]
type = "git"
ref = "main"
subdir = "config"
value = "https://gitlab.com/user_group/central_repository_with_shared_ruleset"
```
Pipeline secret detection assumes the remote ruleset configuration file is called `gitleaks.toml`, and is stored in `config` directory on the `main` branch of the referenced repository.
To extend the default ruleset, the `gitleaks.toml` file should use `[extend]` directive similar to the example above:
```toml
# https://gitlab.com/user_group/central_repository_with_shared_ruleset/-/raw/main/config/gitleaks.toml
[extend]
# Extends default packaged ruleset, NOTE: do not change the path.
path = "/gitleaks.toml"
[[rules]]
id = "example_api_key"
description = "Example Service API Key"
regex = '''example_api_key'''
[[rules]]
id = "example_api_secret"
description = "Example Service API Secret"
regex = '''example_api_secret'''
```
To use a `url` passthrough, add the following to `.gitlab/secret-detection-ruleset.toml` configuration file stored in the same repository, and adjust the `value` as appropriate to point to the path of the extended configuration file
```toml
# .gitlab/secret-detection-ruleset.toml in https://gitlab.com/user_group/basic_repository
[secrets]
[[secrets.passthrough]]
type = "url"
target = "gitleaks.toml"
value = "https://example.com/gitleaks.toml"
```
For more information on the passthrough syntax to use, see [Schema](../pipeline/custom_rulesets_schema.md#schema).
### Ignore patterns and paths
There may be situations in which you need to ignore a certain pattern or path from being detected by pipeline secret detection. For example, you may have a file including fake secrets to be used in a test suite.
In that case, you can utilize [Gitleaks' native `[allowlist]`](https://github.com/gitleaks/gitleaks#configuration) directive to ignore specific patterns or paths.
{{< alert type="note" >}}
This feature works regardless of whether you're using a local or a remote ruleset configuration file. The examples below utilizes a local ruleset using `file` passthrough though.
{{< /alert >}}
To ignore a pattern, add the following to the `.gitlab/secret-detection-ruleset.toml` configuration file stored in the same repository, and adjust the `value` as appropriate to point to the path of the extended configuration file:
```toml
# .gitlab/secret-detection-ruleset.toml
[secrets]
[[secrets.passthrough]]
type = "file"
target = "gitleaks.toml"
value = "extended-gitleaks-config.toml"
```
The extended configuration stored in `extended-gitleaks-config.toml` will be included in the configuration used by the analyzer.
In the example below, we add an `[allowlist]` directive that defines a regex that matches the secret to be ignored ("allowed"):
```toml
# extended-gitleaks-config.toml
[extend]
# Extends default packaged ruleset, NOTE: do not change the path.
path = "/gitleaks.toml"
[allowlist]
description = "allowlist of patterns to ignore in detection"
regexTarget = "match"
regexes = [
'''glpat-[0-9a-zA-Z_\\-]{20}'''
]
```
This ignores any string matching `glpat-` with a suffix of 20 characters of digits and letters.
Similarly, you can exclude specific paths from being scanned. In the example below, we define an array of paths to ignore under the `[allowlist]` directive. A path could either be a regular expression, or a specific file path:
```toml
# extended-gitleaks-config.toml
[extend]
# Extends default packaged ruleset, NOTE: do not change the path.
path = "/gitleaks.toml"
[allowlist]
description = "allowlist of patterns to ignore in detection"
paths = [
'''/gitleaks.toml''',
'''(.*?)(jpg|gif|doc|pdf|bin|svg|socket)'''
]
```
This ignores any secrets detected in either `/gitleaks.toml` file or any file ending with one of the specified extensions.
For more information on the passthrough syntax to use, see [Schema](../pipeline/custom_rulesets_schema.md#schema).
### Ignore secrets inline
In some instances, you might want to ignore a secret inline. For example, you may have a fake secret in an example or a test suite. In these instances, you will want to ignore the secret instead of having it reported as a vulnerability.
To ignore a secret, add `gitleaks:allow` as a comment to the line that contains the secret.
For example:
```ruby
"A personal token for GitLab will look like glpat-JUST20LETTERSANDNUMB" # gitleaks:allow
```
### Detecting complex strings
The [default ruleset](_index.md#detected-secrets) provides patterns to detect structured strings with a low rate of false positives.
However, you might want to detect more complex strings like passwords. Because [Gitleaks doesn't support lookahead or lookbehind](https://github.com/google/re2/issues/411),
writing a high-confidence, general rule to detect unstructured strings is not possible.
Although you can't detect every complex string, you can extend your ruleset to meet specific use cases.
For example, this rule modifies the [`generic-api-key` rule](https://github.com/gitleaks/gitleaks/blob/4e43d1109303568509596ef5ef576fbdc0509891/config/gitleaks.toml#L507-L514) from the Gitleaks default ruleset:
```regex
(?i)(?:pwd|passwd|password)(?:[0-9a-z\-_\t .]{0,20})(?:[\s|']|[\s|"]){0,3}(?:=|>|=:|:{1,3}=|\|\|:|<=|=>|:|\?=)(?:'|\"|\s|=|\x60){0,5}([0-9a-z\-_.=\S_]{3,50})(?:['|\"|\n|\r|\s|\x60|;]|$)
```
This regular expression matches:
1. A case-insensitive identifier that starts with `pwd`, or `passwd` or `password`. You can adjust this with other variations like `secret` or `key`.
1. A suffix that follows the identifier. The suffix is a combination of digits, letters, and symbols, and is between zero and 23 characters long.
1. Commonly used assignment operators, like `=`, `:=`, `:`, or `=>`.
1. A secret prefix, often used as a boundary to help with detecting the secret.
1. A string of digits, letters, and symbols, which is between three and 50 characters long. This is the secret itself. If you expect longer strings, you can adjust the length.
1. A secret suffix, often used as a boundary. This matches common endings like ticks, line breaks, and new lines.
Here are example strings which are matched by this regular expression:
```plaintext
pwd = password1234
passwd = 'p@ssW0rd1234'
password = thisismyverylongpassword
password => mypassword
password := mypassword
password: password1234
"password" = "p%ssward1234"
'password': 'p@ssW0rd1234'
```
To use this regex, extend your ruleset with one of the methods documented on this page.
For example, imagine you wish to extend the default ruleset [with a local ruleset](#with-a-local-ruleset-1) that includes this rule.
Add the following to a `.gitlab/secret-detection-ruleset.toml` configuration file stored in the same repository. Adjust the `value` to point to the path of the extended configuration file:
```toml
# .gitlab/secret-detection-ruleset.toml
[secrets]
[[secrets.passthrough]]
type = "file"
target = "gitleaks.toml"
value = "extended-gitleaks-config.toml"
```
In `extended-gitleaks-config.toml` file, add a new `[[rules]]` section with the regular expression you want to use:
```toml
# extended-gitleaks-config.toml
[extend]
# Extends default packaged ruleset, NOTE: do not change the path.
path = "/gitleaks.toml"
[[rules]]
description = "Generic Password Rule"
id = "generic-password"
regex = '''(?i)(?:pwd|passwd|password)(?:[0-9a-z\-_\t .]{0,20})(?:[\s|']|[\s|"]){0,3}(?:=|>|=:|:{1,3}=|\|\|:|<=|=>|:|\?=)(?:'|\"|\s|=|\x60){0,5}([0-9a-z\-_.=\S_]{3,50})(?:['|\"|\n|\r|\s|\x60|;]|$)'''
entropy = 3.5
keywords = ["pwd", "passwd", "password"]
```
{{< alert type="note" >}}
This example configuration is provided only for convenience, and might not work
for all use cases. If you configure your ruleset to detect complex strings, you might
create a large number of false positives, or fail to capture certain patterns.
{{< /alert >}}
## Available CI/CD variables
Pipeline secret detection can be customized by defining available CI/CD variables:
| CI/CD variable | Default value | Description |
|-----------------------------------|---------------|-------------|
| `SECRET_DETECTION_EXCLUDED_PATHS` | "" | Exclude vulnerabilities from output based on the paths. The paths are a comma-separated list of patterns. Patterns can be globs (see [`doublestar.Match`](https://pkg.go.dev/github.com/bmatcuk/doublestar/v4@v4.0.2#Match) for supported patterns), or file or folder paths (for example, `doc,spec` ). Parent directories also match patterns. Detected secrets previously added to the vulnerability report are not removed. [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/225273) in GitLab 13.3. |
| `SECRET_DETECTION_HISTORIC_SCAN` | false | Flag to enable a historic Gitleaks scan. |
| `SECRET_DETECTION_IMAGE_SUFFIX` | "" | Suffix added to the image name. If set to `-fips`, `FIPS-enabled` images are used for scan. See [Use FIPS-enabled images](_index.md#fips-enabled-images) for more details. [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/355519) in GitLab 14.10. |
| `SECRET_DETECTION_LOG_OPTIONS` | "" | [`git log`](https://git-scm.com/docs/git-log) options used to define commit ranges. [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/350660) in GitLab 15.1.|
In previous GitLab versions, the following variables were also available:
| CI/CD variable | Default value | Description |
|-----------------------------------|---------------|-------------|
| `SECRET_DETECTION_COMMIT_FROM` | - | The commit a Gitleaks scan starts at. [Removed](https://gitlab.com/gitlab-org/gitlab/-/issues/243564) in GitLab 13.5. Replaced with `SECRET_DETECTION_COMMITS`. |
| `SECRET_DETECTION_COMMIT_TO` | - | The commit a Gitleaks scan ends at. [Removed](https://gitlab.com/gitlab-org/gitlab/-/issues/243564) in GitLab 13.5. Replaced with `SECRET_DETECTION_COMMITS`. |
| `SECRET_DETECTION_COMMITS` | - | The list of commits that Gitleaks should scan. [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/243564) in GitLab 13.5. [Removed](https://gitlab.com/gitlab-org/gitlab/-/issues/352565) in GitLab 15.0. |
## Offline configuration
{{< details >}}
- Tier: Premium, Ultimate
- Offering: GitLab Self-Managed
{{< /details >}}
An offline environment has limited, restricted, or intermittent access to external resources through
the internet. For instances in such an environment, pipeline secret detection requires
some configuration changes. The instructions in this section must be completed together with the
instructions detailed in [offline environments](../../offline_deployments/_index.md).
### Configure GitLab Runner
By default, a runner tries to pull Docker images from the GitLab container registry even if a local
copy is available. You should use this default setting, to ensure Docker images remain current.
However, if no network connectivity is available, you must change the default GitLab Runner
`pull_policy` variable.
Configure the GitLab Runner CI/CD variable `pull_policy` to
[`if-not-present`](https://docs.gitlab.com/runner/executors/docker.html#using-the-if-not-present-pull-policy).
### Use local pipeline secret detection analyzer image
Use a local pipeline secret detection analyzer image if you want to obtain the image from a local Docker
registry instead of the GitLab container registry.
Prerequisites:
- Importing Docker images into a local offline Docker registry depends on your
network security policy. Consult your IT staff to find an accepted and approved process
to import or temporarily access external resources.
1. Import the default pipeline secret detection analyzer image from `registry.gitlab.com` into your
[local Docker container registry](../../../packages/container_registry/_index.md):
```plaintext
registry.gitlab.com/security-products/secrets:6
```
The pipeline secret detection analyzer's image is [periodically updated](../../_index.md#vulnerability-scanner-maintenance)
so you should periodically update the local copy.
1. Set the CI/CD variable `SECURE_ANALYZERS_PREFIX` to the local Docker container registry.
```yaml
include:
- template: Jobs/Secret-Detection.gitlab-ci.yml
variables:
SECURE_ANALYZERS_PREFIX: "localhost:5000/analyzers"
```
The pipeline secret detection job should now use the local copy of the analyzer Docker image,
without requiring internet access.
## Using a custom SSL CA certificate authority
To trust a custom Certificate Authority, set the `ADDITIONAL_CA_CERT_BUNDLE` variable to the bundle
of CA certificates that you trust. Do this either in the `.gitlab-ci.yml` file, in a file
variable, or as a CI/CD variable.
- In the `.gitlab-ci.yml` file, the `ADDITIONAL_CA_CERT_BUNDLE` value must contain the
[text representation of the X.509 PEM public-key certificate](https://www.rfc-editor.org/rfc/rfc7468#section-5.1).
For example:
```yaml
variables:
ADDITIONAL_CA_CERT_BUNDLE: |
-----BEGIN CERTIFICATE-----
MIIGqTCCBJGgAwIBAgIQI7AVxxVwg2kch4d56XNdDjANBgkqhkiG9w0BAQsFADCB
...
jWgmPqF3vUbZE0EyScetPJquRFRKIesyJuBFMAs=
-----END CERTIFICATE-----
```
- If using a file variable, set the value of `ADDITIONAL_CA_CERT_BUNDLE` to the path to the
certificate.
- If using a variable, set the value of `ADDITIONAL_CA_CERT_BUNDLE` to the text
representation of the certificate.
## Demos
There are [demonstration projects](https://gitlab.com/gitlab-org/security-products/demos/analyzer-configurations/secret-detection) that illustrate some of these configuration options.
Below is a table with the demonstration projects and their associated workflows:
| Action/Workflow | Applies to/via | With inline or local ruleset | With remote ruleset |
| ----------------------- | -------------- | ------------------ | ------------------- |
| Disable a rule | Predefined rules | [Local Ruleset](https://gitlab.com/gitlab-org/security-products/demos/analyzer-configurations/secret-detection/modify-default-ruleset/local-ruleset/disable-rule-project/-/blob/main/.gitlab/secret-detection-ruleset.toml?ref_type=heads) / [Project](https://gitlab.com/gitlab-org/security-products/demos/analyzer-configurations/secret-detection/modify-default-ruleset/local-ruleset/disable-rule-project) | [Remote Ruleset](https://gitlab.com/gitlab-org/security-products/demos/analyzer-configurations/secret-detection/modify-default-ruleset/remote-ruleset/disable-rule-ruleset) / [Project](https://gitlab.com/gitlab-org/security-products/demos/analyzer-configurations/secret-detection/modify-default-ruleset/remote-ruleset/disable-rule-project) |
| Override a rule | Predefined rules | [Local Ruleset](https://gitlab.com/gitlab-org/security-products/demos/analyzer-configurations/secret-detection/modify-default-ruleset/local-ruleset/override-rule-project/-/blob/main/.gitlab/secret-detection-ruleset.toml?ref_type=heads) / [Project](https://gitlab.com/gitlab-org/security-products/demos/analyzer-configurations/secret-detection/modify-default-ruleset/local-ruleset/override-rule-project) | [Remote Ruleset](https://gitlab.com/gitlab-org/security-products/demos/analyzer-configurations/secret-detection/modify-default-ruleset/remote-ruleset/override-rule-ruleset) / [Project](https://gitlab.com/gitlab-org/security-products/demos/analyzer-configurations/secret-detection/modify-default-ruleset/remote-ruleset/override-rule-project) |
| Replace default ruleset | File Passthrough | [Local Ruleset](https://gitlab.com/gitlab-org/security-products/demos/analyzer-configurations/secret-detection/replace-default-ruleset/file-passthrough/-/blob/main/config/gitleaks.toml) / [Project](https://gitlab.com/gitlab-org/security-products/demos/analyzer-configurations/secret-detection/replace-default-ruleset/file-passthrough) | Not applicable |
| Replace default ruleset | Raw Passthrough | [Inline Ruleset](https://gitlab.com/gitlab-org/security-products/demos/analyzer-configurations/secret-detection/replace-default-ruleset/raw-passthrough/-/blob/main/.gitlab/secret-detection-ruleset.toml?ref_type=heads) / [Project](https://gitlab.com/gitlab-org/security-products/demos/analyzer-configurations/secret-detection/replace-default-ruleset/raw-passthrough) | Not applicable |
| Replace default ruleset | Git Passthrough | Not applicable | [Remote Ruleset](https://gitlab.com/gitlab-org/security-products/tests/secrets-passthrough-git-and-url-test/-/blob/config-demos-replace/config/gitleaks.toml) / [Project](https://gitlab.com/gitlab-org/security-products/demos/analyzer-configurations/secret-detection/replace-default-ruleset/git-passthrough) |
| Replace default ruleset | URL Passthrough | Not applicable | [Remote Ruleset](https://gitlab.com/gitlab-org/security-products/tests/secrets-passthrough-git-and-url-test/-/blob/config-demos-replace/config/gitleaks.toml) / [Project](https://gitlab.com/gitlab-org/security-products/demos/analyzer-configurations/secret-detection/replace-default-ruleset/url-passthrough) |
| Extend default ruleset | File Passthrough | [Local Ruleset](https://gitlab.com/gitlab-org/security-products/demos/analyzer-configurations/secret-detection/extend-default-ruleset/file-passthrough/-/blob/main/config/extended-gitleaks-config.toml) / [Project](https://gitlab.com/gitlab-org/security-products/demos/analyzer-configurations/secret-detection/extend-default-ruleset/file-passthrough) | Not applicable |
| Extend default ruleset | Git Passthrough | Not applicable | [Remote Ruleset](https://gitlab.com/gitlab-org/security-products/tests/secrets-passthrough-git-and-url-test/-/blob/config-demos-extend/config/gitleaks.toml) / [Project](https://gitlab.com/gitlab-org/security-products/demos/analyzer-configurations/secret-detection/extend-default-ruleset/git-passthrough) |
| Extend default ruleset | URL Passthrough | Not applicable | [Remote Ruleset](https://gitlab.com/gitlab-org/security-products/tests/secrets-passthrough-git-and-url-test/-/blob/config-demos-extend/config/gitleaks.toml) / [Project](https://gitlab.com/gitlab-org/security-products/demos/analyzer-configurations/secret-detection/extend-default-ruleset/url-passthrough) |
| Ignore paths | File Passthrough | [Local Ruleset](https://gitlab.com/gitlab-org/security-products/demos/analyzer-configurations/secret-detection/ignore-paths/file-passthrough/-/blob/main/config/extended-gitleaks-config.toml) / [Project](https://gitlab.com/gitlab-org/security-products/demos/analyzer-configurations/secret-detection/ignore-paths/file-passthrough) | Not applicable |
| Ignore paths | Git Passthrough | Not applicable | [Remote Ruleset](https://gitlab.com/gitlab-org/security-products/tests/secrets-passthrough-git-and-url-test/-/blob/config-demos-ignore-paths/config/gitleaks.toml) / [Project](https://gitlab.com/gitlab-org/security-products/demos/analyzer-configurations/secret-detection/ignore-paths/git-passthrough) |
| Ignore paths | URL Passthrough | Not applicable | [Remote Ruleset](https://gitlab.com/gitlab-org/security-products/tests/secrets-passthrough-git-and-url-test/-/blob/config-demos-ignore-paths/config/gitleaks.toml) / [Project](https://gitlab.com/gitlab-org/security-products/demos/analyzer-configurations/secret-detection/ignore-paths/url-passthrough) |
| Ignore patterns | File Passthrough | [Local Ruleset](https://gitlab.com/gitlab-org/security-products/demos/analyzer-configurations/secret-detection/ignore-patterns/file-passthrough/-/blob/main/config/extended-gitleaks-config.toml) / [Project](https://gitlab.com/gitlab-org/security-products/demos/analyzer-configurations/secret-detection/ignore-patterns/file-passthrough) | Not applicable |
| Ignore patterns | Git Passthrough | Not applicable | [Remote Ruleset](https://gitlab.com/gitlab-org/security-products/tests/secrets-passthrough-git-and-url-test/-/blob/config-demos-ignore-patterns/config/gitleaks.toml) / [Project](https://gitlab.com/gitlab-org/security-products/demos/analyzer-configurations/secret-detection/ignore-patterns/git-passthrough) |
| Ignore patterns | URL Passthrough | Not applicable | [Remote Ruleset](https://gitlab.com/gitlab-org/security-products/tests/secrets-passthrough-git-and-url-test/-/blob/config-demos-ignore-patterns/config/gitleaks.toml) / [Project](https://gitlab.com/gitlab-org/security-products/demos/analyzer-configurations/secret-detection/ignore-patterns/url-passthrough) |
| Ignore values | File Passthrough | [Local Ruleset](https://gitlab.com/gitlab-org/security-products/demos/analyzer-configurations/secret-detection/ignore-values/file-passthrough/-/blob/main/config/extended-gitleaks-config.toml) / [Project](https://gitlab.com/gitlab-org/security-products/demos/analyzer-configurations/secret-detection/ignore-values/file-passthrough) | Not applicable |
| Ignore values | Git Passthrough | Not applicable | [Remote Ruleset](https://gitlab.com/gitlab-org/security-products/tests/secrets-passthrough-git-and-url-test/-/blob/config-demos-ignore-values/config/gitleaks.toml) / [Project](https://gitlab.com/gitlab-org/security-products/demos/analyzer-configurations/secret-detection/ignore-values/git-passthrough) |
| Ignore values | URL Passthrough | Not applicable | [Remote Ruleset](https://gitlab.com/gitlab-org/security-products/tests/secrets-passthrough-git-and-url-test/-/blob/config-demos-ignore-values/config/gitleaks.toml) / [Project](https://gitlab.com/gitlab-org/security-products/demos/analyzer-configurations/secret-detection/ignore-values/url-passthrough) |
There are also some video demonstrations walking through setting up remote rulesets:
- [Secret detection with local and remote ruleset](https://youtu.be/rsN1iDug5GU)

4
doc/user/application_security/secret_detection/pipeline/custom_rulesets_schema.md
View File

@ -12,7 +12,7 @@ title: Custom rulesets schema
{{< /details >}}
You can use [different kinds of ruleset customizations](../pipeline/_index.md#customize-analyzer-rulesets)
You can use [different kinds of ruleset customizations](../pipeline/configure.md#customize-analyzer-rulesets)
to customize the behavior of pipeline secret detection.
## Schema
@ -244,7 +244,7 @@ The size of the configuration generated by a single passthrough is limited to 10
| `mode` | All | If `overwrite`, the `target` file is overwritten. If `append`, new content is appended to the `target` file. The `git` type only supports `overwrite`. (Default: `overwrite`) |
| `ref` | `type = "git"` | Contains the name of the branch, tag, or the SHA to pull. |
| `subdir` | `type = "git"` | Used to select a subdirectory of the Git repository as the configuration source. |
| `auth` | `type = "git"` | Used to provide credentials to use when using a [configuration stored in a private Git repository](../pipeline/_index.md#with-a-private-remote-ruleset). |
| `auth` | `type = "git"` | Used to provide credentials to use when using a [configuration stored in a private Git repository](../pipeline/configure.md#with-a-private-remote-ruleset). |
| `value` | All | For the `file`, `url`, and `git` types, defines the location of the file or Git repository. For the `raw` type, contains the inline configuration. |
| `validator` | All | Used to explicitly invoke validators (`xml`, `yaml`, `json`, `toml`) on the target file after the evaluation of a passthrough. |

BIN
doc/user/img/markdown_alerts_v17_10.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 22 KiB

18
doc/user/markdown.md
View File

@ -1646,37 +1646,37 @@ Alerts can be used to highlight or call attention to something. The alert syntax
uses the Markdown blockquote syntax followed by the type of alert.
You can use alerts in any text box that supports Markdown.
There are 5 alert types:
You can use the following types of alerts:
- Note: Calls attention to information that may be useful to the user:
- Note: information that users should take into account, even when skimming:
```markdown
> [!note]
> The following information is useful.
```
- Tip: Advice that may be useful:
- Tip: Optional information to help a user be more successful:
```markdown
> [!tip]
> Tip of the day.
```
- Important: Information that is important to know:
- Important: Crucial information necessary for users to succeed:
```markdown
> [!important]
> This is something important you should know.
```
- Caution: There are possible negative consequences:
- Caution: Negative potential consequences of an action:
```markdown
> [!caution]
> You need to be very careful about the following.
```
- Warning: Something is potentially dangerous or risky:
- Warning: Critical potential risks:
```markdown
> [!warning]
@ -1684,7 +1684,7 @@ There are 5 alert types:
```
The title text shown for an alert defaults to the name of the alert. For example,
`> [!warning]` alert will have the title `Warning`.
`> [!warning]` alert has the title `Warning`.
To override an alert block's title, enter any text on the same line.
For example, to use the warning color but have `Data deletion` as the title:
@ -1706,6 +1706,10 @@ You should consider the following ramifications:
>>>
```
The alerts render as:
![How Markdown alerts are rendered in GitLab](img/markdown_alerts_v17_10.png)
## Colors
[View this topic rendered in GitLab](https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/user/markdown.md#colors).

4
package.json
View File

@ -63,7 +63,7 @@
"@gitlab/fonts": "^1.3.0",
"@gitlab/query-language-rust": "0.4.0",
"@gitlab/svgs": "3.123.0",
"@gitlab/ui": "108.9.0",
"@gitlab/ui": "108.10.0",
"@gitlab/vue-router-vue3": "npm:vue-router@4.5.0",
"@gitlab/vuex-vue3": "npm:vuex@4.1.0",
"@gitlab/web-ide": "^0.0.1-dev-20250211142744",
@ -277,7 +277,7 @@
"eslint-import-resolver-webpack": "0.13.10",
"eslint-plugin-import": "^2.31.0",
"eslint-plugin-local-rules": "^3.0.2",
"eslint-plugin-no-jquery": "3.1.0",
"eslint-plugin-no-jquery": "3.1.1",
"eslint-plugin-no-unsanitized": "^4.1.2",
"fake-indexeddb": "^4.0.1",
"gettext-extractor": "^3.7.0",

2
qa/gdk/Dockerfile.gdk
View File

@ -1,4 +1,4 @@
ARG GDK_SHA=931439442a9f64f20b9a173a81f8306c7c3a4a66
ARG GDK_SHA=af3f6a68f68ead604bbda99726049b777f1beb6b
# Use tag prefix when running on 'stable' branch to make sure 'protected' image is used which is not deleted by registry cleanup
ARG GDK_BASE_TAG_PREFIX

3
spec/lib/gitlab/database/sharding_key_spec.rb
View File

@ -204,7 +204,8 @@ RSpec.describe 'new tables missing sharding_key', feature_category: :cell do
"oauth_device_grants" => "https://gitlab.com/gitlab-org/gitlab/-/issues/496717",
"uploads" => "https://gitlab.com/gitlab-org/gitlab/-/issues/398199",
"bulk_import_trackers" => "https://gitlab.com/gitlab-org/gitlab/-/issues/517823",
"ai_duo_chat_events" => "https://gitlab.com/gitlab-org/gitlab/-/issues/516140"
"ai_duo_chat_events" => "https://gitlab.com/gitlab-org/gitlab/-/issues/516140",
"fork_networks" => "https://gitlab.com/gitlab-org/gitlab/-/issues/522958"
}
has_lfk = ->(lfks) { lfks.any? { |k| k.options[:column] == 'organization_id' && k.to_table == 'organizations' } }

2
spec/models/integration_spec.rb
View File

@ -1777,6 +1777,6 @@ RSpec.describe Integration, feature_category: :integrations do
describe '.instance_specific_integration_types' do
subject { described_class.instance_specific_integration_types }
it { is_expected.to eq(['Integrations::BeyondIdentity']) }
it { is_expected.to include('Integrations::BeyondIdentity') }
end
end

73
spec/models/work_item_spec.rb
View File

@ -187,16 +187,79 @@ RSpec.describe WorkItem, feature_category: :portfolio_management do
end
describe '#widgets' do
subject { build(:work_item).widgets }
subject(:work_item) { build(:work_item) }
it 'returns instances of supported widgets' do
is_expected.to include(
expect(work_item.widgets).to match_array([
instance_of(WorkItems::Widgets::Assignees),
instance_of(WorkItems::Widgets::AwardEmoji),
instance_of(WorkItems::Widgets::CrmContacts),
instance_of(WorkItems::Widgets::CurrentUserTodos),
instance_of(WorkItems::Widgets::Description),
instance_of(WorkItems::Widgets::Designs),
instance_of(WorkItems::Widgets::Development),
instance_of(WorkItems::Widgets::EmailParticipants),
instance_of(WorkItems::Widgets::ErrorTracking),
instance_of(WorkItems::Widgets::Hierarchy),
instance_of(WorkItems::Widgets::Labels),
instance_of(WorkItems::Widgets::Assignees),
instance_of(WorkItems::Widgets::StartAndDueDate)
)
instance_of(WorkItems::Widgets::LinkedItems),
instance_of(WorkItems::Widgets::Milestone),
instance_of(WorkItems::Widgets::Notes),
instance_of(WorkItems::Widgets::Notifications),
instance_of(WorkItems::Widgets::Participants),
instance_of(WorkItems::Widgets::StartAndDueDate),
instance_of(WorkItems::Widgets::TimeTracking)
])
end
context 'when filters are given' do
context 'when both only_types and except_types are given' do
it 'raises an error' do
expect { work_item.widgets(only_types: [true], except_types: [true]) }
.to raise_error(ArgumentError, 'Only one filter is allowed')
end
end
context 'when filtering by only_types' do
it 'only returns widgets on the given list' do
expect(work_item.widgets(only_types: [:milestone, :description])).to match_array([
instance_of(WorkItems::Widgets::Milestone),
instance_of(WorkItems::Widgets::Description)
])
end
end
context 'when passing explicitly nil to except_types' do
it 'only returns widgets on the given list' do
expect(work_item.widgets(only_types: [:milestone, :description], except_types: nil)).to match_array([
instance_of(WorkItems::Widgets::Milestone),
instance_of(WorkItems::Widgets::Description)
])
end
end
context 'when filtering by except_types' do
it 'only returns widgets on the given list' do
expect(work_item.widgets(except_types: [:milestone, :description])).to match_array([
instance_of(WorkItems::Widgets::Assignees),
instance_of(WorkItems::Widgets::AwardEmoji),
instance_of(WorkItems::Widgets::CrmContacts),
instance_of(WorkItems::Widgets::CurrentUserTodos),
instance_of(WorkItems::Widgets::Designs),
instance_of(WorkItems::Widgets::Development),
instance_of(WorkItems::Widgets::EmailParticipants),
instance_of(WorkItems::Widgets::ErrorTracking),
instance_of(WorkItems::Widgets::Hierarchy),
instance_of(WorkItems::Widgets::Labels),
instance_of(WorkItems::Widgets::LinkedItems),
instance_of(WorkItems::Widgets::Notes),
instance_of(WorkItems::Widgets::Notifications),
instance_of(WorkItems::Widgets::Participants),
instance_of(WorkItems::Widgets::StartAndDueDate),
instance_of(WorkItems::Widgets::TimeTracking)
])
end
end
end
end

58
spec/requests/api/graphql/work_item_spec.rb
View File

@ -791,6 +791,64 @@ RSpec.describe 'Query.work_item(id)', feature_category: :team_planning do
)
end
end
context 'when filtering' do
context 'when selecting widgets' do
let(:work_item_fields) do
<<~GRAPHQL
id
widgets(onlyTypes: [DESCRIPTION]) {
type
}
GRAPHQL
end
it 'only returns selected widgets' do
expect(work_item_data).to include(
'id' => work_item.to_gid.to_s,
'widgets' => [{
'type' => 'DESCRIPTION'
}]
)
end
end
context 'when excluding widgets' do
let(:work_item_fields) do
<<~GRAPHQL
id
widgets(exceptTypes: [DESCRIPTION]) {
type
}
GRAPHQL
end
it 'does not return excluded widgets' do
expect(work_item_data).to include(
'id' => work_item.to_gid.to_s,
'widgets' => [
{ "type" => "ASSIGNEES" },
{ "type" => "AWARD_EMOJI" },
{ "type" => "CRM_CONTACTS" },
{ "type" => "CURRENT_USER_TODOS" },
{ "type" => "DESIGNS" },
{ "type" => "DEVELOPMENT" },
{ "type" => "EMAIL_PARTICIPANTS" },
{ "type" => "ERROR_TRACKING" },
{ "type" => "HIERARCHY" },
{ "type" => "LABELS" },
{ "type" => "LINKED_ITEMS" },
{ "type" => "MILESTONE" },
{ "type" => "NOTES" },
{ "type" => "NOTIFICATIONS" },
{ "type" => "PARTICIPANTS" },
{ "type" => "START_AND_DUE_DATE" },
{ "type" => "TIME_TRACKING" }
]
)
end
end
end
end
describe 'notes widget' do

23
yarn.lock
View File

@ -1412,7 +1412,7 @@
resolved "https://registry.yarnpkg.com/@gitlab/fonts/-/fonts-1.3.0.tgz#df89c1bb6714e4a8a5d3272568aa4de7fb337267"
integrity sha512-DoMUIN3DqjEn7wvcxBg/b7Ite5fTdF5EmuOZoBRo2j0UBGweDXmNBi+9HrTZs4cBU660dOxcf1hATFcG3npbPg==
"@gitlab/noop@^1.0.1", jackspeak@^3.1.2, "jackspeak@npm:@gitlab/noop@1.0.1":
"@gitlab/noop@^1.0.1":
version "1.0.1"
resolved "https://registry.yarnpkg.com/@gitlab/noop/-/noop-1.0.1.tgz#71a831146ee02732b4a61d2d3c11204564753454"
integrity sha512-s++4wjMYeDvBp9IO59DBrWjy8SE/gFkjTDO5ck2W0S6Vv7OlqgErwL7pHngAnrSmTJAzyUG8wHGqo0ViS4jn5Q==
@ -1436,10 +1436,10 @@
resolved "https://registry.yarnpkg.com/@gitlab/svgs/-/svgs-3.123.0.tgz#1fa3b1a709755ff7c8ef67e18c0442101655ebf0"
integrity sha512-yjVn+utOTIKk8d9JlvGo6EgJ4TQ+CKpe3RddflAqtsQqQuL/2MlVdtaUePybxYzWIaumFuh5LouQ6BrWyw1niQ==
"@gitlab/ui@108.9.0":
version "108.9.0"
resolved "https://registry.yarnpkg.com/@gitlab/ui/-/ui-108.9.0.tgz#bfc2e48d79fea22b1c3b0bf20e89cbe46f46e32b"
integrity sha512-6wcSK040l9+7ppHzx4ab78oGpJmT5cjOtytoezA9plBq1tpbbFd7ENt7DH0ZWxP9A8M8wVR7D8N1EzGKjesahQ==
"@gitlab/ui@108.10.0":
version "108.10.0"
resolved "https://registry.yarnpkg.com/@gitlab/ui/-/ui-108.10.0.tgz#9434054c9e44b395604b2d55416c83c84fdd09ac"
integrity sha512-xfrDcA/UKlhVEGJAhvdiK1qLy7GEABiRWhJmjkoBZRMjr4Q6dpjqVlr8s7hQf9FMdI6tMVbbV3bGBuMPsGNzLA==
dependencies:
"@floating-ui/dom" "1.4.3"
echarts "^5.3.2"
@ -7389,10 +7389,10 @@ eslint-plugin-local-rules@^3.0.2:
resolved "https://registry.yarnpkg.com/eslint-plugin-local-rules/-/eslint-plugin-local-rules-3.0.2.tgz#84c02ea1d604ecb00970779ad27f00738ff361ae"
integrity sha512-IWME7GIYHXogTkFsToLdBCQVJ0U4kbSuVyDT+nKoR4UgtnVrrVeNWuAZkdEu1nxkvi9nsPccGehEEF6dgA28IQ==
eslint-plugin-no-jquery@3.1.0:
version "3.1.0"
resolved "https://registry.yarnpkg.com/eslint-plugin-no-jquery/-/eslint-plugin-no-jquery-3.1.0.tgz#5eb669405a0b3b6924cf63b8549349cf41235619"
integrity sha512-Ze+eRlAbLAoceBqMXI2E9s6o3dC7zE75niP2Sy4D8I/u1TyLegrIpjc4emPN90dH0IA+uXNUmQbzBuCaihxwIQ==
eslint-plugin-no-jquery@3.1.1:
version "3.1.1"
resolved "https://registry.yarnpkg.com/eslint-plugin-no-jquery/-/eslint-plugin-no-jquery-3.1.1.tgz#5fbd5a1b769f03bbd6dbe19f6c7769669759d75a"
integrity sha512-LTLO3jH/Tjr1pmxCEqtV6qmt+OChv8La4fwgG470JRpgxyFF4NOzoC9CRy92GIWD3Yjl0qLEgPmD2FLQWcNEjg==
eslint-plugin-no-unsanitized@^4.1.2:
version "4.1.2"
@ -9393,6 +9393,11 @@ iterall@^1.2.1:
resolved "https://registry.yarnpkg.com/iterall/-/iterall-1.3.0.tgz#afcb08492e2915cbd8a0884eb93a8c94d0d72fea"
integrity sha512-QZ9qOMdF+QLHxy1QIpUHUU1D5pS2CG2P69LF6L6CPjPYA/XMOmKV3PZpawHoAjHNyB0swdVTRxdYT4tbBbxqwg==
jackspeak@^3.1.2, "jackspeak@npm:@gitlab/noop@1.0.1":
version "1.0.1"
resolved "https://registry.yarnpkg.com/@gitlab/noop/-/noop-1.0.1.tgz#71a831146ee02732b4a61d2d3c11204564753454"
integrity sha512-s++4wjMYeDvBp9IO59DBrWjy8SE/gFkjTDO5ck2W0S6Vv7OlqgErwL7pHngAnrSmTJAzyUG8wHGqo0ViS4jn5Q==
jed@^1.1.1:
version "1.1.1"
resolved "https://registry.yarnpkg.com/jed/-/jed-1.1.1.tgz#7a549bbd9ffe1585b0cd0a191e203055bee574b4"