solidity-security

solidity-securityスキルの概要

solidity-securityは何に使うスキルか

solidity-security は、Solidityスマートコントラクト向けに特化した監査・セキュアコーディングガイドです。コントラクトのロジックをエージェントにレビューさせ、代表的な攻撃パターンを洗い出し、より安全な実装パターンを提案しつつ、本番投入や正式な監査に入る前に「なぜその設計が危険なのか」まで説明してほしい場面で特に力を発揮します。

このスキルを導入すべき人

このスキルが向いているのは、次のようなケースです。

• mainnet や testnet にコントラクトを出す Solidity 開発者
• 初回レビューを回す監査担当者
• DeFi、token、vault、または管理者権限を持つコントラクトを外部 Security Audit 前に整えたいチーム
• 単なる「このコードをレビューして」よりも、構造化されたセキュリティフィードバックを求めるエンジニア

一方で、非EVMプロジェクトや、プロトコル経済設計だけを分析したい用途にはあまり向きません。

実際に解決してくれる仕事

ユーザーが欲しいのは、脆弱性の一覧表だけではありません。たとえば「この vault に reentrancy や権限まわりの問題がないか見たい」といった曖昧な要望を、攻撃経路、より安全な実装、修正優先度まで含んだ再現性のあるレビュー手順に落とし込みたいわけです。solidity-security は、普通のプロンプトよりもこの点で実用性があります。

solidity-securityの違い

このスキルは、対象を絞った実践的な内容になっています。ブロックチェーン全般の広い話ではなく、Solidityで起きやすい代表的な失敗パターンに軸足があります。具体的には次のようなものです。

• reentrancy
• 算術処理のエッジケース
• access control のミス
• unsafe external calls
• セキュリティを意識した実装パターン

そのため、広さよりも精度を重視したいときに相性が良いスキルです。

導入前に知っておきたいこと

このリポジトリは軽量で、スキル本体の内容は主に SKILL.md にまとまっており、追加の rules、scripts、reference files はありません。導入しやすい反面、出力の質は渡すコンテキストに大きく左右されます。入力が「このコントラクトを監査して」だけだと、結果はどうしても総論寄りになります。コントラクトの目的、threat model、privileged roles、重要な関数まで渡せば、solidity-security skill はかなり実用的になります。

solidity-securityスキルの使い方

solidity-securityのインストール方法

skills対応クライアントから、リポジトリ経由でインストールします。一般的な形は次のとおりです。

npx skills add https://github.com/wshobson/agents --skill solidity-security

利用しているエージェント基盤でインストール方法が異なる場合は、次の場所からスキルを追加してください。

https://github.com/wshobson/agents/tree/main/plugins/blockchain-web3/skills/solidity-security

リポジトリで最初に読むべきファイル

まず確認するのは次です。

• plugins/blockchain-web3/skills/solidity-security/SKILL.md

このスキルのフォルダには、補助的な README.md、rules/、references/ がないため、SKILL.md がそのまま運用マニュアルの全体です。最初に “When to Use This Skill” と脆弱性セクションを読み、このスキルがどんな観点でレビューするのかをつかむのがおすすめです。

solidity-securityがうまく機能するために必要な入力

solidity-security usage の質は、どれだけ具体的なコントラクト情報を渡せるかで決まります。最低限、次の情報を入れると効果的です。

• Solidity version
• contract files または重要な抜粋
• contract purpose
• user roles と privileged roles
• asset flows: 誰が deposit、withdraw、mint、burn、liquidate、upgrade するのか
• external integrations: oracles、ERC20s、bridges、routers、callbacks
• trusted actors に関する前提
• 欲しい出力の種類: quick scan、deep audit checklist、exploit scenarios、remediations のどれか

ここが不足していると、このスキルが返せるのは一般論としての脆弱性解説に留まりがちです。

初回レビューに向いたプロンプトの形

最初の依頼として強いプロンプトは、たとえば次のようなものです。

“Use the solidity-security skill to review these contracts for reentrancy, access control, unsafe external calls, arithmetic or accounting mistakes, and other high-severity issues. For each finding, include impact, exploit path, affected functions, and a concrete remediation. Distinguish confirmed issues from areas needing more context.”

このプロンプトが有効なのは、次を明確に要求しているからです。

• 対象となる問題クラスが具体的
• 出力に優先順位がある
• exploit の筋道を説明させている
• 実装レベルの改善案を求めている
• 不確実な点を切り分けさせている

曖昧な依頼を完成度の高いプロンプトに変える方法

弱いプロンプト:

• “Check this Solidity code.”

より良いプロンプト:

• “Use solidity-security for Security Audit preparation on this vault contract. Focus on withdrawal flow, share accounting, admin powers, pausing, upgradeability assumptions, and external token interactions. Identify critical and high findings first, then list medium-risk hardening opportunities.”

後者が良いのは、事業上重要な攻撃面にスコープを絞っているからです。これにより、ノイズが減り、重要な指摘の密度が上がります。

監査向けの推奨ワークフロー

実務で使いやすい solidity-security guide の流れは次のとおりです。

1. まずコントラクト群から threat model の要約を出させる
2. 次に関数ごとの risk map を作らせる
3. state を変更する external-call の経路を深掘りする
4. role 制限付き関数と initialization logic を確認する
5. 上位の finding について remediation examples を出させる
6. パッチ後のコードで再度スキルを実行し、残るリスクを確認する

いきなり巨大な一回監査を投げるより、この段階的な進め方のほうが、たいてい出力品質は安定します。

特に重点を置くべき高価値レビュー領域

solidity-security を呼び出すときは、次の領域を明示的に重点対象にすると効果的です。

• withdrawal と payout functions
• callback 可能な token interaction
• role transfer と ownership logic
• initialization と upgrade paths
• accounting invariants
• oracle または pricing dependencies
• emergency controls
• ERC20 compliance に関する前提

浅いプロンプトだと、こうした箇所にある本質的なリスクを見落としやすくなります。

このスキルが特に得意そうな範囲

ソース内容を見る限り、このスキルは代表的な Solidity 脆弱性クラスと安全な実装パターンに強く、特に reentrancy と、それに関連する checks-effects-interactions のような防御的コーディング習慣を扱うのが得意です。位置づけとしては、セキュリティ重視のコーディング・レビュー支援であり、formal verification やプロトコルレベルの経済モデリングの代替ではありません。

出力品質を上げる実践的なコツ

solidity-security usage の結果を良くしたいなら、次を足してください。

• 資金移動を行う正確な関数を貼る
• どの role が trusted で、どれが外部に開かれているかを明記する
• contract が upgradeable か proxy かを書く
• bug 名だけでなく exploit の前提条件も聞く
• 根拠付きの severity ranking を求める
• コードから確定できる事実と assumptions を分けるよう依頼する

こうした小さな追加でも、判断の精度はかなり変わります。

このスキルに期待しすぎないこと

solidity-security skill に次のことを自動で期待してはいけません。

• tests の実行
• deploy 済み bytecode の検査
• invariants の数学的証明
• 完全な手動 Security Audit の代替
• 一度も言及していない ecosystem 固有の問題の検出

このスキルは、こちらが渡すコードとアーキテクチャ文脈を前提にした、専門的レビューの土台として使うのが最も効果的です。

solidity-securityスキルFAQ

solidity-securityはSecurity Audit準備に向いている？

はい。solidity-security for Security Audit は、外部監査に費用をかける前に、明白な問題や中程度に見つけにくい Solidity の不備を先に潰したい場面で非常に相性が良いです。コードを引き締め、前提条件を文書化し、監査時に避けられる指摘を減らした状態で臨みやすくなります。

汎用的な「audit my contract」プロンプトより良い？

通常は yes です。汎用プロンプトだと、スマートコントラクトの典型的なリスクを並べただけの定型回答になりがちです。solidity-security はエージェントにより狭く明確なセキュリティ視点を与えるため、exploit path、安全なパターン、修正案の具体性にフォーカスしやすくなります。

solidity-securityは初心者にも向いている？

はい、ただし限界はあります。初心者が Solidity の主要な attack surface や安全な実装パターンを学ぶ用途には役立ちます。ただ、これを完全な学習カリキュラムと見なすべきではありません。学習目的なら、各 finding を平易な言葉で説明し、安全な代替実装も示すように依頼すると使いやすくなります。

どんなときにsolidity-securityは不向き？

次の用途には適合度が低めです。

• non-Solidity chains
• front-end wallet security
• tokenomics design review
• governance game theory
• コード文脈なしでの production incident response

こうしたタスクには、より広い blockchain security のプロセスか、別の特化スキルを使うほうが適しています。

1ファイルだけでも見られる？ それともコードベース全体が必要？

1ファイルでもレビューは可能ですが、周辺文脈があるほど結果は良くなります。たとえば vault contract 単体だけでは安全に見えても、token、oracle、access-control、proxy 側に重要な前提が隠れていることがあります。

このスキルは古典的なバグしか扱わない？

いいえ。ただし重心はそこにあります。最も強いのは、既知の Solidity 実装リスクに対するレビューです。逆に、主な懸念が insolvency、oracle manipulation、liquidation design にあるなら、その点を明示して依頼したほうが精度は上がります。

solidity-securityスキルをより良く使う方法

最初にthreat modelを渡す

solidity-security の出力を最も手早く改善する方法は、最初に次を定義して渡すことです。

• attacker capabilities
• trusted roles
• protected assets
• unacceptable outcomes

例:

• “Assume any external user is adversarial, admin key is trusted but fallible, and loss of user deposits is the top-risk outcome.”

これにより、スタイル上の指摘よりも、本当に重要な問題を優先してくれるようになります。

コードだけでなくinvariantsも渡す

強い入力には、次のようなシステム上のルールが含まれます。

• total shares should never exceed claimable assets
• only governance can change fee parameters
• user withdrawals must not depend on untrusted callbacks

invariants を渡すと、このスキルは構文パターンの走査だけでなく、意図した振る舞いに照らしてロジックを検証しやすくなります。

exploit narrativeを求める

よくある失敗は、重要度の裏付けがない finding の羅列です。これを避けるには、次を含めるよう依頼してください。

• entry condition
• attack steps
• expected impact
• realistic な問題か、それとも理論上の話か

こうすることで、solidity-security skill は linter 的に列挙するのではなく、監査者のように理由づけして考えるようになります。

remediation依頼は具体的にする

単に「どう直す？」と聞くだけでは不十分です。次まで指定してください。

• minimal patch
• safer design alternative
• 各修正案の tradeoffs
• patch によって gas costs や UX が変わるか

修正依頼が具体的なほど、一般的なセキュアコーディング論ではなく、そのコードベースで使える提案が返りやすくなります。

パッチ後のコードで再実行する

最初のレビュー後は、修正した関数やコントラクトを貼って次を聞いてください。

• どのリスクが解消されたか
• 何が residual risk として残るか
• 修正で新しい edge case が入っていないか
• 追加すべき tests は何か

導入後の solidity-security install 時間を有効活用するうえでも、この再実行は特に費用対効果の高い使い方です。

注意したい典型的な失敗パターン

このスキルを使っていても、次の点には注意が必要です。

• 推測ベースの脆弱性を大きく言いすぎる
• 継承先コントラクトに隠れた前提を見落とす
• role-management の細部を無視する
• 本質が accounting design なのに、定型的な reentrancy 対策だけで済ませる
• すべての external call を同じ危険度で扱う

これらの誤りは、継承関係の文脈を渡し、各指摘について正確な function path を示すよう求めることで減らせます。

solidity-securityでより深いレビューをするためのプロンプト

2回目以降の強いプロンプト例は次のとおりです。

“Use solidity-security to review only the withdrawal, reward-claim, and admin-setter paths. Ignore gas micro-optimizations. For each issue, cite the function, state variable, attacker capability required, exploit sequence, and the safest realistic remediation for this codebase.”

このプロンプトが有効なのは、レビュー範囲と出力形式を同時に縛れているからです。

testsと手動レビューを組み合わせる

最良のワークフローは、スキル単独ではありません。solidity-security で仮説を出し、その後に次で検証するのが理想です。

• unit tests
• invariant tests
• fuzzing
• manual line-by-line review

この組み合わせは、通常のプロンプトだけ、あるいは静的に読むだけのどちらよりも強力です。

solidity-securityが役立っているかの見極め方

solidity-security guide がうまく機能しているなら、次の改善が見えるはずです。

• 最も危険な関数をより早く特定できる
• exploitability を明確に説明できる
• より良い patch candidate を出せる
• 外部監査人に投げる質問を整理できる
• 汎用プロンプト特有の手探りが減る

2回まわしても出力が曖昧なままなら、原因はインストールではなく、たいていコントラクト文脈の不足です。