security-bounty-hunter

security-bounty-hunter の概要

security-bounty-hunter は、実際のリポジトリからバウンティ対象になり得る脆弱性を見つけることに特化した skill です。特に、リモートから到達可能で、ユーザー操作で引き起こせて、トリアージを通りやすい問題を重視します。Security Audit の作業で、単なる「バグを探して」という一般的な指示では足りず、ノイズの多いローカル限定の懸念よりも報告可能な発見を優先するワークフローがほしい人に向いています。

何を見つけるための skill か

security-bounty-hunter skill は、SSRF、認証バイパス、SQL injection、command injection、path traversal、remote deserialization、upload-to-RCE chain、自動発火型の XSS など、実際に悪用可能な経路を優先します。そのため、発見が責任ある開示や bounty 提出に耐えうるかを見極めたいときに役立ちます。

どんな人に向いているか

アプリ、パッケージ、API をレビューしていて、実際にセキュリティ報告として成立しそうかを素早く判断したいなら、この security-bounty-hunter skill を使ってください。特に、研究者、レッドチーム担当者、バグバウンティハンター、そしてコードベースに高インパクトな露出があるか確認したいエンジニアに有用です。

何が違うのか

この skill の主な価値は判断力にあります。技術的には危険でも、実際の提出ではほぼ問題にならないパターンをモデルに無視させるよう設計されています。その結果、到達可能な攻撃経路、悪用可能性、影響範囲に注意が向きます。これらは、通常は bounty が受理されるかを左右する要素です。

security-bounty-hunter skill の使い方

インストールして有効化する

skill manager で security-bounty-hunter の install コマンドを使い、評価したいリポジトリを指定します。重要なのは、タスクを広いコードレビューではなく、bounty の観点を持った Security Audit として明確に伝えることです。

適切な入力を与える

まず、具体的な対象、スコープ、目的を示してください。強いプロンプトの例は、次のようなものです。「この Node API を、バウンティ対象になり得るリモート到達可能なバグがあるか監査してください。認証バイパス、インジェクション、ファイルアクセス、SSRF を優先し、スタイルの問題やインパクトの小さいローカル限定の発見は無視してください。」こうした入力があると、skill は bounty レビュー担当者と同じような取捨選択をしやすくなります。

先に読むべきファイル

まず SKILL.md を読み、次に README.md、AGENTS.md、metadata.json、そして存在するなら rules/、resources/、references/、scripts/ フォルダを確認してください。このリポジトリでは主要なソースは SKILL.md で、追加のサポートフォルダはありません。そのため、実用的なガイダンスの大半は skill 本体にまとまっています。

早く絞り込むワークフローで使う

security-bounty-hunter の使い方として良い流れは、アプリの表面を把握し、信頼境界を見つけ、ユーザー入力がどの機密操作につながるかを追跡し、権限なしでその経路に到達できるかを検証することです。出力には明示的に「bounty-worthy かどうか」を問うと、理論上の弱点だけでなく、悪用可能性、露出度、提出価値まで踏まえて評価されやすくなります。

security-bounty-hunter skill の FAQ

security-bounty-hunter は上級監査担当者向けだけか

いいえ。対象スタックを理解しているか、リポジトリを明確に説明できるなら、初心者にも使いやすい skill です。具体的なコードベースを与え、抽象的なハードニングの助言ではなく実際の悪用経路に集中させるほど、この skill は力を発揮します。

通常のプロンプトと何が違うのか

通常のプロンプトは、広いチェックリストを返しがちです。security-bounty-hunter skill はそれよりも狭く、リモートから到達可能で、影響が大きく、Security Audit や bug bounty の文脈で受理されやすい発見に分析を寄せます。

どんなときに使うべきではないか

一般的な安全なコーディング指針、コンプライアンスレビュー、全面的なアーキテクチャ評価が欲しいときには使わないでください。また、報告可能な脆弱性を順位付けして探すのではなく、細かな問題まで含めて網羅したい場合にも向きません。

どんなリポジトリでも使えるか

Web アプリ、API、サービス、そして明確なリクエスト処理やデータフローを持つコードベースで最も効果を発揮します。静的コンテンツ、小さなユーティリティ、あるいは監査する現実的な攻撃面がないリポジトリでは、あまり有用ではありません。

security-bounty-hunter skill を改善する方法

スコープと制約をもっと強く伝える

security-bounty-hunter で良い結果を得るには、重要な前提をはっきり指定することが大切です。対象言語、エントリポイント、認証モデル、デプロイ環境、そして何がスコープ内かを明示してください。たとえば、「インターネット向けのエンドポイントだけをレビューし、社内専用の管理ツールは除外する」と書けば、曖昧に「脆弱性を見つけて」と頼むより、はるかに優先順位付けがうまくいきます。

報告向けの出力を求める

Security Audit の結果として実用的なものがほしいなら、証拠、悪用可能性、影響、そしてなぜその問題が bounty-worthy なのかを求めてください。そうすると、skill は CWE ラベルを並べるだけでなく、攻撃経路を説明する方向に寄ります。

リポジトリ名だけでなくコード経路も渡す

すでに怪しいファイル、ハンドラ、ルートが分かっているなら、それもプロンプトに含めてください。たとえば「src/routes/upload.ts と、それが呼び出す先を path traversal や SSRF の観点で確認して」といった指示は、闇雲に探索させるよりずっと強いです。

最初の結果を踏まえて反復する

最初の出力で価値の低い候補を削り込み、そのうえで有望な候補だけを深掘りするよう依頼してください。よくある失敗は、範囲が広すぎるままスキャンしてしまうことです。最も有効な対処は、攻撃クラス、信頼境界、エンドポイント群を一度に 1 つずつ絞っていくことです。