triage-validation

トリアージと検証

誤った回答が1つでもあれば、その発見事項は終了です。その発見事項は却下し、次のテストクラスに進みます。

このスキルにおける「終了」の範囲： このスキルのゲートが却下するのは、検証に失敗した個々の発見事項です。エンゲージメント自体を終了してよいという意味ではありません。7つの質問のゲートで発見事項を却下するということは、その発見事項を報告しないというだけです。エンゲージメント内の他のテストクラスは、すべて引き続き未実施です。カバレッジ軸のルールについては、redteam-mindset の「一次指令：絶対に終了しない」を参照してください。

「該当なし」は有効性比率を下げます。「参考情報」は中立です。7つの質問すべてに合格したものだけを提出してください。

---

7つの質問のゲート

順番に質問してください。誤った回答が1つでもあれば、直ちに終了します。

---

Q1：攻撃者は今すぐ、手順に沿ってこれを悪用できますか？

次のテンプレートを完成させてください。

1. Setup:   I need [own account / another user's ID / no account]
2. Request: [exact HTTP method, URL, headers, body — copy-paste ready]
3. Result:  I can [read / modify / delete] [exact data shown in response]
4. Impact:  The real-world consequence is [account takeover / PII read / money stolen]
5. Cost:    Time: [X minutes], Capital: [$0 / $X subscription required]

手順2を実際の HTTP リクエストとして書けない場合 → 却下してください。

---

Q2：影響はプログラムの受け入れ対象となる影響リストに含まれていますか？

プログラムのページに移動し、「脆弱性の種類」または「対象外」を確認してください。

一般的な重大度：

• クリティカル：操作なしで任意のユーザーのアカウントを乗っ取れる、RCE、データを持ち出せる SQLi、管理者認証のバイパス
• 高：大量の PII の持ち出し、権限昇格、データを取得できる内部 SSRF、全ユーザーに影響する保存型 XSS
• 中：特定ユーザーの重要度が低いデータに対する IDOR、クリックが必要な機密ページでの XSS
• 低：機密性のない情報漏えい、PoC を伴うクリックジャッキング

バグが対象外として列挙されている項目に該当する場合 → 却下してください。

---

Q3：根本原因は対象範囲内のアセットにありますか？

確認事項：

• 脆弱なドメインが対象範囲内のリストに含まれている（*.internal.target.com ではない）
• 本番環境のアセットである（対象範囲に明示的に含まれている場合を除き、ステージング環境や開発環境ではない）
• 会社が単に利用しているサードパーティサービスではない（Stripe、Salesforce、Google Auth ではない）

対象範囲外の場合 → 却下してください。

---

Q4：攻撃者が現実的に取得できない特権アクセスが必要ですか？

• 「管理者なら X を実行できる」＝権限集中のリスク＝（プログラムの99％では）却下
• 「非管理者が、管理者だけに許されるべき X を実行できる」＝有効
• 「物理アクセス／MFA デバイスが必要」＝通常は無効
• 「悪用には被害者アカウントの侵害が必要」＝疑わしく、よくても重大度は低い

---

Q5：すでに知られている、または仕様上の動作として認められていますか？

次を検索してください：

1. プログラムの HackerOne／Bugcrowd の公開レポート：Ctrl+F でエンドポイント名とバグクラスを検索
2. 対象リポジトリの GitHub イシュー：is:issue label:security ENDPOINT_NAME
3. 変更履歴／CHANGELOG.md — この動作についての記載があるか
4. API ドキュメント／設計ドキュメント — 意図した動作として記載されているか

認識済み／設計上の決定である場合 → 却下してください。

---

Q6：「技術的に可能」であることを超える影響を証明できますか？

• XSS → alert(1) や alert(document.domain) だけでなく、実際の Cookie 窃取またはセッションハイジャックを示す
• SSRF → DNS への ping だけでなく、データを返す内部エンドポイントにアクセスする
• SQLi → エラーメッセージだけでなく、実際のテーブルからデータを持ち出す
• IDOR → HTTP 200 ステータスコードだけでなく、レスポンスに他のユーザーの実データが含まれることを示す

「技術的に可能」であることしか示せない場合 → 却下するのではなく、重大度を引き下げてください。

---

Q7：これは無効と知られているバグクラスですか？

以下の「絶対に提出しない」リストを確認してください。チェーンを伴わずにリストに含まれている場合 → 却下してください。

---

レイヤー順序の落とし穴 — 認証バイパスを主張する前にお読みください

バリデーションエラーが返ったからといって、認証を通過した証拠にはなりません。

これは、認証バイパスの誤検知の中でも、最も確信度が高いものです。証拠が具体的に見えるためです。誤った推論は次のとおりです。

「認証なしでリクエストを送信したところ、400 — field X is required が返ってきました。 バリデーションエラーが返るということは、リクエストは認証を通過してビジネスロジックに到達したということです。 つまり、認証がありません。」

この推論が成り立つのは、認証が入力処理の前に実行される場合に限られます。多くのスタックでは、**グローバルな入力サニタイザー、ボディパーサー、またはスキーマフィルターが認証ミドルウェアの前に配置されています。**その場合、不正な形式のボディは認証が実行される前に拒否され、レスポンスは「認証を通過した後、バリデーションに失敗した」場合と見分けがつきません。

テスト方法：最小限の正しい形式のボディを使って、もう一度送信します。

# malformed body — trips the sanitiser, which runs FIRST
curl -s -X POST https://target/api/v1/resource -d '{'
# 400 {"code":"ERR-INPUT-0001","message":"Invalid text. Only permitted
#      characters are allowed"}                      <- looks like auth bypass

# same endpoint, well-formed empty object — now auth is reached
curl -s -X POST https://target/api/v1/resource -H 'Content-Type: application/json' -d '{}'
# 401 {"code":"ERR-AUTH-0001","message":"Not authenticated. Please log in."}

認証レイヤーの位置を示すのは、2回目のレスポンスだけです。

**認可されたエンゲージメントからの教訓。**本番 API では、テストしたエンドポイントの大半で、不正な形式のボディに対してバリデーションエラーのような 400 が返されました。これを認証バイパスと判断した場合、金融・管理業務を担う本番インフラに対する Critical として報告されるところでした。実際は、認証が実行される前に { 文字に反応したサニタイザーによるもので、正しい形式の {} を送ると、そのすべてのエンドポイントが 401 を返しました。再テストした人がいたおかげで、誤った Critical の報告を回避できました。

ルール：

• レイヤーの順序は、単一のレスポンスからは確認できません。決して推測しないでください。
• 不正な形式のボディではなく、パーサーが受け付ける最も簡単な正しい形式のボディで認証を調べてください。
• エラーメッセージが入力形式または文字種について述べている場合、応答しているのはビジネスロジックではなく、パーサーまたはサニタイザーです。
• エラーメッセージがドメインフィールド（accountId is required）に言及しており、正しい形式のボディでも同じメッセージが返る場合は、実際の兆候です。Q6 に進んでください。
• WAF と CDN のレイヤーにも同様に当てはまります。エッジでのブロックは、オリジンからのレスポンスではありません。

---

4つの提出前ゲート

順番に実行してください。4つすべてが PASS である必要があります。

ゲート 0：現実確認（30秒）

[ ] Bug is REAL — confirmed with actual HTTP requests, not code reading alone
[ ] Bug is IN SCOPE — checked program scope page explicitly
[ ] Reproducible from scratch — can reproduce starting from fresh session
[ ] Evidence ready — screenshot, response body, or video

ゲート 1：影響の検証（2分）

[ ] Can answer: "What can attacker DO that they couldn't before?"
[ ] Answer is more than "see non-sensitive data" (unless program pays for info disclosure)
[ ] Real victim: another user's data, company's data, financial loss
[ ] Not relying on victim doing something unlikely

ゲート 2：重複チェック（5分）

[ ] Searched HackerOne Hacktivity for this program + similar bug title/endpoint
[ ] Searched GitHub issues for target repo
[ ] Read most recent 5 disclosed reports for this program
[ ] Not a "known issue" in their changelog or public docs
[ ] Google: "TARGET_NAME ENDPOINT_NAME bug bounty"

ゲート 3：レポート品質（10分）

[ ] Title: [Bug Class] in [Endpoint] allows [actor] to [impact]
[ ] Steps to Reproduce: copy-pasteable HTTP request
[ ] Evidence: screenshot/video of actual impact (not just 200 status)
[ ] Severity: matches CVSS 3.1 score AND program's severity definitions
[ ] Remediation: 1-2 sentences of concrete fix
[ ] NEVER used "could potentially" or "may allow"

---

絶対に提出してはいけないリスト

これらを提出すると、有効性の比率が損なわれます。

Missing CSP / HSTS / security headers
Missing SPF / DKIM / DMARC
GraphQL introspection alone (no auth bypass, no IDOR demonstrated)
Banner / version disclosure without working CVE exploit
Clickjacking on non-sensitive pages (no sensitive action PoC)
Tabnabbing
CSV injection (no actual code execution shown)
CORS wildcard (*) without credential exfil proof of concept
Logout CSRF
Self-XSS (only exploits own account)
Open redirect alone (no ATO or OAuth theft chain)
OAuth client_secret in mobile app (known, expected)
SSRF DNS callback only (no internal service access or data)
Host header injection alone (no password reset poisoning PoC)
Rate limit on non-critical forms (search, contact, login with Cloudflare)
Session not invalidated on logout
Concurrent sessions
Internal IP in error message
Mixed content
SSL weak ciphers
Missing HttpOnly / Secure cookie flags alone
Broken external links
Autocomplete on password fields
Pre-account takeover (usually — very specific conditions required)

---

条件付きで有効 — チェーンが必須

まずチェーンを構築し、エンドツーエンドで動作することを証明してから、報告してください。

単独の発見事項	必須のチェーン	有効な結果
オープンリダイレクト	+ OAuth の redirect_uri → 認証コードの窃取	ATO（Critical）
クリックジャッキング	+ 機密性の高い操作 + 動作する PoC	Medium
CORS ワイルドカード	+ 認証情報付きリクエストによるユーザー PII の持ち出し	High
CSRF	+ 機密性の高い操作（資金の送金、メールアドレスの変更、アカウントの削除）	High
レート制限のバイパス	+ OTP／リセットトークンの総当たり攻撃の成功	Medium/High
DNS のみの SSRF	+ 内部サービスへのアクセス + データの取得	Medium
Host ヘッダーインジェクション	+ 注入したホストを使ったパスワードリセットメールの送信	High
プロンプトインジェクション	+ 他のユーザーのデータの読み取り（IDOR）	High
S3 バケットの一覧表示	+ JS バンドルに含まれる API キーまたは OAuth シークレット	Medium/High
セルフ XSS	+ 被害者に気づかれないまま発生させる CSRF	Medium
サブドメイン乗っ取り	+ そのサブドメインに登録された OAuth redirect_uri	Critical
GraphQL イントロスペクション	+ 認証バイパスのミューテーション、または node() の IDOR	High

---

CVSS 3.1 クイックリファレンス

CVSS スコアの例

発見内容	スコア	深刻度	ベクトル
IDOR による PII の読み取り。任意のユーザーが対象で、認証が必要	6.5	中	AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
IDOR による書き込み／削除。任意のユーザーが対象	7.5	高	AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N
認証のバイパス → 管理パネル	9.8	重大	AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
保存型 XSS → Cookie の窃取、保存型	8.5	高	AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:L/A:N
SQLi → データベース全体のダンプ	9.1	重大	AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N
SSRF → クラウドメタデータ	9.1	重大	AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:N
競合状態 → 二重支払い	7.5	高	AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:N
GraphQL の認証バイパス	8.1	高	AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N
JWT の none アルゴリズム	9.1	重大	AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

保存型 XSS の UI は判断が分かれる項目です。 ページ表示時に発火する保存型 XSS は、長年にわたり CVSS の判断が難しい領域です。NVD／FIRST では UI:R と採点されることが多く、その場合、上記の保存型 XSS のスコアは約 7.6 に下がります。上記の UI:N は「通常のページ利用以外に追加の操作が不要」という状況を想定しています。トリアージ担当者が UI:R を想定している場合は、その判断を説明するか、レポートに数値を転記する前に再採点してください。

指標のクイックガイド

該当する状況	指標	値
インターネット経由で悪用可能	AV	ネットワーク（N）
特別なタイミングや競合状態が不要	AC	低（L）
無料アカウントが必要	PR	低（L）
ログイン不要	PR	なし（N）
管理者権限が必要	PR	高（H）
被害者の操作が不要	UI	なし（N）
被害者がクリックする必要がある	UI	必須（R）
すべてのデータを読み取る	C	高（H）
一部のデータを読み取る	C	低（L）
すべてのデータを変更する	I	高（H）
サービスをクラッシュさせる	A	高（H）
影響がアプリ内に限られる	S	変更なし（U）
ブラウザー／OS／クラウドに影響する	S	変更あり（C）

---

迅速に切り捨てるためのルール

目的は、見込みのないものをすばやく除外し、実際のバグを探すことです。

1. 5 分ルール：5 分以内に Q1 のテンプレートを埋められない場合は、次に進みます
2. 前提条件の数：同時に必要な前提条件が 2 つを超える場合は、切り捨てます
3. 影響のテスト：「攻撃者は何を手に入れるのか？」—具体的なものが何もない場合は、切り捨てます
4. 管理者によるバイパス：「管理者は X を実行できる」は、絶対にバグではありません — すぐに切り捨てます
5. 設計ドキュメントのテスト：文書化された動作であれば、すぐに切り捨てます
6. 泥沼の兆候：Q6 に 30 分以上取り組んでも再現可能な PoC がない場合は、切り捨てます

---

重大度判定ゲート

メモやレポートのどこかで、指摘事項を致命的または高と判定する前に、以下の各項目への回答を一行で書き出してください。具体的に答えられない場合、重大度の判定が誤っています。

1. 攻撃者が実際に到達できる影響まで、チェーン全体を検証しましたか。それとも途中のプリミティブを1つ確認しただけですか。 — 「レイヤーNでプリミティブを確認」≠悪用可能です。複数段階のチェーンでは、チェーンの最上位の重大度に見合う判定をする前に、すべての段階を検証する必要があります。
2. 攻撃者が最終的に何を得るのか、具体的な一文で説明できますか。 — 「SPフロントエンドのウェブサーバーでRCE」は具体的です。「RCEにつながる可能性がある」は具体的ではなく、最大でも高、場合によっては中です。
3. チェーン全体を、最初から最後まで自分で少なくとも2回再現しましたか。 — 2回とは、1回は調査中、もう1回はレポート用のスクリーンショット／PoCのためです。「うまくいくはずだと思う」ではいけません。
4. 継承に関するゲート、署名チェック、対象者チェック、その他チェーンを阻む検証ステップが残っていますか。 — はいの場合、チェーンは致命的ではありません。ゲートを回避するまでは、重大度を下げて「プリミティブが存在」として記録してください。
5. このプログラムで、過去にこの重大度クラスが却下されたことはありますか。 — 多くのプログラムでは、データの種類にかかわらず、「具体的な影響を伴わない情報開示」の上限を低／情報に設定しています。プログラムのスコープを確認してください。

認可されたエンゲージメントからの教訓： JWT の alg:none は当初、対象者検証レイヤーで署名バイパスのプリミティブが確認されたことを根拠に、致命的と判定されました。その後のテストで、発行者の信頼チェックが未署名トークンを引き続き拒否することが判明し、ATOチェーン全体は完了しませんでした。指摘事項は撤回せざるを得ませんでした。最初のドラフトで重大度判定ゲートを実施していれば、Q1によって提出前に致命的という判定を取り下げられたはずです。

---

報奨金を失うアンチパターン

Writing a report before confirming the bug exists (most common)
Submitting theoretical impact without proof
"The API returns more fields than necessary" (sensitivity matters — is it actually sensitive?)
Chaining A+B into one report when they're separate bugs (two separate payouts)
Reporting B saying "similar to A in my other report" — fresh Gate 0 for every bug
Overclaiming severity — triagers trust you less next time
Under-describing impact — triager doesn't understand why it matters

---

撤回の規律

以前に報告した指摘事項が再現できなかった場合、決して黙って削除しないでください。 レポートの付録に撤回を記録してください。これにより、トリアージ担当者に自分の作業を検証していることを示せます。また、すでに否定した誤った報告を担当者が追いかけずに済みます。

撤回記録のテンプレート：

### Retracted: <finding name>

- **Original signal:** <one-line description of what looked like a bug>
- **Disproving evidence:** <concrete reproduction-step + observation that disproves it>
- **Why it looked like a bug:** <root cause of the false positive — e.g., natural marker collision, network jitter, status-code-only confidence>
- **Retraction date:** <YYYY-MM-DD>

認可されたエンゲージメントでの具体的な撤回例 — パターンの参照：

• X-Forwarded-Protoの反映 — 4つのページでヘッダーが反映されているように見えましたが、実際はSPのヘルプリンクのhrefに含まれる文字列 javascript でした。原因：一意でないマーカー。
• ホストヘッダーの :80@evil バイパス — 通常は403になるパスで200 OKが返りましたが、本文はベースラインとバイト単位で同一でした（8341バイト）。原因：ステータスコードだけを根拠にした確信。ELBのホスト正規化により、@evil の部分が削除されました。
• download.aspx のファイル存在確認オラクル — パスの種類によってファイルの有無を判別できるように見えましたが、実際はSPのファイル拡張子ブロックリストによるものでした（.ashx／.asmx／.svc／.config は存在の有無にかかわらず常にブロック）。原因：サーバー側のポリシーとファイルの状態を混同。
• Administrator のタイミング漏えい — Authentication.asmx Loginで、単発では1527ミリ秒、対照では約700ミリ秒でしたが、n=80で交互に再現したところ、すべてのグループが685～716ミリ秒に収まりました。原因：単一サンプルに基づく統計的な主張。

重要な理由： 撤回した指摘事項を付録に記載することは、手法に誠実であることを示します。黙って削除すると、都合のよい結果だけを選んだように見えます。トリアージで2件が崩れる13件のレポートより、撤回の付録を添えた、整理された11件のレポートのほうが信頼できます。

---

関連スキルとチェーン

• report-writing — 7つの質問すべてに合格し、Pre-Severity Gateを問題なく通過した場合に使用します。ワークフローの基本要素：このスキルはreport-writingの前に実行されるゲートです。7Qと4つの提出前ゲートをすべて通過した脆弱性のみが、レポートテンプレートへの引き継ぎ対象になります。
• bugcrowd-reporting — 受理された脆弱性にBugcrowd VRTのマッピングが必要な場合に使用します。ワークフローの基本要素：このスキルが脆弱性を検証した後、bugcrowd-reportingがVRTカテゴリと深刻度要求の段落を決定します。
• evidence-hygiene — 検証済みの脆弱性について、PoCの証拠を取得する必要がある場合に使用します。ワークフローの基本要素：このスキルでは「Q6では影響の証明が必要」としています。evidence-hygieneは、その証明の取得と秘匿化の手順を提供します。
• security-arsenal — 常に却下される項目／条件付きで有効な項目の表を確認する場合に使用します。ワークフローの基本要素：このスキルの「提出禁止リスト」とsecurity-arsenalの「常に却下」表は対応しています。どちらの入口から調べても、ある基本要素が単独で報告可能か、チェーンとの組み合わせでのみ報告可能かを判断できます。
• bb-methodology — フェーズ5（検証と報告）の開始時に使用します。ワークフローの基本要素：フェーズ5のレポート前ゲートでは、レポートの草案を作成する前に/validate（このスキルの7Qゲート）を実行するよう明示的に求めています。

---

オペレーター向けメモ（Claude-BugHunter）

ベンダー提供の基盤に、エンゲージメントから得た知見を追加したものです。実際に許可を得て行ったエンゲージメントと、このリポジトリの31以上のスキル領域で実施したライブテストを横断するフェーズ2の検証から得られた知見です。上流の方法論がWHATを扱うのに対し、このレイヤーでは「実際に機能する条件」と「失敗モード」を扱います。

大規模運用における7問ゲート

7Qゲートは、このスキルで最もROIの高い成果物です。フェーズ2Dの強化ラボキャンペーンでは、次の4種類の誤検知を排除できることが確認されました。

1. リフレクションを装ったURLエコー — レスポンスがURLそのものであるため、ペイロードがレスポンス本文に現れます。Q1（サーバー上で何らかの処理を行う実際のHTTPリクエストかどうか）で排除できます。
2. マーカー検出を装った単語の衝突 — カナリア文字列XSS-testが一致したのは、あなたのインジェクションではなくCSSクラス名です。Marker DisciplineとQ1で排除できます。
3. 状態オラクルと取り違えられたサーバーポリシー — download.aspx?file=foo.configは、ファイルの有無にかかわらず常に「blocked」を返します。Q6（技術的に可能な範囲を超える影響）で排除できます。オラクルではなく、拒否リストにすぎません。
4. 情報漏えいのない200 OK — ステータスコードはベースラインの403と異なりますが、本文はバイト単位で同一です。Body-Diff RuleとQ6で排除できます。

7Qゲートを使わない場合、エンゲージメント全体で提出の妥当性が10〜20％低下すると見込まれます。使用した場合、取り下げ率は一桁台に落ち着きます。

Criticalを報告する前のPre-Severity Gate

ある許可を得たSharePointのエンゲージメントでは、チェーンがエンドツーエンドで実際には完了していないにもかかわらず、Criticalとして提出されかけました。認証状態を読み取る基本要素が、認証状態を変更する基本要素と混同されていました。Pre-Severity Gate（一般的な「これはバグか」という主張ではなく、Criticalの主張に対して7つの質問すべてを実施する）を使っていれば、これを検出できたはずです。

手順：Criticalのタイトル案を書きます。7つの質問それぞれについて、「バグ」をCriticalの主張に置き換えて回答します。Q6（技術的に可能な範囲を超える影響）への回答が「Xを可能にするはずの基本要素はあるが、テストアカウントでXをエンドツーエンドに実証できていない」であれば、深刻度を下げます。Criticalとは、影響が推測できることではなく、影響が実証されていることを意味します。

取り下げの徹底

提出から24時間後に脆弱性を再現できなくなった場合は、先手を打って取り下げてください。理由は2つあります。

1. トリアージ担当者に取り下げられると、スコアが下がります。 自ら取り下げれば「研究者が自分の成果を検証している」と受け取られます。トリアージ担当者に取り下げられると、「研究者がノイズを提出した」と受け取られます。
2. 検証率はプラットフォーム上で追跡されています。 自主的な取り下げは、トリアージ担当者によるN/Aでのクローズと同じ指標には影響しません。評判の指標をより良好に保てます。

上記のRETRACTION DISCIPLINEセクションにある取り下げテンプレートが正式な形式です。黙って削除しないでください。代わりに、エンゲージメントレポートに取り下げの付録を追加してください。

7Qが障壁に感じられる場合

その摩擦こそ、ゲートが機能している証拠です。7Qによって不採用になる調査結果の半数は、Informative または N/A として戻ってきていたものです。この摩擦を受け入れてください。信頼度の低い調査結果がファネルを薄めなくなるため、提出あたりの平均報酬が上がります。

例外：7Qによって調査結果が不採用になっても、依然として正しいと考える場合、答えはゲートを迂回することではなく、より多くの証拠を集めることです。ゲートは「証拠があるか」を確認するものです。証拠を集めてから、もう一度ゲートを通してください。

検証規律ルールとの相互参照

7つの質問は包括的な枠組みであり、bb-methodology の規律ルールはその実装です。

7Qの質問	規律ルール（bb-methodology）
Q1（何らかの処理を行う実際のHTTPリクエスト）	再現性ゲート
Q2（情報提供にとどまらない影響）	事前重大度ゲート
Q3（サーバー側の状態変更またはデータ漏えい）	サーバーポリシーと状態の区別
Q4（テナント間／ユーザー間であることを実証）	OOBゲート（ブラインドクラスの場合）、マーカーディシプリン（リフレクティブクラスの場合）
Q5（既知または重複ではない）	disclosed-reports/ インデックス + HackerOne の hacktivity 確認
Q6（技術的に可能な範囲を超える影響）	OOBゲート + ボディ差分ルール + 統計サンプルルール
Q7（プログラムのルールに照らして対象範囲内）	scope.md の確認（エンゲージメント用スキャフォールド）

質問に「はい」と答えるのが難しい場合、相互参照先のルールが、答えを「はい」にするために作成すべき成果物を示します。Q6は多くのエンゲージメントでつまずきやすい質問です。そのため、3つの規律ルールで補強されています。