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

GitLab Ultimate11.9で導入されました

概要

アプリケーションを開発する際に繰り返し発生する問題は、開発者が意図せずにリモートリポジトリにシークレットや認証情報をコミットしてしまうことです。 他の人がソースにアクセスできる場合や、プロジェクトが公開されている場合、機密情報は公開され、悪意のあるユーザがデプロイ環境などのリソースにアクセスするために利用することができます。

GitLab 11.9では、Secret Detectionと呼ばれる新しいチェック機能が追加されました。 これは、リポジトリのコンテンツをスキャンして、APIキーやその他のあるはずのない情報を見つけます。

GitLabはSASTレポートの一部として特定されたシークレットを数カ所で目に見えるように表示します:

Secret Detection in merge request widget

ユースケース

  • キー、パスワード、APIトークンのようなシークレットの意図しないコミットを検出します。
  • リポジトリの全履歴を1回または定期的にスキャンしてシークレットを探します。

要件

Secret Detectionジョブを実行するには、デフォルトではGitLab Runnerにdocker またはkubernetes のexecutorが必要です。GitLab.comの共有Runnerを使用している場合は、デフォルトで有効になっています。

注意:当社の秘密検知ジョブは現在、Linux コンテナタイプを想定しています。 Windows コンテナはまだサポートされていません。
注意:独自のRunnerを使用する場合はインストールされているDockerのバージョンが19.03.0。 詳細はトラブルシューティング情報を参照してください。

設定

注:GitLab 13.1でシークレットディテクションは独自のCI/CDテンプレートに分割されました。

シークレット検出は、secret-detection ジョブ中に特定のアナライザーによって実行されます。 アプリのプログラミング言語に関係なく実行されます。

秘密検知アナライザーには、Gitleaksと TruffleHogのチェックが含まれています。

注:Secret Detection アナライザは、パスワードがドル記号($)で始まる場合、使用されているパスワードが環境変数である可能性が高いため、「URL 内のパスワード」脆弱性を無視します。 例えば、https://username:$password@example.com/path/to/repo は検出されませんが、https://username:password@example.com/path/to/repo は検出されます。
注:Auto DevOpsが提供するAuto Secret Detectionを使用している場合は、このセクションで示すように手動でシークレット検出を設定する必要はありません。

GitLab 13.1以降でSecret Detectionを有効にするには、GitLabインストールの一部として提供されているSecret-Detection.gitlab-ci.yml テンプレートを含める必要があります。11.9より前のバージョンのGitLabでは、そのテンプレートで定義されているジョブをコピーして使用することができます。

.gitlab-ci.yml ファイルに以下を追加してください:

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

付属のテンプレートは、CI/CDパイプラインにシークレット検出ジョブを作成し、プロジェクトのソースコードにシークレットがないかスキャンします。

結果はSecret Detection レポートのアーティファクトとして保存され、後でダウンロードして分析することができます。 実装の制限により、常に最新の Secret Detection アーティファクトを使用します。

SASTテンプレートの使用

GitLab 13.1以前では、シークレット検出はSAST設定の一部でした。 GitLab 13.1以前に設定したアプリですでにSASTが有効になっている場合は、手動で設定する必要はありません。

予定されている非推奨:GitLabの将来のリリースでは、SASTテンプレートによるシークレット検出の設定は非推奨となります。 将来のイシューを防ぐため、Secret-Detection.gitlab-ci.yml。この新しいテンプレートへの移行プロセスをガイドするビデオを作成しました。

SAST テンプレートを使用すると、sast ジョブ中に特定のアナライザーによってシークレット検出が実行されます。アプリのプログラミング言語に関係なく実行されるため、CI/CD 設定ファイルを変更して有効にする必要はありません。 結果は SAST レポートで確認できます。

設定のカスタマイズ

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

ジョブ定義をオーバーライドするには (例えば、variablesdependenciesのようなプロパティを変更するには)、オーバーライドする SAST ジョブと同じ名前のジョブを宣言します。 この新しいジョブをテンプレート・インクルードの後に配置し、その下に追加のキーを指定します。

以下の例では、シークレット検出テンプレートをインクルードし、同時にSECRET_DETECTION_HISTORIC_SCAN 変数でsecret_detection ジョブをtrueにオーバーライドしています:

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

secret_detection:
  variables:
    SECRET_DETECTION_HISTORIC_SCAN: "true"

テンプレートはパイプライン設定の前に評価されるため、変数の最後の記述が優先されます。

Deprecation:GitLab 13.0から、onlyexceptの使用はサポートされなくなりました。テンプレートをオーバーライドする場合は、代わりに](../../../ci/yaml/README.md#rules) を使用する必要があります。

利用可能な変数

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

環境変数 デフォルト値 説明
SECRET_DETECTION_COMMIT_FROM - Gitleaksのスキャンが開始されるコミット。
SECRET_DETECTION_COMMIT_TO - Gitleaksのスキャンが終了するコミット。
SECRET_DETECTION_HISTORIC_SCAN false Gitleaksの履歴スキャンを有効にするフラグ。

ログレベル

SECURE_LOG_LEVEL env varを設定することで、ログの冗長性を制御することができます。デフォルトはinfoに設定されていますが、以下のレベルのいずれかに設定することができます:

  • fatal
  • error
  • warn
  • info
  • debug

全履歴シークレットスキャン

GitLab 12.11 では、リポジトリの全履歴をスキャンできるようになりました。 この新機能は、リポジトリで初めてシークレット検出を有効にして、シークレットスキャンをフルに実行したい場合に特に便利です。 全履歴に対してシークレットスキャンを実行すると、特に Git の履歴が長い大規模なリポジトリでは時間がかかることがあります。 通常のジョブ定義の一部としてこの変数を設定しないことをお勧めします。

新しい設定変数(SECRET_DETECTION_HISTORIC_SCAN)を設定することで、GitLab Secret Detectionスキャンの動作をリポジトリのGit履歴全体に対して実行するように変更することができます。

全履歴シークレットスキャンを実行する方法を紹介する短いビデオチュートリアルを作成しました。