Four Ways to Forge a Bundle My Own Verifier Calls Clean: Refusal-Site Mutation Testing of an Evidence-Bundle Verifier

現代のデジタル世界において、ソフトウェアシステムはしばしば「信頼せよ、しかし検証せよ」という単純かつ強力な理念に依存しています。コンピュータプログラムが困難な問題を解決した、あるいは膨大なデータセットを分析したと主張するとき、それは一つのレポートを作成します。そのレポートが正直であることを保証するために、他のプログラムが監査役として機能します。これらの監査役は、計算が正しいか、データファイルが改ざんされていないかを確認し、要約された数値が根拠となる生データと一致しているかを検証します。すべてが適正であれば、監査役は「合格」の合図を出し、その結果は世界に向けて公開されます。このプロセスは信頼できるソフトウェアのバックボンス（背骨）であり、互いを知らない見知らぬ者同士が、相手の成果を信頼することを可能にします。しかし、このシステムが機能するためには、監査役自体が完璧でなければなりません。もし監査役が嘘を見逃したり、さらに悪いことに、実際に証拠を確認することなく嘘を真実であると宣言したりすれば、システム全体が崩壊してしまいます。危険なのは単に悪い結果が紛れ込むことではなく、監査役があまりに壊れているために、テストを実際には実行することなくテストをパスさせてしまうことなのです。

エリック・ヒルという研究者は、オフラインシステム用の証拠の束を検証するように設計された、ある監査プログラムを調査することに乗り出しました。彼は、非常に不穏な問いを投げかけました。「このプログラムは、実際には何もチェックしていないのに『パス』と言うことがどれくらいの頻度で起こるのか？」という問いです。それを突き止めるために、彼は単にバグを探すのではなく、自分自身の監査役を体系的に破壊するためのツールを構築しました。彼は、不適切な束を拒絶するために設計されたプログラム内のすべてのコード行を一つずつ取り出し、それらを一つずつオフにしていきました。そして、プログラムのテストスイートがそれに気づくかどうかを見守りました。もし拒絶のためのコード行が削除された後でもテストが依然としてパスする場合、それはその拒絶コードが「死荷重（デッドウェイト）」、つまり実際には何の仕事もしていなかったことを意味します。結果は驚くべきものでした。研究の開始時、監査役の拒絶ポイントの3分の2は、テストに対して不可視の状態でした。プログラムは「ノー」と言う能力の大部分を削ぎ落としても、依然として完璧なスコアを報告するのです。それはまるで、盗品をチェックするように訓練された警備員が、訓練演習の中に一度も盗品が含まれていなかったために、結局どうやって盗品を探すべきかを学んでいないようなものでした。

この研究は、外部の専門家による衝撃的な出来事から始まりました。独立したエンジニアが、見出しの数値が完全に虚偽である証拠の束を提出しましたが、監査役は完璧なパスを出力しました。この不正を作るのにかかったコストは、わずか4バイトでした。エンジニアはあるファイルを極小の空のプレースホルダーに置き換えたのですが、監査役はそのファイルが実際に存在するかどうかをチェックしなかったため、すべてが正常であると判断したのです。ヒルはこの特定の穴を修正しましたが、その後、彼自身の体系的なツールを修復されたプログラムに適用しました。彼は、問題が単一のミスではなく、一つのパターンであることを発見しました。彼は監査役を欺くためのさらなる4つの方法を発見しましたが、そのたびに、プログラムがチェック自体をスキップしていることが判明しました。これらのトリックの一つは、深刻度のラベル内の大文字を一つ変更することであり、それによってプログラムが失敗したチェックの重みを無視するように仕向けるものでした。もう一つは、リストからキーを削除することで、比較すべき対象が存在しないためにプログラムが比較をスキップさせるというものでした。いずれの場合も、プログラムは困難な計算に失敗していたのではなく、単に計算を開始すること自体を怠っていたのです。

この問題がどの程度蔓延しているかを測定するために、ヒルは自身の削除ツールを監査役のコードに対して実行しました。彼は、プログラムが「ノー」と言うはずの場所を112箇所特定しました。それらを一つずつ削除していったところ、75箇所がテストを失敗させることなく削除可能でした。これは、112箇所の拒絶ポイントのうち75箇所が、システムの安全性チェックに対して事実上不可視であったことを意味します。プログラムのスコアは0.330であり、拒絶メカニズムの約3分の1しか実際にテストされていないことを示していました。残りの3分の2は「空虚なパス（vacuous passes）」、つまり証拠を全く検証していないにもかかわらず成功を報告するチェックでした。これは稀なグリッチではなく、安全網に誰も落ちてみようとしなかった穴が開いているという構造的な欠陥です。テストはプログラムが実行されていることを確認していましたが、データが実際に調べられているかどうかを確認していませんでした。

ヒルは、このような問題に対する一般的な解決策、すなわち「発見された特定のバグを修正し、それぞれのバグに対するテストを追加する」という手法をテストしました。彼は発見した4つの偽造を修正し、それらのトリックが二度と通用しないように新しいテストを追加しました。驚いたことに、これでは全体の安全性スコアは改善しませんでした。プログラムには依然として75個の不可視の拒絶ポイントが存在していました。新しいテストは、彼が修正したばかりの新しい穴をカバーするだけで、残りの部分は以前と同様に盲目のままでした。彼が戦略を変えたとき、初めて数字が動きました。バグを修正する代わりに、彼は75個の不可視の拒絶ポイントのそれぞれに対して新しいテストを作成し、プログラムが各ポイントを実際に作動させられることを証明させました。この体系的なアプローチにより、スコアは0.330から1.000へと上昇し、すべての拒絶ポイントが実際に作動可能であることを証明しました。教訓は明白でした。既知のバグを直すだけではシステムを安全にはできない。すべての安全性メカニズムが実際に機能することを証明しなければならないのです。

この研究は、これらのシステムがどのように構築されているかに関するより深い問題も明らかにしました。研究者は、監査役が人間が読むためのレポートと、チェックに使用される生のデータファイルを別々に扱っていることが多いことを発見しました。証拠の束に人間が読むためのレポートが含まれている場合、監査役は、そのレポートが基礎となるデータと一致しているかどうかを検証できないことが頻繁にありました。それはまるで、監査役が要約ページは信頼するものの、領収書を無視しているかのようでした。これは複数の異なるプロジェクトで見られたことであり、開発者の間の共通の習慣を示唆していました。彼らはコンピュータがチェックするデータは紐付けますが、人間が読むデータについては検証を置いてけぼりにするのです。研究者は、このギャップによって虚偽の主張が紛れ込むことがあり、レポートには「すべての欠陥が修正済み」と書かれていても、データはそれとは異なる状態を示すことがあるということを発見しました。

研究を通じて、研究者自身のツールも、彼が研究している問題そのものを反映する形で彼を裏切りました。彼の測定器具は、時として何も測定していないにもかかわらず成功を報告しました。ある事例では、失敗を検出するように設計されたツールが、ベースラインのテストスイートが既に失敗していたために、そのエラーを成功と誤認して完璧なスコアを返しました。これは研究中に7回発生しており、その中にはシステムが壊れている間にツールが完璧なスコアを出したケースも含まれていました。これらの失敗は隠蔽されたのではなく、検証用ソフトウェアが、それが検証しようとしているソフトウェアと同様に、これらの「空のパス」エラーに対して脆弱であることを示すために、論文の中に文書化されました。

この研究の最終的な結論は、異なる種類のテストへの呼びかけです。研究者は、既知のバグのリストによってシステムを安全に保つことはできないと主張しています。もしシステムに、一度も失敗が観察されたことがない安全ゲートがあるならば、それは一度も機能したことが観察されていないのと同じです。確実な方法は、すべてのゲートを体系的にテストし、それらが実際に作動できることを確認することです。研究は、システムが紙の上では完璧に見えても、実際には根本的に壊れている可能性があることを示しました。監査役に、あらゆる方法で悪いデータを拒絶できることを強制することによって、研究者は、自らの失敗に対して盲目であったシステムを、完全に検証されたものへと変えたのです。この著作は、デジタルな信頼の世界において、最も危険なエラーは「失敗したチェック」ではなく、「一度も行われなかったチェック」であることを思い出させる警告として立っています。