シークレット検出の二方式(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') のような動的パス構築も回避経路として残る。
どちらの方式でも「表示後にスクロールバックへ残った分」は消せない。