Claude Media
Claude Codeの42CrunchプラグインでOpenAPIの監査と修正を回す
Claude CodeClaude連携チュートリアル

Claude Codeの42CrunchプラグインでOpenAPIの監査と修正を回す

42Crunchプラグインは、OpenAPI仕様の監査、BOLA/BFLAのライブスキャン、同意つきの修正を1つのループで回します。導入、スキルの使い分け、認証情報、つまずきを扱います。

読了目安 約12分

42Crunchプラグイン(42crunch-api-security-testing)は、OpenAPI仕様のセキュリティ監査と修正をClaude Codeの中で回すためのプラグインです。監査、ライブスキャン、修正、再検証の順にループを組み、OWASP API Securityのリスク(BOLA/BFLAを含む)に沿った指摘を返します。

この記事では、5つのスキルの役割、導入と認証情報の置き場所、監査結果の読み方、修正の同意ゲート、ライブスキャンの前提、つまずきやすい点を順に扱います。

5つのスキルが「監査→スキャン→修正→再検証」を分担する

プラグインを入れると、次の5つのスキルが使えるようになります。スラッシュコマンドでも呼べますし、「42crunchの監査を回して」のような自然文でも起動します。

スキル役割
/42crunch-setup役割42c-ast バイナリの導入と認証情報の設定(初回のみ)
/42crunch-audit役割OpenAPI仕様の静的監査。スコアつきの指摘とAI修正
/42crunch-scan役割稼働中のAPIに対する適合性・認可スキャン(BOLA/BFLA)
/42crunch-api-security-testing役割監査とスキャンを1セッションで通す
/generate-oas役割ソースコードやPostman/Insomniaのコレクションから openapi.json を生成

名前の割に、中身は2段構えです。静的な監査はOpenAPIファイルだけで動き、ライブスキャンは起動済みのAPIサーバーを必要とします。仕様書の段階で潰せる問題と、実際に動かして初めて分かる認可の穴を、別のスキルとして分けています。

導入から最初の監査まで

マーケットプレイスの追加とプラグインの導入は、Claude Code CLIから行います。READMEは、マーケットプレイスの追加とプラグインの導入にCLIが必要だと明記しています。

claude plugin marketplace add https://github.com/42Crunch-AI/claude-plugins
claude plugin install 42crunch-api-security-testing@42crunch-marketplace

セッションの中なら、/plugin marketplace add と /plugin install に同じ引数を渡します。VS Code拡張では /plugin でプラグインマネージャーを開き、MarketplacesタブにリポジトリURLを貼って追加します。インストール先のスコープ(User・Project・Local)は導入時に選びます。スコープの違いはプラグインとマーケットプレイスの解説にまとめています。

導入後の流れはREADMEのクイックスタートに沿うと次の5手です。

手順

導入から最初の修正までの流れ

  1. 1

    環境を整える

    「set up 42crunch」と伝えます。42c-ast の取得と認証情報の設定が走ります。

  2. 2

    監査を回す

    「run a 42Crunch audit」と伝えます。OpenAPIファイルが無ければ、ソースコードからの生成を提案されます。

  3. 3

    指摘を読む

    重大度ごとに整理された指摘が出ます。この時点ではまだ何も書き換わりません。

  4. 4

    修正に同意する

    変更を加える前に必ず同意を求められます。同意すると修正して再監査します。

  5. 5

    ライブスキャンを回す

    「run a conformance scan」と伝えると、起動中のサーバーに対する検査に進みます。

認証情報は3つの方式から選ぶ

42Crunchのアカウントは必須です。READMEが挙げる選択肢は次のとおりです。

  • Starter(無料トライアル)
  • トークン方式の有料プラン(IndividualとIndividual Pro)
  • APIキーを使うPlatformアカウント(Team 10、Team 25、Enterprise)

/42crunch-setup はこの方式の違いに合わせて設定を進めます。認証情報は、macOS/Linuxなら ~/.42crunch/conf/env、Windowsなら %APPDATA%\42Crunch\conf\env に保存されます。macOS/Linuxでは権限が 600 になります。

変数内容方式
API_KEY内容Platformトークン(api_* または ide_*)方式Platform
PLATFORM_HOST内容プラットフォームのベースURL方式Platform
TRIAL_TOKEN内容Starter・Individual・Individual Proのアクセストークン(Base64)方式Token
SCAN42C_HOST内容スキャン対象URLの上書き方式両方

TRIAL_TOKEN は名前に「トライアル」と付いていますが、有料のトークンプランにも使います。READMEによると、後方互換のために変数名を残してあるためです。ファイルはスキルの実行中に手で編集しない、とも書かれています。入力した資格情報は、あとから平文で表示されません。

監査の結果は4つの層に分かれる

/42crunch-audit は、OpenAPI仕様に0〜100のセキュリティスコアをつけます。指摘は重要度の高い順に4層に分類されます。

分類

指摘の4層

  • SQG-Blocking

    Security Quality Gateを通すために必ず直す項目です。

  • Security

    修正が推奨される項目です。

  • Data Validation

    情報として表示される項目です。

  • Spec Conformance

    OAS形式の不備で、スコアやSQGの対象外です。

注意したいのは、合否の基準が方式で変わる点です。Platform方式では、プラットフォームのポリシーに設定されたSQGのしきい値が適用されます。トークン方式には自動のSQGゲートがなく、セッションごとに目標スコアと、ブロック扱いにする重大度を自分で決めます。

つまり、同じ仕様書でも「通った」の意味が方式によって違います。チームで基準をそろえたいなら、Platform方式のポリシーに寄せるのが素直です。トークン方式で使うなら、目標スコアを CLAUDE.md に書いておくとセッションをまたいでぶれません(書き方は後述)。

修正は同意ゲートを通ってから適用される

このプラグインの設計で特徴的なのは、書き換えの前に毎回同意を取る点です。監査が終わると指摘の一覧が出て、そのあとの同意ゲートで、どの修正を適用するかを選びます。修正後は再監査して、SQGを通ったかを確認します。

RECIPES.mdは、よくある使い方を言い回しつきで7つ挙げています。うち、修正の進め方に関わる3つを抜き出します。

やりたいこと伝える内容の例起きること
結果だけ見たい伝える内容の例「Audit my API and show me the findings, but don't apply any fixes」起きること指摘を表示し、修正は適用しない
前回の報告書から直したい伝える内容の例「Fix the audit issues in report.json for openapi.json」起きること監査を飛ばし、既存の報告書を読んで修正に進む
監査とスキャンを通したい伝える内容の例「Run audit and scan」起きること監査のあと、スキャン用の許可確認を挟んで通しで実行

報告書から直すレシピでは、42c-ast audit run が出したJSON、または42Crunchの拡張機能の監査結果をJSONで書き出したものを渡せます。この場合は監査をやり直さないので、最終サマリーにスコアの増減は出ません。直したあとにSQGを通ったか確かめたいときは、改めて監査を回します。

レビュー前の下見にも向いています。チームで指摘を見てから直すかどうかを決めるなら、「修正はまだ適用しない」と最初に伝えておけば、同意ゲートでレビューのみとして扱われます。

OpenAPIがまだ無いときは generate-oas から始める

仕様書がないプロジェクトでは、/generate-oas で openapi.json を作れます。入力の組み合わせは4通りです。

  • コードベースだけ: ルート、パラメーター、リクエスト/レスポンスのスキーマ、認証ミドルウェア、データモデル、サーバー設定を読み取る
  • Postmanコレクションだけ: v2.0/v2.1のコレクション(環境ファイルは任意)から、パス、メソッド、ヘッダー、認証方式を取り出し、{{variableName}} の変数を解決する
  • Insomniaコレクションだけ: v4(JSON)またはv5(JSONかYAML)のエクスポートが対象。サンプルのレスポンスが含まれないため、レスポンスの形は暫定になる
  • コードベースとコレクションの併用: コードベースを構造の基準にし、コレクションの実例の値で補強する。コードから漏れたエンドポイントの発見にも使う

READMEが対応フレームワークとして挙げるのは、Express、Fastify、NestJS、FastAPI、Flask、Django、Spring Boot、Gin、Rails、ASP.NET Coreなどです。スキーマは components/schemas に集約され、書き出す前にセルフレビューが入ります。

生成の直後に監査まで続けるなら、「Generate an OpenAPI spec from my code and then audit it」のように一続きで頼むのがRECIPES.mdの6番目のレシピです。生成した仕様は監査で最初の点数がつくので、まず現状を知る使い方になります。

ライブスキャンは稼働中のAPIが前提になる

/42crunch-scan は、静的な監査では見えない認可の穴を、実際にリクエストを送って調べます。検出するのはBOLA(オブジェクトレベルの認可不備)とBFLA(機能レベルの認可不備)、それに適合性(仕様と実際の挙動のずれ)です。結果は3層で出ます。

  • 認可の失敗: BOLA/BFLAが確認されたもの
  • SQG-Blockingの適合性違反: 必ず直す項目
  • 参考としての適合性違反: レビュー用に表示

実行前の確認がいくつか挟まります。対象URLを確認し、到達できるかを調べ、操作・認証方式・BOLAの候補をOpenAPIから分析して、スキャンの内容をプレビューします。その後、まず正常系の検証実行を行い、本格的なファジングスキャンの前にもう一度同意を求めます。

対象URLはOpenAPIの servers[0] から取るのが既定です。ステージング環境などへ向けたいときは、環境変数 SCAN42C_HOST で上書きします。

export SCAN42C_HOST=https://staging.example.com
claude

上のURLは例です。サーバーが起動していないと、スキャンの段階で止まります。通しで回すRecipe 4でも、第2フェーズの前に到達確認が入ります。

修正の同意はここでも別に取られます。OpenAPI側の契約の更新と、サーバー側のコード変更が、それぞれ同意の対象です。トークン方式ではSQGの自動判定がないため、全指摘が参考情報として並び、何を直すかは自分で決めます。

既存のlintとはどう使い分けるか

OpenAPIの検査には、ルールセットを自分で書くリンタという選択肢もあります。SpectralでOpenAPIをlintする設定は、編集のたびにhookで検証させる構成です。42Crunchのプラグインは、指摘がOWASP API Securityの観点で分類され、0〜100のスコアとSQGで合否が決まる点が違います。

観点Spectralのlint42Crunchプラグイン
ルールの出どころSpectralのlint自分たちで書く42Crunchプラグイン42Crunch側の監査
結果の形Spectralのlintルールごとの警告・エラー42CrunchプラグインスコアとSQG、4層の分類
実行中のAPIの検査Spectralのlintなし42Crunchプラグイン/42crunch-scan で可能
必要なものSpectralのlint手元のlintツール42Crunchプラグイン42Crunchアカウントと 42c-ast

両者は競合するというより、層が違います。命名や書式の社内規約はSpectralのルールに、セキュリティの評価は42Crunchに任せる、という分担が考えられます。両方をCIに載せるかどうかは、各ツールの運用に合わせて決める話です。

セキュリティ系プラグインの審査という視点では、スキル・プラグインのセキュリティスキャンの記事も参考になります。このプラグインも、スキルに加えて外部のバイナリ(42c-ast)を取得して使うため、導入前に提供元と中身を見る対象になります。

CLAUDE.mdに目標を書いて、セッションをまたいで保つ

トークン方式では基準がセッションごとの口頭の約束になるため、プロジェクトの CLAUDE.md に残しておくと再現しやすくなります。次は書き方の一例です(スコアの値は例で、プラグインの既定ではありません)。

## API セキュリティ
- OpenAPI は `openapi.json` が正。変更したら 42Crunch の監査を回す
- 目標スコアは 90 以上、SQG-Blocking は 0 件にする
- 修正は指摘を見せてから適用する。仕様書以外のコードは勝手に変えない
- ライブスキャンの対象は `SCAN42C_HOST` で指す検証環境だけにする

プロジェクトスコープでプラグインを入れると、有効化の設定は .claude/settings.json に入り、コミットすればメンバーにも伝わります。ただしダウンロードまでは共有されないため、各メンバーが一度 claude plugin install 42crunch-api-security-testing@42crunch-marketplace --scope project を実行します。42c-ast の導入と認証情報は、人ごとの手元の作業として残ります。

つまずきやすい点

つまずき

導入後に止まりやすい箇所

  • バイナリが見つからない

    「binary not found」「42crunch not working」と伝えると、/42crunch-setup のトリガーになります。42c-ast は ~/.42crunch/bin/ に置かれ、初回利用時の取得と更新は自動です。

  • スキャンが始まらない

    対象サーバーが起動しているか、servers[0] か SCAN42C_HOST のURLに到達できるかを見ます。到達確認が失敗するとスキャンに進めません。

  • 修正後のスコアが出ない

    既存の報告書から修正した場合は、監査を再実行していないのでスコアの増減がありません。再度の監査で確かめます。

  • TRIAL_TOKENに有料トークンを入れてよいか

    READMEでは、Starter・Individual・Individual Proのトークンをこの変数に入れる設計です。変数名は後方互換のために残されています。

まとめ

42Crunchプラグインの中心は、監査で仕様書の穴を点数にし、同意を挟んで直し、必要なら稼働中のAPIにスキャンをかける、という一周です。仕様書がなければ /generate-oas から入れます。

最初の一歩としては、手元のOpenAPIに対して「修正はまだ適用しない」と伝えて監査を回し、スコアと指摘の層を眺めるところが軽いでしょう。ライブスキャンは、その仕様書がある程度きれいになってから、検証環境に向けて回す順序になります。

この記事を共有:XはてブLinkedIn

関連する記事

Claude Code をもっと見る →