ruzzy

ruzzy skill の概要

ruzzy の用途

ruzy skill は、libFuzzer ベースのカバレッジ誘導型 Ruby ファザー Ruzzy を使うための skill です。特に、sanitizer によるクラッシュ検出を伴う形で Ruby コード、なかでも Ruby の C 拡張を fuzzing したい人向けです。ruzy install と ruzy usage の流れを、リポジトリをざっと見るだけよりも具体的に知りたい場合に向いており、一般的な Ruby 自動化ではなくセキュリティテスト用途を想定しています。

どんな人に向いているか

次のような場合は ruzzy skill を使う価値があります。

• ネイティブ拡張を含む Ruby gem をテストしたい
• Ruby の C コードでメモリ破壊や未定義動作を探したい
• パーサー、シリアライザ、入力処理の経路を fuzzing で検証したい
• Security Audit のワークフローに Ruzzy が合うか判断したい

一方で、単純な unit test や property test、ネイティブコードを対象にしない black-box なアプリテストだけが目的なら、あまり向いていません。

何が違うのか

Ruzzy は、Ruby におけるカバレッジ誘導型 fuzzing の実運用向け विकल्पとして位置づけられています。実務上の違いは、コードカバレッジと sanitizer からフィードバックが得られることです。そのため、単に「ランダムな入力を投げる」だけの手法よりも、深刻な失敗を見つけやすくなります。主なトレードオフはセットアップの手間で、適切な Ruby、clang、Linux 環境が必要ですし、実際に fuzzing できる対象も必要です。

ruzzy skill の使い方

環境をインストールして検証する

ruzy install は、skill 本体とリポジトリの SKILL.md から始めます。リポジトリによると、Ruzzy がサポートするのは Linux x86-64 と AArch64/ARM64 です。macOS や Windows では、ネイティブインストールではなく Dockerfile か開発環境を使う必要があります。

実用的なインストール確認は次のようなものです。

export ASAN_OPTIONS="allocator_may_return_null=1:detect_leaks=0:use_sigaltstack=0"
LD_PRELOAD=$(ruby -e 'require "ruzzy"; print Ruzzy::ASAN_PATH') \
  ruby -e 'require "ruzzy"; Ruzzy.dummy'

この簡単な実行が期待どおりクラッシュするなら、ビルドと sanitizer の連携は正しく機能しています。

ざっくりした目的を使えるプロンプトに落とし込む

ruzy usage で良い結果を出すには、「gem を fuzzing したい」といった曖昧な依頼は避けます。skill が入口関数と harness を選べるだけの情報を与えてください。少なくとも次を含めます。

• 対象の gem または repository 名
• 純 Ruby なのか C 拡張なのか
• どのメソッド、パーサー、API を駆動したいか
• サンプル入力の形式
• 何を重視するか（クラッシュ、ハング、coverage 増加など）

より良い入力例:

“Use ruzzy for Security Audit on this Ruby C extension. The target is MyGem::Parser.parse, which accepts a string payload and can reach native code. Help me build a minimal harness and a seed corpus for malformed JSON-like inputs.”

まずリポジトリのどこを読むか

最初に読むのは SKILL.md です。そのうえで、次のセクションを確認します。

• When to Use
• Quick Start
• Installation
• Platform Support

ワークフローを自分のプロジェクトに合わせて調整する必要があるなら、例を流用する前にインストールコマンドと、本文中のリポジトリ参照を読んでください。導入で詰まりやすいのは、たいていプラットフォームの不一致か、fuzzing する抽象化レベルを間違えることです。

実務で機能するワークフロー

ruzy guide としては、次の流れが堅実です。

1. プラットフォームと Ruby/clang の前提条件を確認する
2. ASAN の preload 設定を検証する
3. 小さくて決定的な入口関数を 1 つ選ぶ
4. その入口の周りに最小限の harness を組む
5. まずは短時間の fuzzing を走らせ、あとで coverage を広げる

Security Audit では、最初の対象範囲を狭く保つのが重要です。入力境界が明確で安定した 1 つのターゲットのほうが、アプリ全体を一気に fuzzing するより価値が出やすいです。

ruzzy skill の FAQ

ruzzy はネイティブ拡張専用ですか？

いいえ。純 Ruby コードと Ruby C 拡張の両方に対応しています。ただし、ネイティブコードが絡むときに最も力を発揮します。目的がアプリケーションロジックのテストだけなら、通常の test suite や property-based testing のほうが簡単なことがあります。

ruzzy のインストールは難しいですか？

サポート対象の Linux では ruzy install の流れは比較的わかりやすいですが、環境の細部は重要です。clang、Ruby、sanitizer の設定がきちんと揃っている必要があります。macOS や Windows では、直接のネイティブインストールではなく Docker か開発環境を使う前提で考えてください。

どんな場合に ruzzy を使うべきではありませんか？

対象を何度も実行できない場合、安定した入力入口を切り出せない場合、あるいは外部サービスへの依存が強いコードでは、Ruzzy は向きません。そのようなケースでは fuzzing のシグナルが弱く、セットアップコストのほうが価値を上回ってしまいます。

初心者にも向いていますか？

はい、すでにどの関数やパーサーを test したいか分かっているなら向いています。まだ対象領域の探索から始める必要があるなら、最初のセキュリティツールとしては簡単ではありません。初心者が成果を出しやすいのは、まず toy example で流れをつかみ、そのあと小さな harness を 1 つずつ実際の対象に合わせていくやり方です。

ruzzy skill を改善する方法

skill の対象をもっと絞る

品質を最も大きく上げるのは、対象の絞り込みです。「gem を fuzzing して」ではなく、正確な callable surface、期待する入力型、そして気にしている失敗の種類を指定してください。たとえば、「decode(input_string) に対して、壊れた UTF-8 と入れ子の区切り記号で起きる crash を見つけたい」は、一般的な依頼よりずっと良い指定です。

実入力と境界値を seed にする

Ruzzy は、代表的な seed を与えると結果が良くなります。特に対象が構造化入力を扱うなら重要です。次のようなものを含めてください。

• 3〜10 個の有効な例
• 壊れた派生例
• 空文字列、巨大バッファ、切り詰められたデータなどの境界ケース

初期 corpus が探索の進み方を左右するため、これは長い説明文よりも重要です。

crash、hang、coverage を見ながら反復する

最初の実行が終わったら、実行時間を伸ばす前に harness を改善します。crash が出たら、最小の再現条件を切り出します。hang が出たら、timeout を厳しくし、状態を単純化します。coverage が伸び悩むなら、初期化のオーバーヘッドを減らし、harness から不要な依存を外します。このフィードバックループが、ruzy usage を Security Audit で実用的にする核心です。