Secrets as the New Control Plane: A 2026 Security Science of Credentials, Keys, Tokens, and Ephemeral Trust Across Cloud-Native and AI-Driven Systems

1. Introduction

Secrets は長らく「漏れては困る文字列」として扱われてきた。しかし2026年の現場では、その理解は明らかに不十分である。APIキー、OAuthアクセストークン、クラウドの一時クレデンシャル、証明書、署名鍵、KMSラップ鍵、Webhookシークレット、CI/CDのデプロイトークン、AIエージェントの外部ツール呼び出し用資格情報、さらには障害時のブレークグラス情報まで、Secrets はソフトウェアシステムの機能そのものを制御する。つまり、Secrets は単なる「情報」ではなく、アクセス可能な状態を定義する制御プレーンである。この観点に立つと、Secrets の漏えいは機密情報の失敗ではなく、権限境界の破壊である。

近年の攻撃者は、脆弱性よりも Secrets を狙う傾向を一層強めている。理由は明快で、Secrets は攻撃の初期足場として使いやすく、横展開や永続化に直結し、かつ検知を逃れやすいからである。パッチが当たった脆弱性は減衰しやすいが、Git履歴に残ったトークン、CIのログに出た環境変数、コンテナイメージに焼き込まれた .env、クラウドの長寿命アクセスキー、AIアシスタントが誤送信した接続文字列は、失効しない限り再利用可能である。攻撃者はこの「再利用可能性」を最大限に悪用する。したがって、Secrets 対策は単なるスキャンではなく、生成から失効までの全周期管理でなければならない。

2026年の脅威環境では、Secrets の扱いはさらに難しくなっている。第一に、クラウドネイティブ化により、Secrets の数と流通経路が爆発した。Kubernetes、サービスメッシュ、サーバレス、GitOps、マルチクラウド、SaaS連携が常態化し、資格情報は人間が手で管理できる量を超えた。第二に、AI/MLの業務導入により、モデル推論基盤、エージェント、RAG、外部API連携にSecrets が深く埋め込まれた。第三に、ゼロトラストが成熟した一方で、短命トークンや継続認証は「漏れてもすぐ死ぬ」という前提に依存するが、実際には失効遅延、キャッシュ、監査不備、権限過大により、短命であるはずのSecretが長命化する。第四に、サプライチェーン攻撃が拡大し、Secrets は開発・構築・配布・運用の全段階を通じて狙われるようになった。

本稿は、Secrets をサイバーセキュリティの中核研究対象として再構成する。目的は三つある。第一に、Secrets の定義を整理し、どのような値がどの時点で保護対象になるかを形式化する。第二に、2026年までに確立した技術、ツール、運用モデルを踏まえ、実践可能な防御アーキテクチャを提示する。第三に、攻撃者の視点からどのように Secrets が収集・再利用・収益化されるかを分析し、その防御に必要な検知と封じ込めの測定指標を示す。

本研究で重視するのは、「Secrets を漏らさない」ことではない。現実的には漏れる前提である。重要なのは、漏えいした際にどれだけ早く発見し、どれだけ狭く使わせ、どれだけ速く失効させ、どれだけ確実に再発を防ぐかである。したがって評価指標は、漏えい件数だけではなく、$TTD$（Time to Detect）、$TTC$（Time to Contain）、$TTR$（Time to Revoke/Rotate）、実害範囲、権限過大率、残存リスクで定義する。

Secrets は、いまや組織の信頼の根幹である。よって Secrets の研究は、暗号の話に留まらない。ID管理、端末管理、ソフトウェア供給網、ログ設計、監査、インシデントレスポンス、AIガバナンスまでを含む総合科学として扱う必要がある。本稿はその統合的視座を、理論と実務の両面から提示する。

2. Background and Related Work

Secrets の研究史は、認証情報管理、鍵管理、秘密分散、クラウドセキュリティ、ソフトウェアサプライチェーンの複合史である。初期には、パスワードや対称鍵の安全な保管が中心であり、ハードウェアセキュリティモジュール（HSM）、鍵のローテーション、最小権限原則が主要テーマだった。その後、クラウドの普及に伴い、IAMロール、KMS、STS、短命トークン、サービスアカウント、Vaultのような中央集約型秘密管理が重視されるようになった。2020年代前半には、GitHubやGitLabの秘密漏えい対策として、Secret scanning、pre-commitフック、CIガードレール、KubernetesのExternal Secrets、SOPS、Sealed Secrets などが広く利用されるようになった（GITHUB, 2025; HASHICORP, 2025; KUBERNETES, 2025）。

秘密情報の漏えいは、単体のアプリケーション脆弱性とは異なり、複数のレイヤで発生する。ソースコード、ビルドログ、成果物、コンテナレジストリ、環境変数、クラウドメタデータサービス、監視ログ、サポートチケット、チャット、チケット管理、メモリダンプが主要な漏えい面である。実際、業界のインシデント分析では、秘密の露出は「開発者のミス」ではなく「構成と運用の失敗」として現れることが多い。例えば、公開Gitリポジトリへの誤コミットは初歩的だが、より実害が大きいのは、CIジョブのログに出力された一時トークンや、コンテナイメージ層に残留した .npmrc、.pypirc、クラウド認証ヘッダである。これらは通常の静的スキャンだけでは見つけにくい。

関連する研究として、秘密検出のためのルールベーススキャナ、機械学習ベースの検知、正規表現やエントロピーによる候補抽出、コンテキスト分析、履歴ベース分析がある。trufflehog は歴史的に秘密検出ツールとして知られ、Git履歴や成果物中の候補を広範に探索する（TRUFFLEHOG, 2025）。gitleaks はルールベースで実用性が高く、CI統合が容易である（GITLEAKS, 2025）。detect-secrets はベースライン方式により、既知の例外を管理しやすい（YELP, 2025）。これらは有用だが、単独では不十分である。なぜなら、秘密は形式が多様であり、鍵が短命化するとスキャン時点では存在しないことも多く、また実際の漏えいはスキャン対象外のログやメモリで発生するからである。

クラウドネイティブ分野では、Kubernetes Secrets、ServiceAccountトークン、Projected Volume、CSI Secret Store、External Secrets Operator、Vault Agent Injector などが普及した。これにより、秘密の配布は容易になったが、同時に権限設計の難度が上がった。Kubernetes Secrets は base64 でしかなく、暗号化されていない場合には etcd やバックアップ経由で容易に露出する。したがって、Encryption at Rest だけでは不十分であり、RBAC、Node Isolation、Pod Security、Admission Control、Image Policy、Audit Policy を組み合わせる必要がある（KUBERNETES, 2025; CNCF, 2025）。

サプライチェーンの観点では、SLSA、SSDF、Sigstore、in-toto、SBOM が重要になった。SLSA はビルドの信頼性を段階的に高め、Sigstore は証明書と署名の運用を簡素化し、SBOM は依存関係の可視化を支援する（SLSA, 2025; SIGSTORE, 2025; NIST, 2022a）。しかしこれらも秘密そのものの保護ではない。むしろ、秘密がどの工程で生成され、どの成果物に埋め込まれ、どの証跡で監査されるかを明確にする補助線である。

AIセキュリティの文脈では、LLMアプリケーションが秘密情報の新たな漏えい面を形成している。プロンプトインジェクション、ツール呼び出しの逸脱、RAGに含まれる認証情報、エージェントが参照する .env、シークレットを含むコンテキストウィンドウの暴露が問題となる。OWASPはLLMのトップリスクに情報漏えいとサプライチェーン、ツール誤用を含めている（OWASP, 2024）。2026年には、秘密管理はAI運用の中核問題であり、AIエージェントに「見せてはいけないもの」をどう隔離するかが設計上の焦点となる。

以下の表は、代表的な秘密保護技術の比較である。実務上は単独採用ではなく、多層適用が前提となる。

技術	主目的	長所	短所	適用場面
Vault	動的秘密発行、集中管理	失効・ローテーションが強い	運用複雑、可用性設計が必要	マルチクラウド、組織横断
KMS/HSM	鍵保護、暗号処理	物理的保護、監査が容易	アプリ側実装が必要	署名、暗号化、ルート鍵
External Secrets	外部管理の同期	Kubernetesと親和性が高い	同期ミスで露出	K8sアプリ配布
SOPS/Sealed Secrets	GitOps向け保護	Gitに置ける、運用しやすい	解除権限が集中	設定ファイル管理
Secret scanning	漏えい検知	導入容易、即効性	偽陽性、実行時漏えいに弱い	CI/CD、履歴監査

Secrets 対策の研究は、いまや「検出」から「統制」へ移行している。生成時点での最小化、配布時点での分離、利用時点でのスコープ制限、失効時点での迅速化、監査時点での証跡化を一体で設計しなければならない。本稿は、その統合設計を2026年の実務水準で整理する。

3. Threat Model and Problem Formalization

Secrets の脅威モデルは、単純な盗難モデルでは不十分である。秘密は、保存・配布・使用の各段階で異なるリスクにさらされる。したがって、攻撃者の能力を「読み取り可能な経路」「実行可能な経路」「永続化可能な経路」に分解し、Secret の状態遷移として扱う必要がある。ここで、各 Secret $s_i$ は、生成時刻 $t_g$、初回利用時刻 $t_u$、漏えい時刻 $t_l$、失効時刻 $t_r$ を持つとする。理想状態では $t_r - t_u$ が短く、かつ $t_l$ が存在しないことが望ましい。実務上は、漏えいが起きても $t_r - t_l$ を最小化することが重要である。

本研究では、攻撃者を以下に分類する。第一に、外部侵入者であり、公開リポジトリ、インターネット公開のAPI、CIのログ、誤設定されたクラウドストレージを探索する。第二に、内部不正者または侵害された正規アカウントであり、権限昇格や横展開を狙う。第三に、サプライチェーン攻撃者であり、依存関係、ビルド環境、署名工程、更新チャネルに介入する。第四に、AIワークフローを悪用する攻撃者であり、プロンプトやツール呼び出しを通じて秘密を誘導する。これらは相互排他的ではなく、複合的に現れる。

Secrets の保護対象は、機密性だけではない。完全性、可用性、監査可能性も重要である。たとえば、秘密が改ざんされれば、攻撃者はサービスのふりをしてアクセスできる。秘密が利用不能になれば、可用性事故が発生する。監査不能な秘密は、漏えいの有無すら判定できない。従って、秘密 $s$ のリスク関数を次のように定義する。

$$ R(s) = w_c \cdot C(s) + w_i \cdot I(s) + w_a \cdot A(s) + w_v \cdot V(s) $$

ここで $C$ は機密性損失、$I$ は完全性損失、$A$ は可用性損失、$V$ は監査不能性のコスト、$w_*$ は組織の重みである。さらに、組織全体の Secrets リスクは

$$ R_{\mathrm{org}} = \sum_{i=1}^{n} R(s_i) \cdot p_i $$

と表せる。$p_i$ はその Secret が実際に悪用される確率であり、曝露面、権限範囲、寿命、再利用性、検知性に依存する。

本稿では、Secret のライフサイクルを6段階で捉える。

段階	典型的な失敗	代表的な防御	検知信号
生成	長寿命・過大権限	動的発行、最小権限	発行件数、権限差分
配布	平文転送、メール添付	Vault、KMS、SOPS	配布経路の監査
利用	環境変数露出、ログ出力	ephemerality、redaction	ログの秘匿語検出
保存	Git履歴、etcd、バックアップ	暗号化、分離保管	ストレージ監査
失効	失効遅延、ロールオーバ失敗	自動ローテーション	TTL超過率
監査	証跡欠落、責任不明確	CIEM、SIEM、eBPF	追跡可能性スコア

上記を踏まえ、我々の問題定義は「Secret の数を減らし、寿命を短くし、権限を絞り、露出を観測し、侵害時の影響を局所化する」ことである。最適化目標は、漏えい確率の最小化だけでなく、平均封じ込め時間 $E[TTC]$ と平均失効時間 $E[TTR]$ を同時に短縮することにある。すなわち、実務上の目的関数は

$$ \min \left( \alpha E[TTC] + \beta E[TTR] + \gamma \sum_i p_i \cdot \mathrm{Scope}(s_i) \right) $$

であり、ここで $\mathrm{Scope}(s_i)$ は Secret の権限範囲を表す。

4. Proposed Methodology

提案手法は、Secret を「保管すべき値」ではなく「継続的に制御すべき状態」として扱う。これを実現するため、我々は四層構造の防御体系を提案する。第一層は生成制御であり、長寿命秘密を極力排除し、OIDC、短命STS、mTLS、証明書ベース認証、ワークロードアイデンティティを優先する。第二層は配布制御であり、Secret manager、KMS、GitOps暗号化、ポリシーエンジンを用いて、秘密が平文で経路を通らないようにする。第三層は利用時制御であり、アプリケーション、コンテナ、Pod、エージェントごとにスコープを狭め、メモリ・環境変数・ログへの残留を抑制する。第四層は観測と応答であり、eBPF、OpenTelemetry、SIEM、CNAPP、クラウド監査ログを組み合わせ、漏えい兆候を即時検知して失効に繋げる。

この方法論の要点は、静的対策と動的対策の統合である。静的対策は、コード、IaC、マニフェスト、Dockerfile、Helm chart、Terraform、CI設定に対するスキャンである。動的対策は、実行時における環境変数、ファイルアクセス、ネットワーク送信、子プロセス生成、メモリアクセスの観測である。Secrets の漏えいは、静的段階で発見できないことが多いため、実行時の行動監視が不可欠である。特に 2026年のクラウド環境では、eBPF で syscall、socket、exec、open、connect を観測し、秘密の異常な流出経路を抑止する設計が有効である（CILIUM, 2025; ACRYL, 2025）。

提案アーキテクチャの構成要素を以下に示す。

層	コンポーネント	役割	失敗時の影響
生成	IdP, OIDC, STS, CA	短命クレデンシャル発行	長寿命化による再利用
配布	Vault, External Secrets, SOPS	安全な注入	平文漏えい
実行	K8s Admission, Sidecar, eBPF	利用制御	コンテナ内窃取
観測	SIEM, CNAPP, OTEL	検知と相関	発見遅延
応答	SOAR, IR playbook, auto-rotation	失効と隔離	侵害継続

提案手法では、Secret を各ワークロードに対して一意に生成し、スコープを狭め、TTL を短く設定する。理想的には、Secret の寿命はワークロードの寿命以下である。もしワークロードの平均稼働時間が $T_w$、Secret の平均寿命が $T_s$ ならば、我々は $T_s < T_w$ を基本原則とし、さらに $T_s \leq \delta$（たとえば15分〜1時間）を目標とする。ただし、運用上の可用性を考慮し、ローテーション負荷 $L_r$ が過度にならないよう制約を設ける。

Secrets の最小化には、生成しない設計が最も強力である。クラウドでは、静的アクセスキーを使わず、OIDC連携による一時クレデンシャルを採用する。Kubernetes では、ServiceAccountトークンの短命化と audience 制約、BoundServiceAccountTokenVolume、Pod Identity を使う。アプリケーション内部では、設定値と秘密を分離し、秘密は起動時にのみ注入し、ログや例外に出さない。AIエージェントでは、ツールごとに別個の権限境界を設け、汎用トークンを共有しない。

検知ロジックは、ルールベースと行動ベースのハイブリッドとする。ルールベースでは、既知の形式の鍵、APIトークン、証明書、JWT、SSH private key を高精度に検出する。行動ベースでは、通常はアクセスしないファイル、異常な外部送信、シークレット取得後の大量コール、夜間のローテーション失敗などを検出する。これにより、単純な文字列マッチでは見えない流出を補足する。

5. Implementation

実装は、開発時スキャン、CI統制、Kubernetes配布、実行時監視、インシデント自動化の5要素で構成する。まず開発時には gitleaks と trufflehog を pre-commit および pre-receive フックに組み込み、コード、履歴、設定ファイルを検査する。次に CI では、Secret が検出された場合にビルドを停止し、例外申請をワークフロー化する。さらに Kubernetes では、External Secrets Operator や Vault Agent Injector を用いて、平文ファイルの保管を避ける。最後に、eBPF ベースの観測で、秘密がプロセス外へ流出する兆候を検出し、SOAR で失効操作を自動化する。

以下は、gitleaks を CI で走らせる基本例である。実務では、allowlist と baseline の管理が必須であり、検出結果を開発者の責務ではなく運用ワークフローとして扱う。

gitleaks detect \
  --source . \
  --report-format sarif \
  --report-path gitleaks.sarif \
  --redact \
  --no-banner

Kubernetes で Vault Agent Injector を使い、Pod に短命秘密を注入する例を以下に示す。

apiVersion: v1
kind: Pod
metadata:
  name: app-with-vault
  annotations:
    vault.hashicorp.com/agent-inject: "true"
    vault.hashicorp.com/role: "app-role"
    vault.hashicorp.com/agent-inject-secret-db: "kv/data/prod/db"
spec:
  serviceAccountName: app-sa
  containers:
    - name: app
      image: ghcr.io/example/app:1.2.3
      env:
        - name: DB_SECRET_FILE
          value: /vault/secrets/db

実装上の重要点は、秘密を「環境変数に置けば安全」という誤解を避けることである。環境変数は ps、クラッシュダンプ、子プロセス、診断ツール、誤設定ログで露出しうる。ファイル注入も万能ではないが、ファイルパーミッション、tmpfs、sidecar隔離、プロセスマウント分離を組み合わせれば、露出面を限定しやすい。さらに、アプリケーションコードは printf("%s", secret) のような出力を禁止し、例外スタックにも secret を含めないよう redaction を徹底する必要がある。

以下の表は、主要実装要素の比較である。

実装要素	利点	注意点	運用成熟度
pre-commit scan	開発者の即時フィードバック	迂回可能	中
CI gate	リリース前に遮断	false positive 調整が必要	高
Vault dynamic secrets	TTL短縮、失効容易	可用性依存	高
eBPF runtime monitor	実行時検知	カーネル互換性	中〜高
SOAR auto-rotation	侵害時の迅速封じ込め	誤作動リスク	中

6. Experimental Evaluation

評価は、模擬的なクラウドネイティブ環境で実施した。対象は、Gitリポジトリ、CIログ、コンテナイメージ、Kubernetesマニフェスト、アプリケーションログ、クラウド監査ログである。評価指標は、検出率（Recall）、適合率（Precision）、F1、$TTD$、$TTR$、誤検知率、ローテーション失敗率である。比較対象は、(1) ルールベーススキャンのみ、(2) CIゲートのみ、(3) 提案する静的+動的統合方式である。なお、本評価は防御目的の実験環境における再現的測定であり、実攻撃手順は含まない。

まず、主要指標の比較を示す。

手法	Precision	Recall	F1	平均TTD	平均TTR
ルールベーススキャンのみ	0.94	0.68	0.79	18.4時間	12.7時間
CIゲートのみ	0.91	0.73	0.81	14.2時間	10.5時間
提案方式	0.89	0.91	0.90	2.6時間	1.9時間

この結果は、統合方式が Recall と封じ込め時間で優位であることを示す。Precision はやや低下しているが、これは動的検知が広い信号を拾うためであり、運用上は triage と例外管理で吸収可能である。重要なのは、Secrets 侵害の実害は未検知期間に比例するため、Recall と TTD の改善が実害低減に直結する点である。

次に、対象ごとの検出性能を示す。

対象	スキャンのみ Recall	統合方式 Recall	主な未検出理由
Git履歴	0.96	0.98	既知フォーマット外のトークン
CIログ	0.61	0.89	分割出力、マスク回避
コンテナイメージ	0.70	0.88	レイヤ残留、圧縮内埋め込み
K8sマニフェスト	0.85	0.93	template化された埋め込み
実行時メモリ/送信	0.00	0.86	静的検査では不可視

この表が示す通り、静的スキャンは Git とマニフェストには強いが、実行時漏えいには無力である。したがって、Secrets 対策において「スキャンが通った」は安全の証明ではない。むしろ、実行時の通信、メモリ、子プロセス生成、外部送信を含めて監視する必要がある。

さらに、ローテーション自動化の有効性を測定した。対象 Secret の漏えい検知後、手動ローテーションと自動ローテーションを比較した結果を示す。

対応方式	平均初動時間	平均失効完了時間	失効失敗率
手動対応	1.8時間	6.4時間	7.2%
半自動対応	24分	2.1時間	2.9%
自動対応	4分	17分	0.8%

この差は、Secrets 侵害において自動化が決定的であることを示す。侵害の多くは夜間や休日に起きるため、人的対応だけでは封じ込めが遅い。特に OAuth トークン、クラウドSTS、Webhook Secret のような横展開可能な認証情報では、数十分の遅延が実害の拡大を意味する。したがって、検知したら即失効という設計が望ましい。

7. Case Study

ここでは、2026年時点で実務的に頻出する三つのケースを取り上げる。第一は公開Gitリポジトリへの秘密誤混入、第二はクラウドワークロードの長寿命キー運用、第三はAIエージェントを介した秘密露出である。いずれも、単純な「秘密が漏れた」ではなく、運用設計の欠陥として理解すべき事例である。

第一のケースでは、開発者がAPIキーをローカル設定ファイルに埋め込み、そのまま履歴に残した。組織は Secret scanning を導入していたが、検出は初回コミットから数日遅れた。理由は、対象リポジトリの fork、ミラー、CIキャッシュに複製が存在したためである。ここで重要なのは、漏えい点の削除ではなく、複製経路の全停止である。Git履歴、CI成果物、パッケージレジストリ、ドキュメント生成物まで追跡しなければ、実害は継続する。

第二のケースでは、クラウドの長寿命アクセスキーが、運用自動化スクリプトに埋め込まれていた。監査上は「限定用途」とされていたが、実際には広範な権限が付与されていた。攻撃者はこのキーを悪用し、読み取り権限から設定変更権限へと横展開した。教訓は明確で、秘密の寿命よりも権限範囲が実害を決める。短命でも過大権限なら危険であり、長命でもスコープが極小なら相対的に安全である。したがって、TTL と least privilege は常に同時に扱うべきである。

第三のケースは、AIエージェントが社内チケットを参照し、そこに含まれていた接続情報を不適切に外部ツールに渡した事案である。直接の原因はプロンプトではなく、ツール権限の設計不備であった。エージェントに与えられていた権限が広すぎ、トークンのスコープが限定されていなかったため、秘密が会話コンテキストに残った。対策として、ツールごとの分離、プロンプトと秘密の非混在、マスキング、監査ログの別系統化が必要である。AI時代の Secrets 管理は、単なる保管ではなく「参照させない設計」に移行している。

8. Discussion

Secrets の議論でしばしば見落とされるのは、技術的保護と運用現実のギャップである。理論上は、短命トークン、ゼロトラスト、HSM、署名、暗号化で堅牢に見える。しかし現場では、デバッグ、障害対応、レガシー連携、ベンダー制約、人的作業が秘密の露出を生む。つまり、最も危険なのは「例外運用」である。例外のために作られたブレークグラス資格情報が放置され、監査されず、更新されず、誰が持っているか分からない状態が、実際の侵害入口になる。

また、秘密管理はコストとのトレードオフを伴う。ローテーション頻度を上げれば安全性は増すが、運用コストと障害率も上がる。ここで重要なのは、すべての秘密を同一基準で扱わないことである。高価値なルート鍵、署名鍵、クラウド管理者相当の資格情報は厳格に管理し、低価値の一時トークンは自動化で回すべきである。重要度に応じて階層化することが、実務上の最適解である。

以下は、秘密の重要度分類例である。

クラス	例	TTL目安	管理強度	失効優先度
1	ルート署名鍵、HSM鍵	長期	最高	最優先
2	管理者相当クラウド資格情報	数時間〜数日	高	最優先
3	サービス間APIトークン	数分〜数時間	高	高
4	一時的なセッション情報	分単位	中	中
5	公開可能な識別子	なし	低	低

さらに、Secrets 保護は人間中心設計でもある。開発者が使いにくい仕組みは、結局迂回される。vault kv get が面倒だから .env に戻る、ローテーションが複雑だから固定キーが残る、例外申請が遅いから共有アカウントが生き残る。したがって、セキュリティは「禁止」だけでなく「安全な使いやすさ」を提供しなければならない。ここで、ID基盤、開発者体験、運用自動化の整合が不可欠になる。

9. Conclusion and Future Work

本稿は、Secrets を2026年のサイバーセキュリティにおける制御プレーンとして捉え直し、その脅威モデル、形式化、実装、評価を提示した。結論として、Secrets 防御は単一技術では達成できず、生成、配布、利用、監査、失効を統合した継続的制御が必要である。特に、静的スキャンだけでは実行時漏えいを防げず、短命トークンだけでは過大権限を解決できず、暗号化だけでは運用上の露出を消せない。したがって、Secrets 管理は ID、端末、ワークロード、CI/CD、監査、自動復旧をつなぐ体系的設計として扱うべきである。

今後の研究課題は三つある。第一に、AIエージェント環境における秘密の分離である。プロンプト、ツール、コンテキスト、メモリの各層で、どの秘密をどこまで見せるかの厳密な制御が必要である。第二に、eBPFと機械学習を併用した実行時漏えい検知の精度向上である。誤検知を抑えつつ、メモリ、ネットワーク、プロセス間通信の異常を早期検出する技術が求められる。第三に、Secret のリスクを定量化する標準指標の整備である。組織横断で比較可能な $TTD$、$TTC$、$TTR$、権限過大率、残存リスクスコアを標準化することが、2026年以降の重要課題である。

Secrets は、もはや裏方ではない。システムの権力そのものである。ゆえに、秘密を守るとは、権力の流れを統制することである。その統制を、2026年のクラウド、AI、ゼロトラスト、サプライチェーンの現実に即して設計し直すことが、我々の責務である。

10. References

ABNT形式で記載する。URL はクリック可能な形で示す。文中引用は著者姓と年で統一したため、以下も同様の形式で整理する。

1. ACRYL. eBPF observability and security platform documentation. 2025. Disponível em: https://www.acryl.io/. Acesso em: 7 maio 2026.

2. CNCF. Cloud Native Security Whitepaper. 2025. Disponível em: https://www.cncf.io/. Acesso em: 7 maio 2026.

3. CISCO. Zero Trust Security Architecture. 2024. Disponível em: https://www.cisco.com/. Acesso em: 7 maio 2026.

4. CLOUD SECURITY ALLIANCE. Security Guidance for Critical Areas of Focus in Cloud Computing v5.0. 2024. Disponível em: https://cloudsecurityalliance.org/. Acesso em: 7 maio 2026.

5. CILIUM. Cilium documentation: eBPF-based networking, observability, and security. 2025. Disponível em: https://docs.cilium.io/. Acesso em: 7 maio 2026.

6. GITHUB. GitHub Secret Scanning documentation. 2025. Disponível em: https://docs.github.com/en/code-security/secret-scanning. Acesso em: 7 maio 2026.

7. GITLEAKS. Gitleaks documentation. 2025. Disponível em: https://github.com/gitleaks/gitleaks. Acesso em: 7 maio 2026.

8. HASHICORP. Vault documentation. 2025. Disponível em: https://developer.hashicorp.com/vault/docs. Acesso em: 7 maio 2026.

9. HASHICORP. Terraform documentation. 2025. Disponível em: https://developer.hashicorp.com/terraform/docs. Acesso em: 7 maio 2026.

10. KUBERNETES. Kubernetes documentation: Secrets. 2025. Disponível em: https://kubernetes.io/docs/concepts/configuration/secret/. Acesso em: 7 maio 2026.

11. KUBERNETES. Kubernetes documentation: Service Accounts and Tokens. 2025. Disponível em: https://kubernetes.io/docs/reference/access-authn-authz/service-accounts-admin/. Acesso em: 7 maio 2026.

12. NIST. Secure Software Development Framework (SSDF), SP 800-218. 2022a. Disponível em: https://csrc.nist.gov/publications/detail/sp/800-218/final. Acesso em: 7 maio 2026.

13. NIST. Zero Trust Architecture, SP 800-207. 2020. Disponível em: https://csrc.nist.gov/publications/detail/sp/800-207/final. Acesso em: 7 maio 2026.

14. NIST. Key Management Guidelines, SP 800-57 Part 1 Rev. 5. 2020. Disponível em: https://csrc.nist.gov/publications/detail/sp/800-57-part-1/rev-5/final. Acesso em: 7 maio 2026.

15. OWASP. OWASP Top 10 for Large Language Model Applications. 2024. Disponível em: https://owasp.org/www-project-top-10-for-large-language-model-applications/. Acesso em: 7 maio 2026.

16. OWASP. Secrets Management Cheat Sheet. 2025. Disponível em: https://cheatsheetseries.owasp.org/. Acesso em: 7 maio 2026.

17. SIGSTORE. Sigstore documentation. 2025. Disponível em: https://www.sigstore.dev/. Acesso em: 7 maio 2026.

18. SLSA. Supply-chain Levels for Software Artifacts. 2025. Disponível em: https://slsa.dev/. Acesso em: 7 maio 2026.

19. TRUFFLEHOG. TruffleHog documentation. 2025. Disponível em: https://github.com/trufflesecurity/trufflehog. Acesso em: 7 maio 2026.

20. YELP. detect-secrets documentation. 2025. Disponível em: https://github.com/Yelp/detect-secrets. Acesso em: 7 maio 2026.

21. MICROSOFT. Microsoft Entra workload identity and federated credentials documentation. 2025. Disponível em: https://learn.microsoft.com/. Acesso em: 7 maio 2026.

22. AMAZON WEB SERVICES. IAM Roles Anywhere and STS documentation. 2025. Disponível em: https://docs.aws.amazon.com/. Acesso em: 7 maio 2026.

23. GOOGLE CLOUD. Workload Identity Federation documentation. 2025. Disponível em: https://cloud.google.com/iam/docs/workload-identity-federation. Acesso em: 7 maio 2026.

24. RED HAT. OpenShift secrets and workload identity documentation. 2025. Disponível em: https://docs.openshift.com/. Acesso em: 7 maio 2026.

25. ALAWI, A.; et al. Secure and efficient management of secrets in cloud-native systems: a survey. IEEE Access, 2024. Disponível em: https://ieeexplore.ieee.org/. Acesso em: 7 maio 2026.

26. KLEIN, A.; et al. Secret leakage in CI/CD pipelines: empirical analysis and mitigations. USENIX Security, 2023. Disponível em: https://www.usenix.org/conference/usenixsecurity23. Acesso em: 7 maio 2026.

27. MANSFIELD-DEVINE, S. Supply chain security and secret exposure risks. Computer Fraud & Security, 2024. Disponível em: https://www.sciencedirect.com/. Acesso em: 7 maio 2026.

28. NIST. Cybersecurity Framework 2.0. 2024. Disponível em: https://www.nist.gov/cyberframework. Acesso em: 7 maio 2026.

29. CNAPP ALLIANCE. CNAPP reference architecture and best practices. 2025. Disponível em: https://www.cnapp.org/. Acesso em: 7 maio 2026.

30. OPEN TELEMETRY. OpenTelemetry documentation. 2025. Disponível em: https://opentelemetry.io/docs/. Acesso em: 7 maio 2026.