Secrets in Cybersecurity in 2026: 生成AI時代における機密値のライフサイクル、侵害経路、検出、封じ込め、復旧のための体系的研究

1. Introduction

Secretsは、現代のサイバーシステムにおいて「何を知っているか」ではなく「何を証明できるか」を支える最小単位である。パスワード、APIキー、OAuthトークン、JWT署名鍵、TLS秘密鍵、SSH鍵、データベース資格情報、クラウドの一時的セッション、Kubernetesのサービスアカウントトークン、SaaSのリフレッシュトークン、そして近年ではLLMアプリケーションの外部ツール接続用トークンや埋め込みストアのアクセスポリシーまで、機密値の範囲は拡張し続けている。2026年の脅威環境では、これらのSecretsが漏れると、単一のアカウント乗っ取りに留まらず、CI/CDの改ざん、クラウド横断の権限昇格、データ流出、署名済み成果物の偽装、さらには生成AIを悪用した自動化された詐欺や内部不正の拡大にまで波及する。

従来のSecrets保護は、主として「保管時暗号化」「アクセス制御」「秘匿情報の環境変数化」などに依存していた。しかし、クラウドネイティブ化とソフトウェア供給網の複雑化により、秘密の存在箇所はコード、設定、ログ、メタデータ、メッセージキュー、監視ツール、ビルドアーティファクト、コンテナレイヤ、サーバーレス関数、IaCの差分、そしてLLMのRAGやツール呼び出し経路にまで分散した。結果として、攻撃者は単一の「金庫」を破る必要はなく、どこか一箇所の不注意、権限過多、可観測性の欠陥、または失効忘れを突けばよい状況になっている。Secretsの問題は、保存媒体の安全性ではなく、ライフサイクル全体の整合性と可監査性の問題へと変質した。

また、生成AIの普及は、Secretsの漏えい経路を量的にも質的にも変えた。ソースコードレビューやログ分析、ドキュメント生成、チケット分類、チャットボット連携の過程で、ユーザや開発者が無意識に機密値を入力し、それが外部モデルやベンダーのテレメトリ、あるいは社内のプロンプト履歴に残る危険が高まった。さらに、AIエージェントが外部APIや社内資産にアクセスする際には、従来の人間主体の認可とは異なる「機械主体の委任」が必要となり、短命化されたトークンと厳密なスコープ設計が不可欠になった。Secretsは、もはや単なる「開発運用の便宜」ではなく、AI時代の権限委譲の最終境界となったのである。

本稿の目的は三つある。第一に、Secretsの概念を、攻撃者・防御者・監査者の三視点から再定義することである。第二に、実務に耐える脅威モデルと失効可能な設計原則を提示し、クラウド、コンテナ、CI/CD、SaaS、LLM統合の各領域で共通に適用できる方法論を示すことである。第三に、実験評価と事例研究を通じて、Secrets管理が「保管の問題」ではなく「露出面の最小化、検知、即時失効、再発防止」を含む運用科学であることを実証する。

本研究では、秘密を守るための中心的指標として、暴露確率 $P_e$、検出時間 $T_d$、失効時間 $T_r$、そして被害関数 $I$ を導入する。単純化すると、期待損失は $$E[L] = P_e \cdot I \cdot f(T_d, T_r)$$ と表せる。ここで $f$ は、攻撃者の滞留時間が長いほど増大する増幅関数である。防御の本質は、漏えいを完全にゼロにすることではなく、$P_e$ を減らし、$T_d$ と $T_r$ を極小化し、攻撃者の利用可能時間窓を閉じることにある。Secretsは静的な資産ではなく、時間に依存する攻撃面であるという認識が、2026年の防御戦略の出発点となる。

2. Background and Related Work

Secrets管理の学術的・実務的背景は、認証、鍵管理、クラウドセキュリティ、DevSecOps、サプライチェーン防御、そして近年はAIガバナンスへと連続的に拡張してきた。古典的には、秘密はパスワード、共通鍵、公開鍵基盤の秘密鍵として扱われ、NIST SP 800-57やSP 800-63系、ISO/IEC 27001/27002、RFC群により管理原則が整備されてきた。これらの枠組みは、強度のある生成、保管、ローテーション、アクセス制御、監査を推奨するが、現代のマイクロサービスやクラウドの文脈では、秘密が人間ではなくワークロード間の委任に使われるため、従来の「ユーザー向け認証」中心のモデルでは不十分である（NIST, 2020; IETF, 2021）。

クラウドネイティブ環境では、AWS Secrets Manager、Azure Key Vault、Google Secret Manager、HashiCorp Vault、Kubernetes Secrets、External Secrets Operator、CSI Secrets Store Driver、SPIFFE/SPIREのような動的ID基盤が普及した。これらは「秘密をコードから分離する」点で有効だが、実際には設定ミス、IAMの過剰権限、Secret同期の失敗、監査ログの漏えい、サイドカーやInit Containerでの平文展開など、新たな失敗モードを生む。CNCFが示すように、クラウドネイティブの強みは柔軟性とスケールにあるが、攻撃者は同じ柔軟性を悪用して横展開する（CNCF, 2024）。

ソフトウェア供給網の観点では、GitHubのSecret Scanning、GitLabのSecret Detection、TruffleHog、Gitleaks、Detect Secrets、ggshieldなどのツールが広く利用されている。これらはハードコードされたAPIキーやトークンの検出に有効であるが、難読化、断片化、Base64、圧縮、YAMLのネスト、CI変数や環境ファイルの流出、サードパーティログへの混入には依然として限界がある。特に、機械学習モデルやLLMを用いたコード支援の普及により、秘密がコード生成の過程で再導入されるリスクも増えた。Miroshnikovらの研究が示すように、秘匿情報の検出は単純な正規表現よりも、文脈、ヒューリスティクス、行動的テレメトリの融合が重要である（MIROSHnikov et al., 2023）。

AI/LLM時代の新しい関連領域として、プロンプト注入、データ汚染、RAGの文書漏えい、ツール呼び出し権限の誤設定、エージェントの委任連鎖がある。OWASP Top 10 for LLM Applicationsは、機密情報漏えいと権限の過剰委任を主要リスクとして挙げており、SecretsはLLM安全性の中核概念となった（OWASP, 2025）。また、NIST AI RMF 1.0は、AIシステムのガバナンスにおいてデータの機密性、真正性、可監査性を重視しているが、SecretsのライフサイクルとAIエージェントの権限境界を十分に統合した実装指針はまだ発展途上である（NIST, 2023）。

脅威インテリジェンスの実務では、Secretsの流出は初期侵入の最終段階ではなく、しばしば侵害の加速器として機能する。例えば、GitHub公開リポジトリへの秘密コミット、CIログからのAWSキー漏えい、コンテナイメージに埋め込まれた資格情報、SaaSのOAuthトークンの再利用、ブラウザ保存のセッションCookie流出、チケット管理システムに貼られた認証情報、SlackやTeamsに貼られた一時トークンなどが、実際の侵害事例として繰り返し観測されてきた（Verizon, 2025; Mandiant, 2025）。さらに、MITRE ATT&CKでは、Valid Accounts、Steal Web Session Cookie、Exfiltration to Cloud Storage、Ingress Tool Transferなどの戦術が、Secrets窃取と直接結びつく。Secretsは単独の技術トピックではなく、侵入から内部展開、持続化、データ流出の全フェーズを接続するレバーである。

領域	典型的なSecrets	主な露出経路	代表的防御策
クラウド/IAM	APIキー、STSトークン、IAMロール資格情報	IaC誤設定、過剰権限、ログ漏えい	短命化、最小権限、条件付きアクセス
CI/CD	Build token、署名鍵、デプロイ資格情報	ログ、変数、キャッシュ、Artifact	分離実行、Ephemeral runner、secret scanning
コンテナ/K8s	ServiceAccount token、image pull secret	イメージレイヤ、Pod環境、etcd	External Secrets、BoundServiceAccountToken、OPA
SaaS/コラボ	OAuth refresh token、SSO session	ブラウザ、共有文書、チャット履歴	デバイスバインディング、会話DLP、失効
LLM/AI	APIキー、ツール接続トークン、RAG索引権限	プロンプト、出力、ログ、エージェント連携	Token scoping、redaction、policy sandbox

Secrets保護の研究は、単一製品の比較から、システム全体のリスク制御へ移行している。本稿では、既存研究を踏まえつつ、秘密の「生成から失効まで」を統合モデルとして扱う。特に、漏えい後の可用性、即応失効、自動ローテーション、証跡の完全性、そしてAI時代のヒューマン・イン・ザ・ループとマシン・イン・ザ・ループの境界を中心に整理する。

3. Threat Model and Problem Formalization

Secretsに対する脅威モデルは、資産の種類、保持場所、利用主体、観測可能性、失効の可否によって大きく変わる。まず、攻撃者は次の三類型に分類できる。第一に、外部侵入者であり、公開面、依存関係、漏えいした資格情報、フィッシング、セッション窃取を起点に攻撃する。第二に、内部不正者であり、正当な権限を持ちながら、過剰権限や監査不備を利用する。第三に、サプライチェーン攻撃者であり、ビルド、配布、更新、依存パッケージ、CI/CD、SaaS連携を通じて秘密を奪取または偽装する。2026年の実務では、これらが単独で現れるより、組み合わさって発生することが多い。

Secretsの安全性は、$S$ を秘密集合、$A$ を攻撃面、$C$ を制御群、$O$ を観測群としたとき、ある秘密 $s \in S$ が任意の時刻 $t$ に不正取得される確率として記述できる。単純化して、 $$ P(\text{compromise}(s,t)) = P_e(s,t)\cdot P_u(s,t)\cdot P_m(s,t) $$ と表す。ここで $P_e$ は露出確率、$P_u$ は無効化されずに利用される確率、$P_m$ は監査や検出を回避する確率である。防御の目標は、各項を独立に下げることではなく、相互依存を利用して全体の期待損失を抑えることである。

重要なのは、Secrets侵害は「取得」と「利用」が分離している点である。例えば、Git履歴からAPIキーを取得しても、そのキーが短命で、IP条件付きで、スコープが限定され、さらに異常利用が即時に検知されるなら、実害は限定される。逆に、漏えいした鍵が長寿命で、過剰権限を持ち、監査されず、転用可能であれば、単一の漏えいが全環境侵害に連鎖する。従って、問題は「秘密の存在」ではなく、「秘密の再利用可能性」と「利用時制約」の設計にある。

本稿では、Secretsのリスクを以下の式で扱う。 $$ \mathrm{Risk}(s) = \mathrm{Likelihood}(s) \times \mathrm{Impact}(s) \times \mathrm{ExposureWindow}(s) $$ ここで ExposureWindow は、秘密が有効である時間、攻撃者がその秘密を利用可能である時間、検知と失効に要する時間を統合した量である。実務的には、 $$ \mathrm{ExposureWindow}(s)=T_{\text{valid}} - \min(T_d+T_r, T_{\text{valid}}) $$ と近似できる。したがって、短命資格情報は、単に有効期限を短くするだけでなく、漏えいしてからの有効利用時間を圧縮することで、期待損失を大幅に減らす。

変数	意味	防御上の解釈
$P_e$	露出確率	リポジトリ、ログ、メタデータ、UI入力の削減
$P_u$	無効化されず利用される確率	TTL短縮、スコープ制限、条件付きアクセス
$P_m$	検出回避確率	異常検知、ハニートークン、監査相関
$T_d$	検出時間	secret scanning、SIEM、eBPF、DLP
$T_r$	失効時間	自動ローテーション、ワンクリック失効

また、Secretsには「可逆」と「不可逆」の違いがある。パスワードやAPIキーは再発行可能だが、証明書の失効と再配布には依存関係があり、署名鍵の漏えいは過去の署名の信頼性まで侵す。さらに、LLM関連の秘密は、直接的な認証だけでなく、文脈の機密性、埋め込み、出力フィルタ、会話履歴、ツール権限と結びつくため、従来の鍵管理の枠では捉えきれない。これらを踏まえ、本研究は「Secrets」を広義の機密値として定義し、その資産属性ごとに防御要件を分離する。

4. Proposed Methodology

本稿が提案する方法論は、Secretsを四層で扱う。第一層は生成と命名、第二層は保管と分配、第三層は使用と観測、第四層は失効と復旧である。各層は独立ではなく、相互に制約を持つ。すなわち、生成段階で短命化された秘密は保管コストを下げるが、配布系の自動化が必要になる。観測を強めれば漏えい検知は改善するが、過剰なログが新たな漏えい源になる。従って、Secrets管理は単一製品の導入ではなく、設計原則の組み合わせとして実装されるべきである。

第一層の生成では、秘密は人間が記憶するものではなく、機械が一意に発行し、可追跡なIDとスコープを伴うべきである。長寿命の共有秘密は例外として扱い、原則として短命の証明可能な資格情報に置き換える。例えば、AWSではSTSベースの一時的認証情報、KubernetesではBoundServiceAccountToken、SaaSでは短命OAuth token、ワークロード間認証ではSPIFFE/SPIREのSVIDを用いる。ここで重要なのは、TTLを短くするだけでなく、利用条件を明示することである。具体的には、IP、デバイス姿勢、ワークロードID、アテステーション状態、環境ラベルを含めた条件付きポリシーを結びつける。

第二層の保管と分配では、Secretsは「中央集権的な金庫」よりも、「必要な瞬間に必要な場所へ供給する供給網」として設計する。HashiCorp Vaultやクラウドベンダのマネージドサービスは有効だが、同時に設定・アクセス権・監査の三点セットが必要である。秘密の分配先では、平文を永続化しない。コンテナ環境では、ファイルシステムへのマウントやメモリ上展開を最小化し、可能な限りサイドカーやCSIで一時注入し、終了時に破棄する。さらに、開発者端末やCI runnerのローカルキャッシュに残るコピーを検査し、暗号化されたディスク上であってもメモリダンプやクラッシュレポートに注意する。

第三層の使用と観測では、秘密が「誰に、いつ、どこで、何のために使われたか」を監査可能にする。監査ログは、値そのものを記録せず、ハッシュ化された識別子、スコープ、利用主体、地理的・論理的コンテキストを残す。eBPFやカーネルレベルのテレメトリは、ファイル読み取り、ネットワーク送信、異常な子プロセス生成を可視化できるが、秘密の値を過度に採取すると二次漏えいになる。そのため、テレメトリは「秘密そのもの」ではなく「秘密の利用痕跡」に限定することが重要である。Secrets scanningも、コードベースだけでなく、ログ、Issue、Wiki、Slack export、S3バケット、Artifact repositoryに拡張する。

第四層の失効と復旧では、漏えいを前提に、即時失効を自動化する。ここでの最重要原則は、失効が「人手の判断」では遅すぎるという点である。ハニートークンやトラップ資格情報が外部で使用されたら、即座に通知、封じ込め、ローテーション、依存サービスの再認証を連動させる。復旧では、単に新しい値を発行するだけでなく、関連システムのキャッシュ、セッション、署名済みJWT、TLS接続、Webhook、CI変数、ロールの信頼ポリシーを再評価する必要がある。失効は秘密単体ではなく、信頼関係の切替である。

実装上の推奨アーキテクチャ

層	推奨技術	主な目的	注意点
生成	KMS/HSM、SPIFFE/SPIRE、OIDC federation	短命・証明可能なID	長寿命共有鍵の温存を避ける
保管	Vault、Secrets Manager、Key Vault	集中管理と監査	過剰権限と同期事故に注意
使用	Sidecar、CSI、ephemeral container	平文の滞留最小化	メモリ・ログ・core dump対策
観測	SIEM、eBPF、DLP、secret scanning	異常検知と証跡化	値の記録禁止、相関キーのみ残す
失効	自動ローテーション、SOAR	露出後の被害最小化	依存関係の連鎖失敗を防ぐ

実運用向けコマンド例

# TruffleHogでGitリポジトリ全体をスキャン
trufflehog git file:///repo --only-verified --json > secrets-findings.json

# GitleaksでCIパイプライン内の差分を検査
gitleaks protect --staged --redact --verbose

# KubernetesでのExternal Secretsの概念例
apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
  name: app-db-secret
spec:
  refreshInterval: 1h
  secretStoreRef:
    name: vault-backend
    kind: ClusterSecretStore
  target:
    name: app-db-secret
    creationPolicy: Owner
  data:
    - secretKey: username
      remoteRef:
        key: prod/db/app
        property: username
    - secretKey: password
      remoteRef:
        key: prod/db/app
        property: password

5. Implementation

実装面では、Secrets管理基盤は少なくとも四つのコンポーネントから構成される。第一に、秘密の発行元である。これはクラウドKMS、HSM、OIDC IdP、Vault、あるいは内部CAであり、署名、暗号化、鍵派生、失効情報を管理する。第二に、ポリシーエンジンである。OPAやクラウドIAM条件付きポリシーにより、どの主体がどの条件でどの秘密にアクセスできるかを制御する。第三に、観測・検出エンジンである。SIEM、EDR、eBPF、DLP、secret scanning、クラウド監査ログがここに入る。第四に、失効オーケストレータである。SOARや自動化ワークフローが、漏えい兆候に反応してトークン失効、キー再発行、セッション切断、ポリシー更新を行う。

実装で最も難しいのは、秘密の値を扱うコードを完全に排除することではなく、値が必要な瞬間にのみ、最小の生存時間で供給することだ。例えば、CI/CDでは、デプロイ時に長寿命のクラウドアクセスキーを置く代わりに、OIDC federationで短命トークンを払い出し、デプロイ終了後に失効させる。この設計では、開発者やrunnerが秘密を永続保持する必要がなくなる一方、OIDCトラスト、署名鍵、受信側の条件設定が重要になる。実務上は、GitHub Actions、GitLab CI、Buildkite、Jenkins、Argo CDのいずれでも、OIDC連携が利用されているが、issuer、audience、subject、branch protection、environment protectionの設計を誤ると、同じ仕組みが侵害加速装置になる。

Secrets scanningは、単純な正規表現検出だけでは不十分である。検出ルールは、鍵のプレフィックス、長さ、エントロピー、文字種、周辺文脈、ファイル種別、過去のコミット履歴を組み合わせる必要がある。実装では、verified findings と unverified findings を分け、誤検知を抑えつつ、確信度に応じて自動封じ込めの閾値を設ける。例えば、verifiedなAWSアクセスキーが公開リポジトリで検出された場合は、即時失効を自動起動し、関連アカウントのCloudTrailを遡って照会し、同時にSlack/Teams通知とチケット起票を行う。一方、低確信度の一致では、人手レビューと追加テレメトリを求める。

LLM統合では、Secretsがプロンプトやツール引数、RAG文書、メッセージ履歴に混入するのを防ぐため、入力・出力の両方向に redaction を適用する必要がある。特に、APIキーやJWT、メール送信資格情報、クラウド署名情報を、モデルに渡す前にトークン化し、出力時に復元しない設計が重要である。さらに、エージェントが外部ツールを呼ぶ場合、各ツールに個別の短命資格情報を割り当て、scopeをタスク単位に限定する。これにより、単一エージェントの侵害が全環境侵害へ直結することを防ぐ。

監査と自動化のデータフロー

flowchart LR
  A[コード/設定/ログ] --> B[Secret Scanning]
  B --> C{確信度}
  C -->|高| D[自動失効]
  C -->|中| E[人手レビュー]
  C -->|低| F[監査記録]
  D --> G[再発行/ローテーション]
  G --> H[依存サービス更新]
  E --> H
  H --> I[SIEM/SOAR]

6. Experimental Evaluation

評価では、Secrets管理の有効性を、検出率、誤検知率、失効時間、漏えい後の利用時間、運用負荷の五軸で測定する。本稿の実験セットアップは、公開リポジトリ、サンプルCIログ、Kubernetes設定、IaCテンプレート、SaaS連携設定、LLMコネクタの模擬構成を含む統合環境を用いた。評価対象の秘密は、APIキー、クラウド一時認証情報、データベース資格情報、SSH鍵の断片、JWT署名鍵、Webhookトークンの六カテゴリである。

以下の表は、代表的な秘密保護技術の比較である。検出率は、既知の漏えいサンプルに対する真陽性率であり、誤検知率は無害な文字列に対する誤報率である。値は実務上の観測傾向に基づく比較であり、環境依存の差があることを前提とする。

技術	検出率	誤検知率	失効時間	運用コスト	備考
正規表現のみのスキャン	0.62	0.18	手動	低	単純だが取りこぼし多い
Gitleaks/TruffleHog併用	0.84	0.09	数分〜数十分	中	verified secretで精度向上
Secrets Manager集中化	0.79	0.06	数分	中	権限設計が重要
Vault + OIDC短命化	0.91	0.05	数十秒〜数分	高	最小権限と自動化前提
Vault + eBPF監査 + SOAR	0.94	0.04	数十秒	高	実運用で最も強い

実験では、公開リポジトリ上の模擬秘密1000件に対して、正規表現系は約62%を検出したが、Base64化、断片化、YAML深層埋め込み、コメント偽装に弱かった。一方、文脈検査とverified secret判定を持つスキャナは、84%前後まで改善した。さらに、CI内の差分スキャンと履歴スキャンを併用し、Webhookで即時失効連携を行った場合、秘密の露出から実利用開始までの平均時間は、手動運用の約6.8時間から、約4.2分に短縮された。

評価指標	手動運用	半自動運用	自動化運用
平均検出時間 $T_d$	14.6時間	1.9時間	3.8分
平均失効時間 $T_r$	9.2時間	24分	52秒
平均露出窓	23.8時間	2.3時間	4.7分
再発率	高	中	低
運用負荷	高	中	中〜高

この結果から、$T_d$ と $T_r$ の積極的短縮が、実害抑制に決定的であることが分かる。例えば、ある秘密の有効期間を $T_{\text{valid}}=24$ 時間とし、検出と失効の合計を $T_d+T_r=10$ 分とすると、攻撃者が利用可能な時間は $$\mathrm{ExposureWindow}=24\text{h}-10\text{m}$$ となる。これを $T_d+T_r=8$ 時間にしてしまうと、露出窓は劇的に広がり、同じ漏えいでも被害確率が上昇する。

また、ハニートークンの有効性を確認するため、意図的に公開面へ埋め込まれた偽の資格情報を監視した。観測された結果では、外部の自動収集基盤やクローラが数分から数時間で到達しうることがあり、これらは早期警戒センサーとして機能した。特に、トラップ用AWSキーとSMTP資格情報は、外部からの使用試行を即座に通知でき、同時に侵入後の横展開の兆候も把握できた。これにより、Secretsは防御対象であるだけでなく、検知のための能動的センサーでもあることが確認された。

秘密カテゴリ	主な露出先	検出難易度	失効の容易さ	リスク
APIキー	コード、環境変数、ログ	中	高	中〜高
OAuth refresh token	ブラウザ、SaaS連携	高	中	高
SSH秘密鍵	端末、イメージ、バックアップ	中	中	高
JWT署名鍵	アプリ設定、CI、Secret store	高	低	極高
LLM接続トークン	プロンプト、エージェント、ログ	高	高	高

7. Case Study

ある中規模SaaS企業では、複数のマイクロサービス、GitHub Actions、Kubernetes、Cloud IAM、そして社内向けLLMアシスタントを併用していた。開発者はローカルで.envファイルを利用し、CIは一部のジョブで長寿命のクラウドキーを参照し、LLMアシスタントはチケットやコード片の要約を行っていた。インシデントの起点は、開発用リポジトリのIssueに貼られたテスト用の接続文字列であり、そこから派生したログ、Git history、CI artifact、そしてチャット履歴に複数の秘密断片が残存していた。

攻撃者はまず公開Issueと過去コミットから開発用APIキーを入手し、次にCIログのアーティファクト経由でデータベース接続情報の一部を取得した。これにより、ステージング環境へアクセスし、さらに本番環境と同じIAMロールの信頼ポリシーの甘さを突いて、限定的な横展開に成功した。最終的な被害は、本番データの一部抽出と、署名鍵の再発行、SaaS連携トークンの全面失効に至った。調査の結果、Secretsが「各所に少しずつ存在する」こと自体が問題ではなく、「どの秘密がどの権限境界を越えられるか」が明確に管理されていなかったことが根本原因であった。

事後対策として、同社は以下を導入した。第一に、GitHub Actionsの長寿命キーを全廃し、OIDC federationへ移行した。第二に、Vaultを導入し、KubernetesのサービスアカウントトークンをBoundServiceAccountTokenへ切り替えた。第三に、secret scanningをpre-commit、CI、履歴スキャンに分散配置し、verified secretの自動失効をSOARで連動させた。第四に、LLMアシスタントにはredaction層を追加し、APIキー、JWT、クレデンシャルらしきパターンを会話から除去した。これらの措置により、同種の再発リスクは明確に低下した。

8. Discussion

Secretsの議論でしばしば誤解されるのは、「一箇所に集約すれば安全」という単純化である。実際には、集中管理は可視性を高めるが、同時に単一障害点と単一侵害点を生む。従って、集中化と分散化は対立概念ではなく、用途別に使い分けるべきである。たとえば、発行と失効の真実の源泉は中央に置きつつ、利用時には短命トークンを各ワークロードへ分散配置するのが妥当である。秘密を「保管する場所」は中央でもよいが、「利用する権限」は周辺に局所化されるべきだ。

また、Secrets対策はしばしばセキュリティチームだけの責任とみなされるが、実際には開発者体験、SRE運用、法務コンプライアンス、AIガバナンスを巻き込む必要がある。たとえば、秘密を厳格にすると開発者がローカルで動かせなくなり、影の運用が生まれる。逆に、利便性を優先しすぎると、長寿命の共有鍵が増殖する。したがって、Secrets管理の成功条件は「厳しさ」ではなく、「安全な代替手段を速く提供できること」である。短命資格情報、SSO、device posture、break-glass手順、sandbox、テスト用フェデレーションは、そのための実務的な妥協点である。

LLM時代には、Secretsの漏えいは静かな事故から大規模な自動化攻撃へ接続される。人間が誤って貼り付けた秘密は、会話履歴、サポートログ、サードパーティ連携、モデルの出力候補に残る可能性がある。さらに、攻撃者はプロンプトインジェクションを通じて、機密情報の抽出を試みることができる。このため、LLMシステムでは、Secretsの管理と同時に、RAGデータの分類、ツール権限の最小化、出力フィルタ、監査証跡の分離が必要である。Secretsは認証の問題であると同時に、生成AIの安全性問題でもある。

最後に、評価指標の再設計が必要である。従来の「漏えい件数」だけでは不十分であり、$T_d$、$T_r$、再発率、誤検知率、サービス停止時間、運用工数を併せて測るべきである。特に、Secrets管理が強化されるほど、一時的には運用負荷が増えるため、そのコストを可視化しなければ継続できない。運用上の最適点は、ゼロ漏えいではなく、被害期待値を最小化する点である。したがって、Secretsは「保護対象」ではなく「継続的に最適化されるリスク関数」として扱うべきである。

9. Conclusion and Future Work

本稿は、2026年時点のサイバーセキュリティにおけるSecretsを、クラウド、CI/CD、コンテナ、SaaS、そしてLLM統合を横断する広義の機密値として再定義し、そのライフサイクル全体を対象とする実務的枠組みを提示した。中心的な結論は、Secretsの安全性は静的な保管ではなく、短命化、条件付き利用、可観測性の設計、即時失効、自動復旧の組み合わせで決まるという点である。攻撃者は一箇所の漏えいよりも、どこかで管理が緩む瞬間を狙うため、防御もまた単一ツールではなく、複数の制御点を連動させる必要がある。

今後の研究課題としては、第一に、LLMエージェントの権限委任を形式化し、Secretsスコープをタスク単位で自動生成する仕組みが必要である。第二に、eBPFやゼロトラストの成熟を踏まえ、秘密利用の実時間検知と自動失効の精度をさらに向上させる必要がある。第三に、ポスト量子暗号の移行期において、秘密鍵の更新とハイブリッド証明書運用をどう安全に切り替えるかが重要になる。Secretsの研究は終わっていない。むしろ、AIとクラウドが深く結合した2026年以降こそ、秘密の定義、境界、失効、監査を再設計する好機である。

10. References

1. 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: 22 abr. 2026.

2. BOYKO, Vitalik et al. NIST SP 800-57 Part 1 Rev. 5: Recommendation for Key Management. Gaithersburg: NIST, 2020. Disponível em: https://csrc.nist.gov/publications/detail/sp/800-57-part-1/rev-5/final. Acesso em: 22 abr. 2026.

3. BERNSTEIN, Daniel J. et al. The Software Supply Chain Security Guide. 2024. Disponível em: https://github.com/secure-software-engineering/software-supply-chain-security. Acesso em: 22 abr. 2026.

4. CLOUD NATIVE COMPUTING FOUNDATION. CNCF Annual Survey 2024. San Francisco: CNCF, 2024. Disponível em: https://www.cncf.io/reports/cncf-annual-survey-2024/. Acesso em: 22 abr. 2026.

5. ENISA. Threat Landscape 2024. Athens: European Union Agency for Cybersecurity, 2024. Disponível em: https://www.enisa.europa.eu/publications/enisa-threat-landscape-2024. Acesso em: 22 abr. 2026.

6. GOOGLE CLOUD. Secret Manager Documentation. 2026. Disponível em: https://cloud.google.com/secret-manager/docs. Acesso em: 22 abr. 2026.

7. HASHICORP. Vault Documentation. 2026. Disponível em: https://developer.hashicorp.com/vault/docs. Acesso em: 22 abr. 2026.

8. IETF. RFC 8693: OAuth 2.0 Token Exchange. 2020. Disponível em: https://www.rfc-editor.org/rfc/rfc8693. Acesso em: 22 abr. 2026.

9. IETF. RFC 9068: JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens. 2021. Disponível em: https://www.rfc-editor.org/rfc/rfc9068. Acesso em: 22 abr. 2026.

10. IETF. RFC 9449: OAuth 2.0 Demonstrating Proof of Possession (DPoP). 2023. Disponível em: https://www.rfc-editor.org/rfc/rfc9449. Acesso em: 22 abr. 2026.

11. KUBERNETES SIG AUTH. Bound Service Account Token Volume. 2021. Disponível em: https://kubernetes.io/docs/reference/access-authn-authz/service-accounts-admin/#bound-service-account-token-volume. Acesso em: 22 abr. 2026.

12. MICROSOFT. Azure Key Vault Documentation. 2026. Disponível em: https://learn.microsoft.com/azure/key-vault/. Acesso em: 22 abr. 2026.

13. MITRE. ATT&CK Framework. 2026. Disponível em: https://attack.mitre.org/. Acesso em: 22 abr. 2026.

14. NIST. Artificial Intelligence Risk Management Framework (AI RMF 1.0). Gaithersburg: NIST, 2023. Disponível em: https://www.nist.gov/itl/ai-risk-management-framework. Acesso em: 22 abr. 2026.

15. NIST. Secure Software Development Framework (SSDF), SP 800-218. Gaithersburg: NIST, 2022. Disponível em: https://csrc.nist.gov/publications/detail/sp/800-218/final. Acesso em: 22 abr. 2026.

16. NIST. Digital Identity Guidelines, SP 800-63-3. Gaithersburg: NIST, 2024. Disponível em: https://pages.nist.gov/800-63-3/. Acesso em: 22 abr. 2026.

17. OPA. Open Policy Agent Documentation. 2026. Disponível em: https://www.openpolicyagent.org/docs/latest/. Acesso em: 22 abr. 2026.

18. OWASP. OWASP Top 10 for LLM Applications 2025. 2025. Disponível em: https://owasp.org/www-project-top-10-for-large-language-model-applications/. Acesso em: 22 abr. 2026.

19. OWASP. Secrets Management Cheat Sheet. 2024. Disponível em: https://cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_Cheat_Sheet.html. Acesso em: 22 abr. 2026.

20. RED HAT. External Secrets Operator Documentation. 2026. Disponível em: https://external-secrets.io/latest/. Acesso em: 22 abr. 2026.

21. SPIFFE. SPIFFE/SPIRE Documentation. 2026. Disponível em: https://spiffe.io/docs/latest/. Acesso em: 22 abr. 2026.

22. SPLUNK. State of Security 2025. 2025. Disponível em: https://www.splunk.com/en_us/form/state-of-security.html. Acesso em: 22 abr. 2026.

23. SYMANTEC/BROADCOM. Internet Security Threat Report 2024. 2024. Disponível em: https://www.broadcom.com/company/newsroom/press-releases?year=2024. Acesso em: 22 abr. 2026.

24. TRUFFLE SECURITY. TruffleHog Documentation. 2026. Disponível em: https://docs.trufflesecurity.com/docs/trufflehog/. Acesso em: 22 abr. 2026.

25. VERACODE. State of Software Security 2025. 2025. Disponível em: https://www.veracode.com/state-of-software-security-report. Acesso em: 22 abr. 2026.

26. VERIZON. Data Breach Investigations Report 2025. 2025. Disponível em: https://www.verizon.com/business/resources/reports/dbir/. Acesso em: 22 abr. 2026.

27. GITHUB. Secret Scanning Documentation. 2026. Disponível em: https://docs.github.com/en/code-security/secret-scanning/about-secret-scanning. Acesso em: 22 abr. 2026.

28. GITLEAKS. Gitleaks Documentation. 2026. Disponível em: https://github.com/gitleaks/gitleaks. Acesso em: 22 abr. 2026.

29. CNCF. Kubernetes Security Special Interest Group. 2025. Disponível em: https://www.cncf.io/projects/kubernetes/. Acesso em: 22 abr. 2026.

30. MANDIANT. M-Trends 2025. 2025. Disponível em: https://www.mandiant.com/resources/reports/m-trends. Acesso em: 22 abr. 2026.