Paper Files / Secrets
Secrets as an Attack Surface: 2026年時点における機密情報の漏えい、管理、検出、封じ込めの体系化研究
本稿は、2026年時点のサイバーセキュリティにおける「Secrets」、すなわちAPIキー、トークン、証明書、SSH鍵、クラウド認証情報、CI/CD用クレデンシャル、モデルAPIキー、署名鍵、内部サービス間認証素材などの機密情報を、独立した攻撃対象面として再定義し、漏えい・濫用・横展開・永続化の観点から体系的に分析する。Secretsは従来、単なる認証情報として扱われてきたが、実運用ではソフトウェア供給網、クラウド制御面、生成AIワークフロー、マシン間通信、ソースコード管理、ログ、メモリダンプ、端末、バックアップ、IaC、メタデータサービスを横断する、極めて高価値な資産である。本研究では、Secretsの露出経路をコード、実行時、観測系、サプライチェーン、人的経路の5層に分解し、脅威モデルを定式化したうえで、静的スキャン、履歴スキャン、リポジトリ到達性分析、eBPFベース実行時観測、クラウド監査ログ相関、LLM利用時のプロンプト注入耐性検証を統合した検出・封じ込め手法を提案する。さらに、Git履歴を含む公開・非公開レポジトリ、コンテナイメージ、CIログ、Terraform状態、Kubernetes Secret、AWS/GCP/Azureの設定実例を用いた評価を行い、従来の単一スキャナ中心の運用に比べ、再発見率、平均検出時間、誤検知率、封じ込め時間を大きく改善できることを示す。加えて、2026年に実運用で観測されるSecretゼロトラスト、短命資格情報、ポスト量子移行、AIガバナンス、CNAPP、eBPF、WAF/EDR/SIEM連携を踏まえ、Secretsを「保管物」ではなく「動的に露出しうる攻撃表面」として管理するための実装上の要件と、組織導入時の現実的なトレードオフを論じる。
1. Introduction
Secrets は、2026年のサイバー防御において最も見落とされやすく、かつ最も破壊的な攻撃対象の一つである。多くの組織では、Secrets を「秘密鍵」「API トークン」「パスワード」といった個別の認証素材として扱い、保管場所を限定し、アクセス制御を強化すれば十分だと考えがちである。しかし実際には、Secrets は認証の素材であると同時に、認可、継続的アクセス、サービス間通信、サプライチェーン検証、監査証跡、モデル利用、バックアップ復旧の根幹を担う。つまり、Secrets は単なるデータではなく、組織の信頼境界そのものを具現化したものだといえる。
この性質は、攻撃者にとって極めて魅力的である。なぜなら、1つの有効な Secret は、しばしば複数のシステムにまたがる権限連鎖を解放し、初期侵害から横展開、クラウド資産の列挙、データ窃取、サービス改ざん、永続化へとつながるからである。2026年の環境では、クラウド、SaaS、Kubernetes、GitOps、IaC、生成AI、CI/CD、内部マイクロサービスが密接に統合されており、Secret の漏えいは単一サービスの侵害に留まらず、供給網全体に波及する。さらに、生成AIの利用が一般化したことで、プロンプト、エージェントメモリ、RAGコーパス、コード補完ログ、チケットシステム、会議要約など、新たな漏えい面が加わった。
既存の防御策は、Secret の保管と配布に偏重してきた。たとえば、HSM、KMS、Vault、Secrets Manager、Kubernetes Secret、環境変数、CI変数、パラメータストアなどである。これらは必要条件ではあるが十分条件ではない。問題は、Secret が「存在する」ことではなく、「どこで、いつ、どの粒度で、誰に、どの経路で、どれだけの時間露出するか」である。実務上は、Git 履歴、PR コメント、Issue、ログ、メモリ、crash dump、アーティファクト、コンテナレイヤ、サーバレス環境変数、S3/GCS/Azure Blob、Webhook、Slack、Notion、Confluence、LLM の補助出力などに秘密が残留する。しかも、その残留はしばしば数分ではなく数か月から数年に及ぶ。
本稿の第一の主張は、Secrets を個別の資格情報管理問題としてではなく、攻撃面としての動的な情報露出問題として再定義すべきだという点である。第二の主張は、検出は静的スキャン単独では不十分であり、コード、履歴、実行時、クラウド監査、端末、CI/CD、生成AI使用経路を横断した相関分析が必要であるという点である。第三の主張は、封じ込めは再発見と回収を含む運用問題であり、短命化、ローテーション、自動失効、権限縮退、証跡保存、復旧計画を統合した制御系として設計すべきだという点である。
2026年の脅威環境では、Secrets の問題はさらに複雑化している。第一に、攻撃者は大規模言語モデルを利用して、コードベースからの Secret 発見、文脈推定、権限推論、回避表現生成、フィッシング文面の自動生成を高度化している。第二に、正規の開発者自身が AI コーディング支援の副作用として、意図せず機密値を入力・再利用・ログ出力してしまう。第三に、ゼロトラストの成熟により長寿命パスワードは減少したが、その代替として短命トークンやサービスアカウント鍵の運用複雑性が増し、ローテーション不備が新たなリスクになった。第四に、ポスト量子暗号移行が始まり、鍵管理の複線化が進むことで、鍵素材の種類とライフサイクルが増大している。
本稿では、この状況に対処するため、Secrets の分類、脅威モデル、検出手法、封じ込め手順、評価指標を一貫した枠組みにまとめる。実装面では、gitleaks、trufflehog、detect-secrets、git-secrets、semgrep、yara、osquery、falco、inspektor-gadget、kubectl、aws CLI、gcloud、az、vault など、2026年時点で実用的に利用されるツール群を現実の運用パイプラインに統合する。また、評価においては、検出精度だけでなく、誤検知、再発見、復旧時間、運用負荷、開発者体験への影響も含める。これにより、Secrets 管理をセキュリティ統制ではなく、組織の可用性と信頼性を支える基盤制御として位置づけ直す。
2. Background and Related Work
Secrets 管理の研究は、長らく認証と鍵管理の延長として発展してきた。初期の関心は、パスワード、共有鍵、証明書、SSH 鍵、OAuth トークンといった認証素材の保護に集中していた。しかし、クラウド移行と DevOps の普及により、Secrets はコード、設定、ログ、環境変数、ランタイム注入、サービスメッシュ、Kubernetes、IaC に広く分散した。これに伴い、秘密の露出は静的な保管漏れから、動的な実行時漏えいへと拡張した。OWASP の Secrets Management Cheat Sheet は、ハードコード禁止、最小権限、ローテーション、集中管理を推奨するが、実運用では「どこに残るか」を完全に把握することが難しい（OWASP, 2024）。
Git リポジトリに埋め込まれた秘密の問題は、比較的古くから認識されてきた。git log の履歴、rebase 後の残骸、公開 fork、クローンのミラー、CI の成果物にまで拡散するため、単純な最新ブランチのスキャンでは不十分である。trufflehog や gitleaks は、Git 履歴やソースコード中のパターンを検査し、認証情報らしき文字列を検出する代表的なツールである（TRUFFLE SECURITY, 2025; GITLEAKS, 2025）。しかし、これらは構文的なパターン検出に偏ると誤検知が多く、逆に厳しすぎると漏えいの見逃しが増える。したがって、実運用ではレピュテーション、コンテキスト、外部照合、許容リストを組み合わせる必要がある。
クラウド秘密情報の漏えいに関しては、AWS、GCP、Azure がそれぞれ KMS、Secrets Manager、Key Vault、SSM Parameter Store、Secret Manager を提供している。これらは保存時の暗号化とアクセス制御を実現するが、アプリケーションが Secret を取得した後の露出、たとえばメモリ常駐、ログ出力、診断ダンプ、エラー文言、A/B テスト、メトリクス埋め込みには対処しづらい。さらに、IAM の権限設計が不適切だと、Secret 自体は保護されていても、Secret を取得できる権限が広範に付与される。AWS の CloudTrail、GCP の Cloud Audit Logs、Azure の Activity Log は監査に役立つが、ログが過剰に大きくなると検知と封じ込めの時間差が拡大する。
Kubernetes とコンテナ環境は、Secrets の扱いに新たな難しさをもたらした。Kubernetes Secret は base64 でエンコードされるだけであり、暗号化 at rest を有効にしていなければ etcd に平文近い形で保存されうる。Pod の環境変数、ボリュームマウント、Init Container、Sidecar、Helm values、ConfigMap の誤用、CI/CD の manifest 出力が漏えい経路となる。2026年には eBPF ベースの可観測性とセキュリティ製品が成熟し、falco、cilium、inspektor-gadget、tracee などを用いた実行時検知が現実的になった。これにより、Secret のアクセス元、プロセスツリー、ネットワーク宛先、syscall パターンを連結した監視が可能になっている。
生成AIの普及は、Secrets の脅威モデルを大きく変えた。GitHub Copilot、Amazon Q Developer、ChatGPT Enterprise、Claude、Gemini 等のコード支援や社内LLMは、生産性を高める一方で、秘密の貼り付け、生成補完への混入、会話履歴への保存、RAG 索引への取り込み、評価データへの残留という新たな露出を生む。さらに、プロンプトインジェクションやツール注入により、エージェントが権限を持つ Secret を誤って外部送信する危険もある。AI セキュリティのガイドラインはこの問題を認識しているが、Secret の管理ポリシーと LLM 利用統制が統合されていない組織は少なくない（NIST, 2024; OWASP, 2024）。
脆弱性と秘密情報の関係は、CVE ベースでも明確である。たとえば、CVE-2024-3094 は xz Utils のサプライチェーン侵害として世界的に注目され、ビルドや署名、配布工程における秘密鍵・署名信頼の脆弱性を再認識させた（NVD, 2024）。CVE-2024-3400 などの機器やサービスの脆弱性では、セッションや認証素材の窃取が侵入後の重要な目標となった。秘密情報が漏れれば、その値自体が「攻撃の実行権限」になるため、バッファオーバーフローのような古典的脆弱性とは異なる速度で被害が拡大する。したがって、Secrets の研究は、脆弱性管理、アイデンティティ管理、サプライチェーン防御、クラウドガバナンスの交差点に位置づけられるべきである。
以下の表は、主要な Secret 類型と、典型的な漏えい経路を整理したものである。
| Secret 類型 | 典型例 | 主な漏えい経路 | 被害の特徴 |
|---|---|---|---|
| APIキー | SaaS API key、LLM API key | ソースコード、.env、CIログ |
即時課金被害、外部API濫用 |
| 長短期トークン | OAuth token、JWT、session cookie | ブラウザ、ログ、メモリ、プロキシ | セッション乗っ取り、横展開 |
| クラウド資格情報 | AWS access key、GCP service account key | 環境変数、IaC、コンテナイメージ | 大規模資産列挙、IAM昇格 |
| 署名鍵 | TLS private key、code-signing key | HSM外部エクスポート、ビルド環境 | なりすまし、配布改ざん |
| サービス間認証素材 | mTLS client cert、SPIFFE SVID | サイドカー、メッシュ設定 | 内部侵入、東西トラフィック悪用 |
| 開発用秘密 | GitHub PAT、NPM token、PyPI token | ローカル設定、PR、Issue | 供給網汚染、パッケージ改ざん |
| AI関連秘密 | LLM API key、RAG接続鍵 | プロンプト、ノート、チャット履歴 | モデル濫用、機密検索 |
| 復旧用秘密 | バックアップ鍵、break-glass cred | 共有保管庫、運用手順書 | 永続化、検知回避 |
3. Threat Model and Problem Formalization
本研究の脅威モデルは、内部者、外部攻撃者、サプライチェーン侵害者、LLM 利用者ミスの4類型を含む。外部攻撃者は、公開情報、漏えいデータ、脆弱な CI/CD、端末侵害、SaaS アカウント乗っ取りを通じて Secret を取得する。内部者は、権限を持つ開発者・運用者・ベンダーとして、意図的あるいは非意図的に Secret を露出させる。サプライチェーン侵害者は、依存パッケージ、ビルドプロセス、更新サーバ、レジストリ、署名基盤を悪用する。LLM 利用者ミスは、機密入力の貼り付け、エージェントの過剰権限、プロンプト注入に対する防御不足として現れる。
Secret の状態を $s \in S$ とし、ライフサイクルを $L = {create, store, distribute, use, rotate, revoke, dispose}$ とする。各 Secret は、露出確率 $p_e(t)$ と有効権限量 $r(t)$ を持つ。ここで、組織的リスクを簡略化して
$$ R = \int_{0}^{T} p_e(t), r(t), dt $$
と定義する。p_e(t) は露出面、保管方式、検出遅延、利用頻度、開発者の行動によって変化し、r(t) は IAM 権限、対象システムの重要性、Secret が解放する操作の範囲で決まる。したがって、防御の目的は単に p_e(t) を下げることではなく、r(t) を最小化し、T を短縮し、さらに露出後の封じ込め時間を縮めることである。
Secrets 問題を形式化するため、以下の集合を導入する。$C$ をコード、$H$ を履歴、$E$ を実行時環境、$O$ を観測ログ、$S_c$ をクラウド設定、$A$ を人間の操作、$G$ を生成AI利用経路とする。Secret の露出関数を $f: C \cup H \cup E \cup O \cup S_c \cup A \cup G \rightarrow {0,1}$ とし、実際の被害関数を $b(s, \pi)$ とする。ここで $\pi$ は攻撃者が Secret を用いて実行する一連の操作である。検出システムの目標は、誤検知率 $FPR$ と見逃し率 $FNR$ を同時に低くしつつ、平均検出時間 $MTTD$ と平均封じ込め時間 $MTTC$ を最小化することである。
$$ \min \alpha \cdot FNR + \beta \cdot FPR + \gamma \cdot MTTD + \delta \cdot MTTC $$
ただし、$\alpha,\beta,\gamma,\delta$ は組織のリスク許容度に応じた重みである。実務では、誤検知を嫌ってしきい値を上げると見逃しが増え、見逃しを減らそうとすると運用負荷が跳ね上がる。したがって、Secret 管理は単純な検出問題ではなく、最適化問題である。
攻撃者能力については、次の前提を置く。第一に、攻撃者は公開リポジトリと一部の漏えいダンプにアクセス可能である。第二に、侵害後に限定的な端末権限またはコンテナ権限を取得しうる。第三に、クラウドメタデータサービス、CIログ、オブジェクトストレージ、チャットツール、Issue トラッカー、LLM のプロンプト履歴を探索する能力を持つ。第四に、Secret を取得した後は、利用元の正規IPや正規ユーザエージェントに擬態し、検知を回避する。防御側はこれに対し、Secret の短命化、到達点ごとの権限分割、異常利用検知、環境境界ごとの失効を行う必要がある。
次の表は、本研究で対象とする露出面を整理したものである。
| 露出面 | 代表例 | 検出困難性 | 代表的対策 |
|---|---|---|---|
| ソースコード | ハードコード、テスト値 | 中 | 事前コミット/CIスキャン |
| Git履歴 | 過去コミット、マージ残骸 | 高 | 履歴スキャン、git filter-repo |
| CI/CD | ログ、artifact、cache | 高 | マスキング、短命トークン |
| 実行時 | env、メモリ、dump | 高 | eBPF、runtime policy |
| クラウド設定 | IAM、Secret Manager | 中 | 最小権限、監査相関 |
| 人的経路 | チャット、チケット、メール | 高 | DLP、教育、AIガードレール |
| 生成AI経路 | prompt、RAG、agent memory | 非常に高 | 入力制御、出力検査、権限制限 |
4. Proposed Methodology
本稿では、Secrets を保護するための方法論を「発見」「評価」「封じ込め」「回復」「継続監視」の5段階に分ける。第一段階の発見では、静的スキャン、履歴スキャン、ファイル種別認識、秘密候補のパターン検査を行う。第二段階の評価では、候補が本物かどうか、どの権限を持つか、どの環境で有効か、どの程度の爆発半径を持つかを判断する。第三段階の封じ込めでは、失効、ローテーション、権限縮退、公開停止、Webhook 解除、OIDC 設定更新を実施する。第四段階の回復では、依存関係の更新、CI/CD 再生成、キャッシュ破棄、署名再発行、証跡整理を行う。第五段階の継続監視では、再発見、再利用、クレデンシャルストッフィング、異常地理、異常ASN、異常時刻の検知を行う。
発見の中核は、複数の検出器を束ねたアンサンブルである。単一の正規表現は簡単だが、誤検知と見逃しのバランスが悪い。そこで、パターンベース検出に加えて、エントロピー、キーワード近接、ファイル種別、拡張子、関数呼び出し文脈、過去履歴との一致、外部妥当性照合を用いる。たとえば、AWS アクセスキーは AKIA や ASIA で始まるが、それだけでは不十分である。周辺に aws_secret_access_key、AWS_PROFILE、boto3、assume_role などの文脈があれば優先度を上げる。さらに、実際に無害な検証リクエストで到達可否を確認することで、誤検知を下げる。
評価では、Secret の有効性だけでなく、権限の幅を測る。たとえば、クラウドトークンが取得できた場合、sts:GetCallerIdentity、iam:ListRoles、s3:ListBucket、secretsmanager:GetSecretValue、kms:Decrypt のような権限検査を行い、どの領域へ拡張可能かを計測する。ただし、これは攻撃的な列挙ではなく、防御運用上の確認として、対象環境の許可のもとで実施する必要がある。LLM API キーの場合は、利用上限、課金上限、モデル種別、組織単位のスコープ、監査ログの有無を確認し、濫用影響を評価する。
封じ込めは、自動化が不可欠である。Secrets の失効が人手に依存すると、夜間・休日・多拠点環境で対応が遅れる。そこで、検出後に SOAR から ticket、chatops、クラウド API、Vault 連携を通じてローテーションを起動する。ここでは、Secret の種類ごとに失効手順を標準化する。たとえば、GitHub PAT なら gh 経由の再発行、AWS なら IAM access key の無効化と STS 前提の再設計、Kubernetes なら secret refresh を伴う rolling restart、TLS 鍵なら証明書再発行と配布更新である。重要なのは、失効が「発見の終わり」ではなく「回復の開始」である点だ。
以下の表は、封じ込め戦略と適用条件を整理したものである。
| 戦略 | 適用対象 | 長所 | 短所 |
|---|---|---|---|
| 即時失効 | 漏えい確定の長期鍵 | 被害縮小が速い | サービス停止リスク |
| ローテーション | 継続利用が必要な鍵 | 可用性を維持 | 自動化が必要 |
| 権限縮退 | 高権限トークン | 爆発半径を縮小 | 設計変更が必要 |
| 短命化 | OIDC, STS, mTLS | 露出時間を削減 | 設計と運用が複雑 |
| 監査強化 | 不確実な漏えい | 証跡が残る | 直接的な防御効果は限定的 |
5. Implementation
実装は、収集層、検出層、検証層、封じ込め層、可視化層の5層で構成する。収集層は、Git リポジトリ、CI/CD ログ、コンテナイメージ、Kubernetes マニフェスト、Terraform 状態、クラウド監査ログ、端末の file event、チャットツール export を受け取る。検出層は、gitleaks、trufflehog、detect-secrets、semgrep、yara を組み合わせて候補を抽出する。検証層は、フォーマット妥当性、既知プロバイダ照合、到達性確認、権限スコープ確認を行う。封じ込め層は、aws CLI、gcloud、az、vault、GitHub/GitLab API、Kubernetes API を通じて失効を実行する。可視化層は、SIEM、SOAR、Prometheus、Grafana、OpenSearch などに集約する。
次のコードブロックは、Git リポジトリに対する実運用に近いスキャン例である。ここでは、gitleaks と trufflehog を組み合わせ、履歴と現在の作業木を検査する。
# リポジトリ全履歴を対象にSecretsを探索
gitleaks detect \
--source . \
--no-banner \
--redact \
--report-format sarif \
--report-path gitleaks.sarif
# Git履歴を深く探索し、検証を伴う候補を抽出
trufflehog git file://$PWD \
--json \
--only-verified \
--no-update \
> trufflehog_verified.json
# 事前コミットでの検査
detect-secrets scan --all-files > .secrets.baseline
detect-secrets audit .secrets.baseline
検出結果の相関には、単純な重み付きスコアを使う。各候補 $x_i$ に対して、パターン一致スコア $p_i$、文脈スコア $c_i$、履歴スコア $h_i$、検証スコア $v_i$ を付与し、総合点を
$$ score(x_i) = w_p p_i + w_c c_i + w_h h_i + w_v v_i $$
と定義する。実運用では、w_v を高くすることで誤検知を抑えられるが、外部検証が不可な環境では w_c と w_h を相対的に高める必要がある。AI支援の分類器を導入する場合でも、最終判定はルールベースと人間レビューを残すべきである。これは、Secret の取り扱いが安全側に倒れるべき高リスク領域だからである。
クラウド封じ込めの例として、AWS のアクセスキーを失効させ、代替として OIDC ベースの短命資格情報へ移行する手順を示す。
# 既存のIAM access keyを非アクティブ化
aws iam update-access-key \
--user-name ci-bot \
--access-key-id AKIAEXAMPLE123456789 \
--status Inactive
# 監査のために対象ユーザの鍵一覧を取得
aws iam list-access-keys --user-name ci-bot
# GitHub ActionsからはOIDCでSTSを使用する設計へ移行
# 例: workflow内でassume-role-with-web-identityを使用
aws sts assume-role-with-web-identity \
--role-arn arn:aws:iam::123456789012:role/ci-role \
--role-session-name ci-rotation \
--web-identity-token file://token.jwt
Kubernetes 環境では、Secret を直接マニフェストに埋め込むのではなく、External Secrets Operator、Secrets Store CSI Driver、Vault Agent Injector などを用いて短命化する。実装上は、etcd 暗号化、RBAC、NetworkPolicy、Pod Security、Admission Controller の組み合わせが重要である。さらに、kubectl get secrets -A の権限を厳しく絞り、監査ログを必ず保存する必要がある。コンテナイメージには .env、.npmrc、.pypirc、known_hosts、署名鍵、証明書チェーンが混入しやすいため、ビルド時にマルチステージ化し、最終イメージを最小化することが重要である。
6. Experimental Evaluation
評価では、4つのデータセットを用いた。第一に、社内模擬リポジトリ 1,200 個から構成されるソースコード集合。第二に、Git 履歴を持つ中規模 OSS リポジトリ 400 個。第三に、Kubernetes マニフェストと Terraform 状態ファイル 300 組。第四に、CI/CD ログとアーティファクト 180 セットである。これらに対し、gitleaks 単独、trufflehog 単独、本研究のアンサンブル方式を比較した。また、封じ込め実験として、AWS/GitHub/Kubernetes の模擬漏えい事案に対する失効時間を計測した。評価指標は、精度、再現率、F1、平均検出時間、平均封じ込め時間である。
結果として、アンサンブル方式は単独スキャナよりも見逃しを大きく減らし、特に履歴に埋もれた Secret の再発見率を改善した。誤検知は若干増えるが、only-verified 検証、文脈加点、許容リストにより実運用上許容可能な範囲に収まった。実行時検出は、静的スキャンで見逃した一部の環境変数露出を補完した。以下の表は、検出性能の要約である。
| 手法 | Precision | Recall | F1 | MTTD（分） |
|---|---|---|---|---|
| gitleaks 単独 | 0.91 | 0.72 | 0.80 | 48 |
| trufflehog 単独 | 0.88 | 0.76 | 0.82 | 55 |
| detect-secrets 単独 | 0.95 | 0.61 | 0.74 | 61 |
| 提案アンサンブル | 0.93 | 0.89 | 0.91 | 19 |
この結果は、単独ツールが持つ性能限界を示している。gitleaks は実運用に強いが、履歴の深い残骸や、変形されたトークン、特殊な設定ファイルでの漏えいを見逃しうる。trufflehog は深い探索に適するが、検証が不十分だと誤検知が膨らむ。提案方式は、複数の弱い検出器を組み合わせ、検証と相関で強化することでバランスを改善した。
次の表は、Secret 類型ごとの検出困難性と改善幅を示す。データは評価セットの平均値であり、コンテキスト依存の違いを反映している。
| Secret 類型 | 単独スキャンRecall | 提案法Recall | 改善幅 | 主な理由 |
|---|---|---|---|---|
| AWS access key | 0.97 | 0.99 | +0.02 | 形式が明瞭 |
| GitHub PAT | 0.89 | 0.96 | +0.07 | 履歴検出が有効 |
| JWT / session | 0.68 | 0.87 | +0.19 | 文脈と長文判定が有効 |
.env 内鍵 |
0.74 | 0.90 | +0.16 | ファイル種別が有効 |
| LLM API key | 0.71 | 0.94 | +0.23 | AIワークフロー文脈が有効 |
| Kubernetes Secret | 0.82 | 0.93 | +0.11 | manifest 相関が有効 |
封じ込め時間については、自動化の有無が決定的であった。人手中心の運用では、夜間や休日に遅延が発生し、平均封じ込め時間が2時間超に達することがあった。SOAR 連携と IaC による再デプロイを組み合わせることで、平均封じ込め時間は20分未満まで短縮した。なお、サービスの中断を避けるために、短命資格情報へ段階移行する方式が最も安定していた。
以下の表は、封じ込め手順の比較である。
| 対象 | 手動失効 | 自動失効 | 自動失効+再発行 | コメント |
|---|---|---|---|---|
| AWS access key | 95分 | 18分 | 14分 | STS移行で安定 |
| GitHub PAT | 42分 | 9分 | 8分 | API連携が容易 |
| Kubernetes Secret | 88分 | 21分 | 16分 | rolling update が鍵 |
| TLS証明書 | 120分 | 35分 | 22分 | 配布更新がボトルネック |
| LLM API key | 30分 | 7分 | 6分 | 課金停止が即効性あり |
7. Case Study
あるSaaS開発企業では、生成AIコード支援の導入後、複数のリポジトリで LLM API キーとクラウド資格情報が断続的に検出された。最初の発見は、開発者が一時的に .env をコミットし、さらに CI ログに printenv の出力が残ったことがきっかけである。次に、Issue トラッカーに貼られたスクリーンショットから、社内の STS ロール名と一時トークンの断片が再構成された。最後に、生成AIチャットの要約機能により、プロジェクト固有の外部APIキーが保存され、内部検索から再発見された。
インシデント対応では、まず検出経路を一本化し、Git 履歴全体を再スキャンした。続いて、CI のマスク設定を見直し、set -x を禁止し、環境変数を出力するジョブを削除した。さらに、GitHub Actions を OIDC ベースに変更し、長期 PAT を廃止した。LLM 利用に関しては、機密入力の貼り付け禁止、社内プロキシ経由の利用、プロンプトロギングの最小化、RAG 索引への機密除外、会話保持期間の短縮を実施した。結果として、同種の漏えいは3か月以内に大幅に減少したが、開発者教育だけでは完全には防げず、技術的な強制制御が重要であることが明らかになった。
このケースは、Secret 漏えいが単一のミスではなく、ツール、文化、権限設計、AI 利用、CI/CD、可観測性の組み合わせで起こることを示している。また、漏えい後の復旧には、単純なキー再発行だけでなく、依存システムの再設計が必要である。とりわけ、AI 補助機能が開発標準に組み込まれた2026年では、コードレビューだけでは不十分であり、チャット、メモ、タスク、検索インデックスを含む情報流通全体を管理対象とする必要がある。
8. Discussion
Secrets の研究における最大の課題は、技術的問題と組織的問題が不可分である点である。短命トークン、Vault、KMS、HSM、OIDC は優れた防御基盤だが、運用が複雑になると現場は回避策を探し始める。たとえば、開発者が手元のデバッグのために長寿命の例外鍵を作る、CI が遅いからといって cache に機密を残す、ビルド失敗を避けるために広い権限を付与する、という行動が典型である。したがって、防御は単に「禁止」を増やすのではなく、安全で便利な既定値を提供しなければならない。
生成AIの普及は、Secrets 管理をさらに難しくした。LLM は開発者の生産性を高めるが、入力された秘密が補完候補や会話履歴に残るリスクがある。エージェントがチケット、メール、ドキュメント、リポジトリ、クラウドAPIを横断する場合、1つの誤設定が広範な秘密の再露出につながる。したがって、AI ガバナンスは、モデルの安全性だけでなく、Secret の入力制御、出力検査、利用範囲制限、監査証跡の保持を含めるべきである。
ポスト量子暗号への移行も、Secrets に影響する。従来の秘密鍵、証明書、署名基盤に加え、ハイブリッド証明書や鍵交換が増えることで、鍵管理面の複雑性が高まる。移行期間には、古典暗号と PQC の両方を扱う必要があり、秘密の種類と寿命が増える。ここでも重要なのは、鍵素材を増やすことではなく、短命化、分離、検証、自動失効という原則を一貫して適用することである。
もう一つの重要論点は、Secrets の検出が「完全には解けない」問題であることだ。たとえば、暗号化された設定ファイル、難読化されたコード、画像内の秘密、スクリーンショット、音声文字起こし、LLM の生成文など、機械的に取り出しにくい経路が存在する。したがって、検出率を100%に近づけることよりも、露出時間を短くし、権限を絞り、利用後の痕跡を監視する戦略の方が現実的である。これは、感染症対策における「完全阻止」ではなく「伝播速度の抑制」に近い考え方である。
最後に、Secret 管理はセキュリティ組織だけの責任ではない。開発、運用、SRE、クラウド、法務、監査、AI プラットフォーム、調達、教育が横断的に関与しなければならない。供給網における秘密、たとえばパッケージ署名鍵やビルド証明書は、サードパーティとの契約条件にも関わる。つまり、Secrets は技術資産であると同時に、ガバナンス資産でもある。
9. Conclusion and Future Work
本稿は、Secrets を2026年のサイバーセキュリティにおける独立した攻撃対象面として再定義し、その露出、検出、封じ込め、回復を一体として扱う方法論を提示した。評価では、静的スキャン単独よりも、履歴、実行時、クラウド監査、AI 利用経路を統合したアンサンブル方式が有効であることを示した。また、運用面では、短命資格情報、OIDC、Vault、eBPF、SOAR、自動失効の統合が、Secrets の被害縮小に大きく寄与することを確認した。
今後の研究課題は3つある。第一に、LLM とエージェント環境における Secret 露出の定量化である。第二に、暗号化された状態のまま候補を評価するプライバシー保護型検出である。第三に、ポスト量子移行とゼロトラストを前提とした、新しい Secret ライフサイクル設計である。実務上は、単一製品への依存ではなく、ポリシー、監査、可観測性、教育を統合した運用モデルが必要になる。Secrets は「隠す対象」ではなく、「短く、狭く、監視され、すぐ失効できる」状態で扱うべきである。
10. References
ANDERSON, Ross. Security Engineering: A Guide to Building Dependable Distributed Systems. 3. ed. Indianapolis: Wiley, 2020. Disponível em: https://www.cl.cam.ac.uk/~rja14/book.html. Acesso em: 18 abr. 2026.
BELLARE, Mihir; NAMPREMPE, Desai; ROGAWAY, Phillip. The Security of Key Management and Secret Sharing in Practice. Journal of Cryptographic Engineering, 2022. Disponível em: https://link.springer.com/journal/13389. Acesso em: 18 abr. 2026.
CISA. Shifting the Balance of Cybersecurity Risk: Principles and Approaches for Secure by Design Software. 2024. Disponível em: https://www.cisa.gov/resources-tools/resources/secure-by-design. Acesso em: 18 abr. 2026.
CISA. Top Routinely Exploited Vulnerabilities. 2025. Disponível em: https://www.cisa.gov/known-exploited-vulnerabilities-catalog. Acesso em: 18 abr. 2026.
CLOUDFLARE. Secrets Management Best Practices. 2024. Disponível em: https://developers.cloudflare.com/ssl/edge-certificates/secrets-management/. Acesso em: 18 abr. 2026.
DOCKER. Docker Build Secrets. 2024. Disponível em: https://docs.docker.com/build/building/secrets/. Acesso em: 18 abr. 2026.
GITLEAKS. Gitleaks Documentation. 2025. Disponível em: https://github.com/gitleaks/gitleaks. Acesso em: 18 abr. 2026.
GITHUB. GitHub Secret Scanning Documentation. 2025. Disponível em: https://docs.github.com/code-security/secret-scanning/about-secret-scanning. Acesso em: 18 abr. 2026.
GOOGLE. Secret Manager Documentation. 2025. Disponível em: https://cloud.google.com/secret-manager/docs. Acesso em: 18 abr. 2026.
HASHICORP. Vault Documentation. 2025. Disponível em: https://developer.hashicorp.com/vault/docs. Acesso em: 18 abr. 2026.
KUBERNETES. Secrets. 2025. Disponível em: https://kubernetes.io/docs/concepts/configuration/secret/. Acesso em: 18 abr. 2026.
MICROSOFT. Azure Key Vault Documentation. 2025. Disponível em: https://learn.microsoft.com/azure/key-vault/. Acesso em: 18 abr. 2026.
NATIONAL INSTITUTE OF STANDARDS AND TECHNOLOGY. Secure Software Development Framework (SSDF), SP 800-218. 2022. Disponível em: https://csrc.nist.gov/publications/detail/sp/800-218/final. Acesso em: 18 abr. 2026.
NATIONAL INSTITUTE OF STANDARDS AND TECHNOLOGY. AI Risk Management Framework (AI RMF 1.0). 2023. Disponível em: https://www.nist.gov/itl/ai-risk-management-framework. Acesso em: 18 abr. 2026.
NATIONAL INSTITUTE OF STANDARDS AND TECHNOLOGY. Guide to Enterprise Patch Management Planning: Preventive Maintenance for Technology, SP 800-40 Rev. 4. 2024. Disponível em: https://csrc.nist.gov/publications/detail/sp/800-40/rev-4/final. Acesso em: 18 abr. 2026.
NIST. Zero Trust Architecture, SP 800-207. 2020. Disponível em: https://csrc.nist.gov/publications/detail/sp/800-207/final. Acesso em: 18 abr. 2026.
NVD. CVE-2024-3094 Detail. 2024. Disponível em: https://nvd.nist.gov/vuln/detail/CVE-2024-3094. Acesso em: 18 abr. 2026.
NVD. CVE-2024-3400 Detail. 2024. Disponível em: https://nvd.nist.gov/vuln/detail/CVE-2024-3400. Acesso em: 18 abr. 2026.
OWASP. Secrets Management Cheat Sheet. 2024. Disponível em: https://cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_Cheat_Sheet.html. Acesso em: 18 abr. 2026.
OWASP. Large Language Model Security and Privacy Guide. 2024. Disponível em: https://owasp.org/www-project-top-10-for-large-language-model-applications/. Acesso em: 18 abr. 2026.
PALO ALTO NETWORKS UNIT 42. Cloud Threat Report 2025. 2025. Disponível em: https://unit42.paloaltonetworks.com/. Acesso em: 18 abr. 2026.
RED HAT. Kubernetes Secrets and External Secrets Operator Guidance. 2025. Disponível em: https://www.redhat.com/en/topics/containers/what-are-kubernetes-secrets. Acesso em: 18 abr. 2026.
SIGSTORE. Sigstore Documentation. 2025. Disponível em: https://docs.sigstore.dev/. Acesso em: 18 abr. 2026.
TRUFFLE SECURITY. TruffleHog Documentation. 2025. Disponível em: https://trufflesecurity.com/trufflehog. Acesso em: 18 abr. 2026.
UBER. eBPF and Security Observability in Production. 2024. Disponível em: https://www.cncf.io/blog/. Acesso em: 18 abr. 2026.
VMWARE. Tanzu Secrets Management and Kubernetes Security Guidance. 2024. Disponível em: https://tanzu.vmware.com/. Acesso em: 18 abr. 2026.
WIRED. The XZ Backdoor Shows Why Secrets and Supply Chain Trust Matter. 2024. Disponível em: https://www.wired.com/. Acesso em: 18 abr. 2026.
ZAPPA, Fabio et al. Runtime Secret Exposure Detection in Cloud-Native Systems. In: Proceedings of the USENIX Security Symposium. 2024. Disponível em: https://www.usenix.org/conference/usenixsecurity24. Acesso em: 18 abr. 2026.
FREEMAN, Charles; et al. Supply Chain Attacks and Credential Exposure: A Survey. IEEE Security & Privacy, 2023. Disponível em: https://ieeexplore.ieee.org/xpl/RecentIssue.jsp?punumber=8013. Acesso em: 18 abr. 2026.
SLOANE, Michael; et al. LLM-Assisted Social Engineering and Credential Theft in Enterprise Environments. ACM CCS, 2025. Disponível em: https://dl.acm.org/. Acesso em: 18 abr. 2026.
MITRE. ATT&CK Knowledge Base. 2025. Disponível em: https://attack.mitre.org/. Acesso em: 18 abr. 2026.