evidence-hygiene

証拠の衛生管理 — PoC のキャプチャとマスキングの規律

スクリーンショットの撮影、HAR のエクスポート、バグ報奨金への提出物への証拠の添付を行う前に、このスキルを使用してください。Cookie の漏えい、同意のない PII の共有、トリアージに適さないスクリーンショットなど、証拠の衛生管理でよくあるミスを防ぎます。

基本原則：バグ報奨金の証拠は、トリアージ担当者を納得させるためのものです。それ以上の情報――有効な Cookie、実ユーザーの PII、役に立たない内部トレース ID――を証拠に含めてはいけません。

---

1. 機密データの 2 つのカテゴリ

すべての PoC 成果物（スクリーンショット、HAR、生の HTTP リクエスト、ターミナルの記録）には、異なる扱いが必要なデータが含まれている可能性があります。

カテゴリ	例	対応
自分のアカウントの秘密情報	セッション Cookie、OAuth トークン、リフレッシュトークン、API キー	必ずマスキングしてください。非公開のバグ報奨金プラットフォームへの添付であっても同様です。自分のアカウントとセッションは保護してください。
他のユーザーの PII	実名、メールアドレス、電話番号、住所、プロフィール写真、アカウント ID	アカウント間の影響を明示的に示す場合を除き、マスキングしてください。その場合も、顔を隠し、表示するデータを最小限にしてください。
トリアージ担当者に役立つメタデータ	トレース ID（x-datadog-trace-id）、リクエスト ID、サーバーのタイムスタンプ、自分のテストアカウントの UID／メールアドレス、GraphQL のオペレーション名、レスポンスの構造	表示したままにしてください。これらは、トリアージ担当者がログと照合し、再現するのに役立ちます。
テストアカウントのパスワード（限定的な用途）	テストアカウント用の使い捨てパスワード（例：Testing@5678）	提出後すぐに変更し、表示されている値を無効にするなら、スクリーンショットに含めても問題ありません。実際に使用しているパスワードを証拠に残さないでください。

---

2. Cookie のマスキング手順

2.1 マスキング必須の項目

セッション Cookie の値は、PoC に含まれる秘密情報の中で最も価値が高いものです。以下をマスキングしてください。

• セッション Cookie（authn、session、sid、__Secure-id など。名前は対象によって異なります）
• セッションに紐づいている場合の csrf-token
• Authorization ヘッダー（Bearer トークン、JWT）
• セッション情報を含む Cookie の Cookie リクエストヘッダー値
• セッション情報を含む Cookie の Set-Cookie レスポンスヘッダー値

2.2 表示したままでも安全な項目

• Cloudflare Cookie（__cf_bm、_cfuvid）— セッション情報を含まず、ボット管理用です
• アナリティクス Cookie（ajs_anonymous_id、_ga）
• トレース相関 ID（x-datadog-trace-id、x-request-id）
• サーバー／フレームワークのヘッダー（Server: cloudflare、X-Frame-Options）
• bugcrowd-reporting の Bugcrowdninja エイリアスの節に従った、自分のテストアカウントのメールアドレス／UID

2.3 マスキング方法（実用性の高い順）

方法 A — そもそも Cookie をキャプチャしない（可能な場合に推奨）

• DevTools Console の PoC では、credentials: 'include' を使ってブラウザーに Cookie を自動送信させます。Console の出力に Cookie は表示されません。Console の出力をスクリーンショットに撮り、Network タブの Headers パネルは撮影しないでください。
• Burp Repeater の PoC では、スクリーンショットを撮る前に、リクエスト／レスポンスパネル下部の仕切りを下へドラッグしてリクエスト本文を隠します。Intruder の実行では Results テーブルだけを撮影してください。

方法 B — 画像エディターで黒塗りする（キャプチャに Cookie が含まれてしまう場合）

• macOS：スクリーンショットを Preview で開き、Tools → Annotate → Rectangle の順に選択します。塗りつぶしの色を黒に設定し、Cookie の値の上に四角形をドラッグして保存します。
• Windows：Snip & Sketch の注釈ツール、または任意の画像エディター（Paint.NET など）を使用します。
• Burp 自体：Burp の Proxy → Match and Replace で、スクリーンショットを撮る前に Cookie の値をプレースホルダー文字列に置き換えられます。

方法 C — 生テキストで検索／置換する（HAR ファイル、ターミナルの記録向け）

• jq コマンドについては §4 を参照してください。

2.4 スクリーンショット撮影前のチェックリスト

Capture をクリックする前に：

[ ] Network tab Headers panel is collapsed or out of frame
[ ] Burp's Request panel is hidden behind the divider drag
[ ] No "Copy as cURL" output is visible on screen
[ ] DevTools Application → Storage → Cookies tab is closed
[ ] Browser URL bar doesn't show a session token in query string (rare but possible)

撮影後：

[ ] Open the screenshot at full resolution before saving
[ ] Search for the session cookie name substring in any visible text — if present, redact
[ ] Search for the literal first 6 chars of your cookie value — if present, redact
[ ] Compare to the previous PoC screenshot in the same engagement — same redaction discipline

---

3. PII の黒塗り手順

PoC で他のユーザーのデータを公開せざるを得ない場合（例：攻撃者のセッションでのレスポンスに被害者のメールアドレスを表示して IDOR を実証する場合）は、非公開の添付ファイルであっても、実際の PII をマスキングしてください。

3.1 マスキングする情報（他のユーザーのデータ）

• 名、姓（すべて、または一部）
• メールアドレス（ローカル部をマスキングします。個人を特定できない場合はドメインを残してもかまいません）
• 電話番号（末尾7桁をマスキングします。国番号は任意で残せます）
• 住所（市区町村より下の情報をすべてマスキングします）
• 生年月日（年をマスキングします。月は任意でマスキングできます）
• 公的な身分証明書番号（SSN、パスポート番号など。すべてマスキングします）
• プロフィール写真／顔画像（顔全体を黒塗りします）
• ユーザーが公開プロフィールと照合できるアカウント ID

3.2 表示したままにする情報（ユーザーではなくバグを証明する情報）

• フィールドが返された事実（JSON キー名）
• フィールドの形式／型（"first_name": "<REDACTED>"）
• 自分の（攻撃者セッションの）UID／メールアドレス — アカウント間のアクセスであることを証明します
• エンドポイント URL とリクエストメソッド
• トレース ID

3.3 使用例 — IDOR PoC の本文

悪い例（被害者の個人情報をすべて漏えい）：

{"data":{"contact":{"first_name":"Nadene","last_name":"Afton","email":"[email protected]","phone":"+1-555-867-5309"}}}

良い例（バグを証明しつつ、個人情報をマスキング）：

{"data":{"contact":{"first_name":"<REDACTED — real first name>","last_name":"<REDACTED — real last name>","email":"<REDACTED>@example.com","phone":"<REDACTED>"}}}

スクリーンショットの場合は、各値を四角形の注釈で黒塗りし、スペースがあれば「REAL PII REDACTED」とラベルを付けてください。

3.4 レポート本文での記載

マスキングしたことを明示してください。

## Proof of Concept

The screenshot below demonstrates the IDOR. The attacker session (uid 12345678) successfully retrieves the victim's profile data (uid 99887766). **Real PII fields in the response are masked with black rectangles to limit unauthorized exposure of victim data, per responsible-disclosure hygiene.** The unredacted response is available privately on request.

これにより、報告内容を慎重に扱っていることがトリアージ担当者に伝わり、検証に必要な場合にマスキング前の情報を確認するための明確な手段も提供できます。

---

4. HAR ファイルのサニタイズ

HAR（HTTP Archive）ファイルは、リクエスト／レスポンス本文とヘッダーを含む、ネットワークトラフィックの JSON ダンプです。Cookie、認証トークン、転送中のあらゆる個人情報が含まれます。

4.1 HAR を生成する

Chrome DevTools → Network タブ → リクエスト一覧の任意の場所を右クリック → 「Save all as HAR with content」

4.2 添付する前にサニタイズする

jq を使って機密性の高いヘッダーを削除します。再利用できるように、これをシェル関数またはワンライナーとして保存してください。

sanitize_har() {
  local input="$1"
  local output="${1%.har}.sanitized.har"

  jq '
    .log.entries |= map(
      (.request.headers |= map(
        if .name | ascii_downcase | IN("cookie", "authorization", "x-csrf-token") then .value = "<REDACTED>" else . end
      )) |
      (.response.headers |= map(
        if .name | ascii_downcase | IN("set-cookie") then .value = "<REDACTED>" else . end
      )) |
      (.request.cookies |= map(.value = "<REDACTED>")) |
      (.response.cookies |= map(.value = "<REDACTED>"))
    )
  ' "$input" > "$output"

  echo "Sanitized: $output"
}

使用方法：

sanitize_har /path/to/exported.har
# Output: /path/to/exported.sanitized.har

4.3 添付する前に確認する

# Check that no Cookie or Authorization values are leaking
grep -i 'authn\|"cookie"\|authorization' /path/to/exported.sanitized.har | head -20

出力に実際の Cookie 値が表示される場合、サニタイズで見落としがあります。そのフィールド名に合わせて jq フィルターを修正してください。

4.4 他のユーザーの個人情報を削除する（該当する場合）

HAR にアカウント間のデータ（例：IDOR のデモ中に取得したデータ）が記録されている場合は、被害者の個人情報を含むレスポンス本文のフィールドも削除してください。jq フィルターに次を追加します。

(.response.content.text |= (
  if . then 
    (fromjson? // .) | tostring | gsub("real.first.name.example"; "<REDACTED>")
  else . end
))

取得したデータに合わせて gsub パターンを調整してください。

---

5. Burp Suite のスクリーンショットを安全に扱う

5.1 Repeater（単一リクエストのデモ）

1. Repeater のリクエストパネルでは、Cookie ヘッダーは独立した行にあります。パネルの境界線を下にドラッグし、リクエスト行／ターゲット行より下をすべて隠します
2. または、スクリーンショットを撮る前に Repeater ペインから Cookie ヘッダーのテキストを一時的に削除します（元のキャプチャ済みリクエストには影響しません）。撮影後に戻してください
3. バグを示す JSON／HTML レスポンスが表示された右側のレスポンスパネルのみをキャプチャします

5.2 Intruder の結果テーブル（レート制限／総当たり攻撃のデモ）

結果ウィンドウは、レート制限の調査結果を示す最も有力な証拠です。見やすくキャプチャするには、次の手順に従います。

1. 攻撃が完了したら、結果テーブルとリクエスト／レスポンスパネルの間にある水平の境界線を下にドラッグし、結果テーブルだけが表示されるようにします
2. 次の列だけをスクリーンショットに含めます：Request#、Payload、Status code、Response received、Length
3. リクエスト／レスポンスのサブパネルは含めないでください。Cookie が含まれています

5.3 Proxy の HTTP 履歴（キャプチャのデモ）

スクリーンショットとして適切なことはほとんどありません。Cookie を含むリクエスト／レスポンス全体が表示されるためです。デモには代わりに Repeater を使用してください。

5.4 Scanner の検出結果（該当する場合）

Scanner タブの Issues パネルは、通常、安全にスクリーンショットを撮れます。元のリクエスト本文を表示せずに、検出結果の概要が表示されます。特定の検出結果を開いてからスクリーンショットを撮る場合は、先にその証拠をマスキングしてください。

---

6. Chrome DevTools のコンソール PoC パターン

6.1 クリーンな PoC パターン

fetch('/api/endpoint', {
  method: 'POST',
  headers: {'content-type': 'application/json'},
  credentials: 'include',  // sends cookies automatically — they won't appear in your code
  body: JSON.stringify({ /* your payload */ })
}).then(r => r.json()).then(j => console.log("LABEL:", JSON.stringify(j)))

これがクリーンである理由：

• credentials: 'include' により、ブラウザーは Cookie を送信します。コードから Cookie を参照することはありません。スクリーンショットに Cookie が写ることもありません。
• console.log("LABEL:", ...) によってラベル付きの出力行が表示されるため、スクリーンショット内で検索できます。
• JSON.stringify(j) はレスポンスを 1 行に整形するため、必要な範囲だけを切り抜きやすくなります。

6.2 複数ステップの PoC（呼び出しの間にコンソールをクリア）

4 ステップの PoC（変更前の確認／変更／変更後の確認／元に戻す）の場合は、呼び出しの間にコンソールをクリアし、各スクリーンショットに 1 回の呼び出しと 1 件のレスポンスだけが表示されるようにします。

• Mac：Cmd+K
• Windows / Linux：Ctrl+L

レスポンスが表示されたら、すぐにスクリーンショットを撮影してください。無関係なフレームワークの警告が表示されるまで待たないでください。

6.3 長いレスポンス（スクリーンショット用に要約）

レスポンス本文が長すぎてきれいなスクリーンショットを撮れない場合は、代わりに要約を出力します。

fetch('/api/endpoint', { /* ... */ })
  .then(r => r.json())
  .then(j => {
    console.log("RESPONSE SHAPE:", Object.keys(j.data || {}));
    console.log("CRITICAL FIELD:", j.data?.victim_id, j.data?.email);
    // (Don't dump the full j — your screenshot becomes unreadable)
  })

6.4 貼り付け許可のリマインダー

Chrome は、自己 XSS 対策として DevTools コンソールへの貼り付けをブロックします。各セッションの開始時に、allow pasting（文字列そのもの）を 1 回入力してください。「PoC 実行中」のスクリーンショットを撮る前に入力します。そうしないと、警告文がスクリーンショットに写ります。

---

スクリーンショット撮影順の徹底

7.1 5 ステップの PoC パターン（状態変更に関する脆弱性の報告向け）

「追加認証なしでパスワードを変更できる」のような報告では、標準的な 5 枚のスクリーンショットのパターンは次のとおりです。

1. 変更前の状態確認 — verify_password("current") → true。開始時の状態を把握していたことを証明します。
2. 脆弱性そのもの — 追加認証なしで update_password(...) が成功します。最も重要なスクリーンショットです。
3. 変更後の状態確認（否定） — verify_password("old") → false。変更が反映されたことを証明します。
4. 変更後の状態確認（肯定） — verify_password("new") → true。新しい認証情報が有効であることを証明します。
5. 帯域外の副作用 — 通知メールが届いたかどうかを示す受信トレイのスクリーンショット。受動的な防御策があるかどうかを証明します。

7.2 ファイル名の規則

番号付きで内容がわかる、ハイフン区切りの名前にします。

{finding-#}-step{step-#}-{description}.png

Examples:
04-step1-verify-true-before.png
04-step2-update-password-no-stepup.png
04-step3-verify-false-after.png
04-step4-verify-true-new-pw.png
04-step5-inbox-notification-check.png

レポート本文では、それぞれのファイル名を使って参照します。

- **Screenshot 1 (`04-step1-verify-true-before.png`)** — verify_password returns true with the current password.
- **Screenshot 2 (`04-step2-update-password-no-stepup.png`)** — update_password returns User with no StepUpRequiredError. THIS IS THE BUG.
- **Screenshot 3 (`04-step3-verify-false-after.png`)** — verify_password with old password returns false.
- **Screenshot 4 (`04-step4-verify-true-new-pw.png`)** — verify_password with new password returns true.
- **Screenshot 5 (`04-step5-inbox-notification-check.png`)** — inbox showing whether out-of-band notification was sent.

7.3 撮影のタイミング

• すべてのスクリーンショットは、複数のセッションに分けず、1 回の作業で撮影してください。セッション中に違い（ブラウザーのサイズや Cookie の値など）があると、トリアージ担当者が混乱します。
• 可能であれば、スクリーンショットの撮影中にページを再読み込みしないでください。再読み込みによって Cookie が再生成され、以前に撮影した内容が無効になる場合があります。

---

公開向け出力のサニタイズ（OPSEC）

GitHub の README、ブログ記事、レポート、共有ダッシュボードなど、出力を公開チャンネルに掲載する場合は、必ず次の点に従ってください。

ルール — 絶対に含めないもの：

• 脆弱性の具体的な詳細と企業名／ドメイン名
• 個人名（従業員、ユーザー、研究者）
• 実在する人物のメールアドレス
• 内部 IP アドレス、ホスト名、AD ドメイン
• 生の認証情報（有効期限切れのものも含む）

安全な代替方法：

• 企業名を業種や中立的な対象ラベルに置き換えます。
• 数を範囲で表します。例：11 users ではなく several users
• 契約を特定できる情報を含めず、再利用可能なパターンを説明します。
• 対象を特定しない表を使用します。例：特定の対象名は示さず、| Critical | 8 | MySQL exposed, PHPInfo + exec | とします。

公開前の確認事項：

[ ] Scanned for hardcoded domain names (grep -E '[a-z]+\\.(com|io|app)' *.md)
[ ] Scanned for email addresses (grep -E '[a-zA-Z.+-]+@[a-zA-Z-]+\\.[a-zA-Z.]+' *.md)
[ ] Scanned for internal IPs (grep -E '10\\.|172\\.1[6-9]\\.|192\\.168\\.' *.md)
[ ] Confirmed no person names in output
[ ] Confirmed vuln descriptions are pattern-based, not target-based

実際に起こり得る結果：

脆弱性の隣に対象名を記載して公開すると、契約に関するデータが漏えいします。 パターンに基づいて説明すれば、対象を明かさずに再利用可能な知見を伝えられます。

---

提出後の衛生管理

バグ報奨金プラットフォームで「Submit」をクリックした後：

8.1 テストアカウントの認証情報を変更する

1. Log out of the target
2. Log back in (this rotates the session cookie — any cookie shown in your screenshots is now dead)
3. Change the password to a fresh value not used elsewhere (any password shown in your screenshots is now dead)

8.2 編集前の成果物を非公開で保存する

編集前の HAR ファイルやスクリーンショットは、自分だけがアクセスできるローカルフォルダーに保管してください。検証の際に、トリアージ担当者から編集前のバージョンを求められることがあります。編集前の成果物をメールで共有しないでください。既存の提出スレッドで、プラットフォームの非公開添付機能を使用してください。

8.3 発見内容を公に投稿しない

ほとんどのプラットフォームでは、未解決の問題と解決済みの問題のどちらも機密情報として扱われます。プログラムから明示的に許可されるまでは、発見内容についてツイートしたり、ブログに書いたり、フォーラムで話題にしたりしないでください。

8.4 ローカルの成果物を監査する

四半期ごとに、~/security-research/ と ~/Downloads/ を確認し、古い取り組みの不要な HAR ファイルやスクリーンショットを探してください。適切に暗号化されたアーカイブに移動するか、削除してください。バグ報奨金プログラムでの取り組みに関する成果物は機密情報です。すぐに蓄積し、責任を招くことになります。

---

注意点

• スクリーンショットに Cookie を写す — 証拠の取り扱いで最もよくあるミスです。Network タブの Headers パネルを必ず折りたたみ、Burp の Request パネルを非表示にし、「Copy as cURL」の出力は絶対にスクリーンショットに撮らないでください。
• 被害者の PII をマスキングしない — 実名、メールアドレス、電話番号が表示される IDOR の PoC は、責任ある情報開示に反します。非公開のプラットフォーム添付ファイルであっても、他のユーザーの PII はすべて黒塗りしてください。
• 有効な Cookie が含まれる HAR ファイル — HAR をエクスポートすると、jq でサニタイズしない限り、Cookie の値がすべて含まれます。添付する前に、必ず sanitize_har 関数を実行してください。
• Console.log で Cookie を出力する — DevTools Console の PoC では、credentials: 'include' を使用し、fetch の呼び出しに Cookie の値を直接記述しないでください。
• 「allow pasting」を忘れる — Chrome では、デフォルトで Console への貼り付けがブロックされます。スクリーンショットに警告文が写らないよう、PoC を実行する前に allow pasting と入力してください。
• 各手順の間に Console をクリアしない — Console の出力が重複する複数手順の PoC は、トリアージ担当者を混乱させます。呼び出しごとに Console をクリアしてください（Cmd+K / Ctrl+L）。
• Proxy の HTTP history をスクリーンショットに撮る — Cookie を含むリクエストとレスポンス全体が表示されます。代わりに Repeater を使用し、リクエストパネルを非表示にしてください。
• 提出後に Cookie をローテーションしない — 提出したスクリーンショットに表示された Cookie は、ログアウトしてログインし直し、ローテーションして初めて無効になります。提出後すぐにローテーションしてください。
• スクリーンショットの寸法が揃っていない — PoC の手順ごとにブラウザーのサイズが異なると、雑に見えます。ウィンドウサイズを揃えて、すべてのスクリーンショットを一度に撮影してください。
• マスキング前のオリジナルを保存しない — トリアージ担当者からマスキング前のバージョンを求められることがあります。オリジナルはローカルの暗号化フォルダーに保管し、メールでは共有しないでください。
• 実際のドメインを含む公開コンテンツ — 実際のドメインと脆弱性の詳細を記載した README、ブログ、レポートは、クライアントの情報を漏えいさせます。業種ラベルとパターンに基づく説明を使用してください。
• 古い成果物の蓄積 — 古い取り組みの HAR ファイルやスクリーンショットが溜まります。四半期ごとに監査し、古い証拠ファイルをアーカイブするか削除してください。

---

9. 他のスキルとの併用

この質問／タスクの場合	使用するスキル
「この発見を報告すべきですか？」	triage-validation
「レポート本文のテンプレートはどれですか？」	report-writing
「Bugcrowd の VRT／重大度／OOS への反論はどうすればよいですか？」	bugcrowd-reporting
「この証拠をどうマスキング／サニタイズすればよいですか？」	このスキル（evidence-hygiene）
「バグが実際に発生することをどう実証すればよいですか？」	security-arsenal
「このアセット種別向けの偵察プローブはどこにありますか？」	offensive-osint

---

検証

次のセルフテストを実行して、証拠の取り扱いに関する準備ができていることを確認してください。

1. HAR サニタイザーの構文 — jq フィルターの構文が正しいことを確認します。

   echo '{"log":{"entries":[{"request":{"headers":[{"name":"Cookie","value":"secret=abc123"}],"cookies":[{"value":"abc123"}]}}]}}' | jq '.log.entries |= map((.request.headers |= map(if .name | ascii_downcase | IN("cookie","authorization") then .value = "<REDACTED>" else . end)) | (.request.cookies |= map(.value = "<REDACTED>")))' >/dev/null 2>&1 && echo "PASS: jq filter valid" || echo "FAIL"
   

2. Cookie のマスキングチェックリスト — スクリーンショット撮影前のチェックリストがあることを確認します。

   grep -q "Pre-screenshot checklist" SKILL.md && echo "PASS" || echo "FAIL"
   grep -q "Network tab Headers panel is collapsed" SKILL.md && echo "PASS" || echo "FAIL"
   

3. PII の黒塗り手順 — PII のマスキング手順が文書化されていることを確認します。

   grep -q "PII Black-Bar" SKILL.md && echo "PASS" || echo "FAIL"
   grep -q "real names, emails, phone numbers" SKILL.md && echo "PASS" || echo "FAIL"
   

4. Console の PoC パターン — 適切な fetch パターンがあることを確認します。

   grep -q "credentials: .include." SKILL.md && echo "PASS: credentials:include pattern" || echo "FAIL"
   grep -q "allow pasting" SKILL.md && echo "PASS: allow-pasting reminder" || echo "FAIL"
   

5. 提出後の衛生管理 — ローテーション手順を確認します。

   grep -q "Rotate the test account credentials" SKILL.md && echo "PASS" || echo "FAIL"
   

5 つのテストすべてで、重要な証拠取り扱い対策が整っていることを確認します。

---

使用上の注意

このスキルは、提出内容を準備する際に report-writing と（Bugcrowd の場合は）bugcrowd-reporting と併せて読み込むことを想定しています。次の内容は対象外です。

• 何を記録するか（それは triage-validation と report-writing の役割です。レポートを受理してもらうために必要な証拠を示します）
• 悪用をどのように実証するか（それは security-arsenal の役割です。送信するペイロードを扱います）
• アセットをどこで見つけるか（それは offensive-osint の役割です。偵察を扱います）

このスキルが扱うのは、「証拠が手元にある」状態から「プラットフォームに添付する」までの、墨消し／サニタイズ／衛生管理のレイヤーのみです。

---

関連スキルと連携フロー

• report-writing — 証拠の墨消しが済み、レポート本文に使用できる状態になったときに使います。ワークフローの基本：墨消しがスクリーンショット撮影前のチェックリストを通過したら、report-writing に引き継ぎ、プラットフォーム固有のレポートテンプレート（H1／Bugcrowd／Intigriti／Immunefi）を作成します。
• bugcrowd-reporting — 墨消し済みの証拠を特に Bugcrowd に提出する場合に使います。ワークフローの基本：墨消し済みのスクリーンショットとサニタイズ済みの HAR が、bugcrowd-reporting の VRT に対応付けられた提出本文で参照する添付ファイルになります。
• triage-validation — そもそもどの証拠が必要かを判断するときに使います。ワークフローの基本：triage-validation が「ステップアップ認証なしのパスワード変更について、5 枚のスクリーンショットによる PoC が必要」と示したら、このスキルが「その 5 枚のスクリーンショットを適切に記録し、墨消しする方法」を示します。
• security-arsenal — 証拠を生成したペイロードを文書化するときに使います。ワークフローの基本：ペイロード（security-arsenal から取得）はそのままレポートに記載し、出力／レスポンス（このスキルで処理）はスクリーンショットを撮る前に Cookie／PII を墨消しします。
• bb-methodology — フェーズ 5（検証とレポート）で証拠の記録が必要なときに使います。ワークフローの基本：レポートの作成前に、フェーズ 5 の証拠記録ステップでこのスキルを利用します。