シークレット検出の二方式(known-value / pattern)
一言まとめ
秘匿値の検出は「既知の値を文字列一致で置換する」か「正規表現・エントロピーで未知の値を拾う」かの二択で、偽陽性と偽陰性のトレードオフが逆になる。前者は自分が管理する値のログ掃除に、後者は漏洩検出に向く。
調査時点: 2026-04。
比較
| 観点 | known-value 方式(例: Teller redact、GitHub Actions add-mask、1Password op run) | pattern 方式(例: Gitleaks、TruffleHog、secretlint、Warp) |
|---|---|---|
| 検出対象 | 事前に取得・設定した既知の値だけ | 正規表現やエントロピー閾値に合致する全文字列 |
| 実装の核 | 部分文字列一致(Teller は kvs.iter().any(|kv| message.contains(&kv.value))) | regex マッチとエントロピー計算 |
| 前提 | 値の供給元が要る(シークレットマネージャ接続、または dotenv 等のローカル設定) | 設定なしで即実行できるものが多い |
| セットアップ | どの値を隠すか列挙する設定ファイルが必須 | 軽量 |
| 偽陽性 | なし(知っている値しか置換しない) | あり(変数名・公開鍵・lockfile のハッシュなどを誤検知) |
| 偽陰性 | 多い(未設定の値・新規シークレットは素通り) | 少ない(パターン網羅に依存) |
| 向く用途 | 自分が管理するシークレットのログ掃除 | 漏洩検出・コミット前スキャン |
要点
- known-value 方式は「自分が管理しているシークレットを隠す」用途に限られ、ハードコードされた未知の API キーは検出できない。
cat .env | <known-value tool>は.envの値で.env自身をマスクする自己循環になる。 - pattern 方式は未知のシークレットを拾える代わりに、誤検知が構造的な最大の弱点になる。ツール側の自己分析でも「正規表現は書けるが保守が困難」「新パターンへの追従コストが高い」「regex で識別できるのは一貫した接頭辞を持つ一部のキーだけ」とされる。ツール横断で誤検知がアラート疲れを生んでいる。
- 文字列の完全一致だけに頼る redact は、変形・分割された秘匿値を取りこぼす。
cat $(echo '.env')のような動的パス構築も回避経路として残る。 - どちらの方式でも「表示後にスクロールバックへ残った分」は消せない。
関連
更新履歴
- 2026-04-16: 初版（ローカル調査ノート）
- 2026-10-17: Wiki へ移植、概念ページとして再構成