LASSIC Media らしくメディア
シークレットスキャン導入を外注で進める進め方
LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託
この記事のポイント
- シークレットスキャンはソースコードやコミット履歴に混入したAPIキー・トークンなどの認証情報を検出する仕組みです。
- gitleaksなどのツールは正規表現とエントロピー分析を組み合わせ、pre-commitフックやCIパイプライン、履歴全体スキャンに組み込めます。
- 誤検知（false positive）の抑制やベースライン管理、検出後の鍵ローテーションの初動まで含めて外注の委託範囲を検討する必要があります。
目次
シークレットスキャンとは何か
シークレットスキャンとは、ソースコードやコミット履歴に混入したAPIキー・パスワード・トークンなどのハードコードされた認証情報を自動検出する仕組みを指します。gitleaksのようなツールは、リポジトリ内のファイルとGitのコミット履歴の両方を走査し、パスワードやAPIキー、トークンといった機密情報を洗い出します*1。
検出対象は現在のコードだけではありません。過去のコミットで一度でも鍵を書いてしまうと、その後に削除してもGitの履歴には残り続けます。シークレットスキャンは、この「今は見えないが履歴には残っている」状態を可視化する点に価値があります。
履歴に残った鍵が公開リポジトリから漏えいする経路
ハードコードされた認証情報がリポジトリに混入する経路として、例外処理やデバッグログへの出力、Dockerイメージやビルド成果物への埋め込み、CI/CDの設定不備によるテスト実行ログへの出力が挙げられます*2。開発中の一時的な動作確認のつもりで鍵を直接コードに書き、そのままコミットしてしまうケースが典型例です。
問題は、現在のファイルから鍵を削除しても解決しない点にあります。OWASP（Open Worldwide Application Security Project、Webアプリケーションセキュリティの国際的な非営利団体）のガイドでは「現在のHEADからシークレットを削除しても履歴からは削除されない」とされ、削除後も漏えいした認証情報は侵害されたものとみなして直ちにローテーションする必要があると明記されています*2。
特にリポジトリを一時的にでもパブリックに公開した場合、GitHubは公開リポジトリ全体を対象にシークレットスキャンを無償で自動実行しています*3。検出されたパートナー発行のシークレット（クラウドサービスやAPIプロバイダーの鍵など）は、GitHubと提携する各サービス事業者に自動で通知され、事業者側での失効対応につながる仕組みです*3。この仕組みは裏を返せば、公開リポジトリに鍵を残すことが第三者に検出される前提のリスクであることを意味します。
正規表現とエントロピー分析による検出の仕組み
gitleaksをはじめとするシークレットスキャンツールは、大きく2つの検出方式を組み合わせています*1。第一に、AWSやSlackなど各サービスのAPIキーが持つ固有のパターンを正規表現でマッチさせる方式です。第二に、シャノンエントロピー（文字列のランダム性を数値化した指標）が一定の閾値を超える文字列を検出する方式です*1。
正規表現方式は既知のフォーマットを持つ鍵に強く、誤検知が起きにくい一方、未知のサービスや独自形式のトークンは拾えません。エントロピー方式はランダムな文字列であれば形式を問わず検出できますが、ハッシュ値やUUIDなど機密情報ではないランダム文字列も拾ってしまう傾向があります。両者を併用することで検出範囲と精度のバランスを取る設計です。
GitHub側のシークレットスキャンも同様に、対象をコードだけに限らずリポジトリのGit履歴全体・Issue・プルリクエスト・Discussions・Wiki・シークレットGistまで広げて走査します*3。対応するシークレットのパターンは順次追加され、新しいパターンが追加されるたびに既存リポジトリが再スキャンされる運用です*3。
pre-commitフック・CI・履歴全体スキャンの組み込み方
シークレットスキャンを開発フローに組み込む代表的な方法は3段階に分かれます。
1つ目はpre-commitフックです。gitleaksは.pre-commit-config.yamlに設定を追加することで、開発者がコミットを実行するたびに自動的にスキャンを走らせられます*1。コミット前に検出できるため、鍵がリモートリポジトリに到達する前に止められる点が利点です。
2つ目はCIパイプラインへの統合です。gitleaksは専用のGitHub Action（gitleaks-action）を提供しており、プルリクエストやプッシュのたびにCI上でスキャンを実行できます*1。開発者のローカル環境でpre-commitフックが未設定・無効化されていた場合の二重の防波堤として機能します。
3つ目は履歴全体スキャンです。gitleaksはgit log -pの出力を活用し、log-optsオプションで特定のコミット範囲を指定した履歴スキャンにも対応します*1。新規導入時には、これまでの全コミット履歴に鍵が残っていないかを一度洗い出す初期スキャンが欠かせません。
GitHub側にはpre-commitフックに相当する仕組みとして、プッシュ保護（push protection）機能があります。これはハードコードされた認証情報がリポジトリに到達する前に検出・ブロックする事前防止型の機能で、コマンドラインからのプッシュ・GitHub UI上でのコミット・ファイルアップロード・REST APIへのリクエストのいずれの経路でも動作します*3。検出時は詳細なメッセージが表示され、開発者は該当箇所を修正してから再度プッシュする流れになります*3。
検出後の初動：鍵のローテーションと履歴除去の考え方
シークレットが検出された場合、まず優先すべきは削除ではなくローテーション（鍵の失効・再発行）です。OWASPのガイドは、漏えいした鍵は速やかに失効させ、新しい鍵に置き換え、露出したシステムから即座に削除し、アクセス履歴を記録するという対応の流れを示しています*2。ある調査では、2022年に漏えいした認証情報のうち64%が2026年1月時点でも有効なままだったと報告されており*2、検出後の放置が長期的なリスクとして残り続けることがうかがえます。
Gitの履歴から鍵の記述そのものを消す作業（履歴の書き換え）については、OWASPも「他の問題を引き起こす可能性がある」と慎重な姿勢を示しています*2。共同開発中のリポジトリで履歴を書き換えると、他の開発者のローカル環境との整合性が崩れ、強制プッシュによる巻き戻し事故にもつながりかねません。このため実務上は、履歴除去よりもまずローテーションを最優先し、履歴の書き換えは影響範囲を洗い出したうえで計画的に実施する判断が求められます。
CI/CD環境における漏えい防止の観点では、パイプラインの出力がシークレットを含まないようにする設計、本番環境パイプラインへのデバッグツールアクセスの制限、ログ記録と監視ルールによる異常検知、最小権限の原則に基づくアクセス制御が基本方針として挙げられています*2。シークレットスキャンはこれらの運用ルールを補完する検出手段という位置づけです。
誤検知（false positive）の抑制とベースライン運用
シークレットスキャンを組織的に運用するうえで実務上の負荷になりやすいのが誤検知への対応です。エントロピー方式はランダムな文字列を機械的に拾うため、テストデータのダミー値やハッシュ値、UUIDまで警告対象になることがあります。
gitleaksには誤検知を抑制する複数の仕組みが用意されています*1。該当行にgitleaks:allowというコメントを付けて特定行を除外する方法、検出結果のフィンガープリント単位で除外リストを管理する.gitleaksignoreファイルによる方法、そしてルール単位で許可リストを設定する方法です*1。
大規模リポジトリを新規に導入する際は、初回スキャンで大量の既存検出結果が出ることが少なくありません。gitleaksの--baseline-pathオプションを使うと、既存の検出結果をベースラインとして指定し、以降のスキャンでは新規に増えた検出結果のみを報告対象にできます*1。導入初期にすべての既存指摘を一度に解消しようとせず、ベースラインを起点に新規混入分を優先して止めていく運用が現実的です。
外注の委託範囲と発注準備で詰めるべき論点
シークレットスキャンの導入自体はツールの設定作業に見えますが、実務では対象リポジトリの棚卸し・除外ルールの設計・検出後のインシデント対応フローの整備まで含めた設計作業が必要になります。この設計を内製だけで担うには、Git運用・CI/CDパイプライン・各クラウドサービスの認証情報体系という複数分野の知識を組み合わせる工数がかかります。
対応を誤った場合の影響も見過ごせません。誤検知の除外ルールを粗く設定すると、本来検出すべき鍵まで見逃す抜け穴になります。逆に除外ルールを設けずに導入すると、大量の誤検知通知が開発チームに届き続け、アラート自体が形骸化するリスクがあります。どちらも「導入しただけで運用が回らない」状態を招く典型例です。
外注を検討する場合、発注前に整理しておきたい論点は次の通りです。第一に、対象範囲（全リポジトリか、公開予定のリポジトリのみか、履歴全体を含むか）を明確にすることです。第二に、検出後の一次対応（誰が鍵の失効を判断し、誰がローテーションを実施するか）の役割分担を契約に含めるかどうかです。第三に、pre-commitフックとCIパイプラインへの組み込み作業、既存リポジトリの初期スキャンとベースライン設定作業のどこまでを委託範囲に含めるかです。これらを発注仕様書（RFP）に落とし込まずに依頼すると、導入後の運用ルール整備が抜け落ちたまま「ツールを入れただけ」の状態になりかねません。
まとめ：シークレットスキャン導入を外注で進める3つの判断軸
本稿ではシークレットスキャンの仕組みと外注検討の論点を整理しました。要点を3つに集約すると次の通りです。第一に、シークレットスキャンは正規表現とエントロピー分析を組み合わせてハードコードされた認証情報を検出し、pre-commitフック・CI・履歴全体スキャンの3段階で組み込む仕組みだという点です。第二に、検出後は履歴除去よりもまず鍵のローテーションを優先し、誤検知はベースラインと除外ルールで段階的に抑え込む運用が現実的だという点です。第三に、外注する場合は対象範囲・初動対応の役割分担・組み込み作業の範囲を発注前に明確にする必要があるという点です。これらを押さえたうえで、自社の体制に合わせて内製と外注の境界線を判断することが、導入後の形骸化を防ぐことにつながります。
よくある質問
シークレットスキャンとSAST（静的アプリケーションセキュリティテスト）は何が違いますか。
シークレットスキャンはハードコードされたAPIキーやパスワードなどの認証情報の混入を検出する仕組みです。一方でSASTはコードの脆弱性（インジェクションや不適切な認可処理など）をソースコード解析によって検出する仕組みで、検出対象が異なります。両者は補完関係にあり、併用が前提です。
公開リポジトリでなくプライベートリポジトリでもシークレットスキャンは必要ですか。
必要です。GitHubの無償の自動スキャンは主に公開リポジトリを対象としており*3、プライベートリポジトリで同等の保護を受けるには機能の有効化やgitleaksのような外部ツールの導入が必要です。プライベートであっても、退職者のアクセス権残存や設定ミスによる意図しない公開のリスクは残ります。
誤検知が多くて開発チームから運用が形骸化しそうな場合はどうすればよいですか。
まずベースライン機能で既存の検出結果を切り分け、新規混入分のみを通知対象にすることが有効です*1。そのうえで、ダミー値やテストデータについては.gitleaksignoreや許可リストで除外ルールを整理し、本当に対応が必要な検出だけが通知される状態に調整する運用が現実的です*1。
シークレットスキャン導入の外注はどこまでを委託できますか。
対象リポジトリの棚卸し、pre-commitフックとCIパイプラインへの組み込み設定、既存リポジトリの初期スキャンとベースライン設定、検出後の一次対応フローの設計までを委託範囲に含められます。ただし実際の鍵のローテーション作業そのものは、各サービスの管理権限を持つ自社側での実施が前提になる場合が多く、役割分担を発注前に明確にする必要があります。
著者：テレリモ総研編集部 鈴木 亮佑
ご不明な点はお問い合わせフォームからもご連絡いただけます。
- *1 出典：gitleaks公式リポジトリ「gitleaks/gitleaks」README（GitHub、参照時点の最新版）https://github.com/gitleaks/gitleaks
- *2 出典：OWASP「Secrets Management Cheat Sheet」（OWASP Cheat Sheet Series）https://cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_Cheat_Sheet.html
- *3 出典：GitHub Docs「About secret scanning」および「About push protection for repositories and organizations」https://docs.github.com/en/code-security/secret-scanning/introduction/about-secret-scanning ／ https://docs.github.com/en/code-security/secret-scanning/introduction/about-push-protection
