LLMがオープンソースライブラリの形式検証を大規模に自動化

ソフトウェア開発者は長年、形式検証のコストの高さに苦しんできました。形式検証とは、コードが特定のバグを含んでいないことを数学的に証明する手法です。AI研究チームとTheoremによる最近の共同プロジェクトでは、大規模言語モデルがこのプロセスを大規模に自動化できることが示されました。Claudeを使用してコンパイル済みバイナリを分析することで、チームは100以上の実世界のオープンソースライブラリに対するセキュリティ特性の証明に成功し、ソフトウェアの正しさを保証する方法における大きな転換点をマークしました。

何が起きたか

このプロジェクトは、本番用ソフトウェアへの形式検証適用に焦点を当てており、特にRISC-Vアーキテクチャのアセンブリコードレベルを対象としています。チームはGoogleのOSS-Fuzzイニシアチブから123のオープンソースライブラリを選択しました。OSS-Fuzzには、バグが発見された際にクラッシュするように設計された、開発者作成のエントリーポイントが数千個含まれています。総当たりテストに頼る代わりに、チームはClaudeに対し、Linux上で実行される単一スレッドの静的バイナリという前提の下で、64 MB未満のあらゆる入力に対してこれらのプログラムが決してクラッシュしないことを証明するよう依頼しました。

数週間の期間を通じて、Claudeはこれらのライブラリ全体で239のエントリーポイントに対する証明を生成しました。結果として得られた証明は合計約1億8,000万行のRocqコードからなり、個別の証明は平均して約60万行に達しました。この過程で、モデルは証明を生成しただけでなく、過去に数兆回の実行が行われたにもかかわらず残存していたバグを発見し、修正しました。この取り組みは、アセンブリレベルの本番用ソフトウェアをAIを用いて形式検証した初の大规模な事例となります。

これらの発見を広く利用可能にするため、チームは分析で使用されたRISC-Vおよびオペレーティングシステムのセマンティクスとともに、証明の一部を公開しています。Theoremは他のオープンソースプロジェクトに対してもこの検証パイプラインを実行するサービスを提供しており、開発者が自らのコードの検証を開始できるよう支援する「Claudeスキル」もリリースしました。このアプローチにより、形式検証はアビオニクスなどのミッションクリティカルなシステムに限定されていたニッチな慣行から、一般的なソフトウェア開発により広く適用可能なツールへと移行します。

仕組み

形式検証では、コードを数学的モデルに変換し、それが一連のセキュリティルールに従うことを証明する必要があります。最大の課題は、複雑なソフトウェアにとって「正しい」とはどういう意味かを定義することでした。このプロジェクトでは、既存のファズテストを正式な仕様に変換することで、手動での仕様策定の必要性を回避しました。ファズテストはランダムな入力を生成してクラッシュを探しますが、すべてのパスがテストされていることを保証することはできません。新しい手法では、仕様を「このテストスイートは常にパスする」と定義し、それをソースコードではなくコンパイルされたRISC-V命令に適用します。

Claudeは、Theoremが提供するRISC-V命令セットおよびLinuxのプロセス動作の公式セマンティクスと、実行可能ファイルの成果物を分析して動作します。モデルは、定義された条件下ではメモリ安全性エラーやアサーション失敗が発生しないことを示す巨大な証明を生成します。これらの証明は、数学的な論理が成立していることを保証する信頼できるカーネルであるRocq証明チェッカーによって検証されます。チェッカーが証明を自動的に検証するため、開発者は数百万行に及ぶ生成コードを手動でレビューする必要はなく、基礎となるモデルとチェッカー自体のみを信頼すれば済みます。

主要な詳細

• プロジェクトでは、OSS-Fuzzイニシアチブ由来の123のオープンソースライブラリにわたる239のエントリーポイントを検証しました。
• Claudeは約1億8,000万行のRocq証明コードを生成し、典型的な証明は60万行に達しました。
• 検証はRISC-Vアセンブリコードを対象とし、Linux上で64 MB未満の入力に対するクラッシュがないことを証明しました。
• モデルは、過去の数兆回のファズテスト実行を生き延びたバグを発見し、修正しました。
• 信頼性は、RISC-VおよびLinuxの公式モデル、定理ステートメント、そしてRocq証明チェッカーに置かれています。
• Theoremは、開発者が同様の検証ワークフローを自身のプロジェクトに適用できるよう支援するClaudeスキルをリリースしています。

なぜ重要なのか

ソフトウェアエンジニアにとって、この進展は形式検証への参入障壁を下げるものです。従来、形式検証には専門家の数年間にわたる努力が必要でした。証明の作成を自動化することで、LLMは日常的なライブラリやアプリケーションに厳格なセキュリティ保証を適用することを現実的なものにします。これにより、チームは反応的なバグ修正や積極的なファジングを超え、メモリ安全性エラーなど脆弱性のクラス全体から安全であることを数学的に証明された重要なコンポーネントを持つモデルへ移行できます。

ソースコードだけでなくコンパイル済みバイナリを検証できる能力は特に重要です。これは、コンパイラの挙動や低レベルな相互作用を考慮に入れ、本番環境にデプロイされた実際の実行可能成果物に対してセキュリティ特性を保証できることを意味します。モデルの能力が向上し、より多くのアーキテクチャ向けのセマンティクスが利用可能になるにつれ、このアプローチはソフトウェア開発ライフサイクルの標準的な一部となり、広く使用されているオープンソース依存関係におけるエクスプロイトのリスクを低減する可能性があります。

できること

• AI生成の形式検証の構造を理解するために、公開された証明の一部とRISC-Vセマンティクスを検討してください。
• Theoremがリリースした新しいClaudeスキルを試して、自身のコードベースで検証ワークフローの実験を開始してください。
• 将来の検証作業において正式仕様の基盤となり得るため、プロジェクトの既存のファズテストを見直してください。
• 特に信頼できない入力を処理するものなど、依存チェーン内の重要なライブラリに対する形式検証ステップの統合を検討してください。
• これらのモデルの拡張は検証可能なソフトウェアの範囲を広げるため、RISC-VおよびLinuxの公式セマンティクスに関する最新情報を追跡してください。
• 検証の出発点として、単一スレッドの静的バイナリという前提が現在のプロジェクトに適用できるかどうかを評価してください。