hackerone

HackerOne バグ報奨金

自動化の流れ：スコープの解析 → アセットごとの並列テスト → 確定的な検出結果の検証 → 報告書の提出。

クイックスタート

1. 入力：HackerOne のプログラム URL またはスコープ CSV。
2. スコープとプログラムのガイドラインを解析します。
3. 対象となる各アセットにつきコーディネーターを 1 つ起動します（並列実行）。
4. 各コーディネーターは標準的なエンゲージメントのフローを実行します（skills/coordination/SKILL.md を参照）。
5. アセットごとに validate-findings ワークフローを実行します（確定的な提出ゲート）。検証済みのセットのみから HackerOne の報告書を生成してください。VALID／REPAIRED ではない検出結果は決して提出しないでください。

スコープ CSV の形式

想定される列：

• identifier — アセットの URL／ドメイン。
• asset_type — URL、WILDCARD、API、CIDR。
• eligible_for_submission — true である必要があります。
• max_severity — critical／high／medium／low。
• instruction — アセット固有の注意事項。

skills/hackerone/tools/csv_parser.py で解析します。eligible_for_submission=true でフィルターします。

エージェントの展開

アセットごとにコーディネーターを 1 つ、並列で起動します。

coordinator_role = Read("skills/coordination/SKILL.md")
Agent(prompt=f"{coordinator_role}\n\nTARGET: {asset_url}\nSCOPE: {program_guidelines}\nOUTPUT_DIR: ...",
      run_in_background=True)

アセット 10 件なら、コーディネーター 10 個を並列実行します（順次実行の約 20～40 時間に対し、約 2～4 時間）。各コーディネーターは skills/coordination/SKILL.md と reference/role-matrix.md に従います。

検出結果の検証（確定的な提出ゲート）

すべての検出結果には、poc.py（実行可能なエクスプロイト）、poc_output.txt（タイムスタンプ付きの実行証明）、手動での再現手順、証拠（スクリーンショット／HTTP キャプチャ／動画）が必要です。これらを検証ツールへの入力として使用します。

各アセットのコーディネーターが処理を終えた後、オーケストレーターはそのアセットに対して validate-findings ワークフローを実行し、VALID または REPAIRED と判定された検出結果のみを提出します。

v = Workflow(name="validate-findings", args={
    "output_dir": asset_output_dir,   # the coordinator's OUTPUT_DIR
    "target": asset_url,
    "business_tier": "revenue",       # production/external bug-bounty scope; else "unknown"
    "votes": 3,                       # adversarial refuters per finding (bounty = stricter)
    "repair": True,                   # regenerate broken/absent PoCs so each finding has a runnable evidence script
    "strict": True,                   # one failed gate => REJECTED
})
# v.counts -> {total, valid, repaired, rejected}; v.validated[] / v.rejected[]
# Verdicts at {asset_output_dir}/artifacts/validated/{id}.json (+ false-positives/).
# Asset report at {asset_output_dir}/reports/validation-report.md.

validate-findings が確定的なゲートであるのは、HackerOne で最もよくある却下理由を直接回避できるためです。各 CVE を NVD + ベクターから再計算した CVSS 基本スコア + CISA KEV + ベンダーのアドバイザリと照合し、問題を証明する証拠が出力されるまで各 PoC を実行して修復し、リスク／重大度を再計算し、すべての主張を生の証拠と照合して裏付け、敵対的な反証によって誤検知を排除します。

このワークフローを実行するのはオーケストレーターだけです（トップレベルにあり、ワークフローは 1 つ下のレベルにあるため、ネストは許可されています）。作業の重複を避けるため、コーディネーターは、候補が生成されるたびに実行する検出結果ごとのインターリーブ検証を暫定的な自己チェックとして扱ってもかまいません。提出において確定的な判定となるのは、単独で実行する validate-findings の判定です。REJECTED の検出結果は誤検知であり、提出、付録、件数のいずれにも含めません。その唯一の記録は artifacts/false-positives/{id}.json です。同様に、コーディネーターが破棄した候補（修正されていない DEMOTED、artifacts/dropped/ 内）は決して提出しません。

HackerOne の PoC 契約は、標準的な検出結果の契約（skills/coordination/reference/validator-role.md）を包含する上位の契約です。

提出レポートの形式

検証済みの検出結果のみを使って各レポートを作成します。HackerOne の標準に従い、以下のセクションが必要です。

1. 概要（2～3 文）。
2. 重大度（CVSS + ビジネスへの影響。v4.0 を優先し、v3.1 → v3.0 → v2.0 の順でフォールバック）— 手入力した数値ではなく、validate-findings がベクターから再計算したスコアと割り当てたリスク区分を使用します。
3. 再現手順（番号付きで明確に記載）— 検証済みの verification-script.py に合わせます。
4. 視覚的な証拠（evidence/validation/ 内のもの）。
5. 影響（現実的な攻撃シナリオ）。
6. 修正方法（実行可能な修正策）。

skills/hackerone/tools/report_validator.py でレポートの形式を検証します（検出結果の検証を補完します）。

出力構成

標準の OUTPUT_DIR（skills/coordination/reference/output-discipline.md）に加え、プラットフォームにそのまま提出できる Markdown を格納するアセットごとの reports/submissions/ を使用します。validate-findings は判定結果を artifacts/validated|false-positives/ に、アセットの reports/validation-report.md に検証レポートを書き出します。

{OUTPUT_DIR}/
├── findings/
│   └── finding-NNN/evidence/validation/   # validate-findings proof packages
├── reports/
│   ├── submissions/                        # built ONLY from artifacts/validated/
│   │   ├── H1_CRITICAL_001.md
│   │   └── H1_HIGH_001.md
│   ├── validation-report.md                # validate-findings asset report
│   └── SUBMISSION_GUIDE.md
├── recon/
├── logs/
└── artifacts/
    ├── validated/          # {id}.json — submit these
    └── false-positives/    # {id}.json — never submit these

プログラムの選定

優先度が高いもの： 新しいプログラム（30 日未満）、対応が迅速（24 時間未満）、報奨金が高い、攻撃対象領域が広いものです。避けるべきもの： 対応が遅い（1 週間超）、報奨金が低い、スコープが制限されているものです。

提出チェックリスト

• validate-findings の判定が VALID または REPAIRED（artifacts/validated/{id}.json が存在すること）。REJECTED の検出結果は絶対に提出しないでください。
• CVSS をベクトルから再計算済み（v4.0 を優先し、v3.1 → v3.0 → v2.0 の順にフォールバック）で、CVE が該当する場合は NVD と一致していること（evidence/validation/cve-verification.md）。
• poc_output.txt を含む動作する PoC（バリデーターが再実行または修復し、エビデンストークンを確認済みであること）。
• 手順を追った再現方法。
• 視覚的なエビデンス。
• 現実的な影響（evidence/validation/risk-assessment.md のリスクスコア／区分）。
• 修正方法のガイダンス。
• 機密データをサニタイズ済み。
• アセットが eligible_for_submission=true であること。

よくある却下理由（事前に対処）

却下理由	防止策
スコープ外	eligible_for_submission=true とアセットタイプの一致を確認する
再現できない	validate-findings は PoC を 3 回再実行（および修復）し、脆弱性クラスのエビデンストークンを要求します。ゲートを通過するのは再現可能な検出結果のみです
重複	提出前に公開済みのレポートを検索し、速やかに提出する
影響が不十分	現実的な攻撃シナリオを記録する。validate-findings はリスク／重大度を再計算するため、評価の妥当性を示せます
重大度／CVSS が不正確	validate-findings はベクトルから基本スコアを再計算し、NVD と KEV を照合します。不一致は提出前に警告されます

ツール

• skills/hackerone/tools/csv_parser.py — HackerOne のスコープ CSV を解析します。
• validate-findings ワークフロー — アセットごとの検出結果を権威的に検証します（NVD／CVSS 計算／KEV／エクスプロイト実行／修復／リスク／敵対的評価）。提出ゲートです。アセットごとに 1 回実行してください。
• skills/hackerone/tools/report_validator.py — レポートの形式が完全か（提出に必要な 6 つのセクション）検証します。validate-findings（検出結果を検証）を補完するもので、検証済みの検出結果から作成した各レポートに対して実行してください。
• skills/coordination/SKILL.md — コーディネーターの足場。

使用方法

/hackerone <program_url_or_csv_path>