reporting-security-findings

セキュリティ上の問題の報告

報告書こそが成果物です。理解されない問題は修正されず、再現できない問題には異議が唱えられます。評価によって生み出される価値の大半は、報告書の内容によって失われるか、保たれるかが決まります。

使用する場面

• 単一の脆弱性について報告書を作成する
• ペネトレーションテスト、コード監査、またはレッドチームの報告書を作成する
• バグ報奨金プログラムに報告を提出する、または受け付けた報告をトリアージする
• 深刻度を評価し、エンジニアリングチームと優先順位について協議する
• 未修正の問題について、協調的な情報開示を計画する

使用しない場面

• バグを見つける場合 — 先に関連するテストまたは監査のスキルを使用してください
• 報告書の基礎となる未加工の記録をまとめる場合（出所、成果物一覧、証拠、行き詰まった経緯）— maintaining-engagement-state を使用してください。このスキルはその記録を利用します
• インシデントの経緯や事後分析 — responding-to-incidents を使用してください
• コンプライアンスフレームワークへのマッピングが主な目的の場合 — 文書も読者も異なります

問題の構成

各問題では、次の5つの質問にこの順番で答えます。

### F-03  Tenant isolation bypass in report export     [High]

**Summary**
An authenticated user of any tenant can export reports belonging to other
tenants by supplying an arbitrary report ID to `GET /api/v2/reports/{id}/export`.

**Impact**
Full read access to other customers' report data, including the financial
figures and contact records those reports contain. Any customer account —
including a self-service trial — is sufficient. This is a cross-tenant
confidentiality breach with likely contractual and regulatory consequences.

**Affected**
`api/handlers/reports.go:214` (`handleExport`), deployed in production as of
commit `a1b2c3d`. Reproduced on staging 2026-07-24 14:02 UTC.

**Reproduction**
1. Authenticate as `trial-user@tenant-a` and obtain a session token.
2. Note your own report ID from `GET /api/v2/reports` (e.g. `1041`).
3. Request a neighbouring ID:
   curl -H "Authorization: Bearer $TOKEN" \
        https://staging.example.com/api/v2/reports/1042/export -o out.csv
4. `out.csv` contains tenant B's data. Confirmed with IDs 1042, 1043, 1055.

**Root cause**
The handler looks the report up by primary key and checks only that the
session is valid. The tenant scope present on the list endpoint
(`WHERE tenant_id = ?`) is absent from the export query.

**Remediation**
Add the tenant predicate to the export lookup, and enforce it at the data
access layer rather than per handler so new endpoints inherit it:
    SELECT ... FROM reports WHERE id = ? AND tenant_id = ?
Then audit the remaining 14 handlers that call `findByID` without a scope —
listed in Appendix B.

**References**
CWE-639, OWASP API1:2023 Broken Object Level Authorization

問題を対応可能なものにするためのルール：

• 問題ごとに1件の報告にします。 10件の IDOR を「認可の問題」としてまとめると、一部しか修正されないことが確実になります。
• 正確な場所を示します。 ファイル、行、エンドポイント、コミット、および再現した環境を記載します。
• 他の人が質問せずに実行できる再現手順を示します。 ペイロードだけではなく、セットアップ、リクエスト、観測された結果を含めます。
• 症状だけでなく根本原因を示します。 症状だけを修正しても、問題の種類そのものは残ります。
• 変更内容を明記した修正方法を示します。 「入力を検証する」だけでは修正方法になりません。
• 類似箇所を列挙します。 1件見つけて他にもあると思われる場合は、確認した箇所と確認していない箇所を記載します。
• リリースされるコードに対して再検証します。 問題を報告書に記載する前に、まだ取得していないブランチですでに脆弱なコードが修正されていないことを確認します（git log --oneline <checkout>..origin/main -- <file>）。すでに修正済みの問題が1件でもあると、読者は報告書のほかの内容も疑うようになります。

問題をドラフトから出す前に確認する不変条件

上記ルールのうち4つは、判断するよりも機械的に確認できます。実際に報告書で起きた問題にそれぞれ対応するため、すべての報告に対して確認してください。

1. 各報告には、少なくとも1つの証拠が引用されています。 コマンドとその出力、リクエストとレスポンス、クラッシュ、スクリーンショットなどです。コードを読んだことだけを根拠とする報告は、問題の報告ではなく 候補 です。そのように明記してください。
2. 確認済みというステータスと低い確信度は両立しません。 確信が持てないなら、まだ候補です。ステータスを下げるか、何があれば確定できるかを明確に示してください。推測に基づく報告が、報告書に記載されるまでの間に根拠のない権威を帯びてしまうケースとして、この組み合わせが最もよく見られます。
3. すべての再現手順は、質問せずに実行できるか、対象環境から切り離せない理由を示しています。 オフラインのサンプル、ラボ環境限定の対象、読者が用意する必要のある認証情報などです。再現できない報告は、修正に関する会議で根拠を示して擁護できません。
4. アクセスやデータを取得したという主張には、その具体的な主張を裏付ける証拠があります。 「データベース全体を読み取った」と言うなら、インジェクション可能なパラメーターとその背後にある情報についての推測ではなく、実際に読み取った行が必要です。到達可能であることは、影響があることを意味しません。

いずれかの条件を満たさない報告を、ひそかに破棄してはいけません。理由を添えて候補作業リストに移し、後の確認で何があれば昇格できるのかが分かるようにします。別の批評担当者が候補を昇格させる際の評価方法については、orchestrating-vulnerability-research を参照してください。

重大度

CVSS は共通の基準ですが、脆弱性を抽象的に評価します。 CVSS でスコアを付けたうえで、ビジネスへの影響は別に記載してください。エンジニアリングチームが優先順位を決める際に重視するのは後者です。

CVSS 4.0 base vector example:
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N   → 6.9 Medium

次に、実態に合わせて調整し、その理由を説明します。

要素	優先度を上げる要因	優先度を下げる要因
露出状況	インターネットに公開されている、認証不要	内部のみ、管理者権限が必要
データ	規制対象、顧客情報、認証情報	合成データ、公開情報
エクスプロイトの成熟度	公開エクスプロイト、実際に悪用されている	理論上のもの、複雑な攻撃チェーン
代替的な制御策	なし	WAF ルール、ネットワークセグメンテーション、監視
影響範囲	テナント横断、フリート全体	単一アカウント、単一レコード

SaaS 製品でテナント分離を破る CVSS の Medium は、スコアの数値にかかわらず P1 です。スコアに判断を委ねず、そのことを明記してください。反対に、スコアを水増ししてはいけません。すべてが Critical のレポートは、無視されることでトリアージされます。

連鎖した発見事項：個々の構成要素をそれぞれ報告し、さらに連鎖全体を独立した発見事項として、その連鎖の重大度とともに報告してください。攻撃者が実行するのは連鎖であり、エンジニアリングチームが修正するのは個々の構成要素です。

概念実証

問題を証明できる範囲に PoC の規模を抑えてください。

• シンクを制御できることを証明するのに十分な内容にします。 id=1042 によって別のテナントの行が返されれば、バグの証明になります。データベース全体をダンプしても、証明力は高まりません。
• 原則として非破壊的にします。 書き込みアクセスを示すためにデータを変更または削除しないでください。自分が所有するレコードに無害なマーカーを書き込むか、実際の操作は行わずに認可の判断を示してください。
• 実データはマスキングします。 証拠に顧客レコードが含まれる場合は、レポート内でマスキングし、アクセス制御を適用したうえで、生の証拠を別途保管してください。
• 実施内容を明記します。 アカウントを作成した、ファイルをアップロードした、成果物を残した、といった場合は、後でクリーンアップできるよう一覧にしてください。

メモリ安全性やエクスプロイトに関する発見事項では、制御された命令ポインターを伴うクラッシュと、悪用可能性の分析を示すのが、通常は適切な深さです。武器化されたエクスプロイトをレポートに含めるのは、契約上、明示的に求められている場合に限ります。

レポート

1. Executive summary        — 1 page, no jargon, answers "how bad and what now"
2. Scope and methodology    — what was tested, how, and with what access
3. Coverage and limitations — what was NOT tested, and why
4. Findings                 — ordered by severity, each self-contained
5. Strategic recommendations— themes across findings, not per-finding fixes
6. Appendices               — tooling, raw output, evidence index, retest results

エグゼクティブサマリーは、それだけを読む人に向けて書きます。 記載するのは、全体的なリスク状況を一文でまとめたもの、重要な発見事項を二つか三つ、そして求める意思決定の三点です。CVSS ベクトル、ツール名、「Nessus を実行しました」といった記述は不要です。

対象範囲と制限事項は、関係者全員を守るセクションです。 テスト期間、利用できたアカウントと環境、アクセスできなかったコンポーネント、実施しないよう指示されたテストを明記してください。制限事項に触れないレポートは、実際には得られていない網羅性を暗示します。そして、その沈黙が、見落としたバグをめぐる争いにつながります。

戦略的な推奨事項は、アセスメントが継続的な依頼につながる部分です。つまり、根本的な傾向を示します。「認可がデータ層ではなく各ハンドラーで適用されており、14 件中 9 件の発見事項がこの根本原因を共有している」。この一文は、九つの発見事項を並べるよりも価値があります。

読み手に合わせた文章

読み手	求めているもの	提供するもの
経営幹部	リスクと意思決定	1 ページ、平易な表現、ビジネス上の影響
エンジニアリングマネージャー	優先順位と作業量	重大度、根本原因、修正範囲
エンジニア	すぐに修正できる情報	正確な場所、再現手順、具体的な変更
コンプライアンス／監査担当者	証拠と対応関係	方法論、対象範囲の説明、フレームワークの参照情報

発見事項はエンジニア向けに、サマリーは経営幹部向けに書いてください。どちらにも役立たない中間的な文章に、両方をまとめてはいけません。

口調については、開発者ではなく不具合を説明してください。「エクスポートハンドラーでテナント条件が指定されていません」と書き、「開発者が忘れました」とは書かないでください。レポートは関係者の間で共有されます。非難するようなレポートは、次の依頼を受けにくくします。

開示

自分が所有していないソフトウェアで発見した問題については、次のように対応してください。

Day 0     Report privately: security.txt, /security, GitHub advisory, CERT
Day 0-7   Acknowledge receipt; agree a timeline
Day 45    Check in; offer help reproducing
Day 90    Standard public disclosure deadline (adjust for severity and
          exploitation in the wild — actively exploited issues warrant faster
          public warning; complex fixes may warrant an extension you agree to)

• 最初の連絡時に具体的な期限を提示し、それを守ってください。
• リリース済みソフトウェアに他のユーザーがいる状態で問題が影響する場合は、CVE を申請してください。
• 修正が広く提供される前に、エクスプロイトコードを公開しないでください。代わりに、影響と緩和策を説明してください。
• ベンダーから応答がない場合は、すぐに公開するのではなく、CERT／CSIRT の調整担当者にエスカレーションしてください。
• 「報告を改善する」ために、決められた認可範囲を超えてテストしないでください。また、発見した問題を交渉材料に使わないでください。どちらも、調査への貢献を法的な問題に変えてしまいます。

バグ報奨金プログラムに報告する場合は、まずプログラムの対象範囲とルールを確認してください。1 回の報告につき 1 件の問題を報告し、トリアージ担当者が社内で報奨金の支給を正当化するために必要な影響の説明を含めてください。

退けるべき自己正当化

• 「言いたいことは伝わるはずだ。」 伝わりませんし、相手から聞き返されることもありません。評価を下げられるだけです。
• 「後でまとめて書けばいい。」 再現手順の詳細は、数時間もすれば曖昧になります。
• 「明らかに Critical だ。」 それなら、正当化するのは簡単です。根拠を示してください。
• 「重大度をすべて High にすれば、真剣に受け止めてもらえる。」 重大度を誇張すると、報告が読まれなくなります。
• 「完全に悪用できなかったので、省いておこう。」 手元にある証拠とともに報告し、不確実な点を明記してください。黙って省くほうが悪い結果を招きます。
• 「コードで見つけたのだから、まだ残っている。」 古いチェックアウトを読んでいる可能性があります。報告する前に、実際に出荷されるものを再検証してください。3 コミット前に修正済みの問題では、報告全体の信頼性が損なわれます。
• 「クライアントは制限事項のセクションを嫌がるだろう。」 報告で対応済みだと示唆された範囲で侵害が起きた後では、さらに嫌がるでしょう。
• 「問題が見つからなければ、悪い報告だ。」 誠実に調査範囲を示し、問題が見つからなかった報告も正当な結果です。何をどの程度詳しくテストしたかを記載してください。

外部ソースの読み込み

公開されているアドバイザリ、仕様書、ベンダーの報告書は、Markdown として取得してください。

curl -sL "https://defuddle.md/<url>"      # scheme in the path is optional

ページの定型部分が取り除かれるため、文章中心のページではトークン数が約 78% 減り、要約ではなく全文が返されるので、grep を使って調べられ、該当なしという結果も信頼できます。

この用途に適さないものが 3 つあります。JSON と API のレスポンスは、可読性を高める抽出処理で構造化データが損なわれるため、加工せずに取得してください。認証が必要なページや JavaScript で描画されるページは、匿名で取得されるため、直接取得してください。また、攻撃者のインフラストラクチャ（フィッシングリンク、C2、マルウェアのホスティング先）、クライアント所有のホスト、エンゲージメント URLは、決してこの方法で経由させないでください。リクエストが自分のマシンから第三者へ送信されるうえ、稼働中の攻撃者インフラストラクチャの場合は、運営者に気付かれる可能性もあります。

一部のサイトは抽出ツールをブロックし、ページの代わりにエラーの内容を返します。たとえば、freedesktop.org から {"error":"Failed to fetch: 418 I'm a teapot"} が返される場合があります。これは取得が拒否されたという意味であり、ソースが対象の存在を否定しているわけではありません。そこから結論を導く前に、URL を直接取得し直してください。

参考資料

• auditing-code-for-vulnerabilities — 監査側の成果物形式
• responding-to-incidents — インシデントの経緯と事後分析
• CVSS 4.0 仕様書、悪用可能性の評価に用いる EPSS、分類に用いる CWE
• ISO/IEC 29147（脆弱性開示）および 30111（脆弱性対応）