シークレットの現状：2025年にGitHubで2,800万件の認証情報が漏えいした理由と、その対策
0 分で読めます
「御社ではAPIキーをどのように管理していますか？」
これは、開発者コミュニティのHacker Newsに投稿された質問です。最も多くの票を集めた回答は、たった一言でした。「ひどいものです。」
データもそれを裏付けています。GitGuardianの「2026 State of Secrets Sprawl」レポートによると、2025年だけで2,865万件の新たなハードコードされたシークレットが公開GitHubリポジトリに追加されました。前年から34%の増加です。GitHub独自のセキュリティレポートでは、2024年に3,900万件のシークレット漏えいが確認されています。IEEE S\&P 2025で発表された8,000万件以上のファイルを分析した学術研究では、プロジェクトの最大30%にリスクがあることが分かりました。
この傾向は、経験レベルや組織の規模を問わず見られます。こうした認証情報の侵害が招いてきた法的・金銭的な影響を見ていきましょう。
この記事では、認証情報が漏えいする理由、漏えいを検出・防止するツール、そして実践的な多層防御の構築方法を包括的に解説します。.envファイルを整理したい個人開発者から、組織全体にスキャンを導入するセキュリティチームまで、役立つ情報が見つかるはずです。
「シークレット」とは何か
シークレットとは、システムやリソースへのアクセスを許可するあらゆるデータです。代表的なものとして、APIキー、データベースのパスワード、SSH秘密鍵があります。しかし、その定義は大きく広がっています。
クラウドIAM認証情報（AWSアクセスキー、GCPサービスアカウントのJSON、Azureクライアントシークレット）
OAuthトークンとリフレッシュトークン
Webhook URL（認証情報が埋め込まれていることがよくあります）
接続文字列（データベース、メッセージキュー、キャッシュ）
暗号化キーと署名証明書
AIサービスのAPIキー（OpenAI、Anthropic、Hugging Face、DeepSeek）
MCPサーバーの設定トークン（急速に増加しているカテゴリです。詳しくは後述します）
OWASP Secrets Management Cheat Sheetでは、シークレットの分類を詳しく解説しています。重要なのは、マシンが認証に使用するものはすべてシークレットであり、現代のアプリケーションでは多くのマシンが相互に通信しているという点です。
シークレットが漏えいする仕組み
シークレットがどのように外部に露出するのかを理解することが、防止の第一歩です。コミュニティでの議論、学術研究、業界データをもとに、最もよくある経路を紹介します。
誤ってコミットする
最もよくあるケースです。開発者が開発中に「テスト用だから」と認証情報をソースコードに追加し、そのファイルをバージョン管理にコミットしてしまいます。後のコミットでシークレットを削除しても、Gitの履歴には永久に残ります。Gitの追記専用のデータモデルでは、git rmを実行しても実際にデータが削除されるわけではありません。攻撃者は公開リポジトリの全履歴をスキャンできますし、実際にそうしています。
r/awsのスレッドで紹介された実例では、あるチームがフロントエンドのJavaScriptに、S3への完全なDelete権限を持つIAMアクセスキーを直接埋め込んでいました。数日以内に、正体不明の攻撃者によってS3バケットが消去されました。
.envファイルの問題
.envファイルは開発を便利にするためのものであり、セキュリティ境界として誤解されてきました。そもそも、セキュリティ境界として設計されたものではありません。リスクはよく知られています。
開発者がファイル名を指定せず
git add .を使うと、.envファイルが誤ってコミットされるSlackのメッセージやスクリーンショット、メモアプリで共有されたり、デバッグのためにChatGPTへ貼り付けられたりする
不用意な
COPY . .ディレクティブによって、Dockerイメージに含まれてしまう
SnykのSnykSecチャンネルでは、このトピックを詳しく解説しています。
.envファイルにシークレットを保存すべきでない理由。実行時のシークレット注入にDopplerや1Password CLIを利用する、実践的な代替策を紹介します。
この動画では、.envファイルを狙ったサプライチェーン攻撃（tinyColorやngx-bootstrapなど、侵害されたNPMパッケージ）を解説し、静的な.envファイルをDopplerや1Password CLIのop runコマンドによる実行時のシークレット注入に置き換える方法を紹介します。
サプライチェーンを介した侵入
開発環境から認証情報を盗む悪意あるパッケージは、仮定の話ではありません。Snykは、実際に起きた複数のインシデントを追跡してきました。
Shai-Hulud NPMワームは、NPMとGitHubのトークンを大規模に探し出して窃取するよう設計されていました
tinyColor/ngx-bootstrapの侵害では、週に数百万回ダウンロードされるパッケージに、認証情報を盗むマルウェアが埋め込まれました
特に注目すべき事例では、攻撃者が侵害されたNPMパッケージ（
@ctrl/tinycolor、週間ダウンロード数220万）にTruffleHog自体を悪用したペイロードを仕込み、このセキュリティツール自身のスキャン機能を使ってシークレットを見つけ出し、窃取しました。
コード以外の場所
GitGuardianの調査によると、認証情報に関するインシデントの28%は、コードリポジトリ以外の場所で発生しています。シークレットは次のような場所から漏えいします。
Slackのメッセージ（2.4%のチャンネルに、少なくとも1つの漏えいしたシークレットが含まれる）
Jiraのチケット（6.1%で認証情報が露出。バグ報告のログに含まれていることがよくあります）
Confluenceのページ（接続文字列を含むドキュメント）
Docker Hubのイメージ（認証情報が埋め込まれたイメージが1万件以上見つかっています）
コード整形サービス（開発者がコードをオンラインの整形ツールに貼り付けるケース）
arXivのプレプリント（Dubniczkyほか、2025年の報告によると、LaTeXのソースファイルから数千件のクラウドAPIキーが見つかっています）
AI支援開発の影響
これは最も急速に増加している漏えい経路です。GitGuardianの2026年レポートによると、AI支援によるコミットでは3.2%の割合でシークレットが漏えいしており、通常の約2倍に達しています。背景にはいくつかの要因があります。
AIコーディングツールが、ハードコードされた認証情報を含む動作可能なコードを生成することがある
コード補完機能が、学習データに含まれる認証情報を記憶し、再び出力する可能性がある（Huangほか、2023年、被引用数39件）
2024年のインシデントでは、AIコードエディターのCursorが、ファイルが
.cursorignoreに記載されていた場合も、タブ補完のために.envファイルの内容をサーバーに送信していたことが明らかになりましたニューラルネットワークを使ったコード補完ツールは、何がシークレットにあたるのかを本質的に理解しているわけではありません
AIサービスの認証情報は、漏えいするシークレットの中で最も急速に増加しているカテゴリで、2025年には前年比81%増となりました。特によく漏えいしているのは、Hugging Faceのトークン、Azure OpenAIのキー、Weights & Biasesの認証情報です。DeepSeekのAPIキーだけでも、2025年に11万3,000件が検出されました。
MCP認証情報の問題
Model Context Protocol（MCP）サーバーを利用している場合、新たに注意すべき認証情報の露出箇所があります。GitGuardianは、公開GitHub上のMCP関連設定ファイルから固有のシークレットを24,008件発見し、そのうち2,117件が現在も有効であることを確認しました。
根本原因は見逃せません。公式のMCPクイックスタートドキュメントでは、設定例にAPIキーを直接ハードコードしていることがよくあります。開発者はこの例をコピーし、プレースホルダーを実際のキーに置き換えて、設定ファイルをコミットします。MCPのエコシステムは急速に拡大しており、このパターンも同じ速度で広がっています。
Snykは、MCPサーバーのセキュリティ確保やエージェント型AI開発環境のリスクについて、数多くの記事を公開しています。悪意あるMCPサーバーやAgent Skillsエコシステムにおける認証情報の漏えいに関する調査も、さらなる背景を示しています。AIアプリケーションの構築に使うツール自体が、認証情報を露出させる経路になりつつあるのです。
安全なAIコードの秘訣。SnykがAI開発ワークフローと連携し、生成コードに潜むセキュリティの問題を検出する方法を紹介します。
SASTとシークレットスキャン：関連するが別のもの
開発者コミュニティでよく話題になる誤解の1つに、SAST（静的アプリケーションセキュリティテスト）ツールがシークレットスキャンもカバーするという思い込みがあります。両者は互いを補完しますが、別々の分野です。その違いを理解しておくことが重要です。
Snyk CodeなどのSASTツールは、インジェクションの脆弱性、安全でないデシリアライゼーション、認証の回避など、ソースコードに含まれるセキュリティ上の脆弱性を分析します。通常は、作業ツリー（ファイルの現在の状態）をスキャンします。
専用のシークレットスキャンツールは対象範囲が異なり、すべてのコミット、ブランチ、そしてオブジェクトストアに残っている削除済みファイルも含め、Gitの全履歴をスキャンします。次のような理由から、これは重要です。
あるコミットでシークレットを登録し、次のコミットで削除しても、Gitの履歴には残る
コミットをまとめても、SHA-1ハッシュからアクセスできる「ぶら下がり」データは消えない
削除したファイルも
.packファイル内に残っていればスキャンできるバグ報奨金プログラムの報告では、公開リポジトリの削除済みファイルやぶら下がりブロブのスキャンだけで、6万4,000ドルを獲得した事例が紹介されています。
実際には、コードレベルの脆弱性を見つけるSASTと、認証情報の露出を検出する専用スキャナーの両方が、組織にとって有益です。それぞれ異なるリスク領域に対応します。r/devsecopsのある実務者の言葉を借りると、「シークレットスキャンツールはGitの履歴も調べるため、リポジトリの規模によっては時間がかかることがあります。」
シークレットスキャンツールの全体像
シークレットスキャンのオープンソースエコシステムは、大きく成熟しました。各ツールの強みと制約を率直に評価しながら、2026年の状況を見ていきましょう。
TruffleHog
TruffleHog（約25,300スター、Go、AGPL-3.0）は、2016年にDylan Ayreyによって作成され、現在はTruffle Security Co.がメンテナンスしています。同社は2025年11月にシリーズBで2,500万ドルを調達しました。
特筆すべき機能は、認証情報をリアルタイムで検証できることです。正規表現ルールとのパターン照合に加えて、TruffleHogは検出した認証情報をプロバイダーのAPIで実際に検証し、まだ有効かどうかを確認できます。これにより、誤検知を大幅に減らせる可能性があります。800種類以上の検出器を備え、--only-verifiedフラグを使えば、有効性が確認された認証情報だけに絞り込めます。
TruffleHogはGitの履歴、S3バケット、GitHub/GitLabの組織（イシュー、PR、コメントを含む）、Dockerイメージ、Jira、Confluence、Slack、Syslogをスキャンし、認証情報が現れる可能性のある幅広い場所をカバーします。
制約：AGPL-3.0ライセンスはエンタープライズでの導入に際して障壁になることが報告されており、Hacker NewsやRedditの複数のスレッドで、法務チームが導入を認めない場合があると指摘されています。また、大規模なスキャンではリソースを多く消費し、正規表現のみを使う代替ツールより実行速度が遅くなります。
Gitleaks
Gitleaks（約25,700スター、Go、MIT）は、最も広く使われているオープンソースのシークレットスキャナーの1つです。Zach Riceが作成し、TOMLベースのカスタムルールによる高速で柔軟なスキャンを提供しています。
Gitleaksの強みは、速度と柔軟な設定です。ミリ秒単位の応答が求められるpre-commitフックに最適です。MITライセンスのため、企業でも導入しやすくなっています。
その代わり、誤検知が発生しやすくなります。Gitleaksはリアルタイム検証を行わず、正規表現による照合を使うため、シークレットに見えるだけのパターンも検出します。r/devsecopsの実務者は、Gitleaksをブロッキングチェックとして有効にする前に、まずベースラインモードで実行し、オフラインで誤検知を調整することを一貫して推奨しています。特にgeneric-api-keyルールは、誤検知が多く発生する原因となります。
注目すべきことに、Zach Rice本人（u/Phorcez）もこのトレードオフを認めています。「Gitleaksは軽量で高速、設定の自由度も高い一方、検証機能はありません。検証が必要なら、TruffleHog、あるいはTruffleHog Enterpriseのようなツールを使うとよいでしょう。」
その他の注目すべきスキャナー
Nosey Parker（スター2,300件、Rust、Apache 2.0）。ペンテスト企業Praetorianが開発。汎用的なシークレットの検出には、正規表現だけを使う方法より優れているとされる文字列エントロピーアルゴリズムを採用しています。Rustベースで高速です。
Kingfisher（スター876件、Rust、Apache 2.0）。MongoDBが2025年に公開したツールで、Gitleaksの2～5倍の速度をうたっています。リアルタイム検証と影響範囲のマッピング（漏えいしたキーが実際に何にアクセスできるか）を追加しています。Nosey Parkerからフォークされ、tree-sitterを使った言語コンテキストの認識に対応しています。影響範囲の可視化は画期的な機能です。
git-secrets（スター数13,200、Shell、Apache 2.0）。AWS Labsが提供する軽量なbashベースのフックです。AWS認証情報に特化しており、その範囲では「完成」したツールと見なされています。
ggshield（スター数1,900、Python、MIT）。500種類以上のシークレットに対応し、商用プラットフォームを基盤とするGitGuardianのCLIです。CursorとClaudeに対応するAIコーディングアシスタント向けフックを2026年3月に追加しました。
Talisman（スター数2,100、Go、MIT）。ThoughtWorksが開発しています。すべてのリポジトリにグローバルなgitフックとしてインストールでき、組織全体への適用に適しています。
ripsecrets（スター数900、Rust、MIT）。保守的なルールにより誤検知率を低く抑えた、特化型の高速なpre-commitフックです。
学術ベンチマークが示すもの
NC State Universityの研究者は、SecretBenchデータセット（818リポジトリから収集した97,479件のラベル付きインスタンス）を用いたシークレット検出ツールの初の厳密な比較研究を発表しました。その結果は示唆に富んでいます。
Gitleaks：再現率88%（最高）、適合率46%
GitHub Secret Scanner：適合率75%（最高）、再現率はそれより低い
TruffleHog：再現率52%、適合率は中程度
ツール間の重複：ggshieldとTruffleHogの真陽性の重複はわずか76%。ggshieldとGitleaksでは、わずか18%です。
研究チームは、調査対象のどのツールもすべての種類のシークレットを検出できなかったことから、複数のツールを組み合わせて使うことを明確に推奨しています。このデータは、多層的なアプローチの必要性を裏付けています。
台頭するLLMベースのアプローチ
FuzzingLabsは、実際のコードベースを対象にLLMベースのシークレット検出を従来のツールと比較してベンチマークしました。その結果、GPT-5-miniの再現率は84.4%で、Gitleaksの37.5%を上回りました。学術研究でもこの傾向が裏付けられており、ファインチューニングしたオープンソースモデル（LLaMA-3.1 8B、Mistral-7B）はSecretBenchデータセットでF1スコア0.985を達成しています。
LLMは、変数をまたいで連結されたシークレット、難読化されたトークン、デコードされた変数、コメントアウトされた認証情報など、正規表現ベースのツールが見逃しがちなパターンを検出できます。これが次世代の検出ツールとなる可能性は高いでしょう。
オープンソースのメンテナーへの注意点
この記事で取り上げたツールの多くは、それ自体がオープンソースプロジェクトです。認証情報管理ツールのエコシステムも拡大を続けています。この分野（またはその他の分野）のオープンソースプロジェクトをメンテナンスしている方は、Snyk Secure Developer Programをご利用ください。条件を満たすオープンソースプロジェクトに、SAST、SCA、コンテナ、IaCスキャンを含むエンタープライズレベルのセキュリティスキャンを無料で提供します。この記事で紹介してきた多層的なセキュリティを、ツール自体にも適用できます。
シークレット管理ツール：シークレットをどこに保管すべきか？
漏えいしたシークレットの検出は、問題の一側面に対処するものです。もう一つの側面は、そもそもシークレットを安全に保管し、配布することです。
HashiCorp Vault
Vault（スター数35,300）は、シークレット管理におけるエンタープライズ標準であり続けています。特筆すべき機能は動的シークレットです。長期間有効な認証情報を保管する代わりに、要求に応じて有効期間の短い認証情報を生成します。また、暗号化サービス、PKI、SSH証明書の署名にも対応しています。
知っておくべき背景が2点あります。Vaultのライセンスは2023年にMPLからBSL 1.1に変更され、コミュニティフォークのOpenBaoへの関心が高まりました。また、IBMはHashiCorpを約64億ドルで買収し、VaultはIBMのプラットフォームの一部となりました。
現場のエンジニアによると、Vaultは強力ですが複雑です。r/devopsでの次の指摘がその実態をよく表しています。「Vaultを自分たちで導入した顧客の約3分の2は、導入方法を誤っており、何も使っていなかった場合と同等か、それより安全性の低いシークレット管理を実際に行っている」。Vaultを最大限に活用するには、専任の運用サポートが必要なインフラとして扱うのが最適です。
Infisical
Infisical（スター数25,600、MIT）は、最も急成長しているオープンソースのシークレット管理プラットフォームです。シークレット管理、シークレットスキャン、PKIを単一の製品に統合し、毎日リリースを行っています。YC W23。セルフホストとクラウドの両方に対応しています。
VaultのBSLライセンスへの変更以降、コミュニティではMITライセンスの代替製品への関心が高まっています。Infisicalは、オープンソースライセンスを維持しながら、エンタープライズ向け機能（RBAC、監査ログ、環境分離、Kubernetesオペレーター）を提供します。VaultやDopplerとともに、2024～2025年のコミュニティでの議論でも頻繁に取り上げられています。
SOPS
SOPS（スター数21,300、MPL 2.0）は異なるアプローチを採用しています。YAML、JSON、ENVファイル内のシークレットをその場で暗号化し、暗号化されたファイルをGitにコミットします。キーは読み取れる状態を保つため（差分確認やlintに重要）、値はAWS KMS、GCP KMS、Azure Key Vault、またはageで暗号化されます。
SOPSはGitOpsワークフローに関する議論でよく話題に上り、「シークレットをどう管理していますか？」というスレッドでよく推奨されています。ローカル開発にdirenvを組み合わせれば、シークレットを安全にバージョン管理へ登録したいチームにとって実用的な方法です。
その他の管理ツール
Doppler：最近のコミュニティスレッドでよく推奨されている商用SaaSです。環境を分離でき、インフラ不要でシークレットを管理できます。
1Password CLI（
op run）：シークレットをディスクに書き込まず、実行時に注入します。シークレット注入前にTouch IDを求める生体認証ゲートは、静的ファイルと比べてセキュリティを大きく向上させます。dotenvx（スター数5,300）：オリジナルの
dotenvの作者が開発しています。暗号化された.env.vaultファイルにより、シンプルな開発手法と適切なシークレット管理をつなぎます。External Secrets Operator（スター数6,500）：30以上の外部バックエンドからシークレットを同期する、Kubernetesにおける事実上の標準です。
多層防御を構築する：実践ガイド
すべての認証情報漏えいを防ぐ単一のツールや手法はありません。Reddit、Hacker News、OWASP、学術研究で示されている業界の共通認識は、多層防御です。
レイヤー1：pre-commitフック（コミット前に検出）
Gitleaks、ggshield、TruffleHogなどのシークレットスキャンツールをpre-commitフックとしてインストールしましょう。最も迅速なフィードバックが得られ、誤ってコミットされるシークレットの大半を検出できます。
重要：クライアント側のpre-commitフックは回避できます（--no-verify）。より強固に適用するには、リポジトリレベルでシークレットを含むプッシュをブロックするサーバー側のpre-receiveフックを実装してください。
スキャンを初めて導入するときは、ベースラインモードを使用します。リポジトリの全履歴をスキャンし、既存の検出結果を確認したうえで、以降は新しいシークレットだけをアラート対象にします。こうすることで、誤検知による疲弊で導入が進まなくなるのを防げます。
レイヤー2：CI/CDスキャン（pre-commitで見逃したものを検出）
CIパイプラインにスキャンのステップを追加しましょう。TruffleHogの--only-verifiedフラグのように認証情報の検証に対応するツールなら、検出した認証情報が現在も有効か確認し、ノイズを減らせます。
このレイヤーでは、pre-commitフックをすり抜けたシークレット（フックの無効化、squashされたコミット、force push、フォークからのコントリビューションなど）を検出します。
レイヤー3：一元管理されたシークレット保管庫（漏えいの発生源をなくす）
シークレットを.envファイル、環境変数、設定ファイルから完全に取り除きます。実行時の注入には、専用のシークレットマネージャーを使用しましょう。
AWSを利用する環境：IAMロールとAWS Secrets ManagerまたはSSM Parameter Store
マルチクラウド環境：Vault、Infisical、またはDoppler
Kubernetes環境：任意の保管庫からシークレットを同期するExternal Secrets Operator
小規模チーム：暗号化された設定にはSOPS + age、または暗号化された
.envにはdotenvx
シークレットマネージャーを唯一の信頼できる情報源とし、.envファイル、CI変数、チームのWikiに残るシークレットのコピーと併存させないでください。
レイヤー4：CI/CDにOIDCを導入（静的認証情報を完全になくす）
検討する価値のあるアーキテクチャ変更の一つが、静的なCI/CD認証情報をOIDCベースのフェデレーションIDに置き換えることです。
このパターンでは、GitHubのOIDCプロバイダーを使ってAssumeRoleWithWebIdentity経由で有効期間の短いAWS認証情報を取得します。IAMアクセスキーをどこにも保存する必要はありません。Hacker Newsやr/devopsでのコミュニティの認識は明確です。GitHub Secretsに静的な認証情報を保存するのは、今やアンチパターンです。
レイヤー5：全履歴の定期スキャン（過去の漏えいを検出）
組織内のすべてのリポジトリ履歴を定期的にスキャンするよう設定しましょう。次のものを検出できます。
スキャン導入前にコミットされたシークレット
削除されたコミットや参照されていないgitオブジェクト内のシークレット
非公開から公開に変更された過去のリポジトリ
組織全体のスキャンに対応するツールはいくつかあります。たとえばTruffleHogは、GitHub組織全体をスキャンできます。
レイヤー6：トークン形式の設計（シークレットを識別可能にする）
APIを構築する場合は、識別可能なトークンを設計しましょう。GitHubは2021年にトークン形式を再設計し、ghp_のような既知のプレフィックスとチェックサムを組み込むことで、スキャンの精度を大幅に向上させました。Stripeのsk_live_プレフィックスが代表例です。
自己識別型トークンは、エコシステム内のあらゆるスキャンツールの効果を大きく高めます。GitHubのプロダクトマネージャーも、すべてのサービスプロバイダーにこのパターンを採用するよう明確に呼びかけています。
シークレットが漏えいした場合：インシデント対応
すべての対策を講じても、漏えいは起こり得ます。対応手順は次のとおりです。
ただちにローテーションする。議論や事前調査はせず、認証情報を無効化して新しいものを発行してください。自動検出ボットは、公開リポジトリへのプッシュから数分以内にGitHub APIをスキャンします。
監査ログを確認する。CloudTrail、GCP Audit Logs、または同等のログを調べ、露出した認証情報が不正に使用されていないか確認してください。
影響範囲を評価する。その認証情報でどのようなアクセスが可能でしたか？どのデータにアクセスされた可能性がありますか？
履歴の削除は二次対応です。コンプライアンス上必要な場合は、git filter-repoまたはBFG Repo-Cleanerを使用して、gitの履歴からシークレットを削除します。ローテーションはセキュリティリスクに対処し、履歴の削除はコンプライアンスと衛生面に対処します。履歴を消去したかどうかにかかわらず、一度でも公開されたシークレットは侵害されたものとして扱うべきです。
r/devsecopsでの現場の共通認識は、シークレットをローテーションして（履歴に残っていても害がない状態にして）、コンプライアンス上必要な場合を除き履歴は削除しない、というものです。ローテーション済みの認証情報をハニーポットの目印として履歴に残す組織もあります。
法的な現実：認証情報の漏えいには代償が伴う
認証情報のセキュリティをめぐる法的環境は、大きく変化しています。以下の事例は、認証情報の管理がビジネス上の重要課題である理由を示しています。
United States v. Sullivan（第9巡回区控訴裁判所、2025年）。Uberの最高セキュリティ責任者は、GitHubリポジトリにハードコードされたAWS認証情報が原因の侵害を隠蔽したとして、司法妨害および重罪の不告知で刑事有罪判決を受けました。攻撃者は認証情報を見つけ、5,700万人分のデータを含むS3ストレージにアクセスしました。Sullivanのチームは侵害を公表せず、バグ報奨金プログラムを通じて攻撃者に10万ドルを支払いました。第9巡回区控訴裁判所は有罪判決を支持し、認証情報を利用した侵害を隠蔽した経営幹部は、個人として刑事責任を問われることを示しました。
Capital One（2022年）。元AWSエンジニアがSSRFの脆弱性を悪用してクラウドIAMメタデータ認証情報を窃取し、約1億人の顧客データへのアクセスを可能にしました。民事集団訴訟は1億9,000万ドルの和解に至りました。
FTCによる執行措置。FTC v. Wyndham（第3巡回区控訴裁判所、2015年）（73件の引用）を受け、FTCの同意命令では現在、認証情報の定期的なローテーションプログラム、コードリポジトリのシークレットスキャン、ソースコードへの認証情報のハードコード禁止が日常的に義務付けられています。FTCは、認証情報のセキュリティ上の不備をめぐり、UberやMetaなどに対して執行措置を和解しています。
SEC v. SolarWinds（ニューヨーク南部地区連邦地方裁判所、2023年）。SECは、SolarWindsが実際のシークレット管理の実態を投資家に偽って伝えたとして提訴しました。主要な主張は一部棄却後も維持され、侵害に関する責任が証券法の領域にまで及ぶことを示しました。
認証情報とアクセス制御の不備に端を発したEquifaxの情報漏えいにより、FTC史上最大となる7億ドルの和解金が発生しました。
押さえておきたい6つの原則
以下は、OWASP、学術研究、実務者の議論から得られた知見です。
非公開リポジトリには、公開リポジトリより多くのシークレットが含まれています。 GitGuardianによると、非公開リポジトリは公開リポジトリよりもハードコードされたシークレットが含まれている可能性が6倍高いとのことです。非公開リポジトリも複製やフォーク、請負業者によるアクセスの対象になり、公開されてしまうこともあります。
コミットされたシークレットは、Gitの履歴に残り続けます。次のコミットで削除した場合も、リポジトリが非公開の場合も同じです。Gitの追記専用のデータモデル上、一度コミットされた認証情報は漏えいしたものとして扱う必要があります。
ツールによって検出範囲は異なります。学術的なベンチマークでは、ツール間の真陽性検出結果の重複はわずか18～76%にとどまることが示されています。異なるレイヤーで複数のツールを実行すれば、検出範囲を広げられます。
認証情報のローテーションはリスクに対処し、履歴の消去はコンプライアンスに対処します。認証情報を無効化すれば、Gitの履歴に残っていても問題はありません。ローテーションせずに履歴だけを消去しても、リスクは解消されません。
検出後の対応がなければ、検出だけでは効果が限られます。2022年に漏えいしたシークレットの64%は、2026年になっても有効なままでした。検出しても修復しない組織は、根本的なリスクを抱え続けることになります。
開発者のワークステーションは、攻撃対象領域として拡大しています。サプライチェーン攻撃、ファイルにアクセスできるAIコーディングツール、MCPサーバーを標的とするプロンプトインジェクションは、いずれもローカルマシン上で認証情報を窃取する経路となります。武器化されたAIコーディングエージェントに関するSnykの調査では、この新たな攻撃対象領域を取り上げています。
まずはここから
前述の多層防御は、一度にすべて取り組むには大変に感じるかもしれません。幸い、各レイヤーは単独でも効果を発揮し、段階的に導入できます。
まずは可視化から -認証情報の漏えいを修正するには、まず発生箇所を把握する必要があります。pre-commitスキャンフック（Gitleaks、ggshield、TruffleHogなどのツールが対応）を追加して新たな漏えいを検出し、認証情報の検証機能を使った組織全体のスキャンを実行して、現在の露出状況を把握しましょう。SASTにSnyk Codeをすでに利用している場合は、専用のシークレットスキャンを組み合わせることで、コードレベルの脆弱性と認証情報の露出の両方に対応できます。
.envファイルとCI/CDシークレットを監査しましょう - 実際の認証情報がバージョン管理に含まれていないか、非公開リポジトリも含めて確認してください。コミットされている認証情報はすべてローテーションしましょう。CI/CDパイプラインも確認し、静的な認証情報をOIDCベースのフェデレーションIDに置き換えられないか検討してください。シークレット管理の方法を見直しましょう。 -チームが今も
.envファイルを使って認証情報を受け渡したり、環境変数を手動で設定したりしている場合は、Infisical、Vault、Dopplerなど、実行時にシークレットを注入する一元管理の選択肢を検討してください。AI開発ワークフローを保護しましょう -AIコーディングアシスタントやMCPサーバーを利用している場合は、ハードコードされた認証情報が設定に含まれていないか確認してください。SnykのMCPサーバー連携では、AIが生成したコードをリアルタイムでスキャンできます。また、Snyk Open Sourceは、侵害された依存関係がコードベースに到達する前に検出します（認証情報窃取マルウェアを送り込むのと同じサプライチェーン攻撃経路です）。
組織全体のセキュリティ意識を高めましょう -効果的な認証情報管理には、ツールとチームの取り組みの両方が欠かせません。Snykの開発者向けセキュリティプラットフォームは、SAST、SCA、コンテナセキュリティ、IaCスキャンを開発者のワークフローに統合し、チームにセキュリティ態勢の統合的なビューを提供します。開発者が普段使っている環境でセキュリティ上の問題を確認できれば、自然と導入が進みます。
HNで最も多くの賛成票を集めた回答は、率直なものでした。多くの組織では、認証情報が適切に管理されていません。しかし、改善に役立つツール、実践方法、コミュニティの知見は、かつてないほど利用しやすくなっています。
上記で取り上げた、AIを悪用したシークレット漏えいや認証情報の露出リスクの急増に、Pythonアプリケーションは備えられていますか？「Python環境におけるAIセキュリティ危機」ホワイトペーパーをダウンロードして、先進的なチームがAIを活用した開発ワークフローをどのように保護しているかご覧ください。
ホワイトペーパー
Python環境に潜むAIセキュリティの危機
開発スピードが急上昇する中、AI環境が何にアクセスできるか、本当に把握できていますか？