GitとCI/CDに関する知識ゼロのSEが、GitLabのSecret Detectionでリポジトリにある機密情報の検知を試すだけ (2023/07/12 更新)

2023/07/12　GitLab.com Enterprise Edition 16.2.0-pre の画面に差し替え、一部の文言を更新しました。

皆様こんにちは。SEの小池と申します。

リモートのGitリポジトリをお使いの方なら一度は目にしたことがあるであろう、 APIキーや認証情報が入ったソースコードを、うっかりリポジトリで全世界に公開しちゃった というニュース。

年に数回くらい見かけるニュースなのですが、他人事じゃないですよね‥‥。

でもご安心 (？) ください！

GitLabなら無料版でも使用できる Secret Detection という機能で、リポジトリに入っている機密情報を検出することができます！

今回のブログではGitLabの Secret Detection という機能をご紹介しつつ、ちょっとだけ試します。

本記事の対象の方
今回のブログのゴール
このブログをお読みいただくにあたっての事前ご連絡事項
Secret Detection の概要
Secret Detection の前提条件と有効にする方法
Secret Detection を試すためのシナリオ
最後に

本記事の対象の方

GitLabの Secret Detection をとりあえず触ってみたい方。
GitLabの Secret Detection に関して情報収集をなさっている方。
GitLabのリポジトリに機密情報が含まれているかをチェックなさりたい方。

今回のブログのゴール

このブログのゴールはこちらです。

今回のゴール

GitLabの Secret Detection の概要を把握する。
GitLabの Secret Detection を使ってみる。

このブログをお読みいただくにあたっての事前ご連絡事項

本記事はSaaS版 (GitLab.com) の Enterprise Edition 16.2.0-pre (Ultimate) における仕様をベースに記載しております。それ以外のエディションやバージョンではこの記事に記載の通りではない可能性がございます。
本記事の操作説明と画面ショットはGitLabのローカライズを日本語にした状態で説明しております。それ以外の言語をご利用の方は適宜読み替えてください。
本記事はGitやCI/CDに関する知識ゼロのSEによるなんちゃって記事です。GitLabのディープな使用法についてはGitLabの公式オンラインドキュメント (こちら) をご参照ください。

Secret Detection の概要

Secret Detectionは、GitLabのリポジトリをスキャンし、そこに含まれるAPIシークレットキーなどの機密情報を検出する機能です。
参考：Secret Detection | GitLab

本機能でスキャン可能なリポジトリは、プログラミング言語やフレームワークに依存しません。
ただし、バイナリファイルのスキャンはサポートされていません。(2023/02/16 時点)

結果はシークレット検出レポートアーティファクト (json形式) として保存され、閲覧・ダウンロードできます。(*)
Ultimate を利用している場合は、アーティファクトに加え、メニュー [安全] > [脆弱性レポート] から検知数・重要度・概要・解決状況等を一目で確認することができます。
また、GitLab SaaS版 (GitLab.com) であれば後処理フック (post-processing hooks) をサポートしているので、機密情報を検出したときに特定のアクションを実行させることも可能です。(*)
* 全ティア (Free, Premium, Ultimate) で使用可能です。

スキャン範囲は対象がデフォルトブランチか否かによって異なります。
デフォルトブランチの場合は、そのブランチに含まれるリポジトリ全体をスキャンします。
それ以外のブランチの場合は、コミットに関連するリポジトリのみがスキャンされます。
また、デフォルトブランチか否かにかかわらず、変数SECRET_DETECTION_HISTORIC_SCANを設定することで、過去の履歴も全てスキャンすることも可能です。
参考：Secret Detection - Coverage | GitLab

検出が可能な機密情報のフォーマットについては 2023/02/16 現在で明言されていませんが、アナライザに Gitleaks を使っていると記載があるため、大雑把には「Gitleaksでルールで定義されている機密情報を検知できる」と推測されます。
(この推測は筆者の独断によるもので、GitLabのSecret Detection機能の仕様を説明したものではありません。)

Secret Detection の前提条件と有効にする方法

Secret Detection を利用するには以下の前提条件があります。
なお、GitLab.com の共用 Runner には以下を満たす Runner が存在します。したがって、GitLab.com で共用 Runner を使う場合に限り、別途で Runner を用意する必要はありません。
参考：Secret Detection - Enable Secret Detection | GitLab

Secret Detection の前提条件

Linuxベース 且つエクゼキューターが docker または kubernetes のRunnerが存在すること。

WindowsベースのRunnerはサポートされていません。
amd64 以外の CPU アーキテクチャはサポートされていません。

自前の Runner を利用している場合は、その Runner で使用する Docker のバージョンが 19.03 ではないこと。
.gitlab-ci.yml でキーワード stages で明示的にステージを宣言している場合は、test ステージが存在すること。

Secret Detectionを有効にする方法は、3つあります。
参考：Secret Detection - Enable Secret Detection | GitLab

Auto Secret Detection を含む Auto DevOps を有効にする方法
.gitlab-ci.ymlファイルを手動で編集する方法
セキュリティとコンプライアンスから有効にする方法

上記のいずれでもSecret Detectionを有効にすることができます。
このブログの次の章では、例として上記の2番目の方法 (.gitlab-ci.ymlファイルを手動で編集する方法) で試してみます。

Secret Detection を試すためのシナリオ

GitLabのSecret Detection機能で、リポジトリのファイルに記載されたAWSのアクセスキーIDを検知できるか試してみます。
シナリオの流れは以下の通りです。

GitLab.comにSecret Detection機能お試し用のプロジェクトを作成する。
リポジトリのmainブランチに.gitlab-ci.ymlを作成し、Secret Detection機能を有効にする。
リポジトリにAWSのアクセスキーIDを記載したファイルを保存する。
CI/CDパイプラインでAWSアクセスキーIDが検知できるか確認する。

では早速、シナリオの①を実施します。
GitLab.comにSecret Detectionお試し用のプロジェクトを作成します。この時、README.mdを作成するなどして、mainブランチがある状態にしてください。

続いてシナリオの②を実施します。
[ビルド]＞[パイプラインエディタ]をクリックします。

[パイプラインの設定]をクリックします。

サンプル入力を全て削除します。

こちらのGitLab Docsのリンク先の内容、もしくは、以下の内容をコピーし、エディタに貼り付けます。

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

任意のコミットメッセージを付けて、mainブランチにコミットします。
ロール Developer 等の場合は直接mainブランチにコミットできないので、この場合は別名のブランチにコミットした後にmainブランチにマージしてください。

続いてシナリオの③を実施します。
プロジェクトのトップページで、[+] > [新規ファイル] をクリックします。

任意のファイル名を指定します。ここでは例としてAWS_secret_test.txtとします。
続けて、ファイル内容を以下のように記載します。

Access_key_ID=＜AWSのアクセスキーID。"AKI" で始まる文字列。＞

mainブランチもしくは任意のブランチにコミットします。

[ビルド]＞[パイプライン]を開き、一番新しいのパイプラインの実行履歴のステータスが [成功] になっていることを確認します。
(もし、この時点でパイプラインが完了していないかった場合は、F5キーなどで画面をリフレッシュしてパイプラインが完了するのを待ちます。)

最後にシナリオの④を実施します。
一番新しいパイプラインが完了したら、実行履歴の右側にある[アーティファクトのダウンロード]＞[secret_detection:secret_detection]をクリックし、アーティファクト (json形式のファイル) を任意の場所にダウンロードします。

ダウンロードしたアーティファクトを確認します。
Secret Detection機能で機密情報と判定・検知されると、脆弱性 (vulnerabilities) として検知されます。
今回はAWSのアクセスキーIDを書きしましたが、思いっきり "AWS Access Token" という名前のルールに、 重要度：クリティカル で検知されました。

アーティファクト以外でも検知結果を確認することができます。
例えば Ultimate を利用中且つ mainブランチであれば、[安全] > [脆弱性レポート] から、Secret Detection機能による検知結果を視覚的に確認することができます。
シンプルに見やすい！

結果として、Secret Detection 機能で AWSアクセスキーID を無事検知出来ました。
ここまでブログ書いた状態で、万が一検知できなかったらどうしようかとヒヤヒヤしていた筆者でした。

以上でSecret Detection機能のちょっとだけお試しシナリオは完了です。

最後に

この度はGitもCI/CDもよくわかっていないど素人SEによるGitLab検証ブログをお読みいただき、誠にありがとうございます。
このブログの目標は以下のとおりでしたが、皆さまはいかがでしたでしょうか。

今回のゴール

GitLabの Secret Detection の概要を把握する。
GitLabの Secret Detection を使ってみる。

Secret Detection 機能は GitLab が売りにしている AutoDevOpsの一つです。

もしかして、他の人が作った部分に機密情報が入っているかも‥‥。
もし、機密情報をパブリックのリモートリポジトリにコミットしてしまったら‥‥。
すぐに気がついて削除したとしても、機密情報の更新が必要‥‥。
最悪、全然気が付かないで機密情報が流出し、悪用されてしまったら‥‥。
うぅ、書いただけで気分悪くなってきました。

タラレバを言い始めるとキリがないですが、それでも万が一、機密情報を漏洩した際はすさまじい代償を払う事態になりかねません。
GitLab の Secret Detection 機能は Free版でも利用可能な有能な機能です。
CI/CDパイプラインを利用していなかったとしても、Secret Detection 機能だけ実装しておくだけでも、大分安心感があります。
GitLabご利用中の方は、是非本機能の利用をご検討いただければと存じます。

この記事がGitLabを触り始めた方の一助となれば幸いにございます。

GitLabに関するお問い合わせは、以下のフォームからお願い致します。
GitLab製品お問い合わせ

今までのGitLabの検証ブログはこちらです。