solana-vulnerability-scanner

solana-vulnerability-scanner skill の概要

solana-vulnerability-scanner は、一般的な Rust コードレビューでは見落としやすい Solana プログラムのセキュリティ問題を重点的に確認するための監査スキルです。特に、CPI、PDA ロジック、signer チェック、account ownership チェック、instruction introspection を使っている native Solana や Anchor プログラムを、デプロイ前に確認したいエンジニア、監査担当者、セキュリティチームに向いています。

solana-vulnerability-scanner skill は、広範な smart-contract linter ではありません。Solana 固有の影響の大きいミスを少数に絞って洗い出し、そのプログラムがリリースに耐えるか、あるいはより深い手動レビューが必要かを判断しやすくするためのものです。

この skill が検出するもの

このリポジトリは、arbitrary CPI、不適切な PDA 検証、signer や ownership チェックの欠落、sysvar spoofing を含む 6 つの重要な脆弱性パターンを中心に構成されています。そのため solana-vulnerability-scanner は、「このコードはコンパイルするか？」ではなく、「攻撃者が Solana の account モデルにおける信頼前提をすり替えられるか？」という問いに答えたいときに役立ちます。

最適なユースケース

solana-vulnerability-scanner は、ローンチ直前のプログラム、upgrade review、protocol integration、そして特定の program、authority、sysvar を表すものとして account を信頼しているあらゆるコードパスの Security Audit に向いています。一般的な business logic のレビューや、Solana ではない Rust crate にはあまり向きません。

何が違うのか

solana-vulnerability-scanner の価値は、Solana 特有の判断ロジックにあります。どの account validation や CPI の境界が実際の exploitability を左右するのかに集中できるため、どの Rust repository にも当てはまる一般論で時間を浪費せずに済みます。

solana-vulnerability-scanner skill の使い方

skill をインストールする

solana-vulnerability-scanner は次のコマンドでインストールします。

npx skills add trailofbits/skills --skill solana-vulnerability-scanner

このインストール先が重要なのは、skill が trailofbits/skills リポジトリ内の plugins/building-secure-contracts/skills/solana-vulnerability-scanner にあるためです。つまり、これは汎用の coding assistant プロンプトではなく、Security Audit のワークフローとして扱うべきものです。

正しい対象と範囲を与える

solana-vulnerability-scanner をうまく使うには、監査対象を明確にすることから始めます。具体的には、repository 名、program entrypoint、framework の種類、そして気にしている trust boundary を伝えます。たとえば、「この Anchor program を arbitrary CPI、PDA derivation のミス、initialize と withdraw のフローにおける signer チェック欠落の観点で監査してほしい」といった入力が有効です。

「この Solana app をスキャンして」といった曖昧な指示では、重要な account や instruction を取りこぼしやすくなります。

先に読むべきファイル

solana-vulnerability-scanner のインストール後のレビューでは、まず SKILL.md を読み、次に resources/VULNERABILITY_PATTERNS.md を確認してください。この resource file には、skill が前提にしている具体的なチェック項目と例がまとまっており、ファイル名だけを手がかりに推測するよりずっと有用です。

あわせて、次の要素を定義している program ファイルも目を通してください。

• invoke() または invoke_signed() を使った CPI 呼び出し
• Anchor の #[derive(Accounts)] struct
• PDA の derivation と seed 検証
• account ownership と signer 制約
• sysvar または program account のチェック

実践的なワークフロー

この skill は 2 回に分けて使うと効果的です。最初に、疑わしい vulnerability class と影響を受ける instruction を洗い出してもらいます。次に、各フラグ付きパスについて、どの account が user-controlled なのか、どの program ID が期待されているのか、validation が CPI や state change の前に行われているのかを account レベルで確認します。

良いプロンプト例は次のとおりです。
「solana-vulnerability-scanner の 6 つの重要な脆弱性について、これらの Solana/Anchor instructions をレビューしてください。account validation、CPI target、PDA seeds、sysvar trust に注目し、instruction ごとに findings を返し、exploitability を説明し、false positive も示してください。」

solana-vulnerability-scanner skill の FAQ

solana-vulnerability-scanner は Anchor 専用ですか？

いいえ。native Solana Rust program と Anchor ベースの program の両方を対象にしています。ただし、Anchor code は checks をより宣言的に表現することが多いため、レビューの焦点は constraint が十分かどうか、program 型と account 型が正しく制約されているかどうかに移ります。

通常のコードレビュー用プロンプトと何が違うのですか？

通常のプロンプトでも怪しいロジックには気づけることがありますが、solana-vulnerability-scanner は Solana の account model と、攻撃者が CPI、PDA handling、account validation をどう悪用するかに合わせて調整されています。その結果、Solana の security audit で最も重要な問題をより広くカバーできます。

初心者でも使えますか？

はい。program entrypoint と主要な instruction account が分かるなら使えます。初心者は、solana-vulnerability-scanner をガイド付きの checklist として使い、リポジトリ全体を一度に監査しようとするのではなく、フラグされた instruction について順番に質問するのが最も効果的です。

使わないほうがよいのはどんなときですか？

tokenomics、business logic、governance design の唯一のレビュー手段として solana-vulnerability-scanner に頼るべきではありません。強いのは security-critical な Solana パターンであり、プロトコル全体の正しさや経済モデルの検証ではありません。

solana-vulnerability-scanner skill を改善する方法

正確な instruction path を指定する

品質を大きく上げる一番の方法は、instruction 名、想定される authority、account の役割を明示することです。「私の program をチェックして」ではなく、どの handler をレビューしてほしいのか、どの account が trusted、mutable、signer-gated、program-owned であるべきなのかを伝えてください。そうすることで solana-vulnerability-scanner は、本当の露出と無害な配線を切り分けやすくなります。

信頼前提を先に書く

ある account が token program、system program、metadata program、あるいは特定の PDA であるべきなら、その前提を明記してください。user-supplied にできる account があるなら、それも伝えてください。Solana のバグは、実際には validation 不足であることが多いため、信頼前提が明確だと solana-vulnerability-scanner の出力精度が上がります。

単なる指摘ではなく、exploitability を聞く

solana-vulnerability-scanner をよりよく使うには、各問題の attack path と、exploit を成立させる前提条件まで尋ねてください。そうすることで、出力が「スタイル上の問題」と「セキュリティバグ」を区別するようになり、Security Audit の用途に合った結果が得られます。

具体的なコード領域で繰り返し確認する

最初のレビューで CPI や PDA のパターンが指摘されたら、その特定の関数と対応する Accounts struct に絞って再レビューしてください。1 instruction ずつ範囲を狭め、account 制約、program ID、seed が意図した trust model と完全に一致しているかを確認するのが、最も良い結果につながります。