企業向けシークレット検出プログラムを実装する –GitGuardian導入事例

この記事では、シークレット検出プログラムの実装により、お粗末なソースコードのシークレット管理に終止符を打ったGitGuardianのある顧客企業の取り組みについて説明します。

Implementing a Secrets Detection Program for the Enterprise – a case study

本記事は、GitGuardian社のホームページで公開されたブログ記事を日本語に翻訳したものです。
(原題)Implementing a Secrets Detection Program for the Enterprise – a case study

2回シリーズの前回の記事では、ソースコード中に書き込まれた何千ものシークレットというセキュリティ上の負債処理についてその複雑な側面をいくつか検討しました。

遠い過去を探る行為は、ソフトウェア開発ライフサイクル(Software Development Life Cycle =SDLC)におけるシークレットスプロール現象の脅威低減に向けた重要な一歩ですが、シークレット検出プログラムを実装すればそれで終わりというわけではありません。開発が進み、プログラムが成熟するに従い、予防に力を入れ、修復の負担を減らしたいと考えるのが世の常です。

この記事では、シークレット検出プログラムの実装により、お粗末なソースコードのシークレット管理に終止符を打ったGitGuardianのある顧客企業の取り組みについて説明します。

それでは、詳しくみていきましょう。

背景

今回取り上げる企業概要

GitGuardianは、サイバーセキュリティを専門とする米国のある多国籍企業と業務提携を結び、5,000を超える開発者に対してエンタープライズ向けシークレット検出・修復プラットフォームを展開してきました。

今回の事例で取り上げる企業は世界中に拠点を展開し、世界中の何千もの顧客にサービスを提供しています。同企業の主軸商品・サービスはネットワークやエンドポイントのセキュリティ対策ですが、守備範囲をクラウドネイティブのアプリケーション保護とセキュリティオペレーションに拡大しているところです。

なぜシークレット検出プログラムを行うことにしたのか?

サイバーセキュリティを専門とするこの多国籍企業の経営陣は、シークレット流出のリスクについて然るべき認識を持っていましたが、次のような複数の要因を背景に、同社AppSecプログラムにおけるシークレット検出と修復が重視されるようになりました:

  • シークレットあるいはソースコードの流出を伴う、世間を騒がすインシデント、サプライチェーン攻撃の急増(Solarwinds、Codecov、Daimler-AG、Nissan、United Nations、State of New York)。
  • 外部からの侵入テスト、コードレビュー、社内のレッドチーム演習による、情報漏えいリスクのある認証情報の発見。これはどの組織でも起こり得ることです。
  • 精力的なM&A活動 (企業買収による外側への成長)による、新しい技術環境およびコードベースの導入。
  • アプリケーションおよびソースコードに脆弱性がないかどうか入念な精査が継続的に行われていることを証明する顧客からの定期的な要請(「NIST Minimum Testing Standards for Software Vendors」を参照)。

シークレット検出プログラムの目的

シークレット検出プログラムの目的は、組織やステークホルダー(CISO、セキュリティ担当VP、テクニカル・セキュリティ担当者、エンジニアリング担当役員等)ごとに異なる場合もありますが、どの組織にも共通しているのは、シークレット漏えいリスクの低減です

このサイバーセキュリティ企業はほかにも以下について検討を重ねていました:

  • ソフトウェア開発プロセスにおいて、セキュリティテストを工程の早い段階に前倒しするいわゆるシフトレフト を行い、さらにAppSecチームによる把握と管理が可能な後工程まで延長する(いわゆるシフトライト)。
  • オープンソースをベースにした自社開発検出ソリューションとの比較による総保有コスト(TCO )+投資利益率(ROI)を立証する。
  • アプリケーションセキュリティ分野の人材不足解消方法を見つけ、自動化の導入によりフルタイム社員相当の人材採用ニーズに対応する。

コード中のゼロシークレットポリシーに向けた取り組み

問題の評価

この企業が最初に実施したのは、1,000名ほどの開発者が活発に参加するかなりの規模のペリメーター、すなわちコードベース上での概念実証(Proof Of Concept=POC)です。全履歴の精査からは、コード中に書き込まれた何千という認証情報が見つかりました。

また、GitGuardianが実施した詳細分析からも、開発者がこのペリメーターに毎月アップする認証情報件数は平均で数百件に及ぶことが判明し、このことは後にこの企業のセキュリティリーダーたちが「止血」と呼ぶ取り組みの強力な動機付けとなりました。

「修復」よさらば、来たれ「予防」

GitGuardianはバージョン管理システム(GitHub、GitLab、Bitbucket)、CI/CDツールとネイティブに連携し、セキュリティチームのインシデント、ポリシー違反をリアルタイムで検出します。このダウンストリーム検出は、状況を可視化し、インシデント対応のワークフロー開始(ソースコードに書き込まれた認証情報の削除)のトリガーとなります。ここで重要なのは、この段階での精査はあくまでも情報収集であり、具体的な防御策の導入ではないということです。


この会社のAppSecチームは人手が足りていない状態で、SASTやSCAスキャナーで検出された別の脆弱性管理に追われている状態です。そのため、同チームはソースコードに認証情報が書き込まれたコミットのプッシュイベントをブロックする、開発者向けの「ガードレール」を導入する必要があることに気付きました。つまり、「止血」が必要だったのです。GitGuardianは、GitのPre-receiveフックを使った、ggshield(コマンドラインインターフェイス)のセットアップを支援しました。


GitフックでシークレットをキャッチすることでVCSへの流出を回避

この実装は非常に強力です。セルフホスト型のGitHubあるいはGitLabインスタンスに導入するだけで、すべてのコードコントリビューションでpushをブロックしてくれます。仕組みは以下の通りです:

  • GitGuardianがシークレットをキャッチすると、開発者はローカルのGitコミットからそのシークレットを削除しないと次のpushを実行できない。
  • 開発者がそれは誤検知であると断定できる、あるいはリスクは承知で、機密ではないとするシークレットをプッシュするのであれば、Break-glass(緊急アクセス用管理者)という選択肢の利用も可能です。

投資利益率(ROI)の立証

上記のような仕組みにより、GitGuardian Internal Monitoringは、開発ワークフローへの影響を極力抑える形でインシデント件数を約80% 削減しています。

また何百件という毎月のインシデント検証に対応する必要がなくなったため、AppSecチームのリソースにもかなりの余裕が生まれています。


セキュリティエンジニアは、開発者が見逃したチェック(シークレットの完全な取り消しと定期的な更新(ローテーション)が必要となる)チェックがないかアラートを入念に調べる必要がありますが、現在この件数は平均で約50件となっています。

この企業が次にすべき取り組み

セキュリティ上の負債を取り除く

新規インシデントを予防できるようになったことで、AppSecチームはセキュリティ上の負債に取り組めるようになり、現在は過去のインシデントを分析し、GitGuardianによる支援の前にソースコード中に書き込まれたシークレットの脅威に対応しています。

本施策の計画および実施方法の詳細については、本ガイドの第1回、「Implementing a Secrets Detection Program for the Enterprise – Investigating, prioritizing, and remediating thousands of incidents」(企業向けシークレット検出プログラムを実装する - 何千件ものインシデントの調査、優先順位付け、修復)をご一読いただくことをお勧めします。

その他の開発者向けプレリリースツールの導入

pre-receiveフックに自動シークレット検出を追加することで、セキュリティチームはシークレットの流出はほぼないという安心感を得ることができます。ただし、この安心感は、シークレットを取り除くためにローカルのgit履歴を書き換えなければならないという、開発者にとってのちょっとした手間を伴います。

この手間を回避する手段として、開発者はGitのpre-commitフックを使って、コミットの履歴に変更を挿入する前にGitインデックスを精査するという選択肢が可能です。Ggshield(GitGuardianのCLI)がこのステージングエリアでシークレットを検出すると、開発者はテキストファイルからシークレットを削除でき(Gitコマンドは不要です)、その上でコミットすることができます。

ただし、ひとつ注意しなければならないのは、中央集約型のセキュリティチームの場合、このレベルのプロテクションは適用できないという点です。その場合は、開発者チームの善意に頼る、 またGitGuardianがお届けする開発者の英知に望みを託してみる必要があります。

最後に

これまでGitGuardianチームは、長い時間をかけて、大規模組織向けのシークレット検出プログラム導入に関するかなりの量のノウハウを蓄えてきました。

2021年の初めの時点で、GitGuardianのInternal Monitoringをご利用いただいている大手企業様10社の平均開発者ライセンス数は1,380でした。1年後、この数はほぼ倍増し、デプロイ1件あたり2,688開発者ライセンスとなっています。このことは、GitGuardianのプラットフォームとサポートの成熟の証といってもいいでしょう。

GitGuardianが提供するシークレット保護ソリューションの詳細が必要な方は、テリロジーワークスまでお問い合わせください。