BetterleaksのシークレットスキャナーとGitleaksの比較

Betterleaksの秘密スキャナー：アーキテクチャと鍵

近年、リポジトリ内の機密情報の検出方法は大きく変化しました。以前は、コード内の疑わしい文字列やエントロピーの高いキーを探すだけで十分でした。しかし現在では状況が異なり、リポジトリの規模拡大、CI/CDパイプラインの高速化、そして何よりも自動化ツールやAIモデルによって生成されるコード量の増加が顕著になっています。

これには実際的な意味合いがある。問題はもはや秘密を見つけることだけではなく、真に危険なものと、単に危険に見えるものを区別することだ。多くのチームは、こうしたスキャナーの真のコストは分析を実行することではなく、何百もの誤検出を検証することにあることに気づき始めている。

検出アーキテクチャ：Betterleaksで何が変わるのか？

Betterleaksはまさにこのような文脈で登場した。秘密情報のスキャン方法を完全に刷新しようとするものではないが、パターンを検出すれば十分だという広く浸透している前提に異議を唱えている。

多くの現代のリポジトリではそうではありません。

ザック・ライス氏が開発し、合気道の支援を受けて維持されているこのプロジェクトは、従来とは少し異なるアプローチを提案している。単に一致するものを検出することに焦点を当てるのではなく、アラートとして発信する前に、その発見が妥当かどうかを検証しようとするのだ。

これは些細なことのように思えるかもしれませんが、大規模チームの力関係を大きく変えてしまいます。スキャンシステムが無関係なアラートを大量に生成すると、チームは自然とそれらを無視しがちです。しかし、セキュリティにおいては、アラートを無視することは、アラートがないよりも悪い結果を招く可能性があります。

この問題に対処するため、Betterleaksは2つの興味深い技術的要素を導入しています。1つはCEL（共通表現言語）を使用した検証、もう1つはBPEトークン化に基づいた「トークン効率」と呼ばれる指標です。

一見秘密に見えるものすべてが、実際に秘密であるとは限らないというのが、この考え方の根底にある。エントロピーの高い文字列の中には、単なるハッシュ値、識別子、あるいは自動生成された断片であるものもある。このシステムの目的は、そうしたノイズを低減することである。

プロジェクトのドキュメントには、CredDataデータセットにおいて、BPEトークン化が98.6%のリコール率を達成したのに対し、エントロピーを用いた場合は70.4%であったという比較が記載されています。他のベンチマークと同様に、これらの数値はあくまで目安です。参考値としては役立ちますが、実際のデータベースでのテストに取って代わるものではありません。

違いを生み出すコンポーネント

プロジェクトの特徴を検討すると、明確な方向性が見えてくる。それは、技術的な複雑さを過度に高めることなく、実際の環境への導入を容易にすることである。

最も顕著な要素としては、以下のものが挙げられます。

• CEL（共通式言語）を使用したルール定義による検証
• トークン効率スキャンは、エントロピーではなくBPEトークン化に基づいており、CredDataデータセットにおいて、エントロピーを用いた場合の70.4%に対し、98.6%のリコール率を達成した。
• 純粋なGo言語による実装（CGOやHyperscanへの依存なし）
• 二重／三重にエンコードされた秘密情報の自動処理
• より多くのプロバイダー向けにルールセットを拡張
• リポジトリ分析を高速化するための並列化されたGitスキャン

このリストは単なる技術的な改良点の羅列のように見えるかもしれないが、興味深いのはそれらが日常生活にどのような影響を与えるかということだ。

例えば、ネイティブ依存関係のない完全なGo実装は、CI/CDパイプラインへの統合を大幅に簡素化します。多くのチームでは、こうした些細な点が、ツールが実際に使用されるか、リポジトリに埋もれたまま忘れ去られるかを左右するのです。

BPEトークン化は、従来とは異なるアプローチを採用しています。単にチェーンのランダム性を測定するのではなく、現代の認証情報が実際にどのように構成されているかをより正確に反映するトークンパターンを分析します。

スキャナーが何かを検出するとどうなりますか？

Betterleaksが潜在的な秘密を検出したとしても、そこでプロセスは終わりません。

まず、CELで定義されたルールを使用してコンテキストが評価されます。これにより、例えばフォーマットが想定されるプロバイダーと一致するかどうかを確認したり、例や架空データによく現れるパターンを除外したりするなど、追加の条件を適用できます。

この手順は些細なことのように思えるかもしれないが、実際には大きな影響を与える。誤検知は時間の浪費につながるだけでなく、アラートシステムに対するチームの信頼を低下させる。

もう一つ興味深い点は、複数回エンコードされた秘密情報の自動処理です。一部のリポジトリでは、認証情報がbase64などのエンコード方式で変換されて表示されるため、検出が困難になります。

とはいえ、見落とされがちな点を覚えておくことは重要です。スキャナーは人間のレビューを完全に代替することはできません。秘密情報を検出することは始まりに過ぎず、それをどう扱うか（取り消す、ローテーションする、無視する、調査するなど）は、状況に応じて判断する必要があります。

ガバナンスと人間中心のアプローチ／AI

BetterleaksはMITライセンスの下で公開されており、カナダロイヤル銀行、Red Hat、Amazonなどの組織からの外部貢献が含まれています。

このプロジェクトはまた、現代のリポジトリでますます顕著になっている現実、つまり開発者が書いたコードと自動化ツールによって生成されたコードが混在している状況に適応しようとしている。

この文脈において、このツールは、人間が操作するワークフローと、リポジトリ全体をレビューする自動システムの両方でうまく機能することを目指しています。これは、 自動化とツール コードを分析したり、自動レビューを生成したりするもの。

ロードマップには、次のような興味深いアイデアも含まれています。 Git以外のデータソースプロバイダーAPIを介した、調査結果の分類および自動取り消しメカニズムのための言語モデル支援。

これは興味深い議論を巻き起こす。認証情報の取り消しを自動化することで、インシデントへの対応時間を短縮できる可能性があるが、同時に分類システムの正確性に依存することにもなる。

自動的な取り消しが失敗した場合、または誤って実行された場合、業務への影響は甚大となる可能性がある。

実務上の意味合いと限界

運用面から見ると、Betterleaksは誤検知を減らし、導入を簡素化したいと考えているチームにとって魅力的なツールです。

しかし、いくつかの制限事項も念頭に置いておくことが重要です。

• 再現率の指標は使用するデータセットに依存し、リポジトリによって大きく異なる場合があります。
• 鍵の失効などの操作を自動化するには、追加の制御機能と監査ログが必要になります。
• 秘密のスキャナーは、より広範な戦略における防衛策の一つに過ぎない。

多くの場合、そのようなツールを採用するかどうかの決定は、その理論的な正確さよりも、もっと単純なこと、つまりチームのワークフローにうまく統合できるかどうかに左右される。

摩擦が大きすぎる高精度スキャナーは通常は採用されない。一方、適度な精度で統合しやすいスキャナーは通常採用される。

その意味で、Betterleaksはバランスを取ろうとしている。誤検知をすべて排除したり、既存のセキュリティプロセスを置き換えたりすることを約束するものではないが、ノイズを減らし、最新のパイプラインへの統合を容易にすることを目指している。

このプロジェクトはGitHubで公開されています。 これは、自動化、分析エージェント、言語モデルによって生成されたコードが開発フローの通常の一部となっているリポジトリに適応することを意図した、Gitleaksで使用されているアプローチの進化形として提示されています。