• 検出されたシークレット
  • 新しいパターンの追加
• ティアごとの機能
• カバレッジ
• テンプレート
• シークレット検出の有効化
  • .gitlab-ci.yml ファイルを手動で編集します。
  • 自動的に設定されたマージリクエストを使用します。
• 漏洩したシークレットへの対応
• 特定のアナライザーバージョンへのピン留め
• スキャン設定の構成
  • シークレットの無視
  • 利用可能な CI/CD 変数
    • FIPS対応イメージを使用
• 全履歴シークレット検出
  • 全履歴のシークレット検出を有効にする
• カスタムルールセット
  • 定義済みのアナライザ・ルールの無効化
  • 定義済みのアナライザ・ルールの上書き
  • カスタム設定の合成
    • デフォルト設定の拡張
  • リモート設定ファイルの指定
• オフライン環境でのシークレット検出の実行
  • GitLab Runnerの設定
  • ローカルのSecret Detectionアナライザーイメージを使います。
  • カスタム認証局の設定
• テキスト・コンテンツの潜在的な漏洩に対する警告
• トラブルシューティング
  • デバッグレベルのロギング
  • 警告gl-secret-detection-report.json: no matching files
  • エラー：Couldn't run the gitleaks command: exit status 2
  • エラー：ERR fatal: ambiguous argument
  • exec /bin/sh: exec format error ジョブログのメッセージ

シークレット・ディテクション

• GitLab 13.1では、Secret DetectionはSAST設定から独自のCI/CDテンプレートに分割されました。GitLab 13.0以前を使用していてSASTが有効になっている場合、Secret Detectionはすでに有効になっています。
• 13.3でGitLab UltimateからGitLab Freeに移動しました。
• GitLab 14.0では、Secret Detectionジョブsecret_detection_default_branch 、secret_detection 1つのジョブに統合されました。 secret_detection

Git リポジトリにキーや API トークンのようなシークレットを誤ってコミットしてしまうことがあります。機密の値がリモートのリポジトリにプッシュされると、そのリポジトリにアクセスできる人なら誰でも、悪意のある目的のためにシークレットの作成者になりすますことができます。ほとんどの組織では、このリスクに対処するために、公開されたシークレットを破棄して置き換えることを義務付けています。

Secret Detectionはリポジトリをスキャンし、シークレットの漏洩を防止します。Secret Detectionスキャンは、使用されている言語やフレームワークに関係なく、すべてのテキストファイルに対して機能します。

シークレットディテクションを有効にすると、スキャンはsecret_detection という名前の CI/CD ジョブで実行されます。GitLab のどの階層でも、スキャンを実行して SecretDetection の JSON レポートのアーティファクトを見ることができます。

GitLab Ultimateでは、Secret Detectionの結果も処理されるため、以下のことが可能です：

• マージリクエストウィジェット、パイプラインセキュリティレポート、脆弱性レポートUIで見ることができます。
• 承認ワークフローで使用します。
• セキュリティダッシュボードでレビュアー。
• 公開リポジトリの情報漏えいに自動的に対応。

検出されたシークレット

GitLabはシークレット検出で使われる検出ルールをメンテナーしています。デフォルトのルールセットには100以上のパターンが含まれています。

ほとんどの Secret Detection パターンは、特定の種類のシークレットを探します。多くのサービスは、シークレットに接頭辞やその他の構造的な詳細を追加しています。たとえば、GitLabはデフォルトでプロジェクト、グループ、個人のアクセストークンにglpat- という接頭辞 を付加しています。

より信頼性が高く、信頼性の高い結果を提供するために、Secret Detection は URL のような特定のコンテキストにあるパスワードやその他の構造化されていないシークレットのみを探します。

新しいパターンの追加

リポジトリ内の他の種類のシークレットを検索するには、カスタムルールセットを設定します。

シークレット検出の全ユーザーに新しい検出ルールを提案するには、デフォルトルールを含むファイルに対してマージリクエストを作成してください。

クラウドまたはSaaS製品をオペレーションしていて、ユーザーをよりよく保護するためにGitLabと提携することに興味がある場合は、漏えいしたクレデンシャル通知のためのパートナープログラムについて詳細をご覧ください。

ティアごとの機能

GitLabの階層によって利用できる機能が異なります。

カバレッジ

シークレットディテクションは、状況に応じてコードのさまざまな側面をスキャンします。デフォルトブランチ」以外のすべてのメソッドにおいて、シークレットディテクションは作業ツリーではなくコミットをスキャンします。たとえば、あるコミットでシークレットが追加され、後のコミットで削除された場合、シークレットディテクションはそれを検出することができます。

• 履歴スキャン

  SECRET_DETECTION_HISTORIC_SCAN 変数が設定されている場合、すべてのブランチのコンテンツがスキャンされます。リポジトリのコンテンツをスキャンする前に、Secret Detection はコマンドgit fetch --all を実行してすべてのブランチのコンテンツを取得します。

• コミット範囲

  SECRET_DETECTION_LOG_OPTIONS 変数が設定されている場合、シークレットアナライザはパイプラインが実行されているブランチまたは参照の履歴全体を取得します。その後、シークレット検出が実行され、指定されたコミット範囲がスキャンされます。

• デフォルトのブランチ

  デフォルトブランチで Secret Detection を実行すると、Git リポジトリはプレーンフォルダとして扱われます。現在の HEAD のリポジトリの内容だけがスキャンされます。コミット履歴はスキャンされません。

• プッシュイベント

  プッシュイベントにおいて、Secret Detectionはランナーで利用可能な情報をもとに、スキャンするコミット範囲を決定します。コミット範囲を決定するには、変数CI_COMMIT_SHA とCI_COMMIT_BEFORE_SHA が重要です。

  • CI_COMMIT_SHA は指定したブランチの HEAD でのコミットです。この変数は常にプッシュイベントに設定されます。
  • CI_COMMIT_BEFORE_SHA はほとんどの場合に設定されます。しかし、新しいブランチでの最初のプッシュイベントやマージパイプラインでは設定されません。このため、複数のコミットが新しいブランチにコミットされた場合のシークレット検出は保証されません。

• マージリクエスト

  マージリクエストでは、Secret Detection はソースブランチで行われたすべてのコミットをスキャンします。この機能を使用するには、マージリクエストパイプラインをサポートしているlatest Secret Detection テンプレートを使用する必要があります。Secret Detection の結果は、パイプラインが完了した後にのみ利用できます。

テンプレート

シークレット検出のデフォルト設定はCI/CDテンプレートで定義されています。テンプレートのアップデートはGitLabのアップグレードとともに提供され、改善や追加の恩恵を受けることができます。

利用可能なテンプレート

• Secret-Detection.gitlab-ci.yml:秘密検出 CI/CD テンプレートの安定したデフォルトバージョン。
• Secret-Detection.latest.gitlab-ci.yml:秘密検知テンプレートの最新バージョン。

テンプレートのバージョン管理について詳しくは、CI/CDのドキュメントを参照してください。

シークレット検出の有効化

前提条件：

• Linux ベースの GitLab Runner で、docker またはkubernetes の Executor。GitLab.com の共有 Runner を使っている場合は、デフォルトで有効になっています。
  • Windows Runnerはサポートされていません。
  • amd64以外のCPUアーキテクチャには対応していません。
• 独自のRunnerを使用する場合は、インストールされているDockerのバージョンが19.03.0 でないことを確認してください。詳細はトラブルシューティング情報をご覧ください。
• GitLab CI/CD 設定 (.gitlab-ci.yml) にtest ステージが含まれている必要があります。

シークレット検出を有効にするには、以下のどちらかを行います：

• Auto DevOpsを有効にする（Auto Secret Detectionを含む）。

• .gitlab-ci.yml ファイルを手動で編集 。.gitlab-ci.yml ファイルが複雑な場合は、この方法を使用してください。

• 自動的に設定されるマージリクエストを使用します。

.gitlab-ci.yml ファイルを手動で編集します。

この方法では、既存の.gitlab-ci.yml ファイルを手動で編集する必要があります。GitLab CI/CD設定ファイルが複雑な場合は、この方法を使用してください。

1. 左のサイドバーで「検索」または「移動」を選択してあなたのプロジェクトを検索します。
2. Build > Pipeline editorを選択します。

3. 以下をコピーし、.gitlab-ci.yml ファイルの下部に貼り付けます：

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

4. Validate]タブを選択し、[Validate pipeline]を選択します。Simulation completed successfully」というメッセージは、ファイルが有効であることを示しています。
5. Edit（編集）タブを選択します。
6. オプション。コミット・メッセージ・テキスト・ボックスで、コミット・メッセージをカスタマイズします。
7. ブランチ・テキスト・ボックスに、デフォルト・ブランチの名前を入力します。
8. 変更をコミット を選択します。

パイプラインに秘密検出ジョブが含まれるようになりました。

自動的に設定されたマージリクエストを使用します。

• GitLab 13.11で導入され、機能フラグの後ろにデプロイされ、デフォルトで有効になっています。
• GitLab 14.1で機能フラグが削除されました。

この方法では、.gitlab-ci.yml ファイルに秘密検出テンプレートが含まれたマージリクエストが自動的に作成されます。そして、マージリクエストをマージしてシークレット検出を有効にします。

シークレット検出を有効にするには

1. 左のサイドバーで「検索」または「移動」を選択してあなたのプロジェクトを検索します。
2. セキュア > セキュリティ設定を選択します。
3. シークレット検出]の行で、[マージリクエストで設定]を選択します。
4. オプション。フィールドを入力します。
5. マージリクエストを作成を選択します。
6. マージリクエストをレビューし、マージします。

パイプラインに秘密検出ジョブが含まれるようになりました。

漏洩したシークレットへの対応

シークレットが検出されたら、すぐにローテーションしてください。GitLabは漏れたシークレットの種類によっては自動的に失効させようとします。自動的に失効しないものについては、手動で失効させる必要があります。

リポジトリの履歴からシークレットを削除しても、漏えいに完全にアドレスすることはできません。元のシークレットは、リポジトリのフォークやクローンに残っています。

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

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

場合によっては、特定のバージョンを使う必要があるかもしれません。例えば、後のリリースのリグレッションを避ける必要があるかもしれません。

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

タグを設定できます：

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

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

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

secret_detection:
  variables:
    SECRETS_ANALYZER_VERSION: "4.5"

スキャン設定の構成

シークレット検出のスキャン設定は、.gitlab-ci.ymlのvariables パラメータを使用してCI/CD 変数で変更できます。

ジョブの定義を上書きする (たとえば、variables やdependencies のようなプロパティを変更する) には、上書きする秘密検知ジョブと同じ名前のジョブを宣言します。この新しいジョブをテンプレートインクルードの後に置き、その下に追加のキーを指定します。

以下の例では、.gitlab-ci.yml ファイルを_抜粋して_います：

• シークレット検出テンプレートが含まれています。
• secret_detection ジョブでは、CI/CD 変数SECRET_DETECTION_HISTORIC_SCAN はtrue に設定されます。テンプレートはパイプライン設定の前に評価されるため、変数の最後の言及が優先されます。

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

secret_detection:
  variables:
    SECRET_DETECTION_HISTORIC_SCAN: "true"

シークレットの無視

シークレットを無視したいインスタンスもあるでしょう。例えば、サンプルやテストスイートの中に偽のシークレットがあるかもしれません。このようなインスタンスでは、シークレットを脆弱性としてレポートさせるのではなく、 無視したいでしょう。

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

使用例：

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

利用可能な CI/CD 変数

シークレット検出は、利用可能なCI/CD変数を定義することでカスタマイズすることができます：

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

FIPS対応イメージを使用

GitLab 14.10で導入されました。

デフォルトのスキャナイメージは、サイズとメンテナーのためにAlpineイメージをベースに構築されています。GitLabはFIPS対応のRed Hat UBIバージョンのイメージを提供しています。

FIPS 対応のイメージを使うには、以下のいずれかを行います：

• CI/CD 変数SECRET_DETECTION_IMAGE_SUFFIX を-fips に設定します。
• デフォルトの画像名に拡張子-fips を追加します。

使用例：

variables:
  SECRET_DETECTION_IMAGE_SUFFIX: '-fips'

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

全履歴シークレット検出

デフォルトでは、シークレット検出は Git リポジトリの現在の状態のみをスキャンします。リポジトリの履歴に含まれるシークレットは検出されません。このアドレスに対応するために、Secret Detection は Git リポジトリの全履歴をスキャンすることができます。

完全な履歴のスキャンは、Secret Detection を有効にした後に一度だけ行うようにしましょう。完全な履歴のスキャンには時間がかかることがあり、特に Git の履歴が長い大規模なリポジトリでは時間がかかります。最初の全履歴スキャンが完了したら、パイプラインの一部として標準の Secret Detection のみを使用してください。

全履歴のシークレット検出を有効にする

全履歴シークレット検出を有効にするには、.gitlab-ci.yml ファイルの変数SECRET_DETECTION_HISTORIC_SCAN をtrue に設定します。

カスタムルールセット

• GitLab 13.5 で導入されました。
• パススルーチェーンをサポート。GitLab 14.6で、パススルーのタイプをfile,git,url に拡張。
• GitLab 14.8でオーバーライドルールをサポート。

GitLab UIで報告されるシークレットをカスタマイズできます。しかし、secret_detection のジョブログには常にデフォルトのシークレット検出ルールによって検出されたシークレットの数が含まれます。

以下のカスタマイズオプションは個別に、あるいは組み合わせて使うことができます：

• 定義済みのルールを無効にします。
• 定義済みのルールを無効にします。
• カスタム設定の合成。
• リモート設定ファイルを指定します。

定義済みのアナライザ・ルールの無効化

アクティブにしたくない特定のシークレット検出ルールがある場合、それを無効にすることができます。

アナライザ ルールを無効にするには

1. プロジェクトのルートに.gitlab ディレクトリを作成します（まだ存在しない場合）。
2. .gitlab ディレクトリがまだ存在しない場合は、secret-detection-ruleset.toml という名前のカスタム・ルールセット・ファイルを作成します。
3. ruleset セクションのコンテキストで、disabled フラグをtrue に設定してください。
4. 1つ以上のruleset.identifier サブセクションで、無効にするルールを列挙して ruleset.identifierください。ruleset.identifier すべての ruleset.identifierセクションには
   • type 定義済みルール識別子フィールド。
   • ルール名のvalue フィールド。

次の例のsecret-detection-ruleset.toml ファイルでは、識別子のtype とvalue に一致することで、無効化されたルールがsecrets に割り当てられています：

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

定義済みのアナライザ・ルールの上書き

カスタマイズしたいシークレット検出ルールがある場合、それを上書きすることができます。例えば、特定のシークレットの重大度を上げることができます。

ルールを上書きするには

1. プロジェクトのルートに.gitlab ディレクトリを作成します（まだ存在しない場合）。
2. .gitlab ディレクトリがまだ存在しない場合は、secret-detection-ruleset.toml という名前のカスタム・ルールセット・ファイルを作成します。
3. 1つ以上のruleset.identifier サブセクションに、オーバーライドするルールを列挙して ruleset.identifierください。ruleset.identifier すべての ruleset.identifierセクションには
   • type 定義済みルール識別子フィールド。
   • ルール名のvalue フィールド。
4. ruleset セクションのruleset.override コンテキストに、オーバーライドするキーを指定します。任意のキーの組み合わせをオーバーライドできます。有効なキーは以下のとおりです：
   • 説明
   • メッセージ
   • 名前
   • 重大度 (有効なオプション: 重大、高、中、低、不明、情報)

次の例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"

カスタム設定の合成

パススルーを使用して、デフォルトのシークレット検出ルールセットを上書きできます。secrets アナライザでサポートされているパススルー タイプは次のとおりです：

• raw
• file

パススルーを定義するには、次の_いずれかを_ secret-detection-ruleset.toml ファイルに追加します：

• インライン (raw) 値を使用：

   [secrets]
     description = 'secrets custom rules configuration'
     
     [[secrets.passthrough]]
       type  = "raw"
       target = "gitleaks.toml"
       value = """\
   title = "gitleaks config"
   # add regexes to the regex table
   [[rules]]
   description = "Test for Raw Custom Rulesets"
   regex = '''Custom Raw Ruleset T[est]{3}'''
   """
  

• 現在のリポジトリにコミットされた外部file を使用しています：

   [secrets]
     description = 'secrets custom rules configuration'
     
     [[secrets.passthrough]]
       type  = "file"
       target = "gitleaks.toml"
       value = "config/gitleaks.toml"
  

パススルーの構文の詳細については、SAST カスタマイズルールセットのページのパススルーのセクションを参照してください。

デフォルト設定の拡張

Gitleaksextend support を利用することで、デフォルト設定を拡張し、追加の変更を加えることができます。

以下のfile パススルーの例では、文字列glpat-1234567890abcdefghij はシークレット検出によって無視されます。GitLab パーソナル・アクセストークン(PAT) はテストケースで使用されます。これを検出すると誤検出となります。

secret-detection-ruleset.toml ファイルは、extended-gitleaks-config.toml ファイル extended-gitleaks-config.toml内の設定を含めることを定義しています。extended-gitleaks-config.toml この extended-gitleaks-config.tomlファイルには、Gitleaks のカスタム設定が定義されています。allowlist スタンザは無視される(“allowed”)秘密にマッチする正規表現を定義します。

# .gitlab/secret-detection-ruleset.toml
[secrets]
  description = 'secrets custom rules configuration'

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

# extended-gitleaks-config.toml
title = "extension of gitlab's default gitleaks config"

[extend]
# Extends default packaged path
path = "/gitleaks.toml"

[allowlist]
  description = "allow list of test tokens to ignore in detection"
  regexTarget = "match"
  regexes = [
    '''glpat-1234567890abcdefghij''',
  ]

リモート設定ファイルの指定

プロジェクトは、現在のリポジトリ以外のルールセット設定を指定するために、CI/CD変数で設定することができます。

SECRET_DETECTION_RULESET_GIT_REFERENCE 変数は、URI、オプションの認証、オプションの Git SHA を指定するための SCP スタイルの構文を使用します。変数は以下のフォーマットを使います：

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

次の例では、スキャン対象のプロジェクトに秘密検知テンプレートを含め、別のプロジェクト設定を参照するための変数SECRET_DETECTION_RULESET_GIT_REFERENCE を指定しています。

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

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

リモート設定の構文の詳細については、SAST カスタマイズ ルールセット ページの非公開リモート設定の指定例を参照してください。

オフライン環境でのシークレット検出の実行

オフライン環境では、インターネットを通じた外部リソースへのアクセスが制限されたり、制限されたり、断続的になったりします。このような環境でセルフマネージドGitLabインスタンスを使用する場合、Secret Detectionはいくつかの設定変更を必要とします。このセクションの説明は、オフライン環境での詳細な説明と一緒に完了する必要があります。

GitLab Runnerの設定

デフォルトでは、ランナーはローカルにDockerイメージがある場合でも、GitLabコンテナレジストリからDockerイメージを取得しようとします。Dockerイメージが最新であることを保証するために、このデフォルト設定を使うべきです。しかし、ネットワーク接続が利用できない場合は、デフォルトのGitLab Runnerpull_policy 変数を変更する必要があります。

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

ローカルのSecret Detectionアナライザーイメージを使います。

GitLabコンテナレジストリではなく、ローカルのDockerレジストリからイメージを取得したい場合は、ローカルのSecret Detectionアナライザイメージを使用します。

前提条件：

• ローカルのオフラインDockerレジストリへのDockerイメージのインポートは、ネットワークセキュリティポリシーに依存します。外部のリソースをインポートしたり、一時的にアクセスしたりするための承認者を見つけるために、ITスタッフに相談してください。

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

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

   Secret Detectionアナライザのイメージは定期的に更新されるため、ローカルのコピーを定期的に更新する必要があります。

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

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

これでSecret Detectionジョブは、インターネットアクセスを必要とせずに、Secret DetectionアナライザーのDockerイメージのローカルコピーを使用するようになります。

カスタム認証局の設定

カスタム認証局を信頼するには、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 の値を証明書のテキスト表現に設定します。

テキスト・コンテンツの潜在的な漏洩に対する警告

• GitLab 15.11 で導入。
• カスタム接頭辞を持つ個人アクセストークンの検出が GitLab 16.1 で導入されました。GitLab セルフマネジメントのみ。

イシューを作成したり、マージリクエストを提案したり、コメントを書いたりするときに、誤ってセンシティブな値を投稿してしまうことがあるかもしれません。例えば、APIリクエストの詳細や認証トークンを含む環境変数などを貼り付けてしまうかもしれません。

GitLab は、イシューの説明、マージリクエストの説明、コメント、返信のテキストに機密トークンが含まれているかどうかをチェックします。トークンが見つかった場合は、警告メッセージが表示されます。その後、投稿する前にメッセージを編集することができます。このチェックは、メッセージがサーバーに送信される前にブラウザで行われます。チェックは常にオンになっているので、設定する必要はありません。

あなたのテキストは以下のシークレットタイプでチェックされます：

• GitLabパーソナルアクセストークン
  • 個人アクセストークンプレフィックスが設定されている場合は、そのプレフィックスを使ったトークンがチェックされます。
• GitLabフィードトークン

この機能は、Gitリポジトリから漏れたシークレットをチェックするSecret Detectionスキャンとは別のものです。イシュー 405147は、この二つの保護機能を連携させるための取り組みを追ったものです。

トラブルシューティング

デバッグレベルのロギング

デバッグ・レベルのロギングは、トラブルシューティングの際に役立ちます。詳細については、デバッグレベルロギングを参照してください。

警告gl-secret-detection-report.json: no matching files

これについては、一般的なアプリケーションセキュリティのトラブルシューティングのセクションを参照してください。

エラー：Couldn't run the gitleaks command: exit status 2

シークレット検出アナライザは、シークレットをスキャンするためにコミット間にパッチを生成することに依存しています。マージリクエストのコミット数がGIT_DEPTH CI/CD 変数の値より大きい場合、Secret Detection はシークレットの検出に失敗します。

例えば、60のコミットを含むマージリクエストからパイプラインがトリガーされ、GIT_DEPTH 変数が60未満に設定されているとします。この場合、クローンの深さが浅く、関連するコミットがすべて含まれていないため、シークレット検出ジョブは失敗します。現在の値を確認するには、パイプライン設定を参照してください。

これがエラーの原因であることを確認するには、デバッグレベルのロギングを有効にして、パイプラインを再実行します。ログは次の例のようになるはずです。object not found” というテキストは、このエラーの症状です。

ERRO[2020-11-18T18:05:52Z] object not found
[ERRO] [secrets] [2020-11-18T18:05:52Z] ▶ Couldn't run the gitleaks command: exit status 2
[ERRO] [secrets] [2020-11-18T18:05:52Z] ▶ Gitleaks analysis failed: exit status 2

このイシューを解決するには、GIT_DEPTH CI/CD 変数 を高い値に設定します。秘密検知ジョブにのみこれを適用するには、.gitlab-ci.yml ファイルに以下を追加します：

secret_detection:
  variables:
    GIT_DEPTH: 100

エラー：ERR fatal: ambiguous argument

リポジトリのデフォルトブランチがジョブのトリガーされたブランチと無関係な場合、ERR fatal: ambiguous argument エラーというメッセージで秘密検出が失敗することがあります。詳細は issue!352014を参照してください。

このイシューを解決するには、リポジトリのデフォルトブランチを正しく設定してください。secret-detection ジョブを実行したブランチと関連履歴のあるブランチに設定してください。

exec /bin/sh: exec format error ジョブログのメッセージ

GitLab Secret Detectionアナライザは、amd64 CPUアーキテクチャ上での実行のみをサポートしています。このメッセージは、ジョブがarm のような異なるアーキテクチャで実行されていることを示しています。