GitHubが2万件の秘密情報アラートをゼロに—内部の実践的な対策を公開

20,000件のアラートは実は「ノイズ」だった

GitHubのセキュリティチームが社内で実施した秘密情報スキャンパイロットプログラムの結果は、一見するとショッキングでした。15,000以上のリポジトリから 2万件以上の秘密情報 が検出されたのです。

しかし詳しく調査すると、実態は異なっていました。

わずか5つのリポジトリだけで約18,000件のアラートを占めており、そのほぼすべてがテストフィクスチャや無効化された認証情報、テスト用の偽装シークレット（本物そっくりだが実際には機能しないもの）だったのです。

実際に対応が必要だったのは、残りの2,000件程度。この区別がつかなければ、セキュリティエンジニアは本当のリスクに目を向けられません。Secret Scanningは検出には優れていますが、その後の トリアージ（優先度判定）がカギ になることが明確になりました。

GitHubが秘密情報スキャンを提供する企業だからこそ、自社でも大量のテスト用シークレットが蓄積していたというのは興味深い点です。同じパターンはセキュリティツール開発企業に限った話ではなく、多くの成熟した開発組織で起こりうる課題だと感じます。

コード以外の場所に隠れた秘密情報

セキュリティリスク削減の難しさは、秘密情報がコードの中だけに存在しないという点にありました。GitHubチームが発見した秘密情報の所在先は、想像以上に多岐にわたっていました：

• サポートチケット —顧客が問題報告時に誤ってトークンを含める
• バグバウンティ報告書 —セキュリティ研究者が脆弱性再現時にAPIリクエスト全体を提示
• インシデント対応記録 —事象の調査・解決過程での痕跡
• 社内ウィキ —ドキュメントやナレッジベース

秘密情報の削除プロセス自体が、新たなリスクを生まないよう慎重に設計する必要があったのです。

たとえば、自動で対応イシューをオープンしたり、修正コミットをプッシュしたりすれば、却ってそのイシューやコミット履歴に秘密情報が記録される危険性がありました。このため、GitHubはカスタマーサポート、インシデント対応、バグバウンティプログラムなどの各チームと共同で、統一されたリメディエーション・プレイブック（対応手順書）を策定する必要がありました。

組織規模が大きくなるほど、セキュリティ対応は単一のチームでは完結しません。この点で GitHub の事例は、多くの開発組織にとって参考になるはずです。

段階的なアプローチ—「新たな債務を止めてから整理する」

GitHubが20,000件のアラートをゼロに削減できた背景には、体系的なアプローチがありました。セキュリティエンジニアが個別に対応していたのではなく、運用上の債務削減と同じ方法論を適用 した点が重要です。

何より優先されたのは Phase 1：新たな秘密情報の流入を完全に止める ことでした。

具体的には、Secret Scanning機能を全リポジトリで有効化し、開発者がコミット前にシークレットを検出・修正できる仕組みを作りました。これにより、既存のバックログ削減と並行して、新たなアラートの増加を防ぐことができたのです。

個人的には、このアプローチは他の技術債務（レガシーコード、セキュリティ脆弱性、パフォーマンス問題）の管理にも応用できるフレームワークだと思います。「止めてから片付ける」という順序の重要性は、セキュリティに限った話ではないでしょう。

開発組織が今すぐ実装できる施策

GitHubの事例から、エンジニアやセキュリティチームが実装可能な具体的な施策が浮かび上がります：

1. テスト用秘密情報の標準化
テストコードに本物のトークンを使わず、test_ プレフィックスや特定の形式の偽装秘密を使う。Secret Scanning用ルールにホワイトリスト条件を追加して、テスト用パターンを除外する。

2. 秘密情報の流入経路の把握
コード以外の場所（サポートシステム、バグバウンティプラットフォーム、ドキュメント）でも秘密情報が発生することを前提に、各部門と対応プレイブックを作成する。

3. 優先度付けの自動化
すべてのアラートを同じ重みで扱わない。検出された秘密情報が「アクティブ」か「非アクティブ」かを判定し、リスク評価に反映させる。

GitHub Advanced Security（GHAS）やSecret Scanningなどの機能を既に導入している企業であれば、これらの施策はすぐに検討できるものばかりです。

（参考：GitHub Blog）