パイプラインシークレット検出をカスタマイズする

サブスクリプションティアと設定方法によっては、パイプラインシークレット検出の動作を変更できます。

アナライザーの動作をカスタマイズする対象:

• アナライザーが検出するシークレットの種類を変更します。
• 別のアナライザーバージョンを使用します。
• 特定の方法でプロジェクトをスキャンします。

アナライザーのルールセットをカスタマイズする対象:

• カスタムシークレットタイプを検出します。
• デフォルトのスキャナールールをオーバーライドします。

アナライザーの動作をカスタマイズする

アナライザーの動作を変更するには、.gitlab-ci.ymlのvariablesパラメータを使用して変数を定義します。

新しいパターンを追加

リポジトリ内の他の種類のシークレットを検索するには、アナライザールールセットをカスタマイズできます。

パイプラインシークレット検出のすべてのユーザーに対して新しい検出ルールを提案するには、ルールの信頼できる唯一の情報源を参照し、ガイダンスに従ってマージリクエストを作成してください。

クラウド製品またはSaaS製品を運用していて、ユーザーをより適切に保護するためにGitLabとの提携に関心がある場合は、漏洩した認証情報の通知に関するパートナープログラムの詳細をご覧ください。

特定のアナライザーバージョンにピン留め

GitLab管理のCI/CDテンプレートは、メジャーバージョンを指定し、そのメジャーバージョン内の最新のアナライザーリリースを自動的にプルします。

場合によっては、特定のバージョンを使用する必要があるかもしれません。たとえば、後のリリースで発生したリグレッションを回避する必要がある場合などです。

自動更新の動作をオーバーライドするには、Secret-Detection.gitlab-ci.ymlテンプレートを含めた後、CI/CD設定ファイルでSECRETS_ANALYZER_VERSION CI/CD変数を設定します。

タグには次のいずれかを設定できます:

• メジャーバージョン（例: 4）: パイプラインは、このメジャーバージョン内でリリースされるマイナーまたはパッチアップデートを使用します。
• マイナーバージョン（例: 4.5）: パイプラインは、このマイナーバージョン内でリリースされるパッチアップデートを使用します。
• パッチバージョン（例: 4.5.0）: パイプラインはアップデートを受け取りません。

この例では、特定のマイナーアナライザーバージョンを使用しています:

include:
  - template: Jobs/Secret-Detection.gitlab-ci.yml

secret_detection:
  variables:
    SECRETS_ANALYZER_VERSION: "4.5"

履歴スキャンを有効にする

履歴スキャンを有効にするには、変数SECRET_DETECTION_HISTORIC_SCANをtrueファイルで.gitlab-ci.ymlに設定します。

マージリクエストパイプラインでジョブを実行する

マージリクエストパイプラインでセキュリティスキャンツールを使用するを参照してください。

アナライザージョブをオーバーライドする

ジョブ定義をオーバーライドするには（たとえば、variablesやdependenciesなどのプロパティを変更する）、オーバーライドするsecret_detectionジョブと同じ名前でジョブを宣言します。テンプレートの挿入後にこの新しいジョブを配置し、その下に追加のキーを指定します。

次の.gitlab-ci.ymlファイルの例の抜粋:

• Jobs/Secret-Detection CI/CDテンプレートが含まれています。
• secret_detectionジョブでは、CI/CD変数SECRET_DETECTION_HISTORIC_SCANがtrueに設定されています。テンプレートはパイプライン設定の前に評価されるため、変数の最後の記述が優先され、履歴スキャンが実行されます。

include:
  - template: Jobs/Secret-Detection.gitlab-ci.yml

secret_detection:
  variables:
    SECRET_DETECTION_HISTORIC_SCAN: "true"

利用可能なCI/CD変数

利用可能なCI/CD変数を定義して、パイプラインシークレット検出の動作を変更します:

以前のGitLabバージョンでは、次の変数も利用可能でした:

アナライザーのルールセットをカスタマイズする

スキャンされるリポジトリまたはリモートリポジトリのいずれかで、カスタムルールセット設定ファイルを作成することにより、パイプラインシークレット検出を使用して検出されるシークレットの種類をカスタマイズできます。

カスタマイズにより、次のことが可能になります

• デフォルトのルールセットのルールの動作を変更します。
• デフォルトのルールセットをカスタムルールセットに置き換えます。
• デフォルトのルールセットの動作を拡張します。
• シークレットとパスを無視します。

ルールセット設定ファイルを作成する

ルールセット設定ファイルを作成するには:

1. まだ存在しない場合は、プロジェクトのルートに.gitlabディレクトリを作成します。
2. .gitlabディレクトリにsecret-detection-ruleset.tomlという名前のファイルを作成します。

デフォルトのルールセットのルールを変更する

デフォルトのルールセットで事前定義されたルールを変更できます。

ルールを変更すると、パイプラインシークレット検出を既存のワークフローまたはツールに適応させることができます。たとえば、検出されたシークレットの重大度をオーバーライドしたり、ルールがまったく検出されないように無効にしたりできます。

また、リモートGitリポジトリまたはWebサイト) にリモートで保存されたルールセット設定ファイルを使用して、事前定義されたルールを変更することもできます。新しいルールでは、カスタムルール形式を使用する必要があります。

ルールを無効にする

アクティブにしたくないルールを無効にすることができます。アナライザーのデフォルトルールセットからルールを無効にするには:

1. ルールセット設定ファイルを作成します(まだ存在しない場合)。
2. disabledフラグを、rulesetセクションのコンテキストでtrueに設定します。
3. 1つ以上のruleset.identifierサブセクションで、無効にするルールをリストします。すべてのruleset.identifierセクションには、次のものがあります:
   • 事前定義されたルール識別子のtypeフィールド。
   • ルール名のvalueフィールド。

次のsecret-detection-ruleset.tomlファイルでは、無効になっているルールは識別子のtypeとvalueによって照合されます:

[secrets]
  [[secrets.ruleset]]
    disable = true
    [secrets.ruleset.identifier]
      type  = "gitleaks_rule_id"
      value = "RSA private key"

ルールをオーバーライドする

カスタマイズする特定のルールがある場合は、それらをオーバーライドできます。たとえば、特定の種類のシークレットの重大度を高めることができます。これは、それをリークすると、ワークフローに大きな影響を与えるためです。

アナライザーのデフォルトルールセットからルールをオーバーライドするには:

1. ルールセット設定ファイルを作成します(まだ存在しない場合)。
2. 1つ以上のruleset.identifierサブセクションで、オーバーライドするルールをリストします。すべてのruleset.identifierセクションには、次のものがあります:
   • 事前定義されたルール識別子のtypeフィールド。
   • ルール名のvalueフィールド。
3. ruleset.overrideコンテキストのrulesetセクションで、オーバーライドするキーを指定します。任意のキーの組み合わせをオーバーライドできます。有効なキーは次のとおりです:
   • description
   • message
   • name
   • severity (有効なオプションは、Critical、High、Medium、Low、Unknown、Infoです)

次のsecret-detection-ruleset.tomlファイルでは、ルールは識別子のtypeとvalueによって照合され、その後オーバーライドされます:

[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"

リモートルールセットを使用する場合

リモートルールセットは、現在のリポジトリの外部に保存されている設定ファイルです。これを使用して、複数のプロジェクトにわたってルールを変更できます。

リモートルールセットを使用して事前定義されたルールを変更するには、SECRET_DETECTION_RULESET_GIT_REFERENCE CI/CD変数を使用できます:

include:
  - template: Jobs/Secret-Detection.gitlab-ci.yml

variables:
  SECRET_DETECTION_RULESET_GIT_REFERENCE: "gitlab.com/example-group/remote-ruleset-project"

パイプラインシークレット検出は、構成がCI/CD変数によって参照されるリポジトリの.gitlab/secret-detection-ruleset.tomlファイルで定義されていることを前提としています。リモートルールセットが保存されている場所です。そのファイルが存在しない場合は、作成し、前に概説したように、事前定義されたルールをオーバーライドまたは無効にする手順に従ってください。

SECRET_DETECTION_RULESET_GIT_REFERENCE変数は、URI、オプションの認証、およびオプションのGitセキュアハッシュアルゴリズムを指定するためのGit URIと同様の形式を使用します。変数は次の形式を使用します:

<AUTH_USER>:<AUTH_PASSWORD>@<PROJECT_PATH>@<GIT_SHA>

設定ファイルが認証を必要とするプライベートプロジェクトに保存されている場合は、CI/CD変数に安全に保存されているグループアクセストークンを使用して、リモートルールセットを読み込むことができます:

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"

グループアクセストークンには、read_repositoryスコープと、少なくともレポーターロールが必要です。詳細については、リポジトリの権限を参照してください。

グループアクセストークンに関連付けられているユーザー名を見つける方法については、グループのボットユーザーを参照してください。

デフォルトのルールセットを置き換える

カスタマイズを使用して、デフォルトのルールセット構成を置き換えることができます。それらは、パススルーを使用して単一の構成に結合できます。

パススルーを使用すると、次のことができます:

• 単一の構成に最大20個のパススルーをチェーンして、事前定義されたルールを置き換えるか、または拡張します。
• パススルーで環境変数を含めます。
• パススルーを評価するためのタイムアウトを設定します。
• 定義された各パススルーで使用されるTOML構文を検証します。

インラインルールセットを使用する場合

rawパススルーを使用して、インラインで提供される構成を使用してデフォルトのルールセットを置き換えることができます。

同じリポジトリに保存されている.gitlab/secret-detection-ruleset.toml設定ファイルに以下を追加し、[[rules]]で定義されたルールを必要に応じて調整します:

[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}'''
"""

前の例では、定義された正規表現をチェックするルールを使用してデフォルトのルールセットを置き換えます - Custom Raw Ruleset Tには、e、s、またはt文字のいずれかからの3文字のサフィックスが付きます。

使用するパススルー構文の詳細については、スキーマを参照してください。

ローカルルールセットを使用する場合

fileパススルーを使用して、別のファイルでコミットされたデフォルトのルールセットを現在のリポジトリに置き換えることができます。

同じリポジトリに格納されている.gitlab/secret-detection-ruleset.toml設定ファイルに以下を追加し、ローカルルールセット設定でファイルのパスを指すように必要に応じてvalueを調整します:

[secrets]
  [[secrets.passthrough]]
    type   = "file"
    target = "gitleaks.toml"
    value  = "config/gitleaks.toml"

これにより、config/gitleaks.tomlファイルで定義された構成を使用して、デフォルトのルールセットが置き換えられます。

使用するパススルー構文の詳細については、スキーマを参照してください。

リモートルールセットを使用する場合

gitおよびurlパススルーを使用して、リモートGitリポジトリまたはオンラインで保存されているファイルで定義された構成を使用して、デフォルトのルールセットを置き換えることができます。

リモートルールセットは、複数のプロジェクトで使用できます。たとえば、名前空間の1つの複数のプロジェクトに同じルールセットを適用する場合は、いずれかの種類のパススルーを使用してそのリモートルールセットを読み込むして、複数のプロジェクトで使用できるようにします。また、ルールセットの一元管理も可能になり、承認されたユーザーのみが編集できます。

gitパススルーを使用するには、次のものをリポジトリに格納されている.gitlab/secret-detection-ruleset.toml設定ファイルに追加し、Gitリポジトリのアドレスを指すようにvalueを調整します:

# .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"

この構成では、アナライザーはuser_group/central_repository_with_shared_rulesetに格納されているリポジトリのmainブランチにあるconfigディレクトリ内のgitleaks.tomlファイルからルールセットを読み込みます。次に、user_group/basic_repository以外のプロジェクトで同じ構成を含めることができます。

または、urlパススルーを使用して、リモートルールセット設定でデフォルトのルールセットを置き換えることもできます。

urlパススルーを使用するには、次のものをリポジトリに格納されている.gitlab/secret-detection-ruleset.toml設定ファイルに追加し、リモートファイルのアドレスを指すようにvalueを調整します:

# .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"

この構成では、アナライザーは指定されたアドレスに格納されているgitleaks.tomlファイルからルールセット構成を読み込みます。

使用するパススルー構文の詳細については、スキーマを参照してください。

プライベートリモートルールセットを使用する

ルールセット構成がプライベートリポジトリに格納されている場合は、パススルーのauth設定を使用してリポジトリにアクセスするための認証情報を提供する必要があります。

プライベートリポジトリに格納されているリモートルールセットを使用するには、次のものをリポジトリに格納されている.gitlab/secret-detection-ruleset.toml設定ファイルに追加し、Gitリポジトリのアドレスを指すようにvalueを調整し、適切な認証情報を使用するようにauthを更新します:

[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"

使用するパススルー構文の詳細については、スキーマを参照してください。

デフォルトのルールセットを拡張する

また、必要に応じて、追加のルールを使用してデフォルトのルールセット構成を拡張することもできます。これは、デフォルトのルールセットでGitLabによって維持されている信頼性の高い事前定義されたルールから引き続き恩恵を受けたいが、独自のプロジェクトおよびネームスペースで使用される可能性のある種類のシークレットのルールも追加する場合に役立ちます。新しいルールは、カスタムルール形式に従う必要があります。

ローカルルールセットを使用する場合

fileパススルーを使用してデフォルトのルールセットを拡張し、追加のルールを追加できます。

同じリポジトリに格納されている.gitlab/secret-detection-ruleset.toml設定ファイルに以下を追加し、拡張設定ファイルのパスを指すように必要に応じてvalueを調整します:

# .gitlab/secret-detection-ruleset.toml
[secrets]
  [[secrets.passthrough]]
    type   = "file"
    target = "gitleaks.toml"
    value  = "extended-gitleaks-config.toml"

extended-gitleaks-config.tomlに格納されている拡張設定は、CI/CDパイプライン内のアナライザーで使用される設定に含まれています。

以下の例では、検出される正規表現を定義する新しい[[rules]]セクションを追加します:

# 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'''

このルールセット設定により、アナライザーは、定義された正規表現パターンと一致する文字列を検出します。

使用するパススルーの構文の詳細については、スキーマを参照してください。

リモートルールセットを使用する場合

デフォルトのルールセットをリモートルールセットに置き換える方法と同様に、.gitlab/secret-detection-ruleset.toml設定ファイルがあるリポジトリの外部に格納されているリモートGitリポジトリまたはファイルに格納されている設定を使用して、デフォルトのルールセットを拡張することもできます。

これは、前述したgitまたはurlのいずれかのパススルーを使用することで実現できます。

gitパススルーでそれを行うには、同じリポジトリに格納されている.gitlab/secret-detection-ruleset.toml設定ファイルに以下を追加し、拡張された設定ファイルのパスを指すように、必要に応じてvalue、ref、およびsubdirを調整します:

# .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"

パイプラインのシークレット検出は、リモートルールセット設定ファイルがgitleaks.tomlという名前で、参照されているリポジトリのmainブランチのconfigディレクトリに格納されていることを前提としています。

デフォルトのルールセットを拡張するには、gitleaks.tomlファイルで、前の例と同様に[extend]ディレクティブを使用する必要があります:

# 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'''

urlパススルーを使用するには、同じリポジトリに格納されている.gitlab/secret-detection-ruleset.toml設定ファイルに以下を追加し、拡張された設定ファイルのパスを指すように、必要に応じてvalueを調整します

# .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"

使用するパススルーの構文の詳細については、スキーマを参照してください。

スキャン実行ポリシーを使用する

スキャン実行ポリシーでルールセットを拡張および適用するには、以下を実行します:

• スキャン実行ポリシーでパイプラインシークレット検出設定をセットアップするの手順に従ってください。

正規表現とパスを除外する

パイプラインのシークレット検出によって特定の正規表現またはパスが検出されないようにする必要がある場合があります。たとえば、テストスイートで使用される偽のシークレットを含むファイルがあるとします。

その場合は、Gitleaks’ native [allowlist]ディレクティブを使用して、特定のパターンまたはパスを除外できます。

正規表現を無視するには、同じリポジトリに格納されている.gitlab/secret-detection-ruleset.toml設定ファイルに以下を追加し、拡張された設定ファイルのパスを指すように、必要に応じてvalueを調整します:

# .gitlab/secret-detection-ruleset.toml
[secrets]
  [[secrets.passthrough]]
    type   = "file"
    target = "gitleaks.toml"
    value  = "extended-gitleaks-config.toml"

extended-gitleaks-config.tomlに格納されている拡張設定は、アナライザーで使用される設定に含まれています。

以下の例では、無視する（「許可された」）シークレットに一致する正規表現を定義する[allowlist]ディレクティブを追加します:

# 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}'''
  ]

これにより、数字と文字の20文字のサフィックスを持つglpat-に一致する文字列は無視されます。

同様に、スキャンから特定のパスを除外できます。以下の例では、[allowlist]ディレクティブの下で無視するパスの配列を定義します。パスには、正規表現または特定のファイルパスのいずれかを指定できます:

# 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)'''
  ]

これにより、/gitleaks.tomlファイル、または指定された拡張子のいずれかで終わるファイルで検出されたシークレットは無視されます。

Gitleaks v8.20.0以降、[allowlist]でregexTargetを使用することもできます。つまり、既存のルールをオーバーライドすることで、パーソナルアクセストークンのプレフィックスまたはカスタムインスタンスプレフィックスを設定できます。たとえば、personal access tokensの場合は、次のように設定できます:

# extended-gitleaks-config.toml
[extend]
# Extends default packaged ruleset, NOTE: do not change the path.
path = "/gitleaks.toml"

[[rules]]
# Rule id you want to override:
id = "gitlab_personal_access_token"
# all the other attributes from the default rule are inherited
    [[rules.allowlists]]
    regexTarget = "line"
    regexes = [ '''CUSTOMglpat-''' ]

[[rules]]
id = "gitlab_personal_access_token_with_custom_prefix"
regex = '<Regex that match a personal access token starting with your CUSTOM prefix>'

デフォルトルールセットで設定されているすべてのルールを考慮する必要があることに注意してください。

使用するパススルーの構文の詳細については、スキーマを参照してください。

インラインでシークレットを無視する

場合によっては、インラインでシークレットを無視する必要がある場合があります。たとえば、例またはテストスイートに偽のシークレットが含まれている場合があります。これらのインスタンスでは、脆弱性としてレポートされるのではなく、シークレットを無視する必要があります。

シークレットを無視するには、シークレットを含む行にコメントとしてgitleaks:allowを追加します。

例:

"A personal token for GitLab will look like glpat-JUST20LETTERSANDNUMB"  # gitleaks:allow

複雑な文字列の検出

デフォルトルールセットは、誤検出率の低い構造化文字列を検出するためのパターンを提供します。ただし、パスワードのようなより複雑な文字列を検出したい場合があります。Gitleaksは先読みまたは後読みをサポートしていないため、構造化されていない文字列を検出するための信頼性の高い一般的なルールを作成することはできません。

すべての複雑な文字列を検出できるわけではありませんが、特定のユースケースを満たすようにルールセットを拡張できます。

たとえば、このルールは、Gitleaksのデフォルトルールセットのgeneric-api-keyルールを変更します:

(?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|;]|$)

この正規表現は以下に一致します:

1. pwd、passwd、またはpasswordで始まる大文字と小文字を区別しない識別子。secretやkeyのように、他のバリエーションでこれを調整できます。
2. 識別子に続くサフィックス。サフィックスは数字、文字、および記号の組み合わせであり、長さは0〜23文字です。
3. =、:=、:、または=>などの一般的に使用される代入演算子。
4. シークレットの検出を支援するために境界としてよく使用される、シークレットのプレフィックス。
5. 数字、文字、および記号の文字列で、長さは3〜50文字です。これはシークレット自体です。より長い文字列が必要な場合は、長さを調整できます。
6. シークレットのサフィックス。境界としてよく使用されます。これは、ティック、改行、改行などの一般的な結末に一致します。

この正規表現に一致する文字列の例を次に示します:

pwd = password1234
passwd = 'p@ssW0rd1234'
password = thisismyverylongpassword
password => mypassword
password := mypassword
password: password1234
"password" = "p%ssward1234"
'password': 'p@ssW0rd1234'

この正規表現を使用するには、このページに記載されているいずれかの方法でルールセットを拡張します。

たとえば、このルールを含むローカルルールセットでデフォルトのルールセットを拡張するとします。

同じリポジトリに格納されている.gitlab/secret-detection-ruleset.toml設定ファイルに以下を追加します。拡張された設定ファイルのパスを指すようにvalueを調整します:

# .gitlab/secret-detection-ruleset.toml
[secrets]
  [[secrets.passthrough]]
    type   = "file"
    target = "gitleaks.toml"
    value  = "extended-gitleaks-config.toml"

extended-gitleaks-config.tomlファイルで、使用する正規表現を含む新しい[[rules]]セクションを追加します:

# 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"]

デモ

これらの設定オプションの一部を示すデモプロジェクトがあります。

以下は、デモプロジェクトとそれらに関連するワークフローの表です:

リモートルールセットの設定について説明するビデオデモもあります:

• ローカルおよびリモートルールセットを使用したシークレット検出

オフライン設定

オフライン環境は、インターネットを介した外部リソースへのアクセスが制限、規制、または断続的です。このような環境のインスタンスでは、パイプラインのシークレット検出には、いくつかの設定の変更が必要です。このセクションの手順は、オフライン環境に詳述されている手順と組み合わせて完了する必要があります。

GitLab Runnerを設定する

デフォルトでは、Runnerは、ローカルコピーが利用可能な場合でも、GitLabコンテナレジストリからDockerイメージをプルしようとします。Dockerイメージが最新の状態に保たれるようにするには、このデフォルトの設定を使用する必要があります。ただし、ネットワーキング接続が利用できない場合は、デフォルトのGitLab Runner pull_policy変数を変更する必要があります。

GitLab RunnerのCI/CD変数pull_policyをif-not-presentに設定します。

ローカルパイプラインシークレット検出アナライザーイメージを使用する

GitLabコンテナレジストリではなく、ローカルDockerレジストリからイメージを取得する場合は、ローカルパイプラインシークレット検出アナライザーイメージを使用します。

前提要件:

• Dockerイメージをローカルのオフラインレジストリにインポートするプロセスは、ネットワーキングのセキュリティポリシーによって異なります。IT部門に相談して、外部リソースをインポートまたは一時的にアクセスするための承認済みプロセスを確認してください。

1. デフォルトのパイプラインシークレット検出アナライザーイメージをregistry.gitlab.comからローカルDockerコンテナレジストリにインポートします:

   registry.gitlab.com/security-products/secrets:6

   パイプラインシークレット検出アナライザーのイメージは定期的に更新されるため、ローカルコピーも定期的に更新する必要があります。

2. CI/CD変数SECURE_ANALYZERS_PREFIXをローカルDockerコンテナレジストリに設定します。

   include:
     - template: Jobs/Secret-Detection.gitlab-ci.yml
   
   variables:
     SECURE_ANALYZERS_PREFIX: "localhost:5000/analyzers"

パイプラインシークレット検出ジョブは、インターネットアクセスを必要とせずに、アナライザーDockerイメージのローカルコピーを使用するようになりました。

カスタムSSL CA認証局を使用する

カスタム認証局を信頼するには、ADDITIONAL_CA_CERT_BUNDLE変数を、信頼するCA証明書のバンドルに設定します。これは、.gitlab-ci.ymlファイル、ファイル変数、またはCI/CD変数のいずれかで行います。

• .gitlab-ci.ymlファイルでは、ADDITIONAL_CA_CERT_BUNDLEの値は、X.509 PEM公開キー証明書のテキスト表現を含める必要があります。

  例:

  variables:
    ADDITIONAL_CA_CERT_BUNDLE: |
        -----BEGIN CERTIFICATE-----
        MIIGqTCCBJGgAwIBAgIQI7AVxxVwg2kch4d56XNdDjANBgkqhkiG9w0BAQsFADCB
        ...
        jWgmPqF3vUbZE0EyScetPJquRFRKIesyJuBFMAs=
        -----END CERTIFICATE-----

• ファイル変数を使用する場合は、ADDITIONAL_CA_CERT_BUNDLEの値を証明機関へのパスに設定します。

• 変数を使用する場合は、ADDITIONAL_CA_CERT_BUNDLEの値を証明機関のテキスト表現に設定します。