第11章：脆弱性の開示とセキュリティアップデート

FileBoltは責任ある開示を歓迎し、予測しやすい修正とコミュニケーションの仕組みを通じて信頼を築きます。同時に、セキュリティ機能は進化し続けられるものでなければなりません。これにはWebセキュリティポリシー、サーバー側の認証の仕組み、エンドツーエンド暗号とプロトコルの実装（例： cryptoVersion のアップグレード）が含まれます。本章では、公開の連絡窓口、対応ワークフロー、修正リリースとお知らせの原則を説明するとともに、バージョン管理による進化と廃止の方針について解説します。

11.0 概要

MUST：公開の脆弱性報告窓口（security.txtやサポート用メールアドレスなど）を設けます。
SHOULD：詳細を安全に送れるよう、暗号化された報告手段（PGP鍵など）を用意します。
SHOULD：対応と修正の目安（SLA／目標期間）を明確に定め、必要に応じてステータスページで周知します。
MUST：ゼロナレッジの約束に影響し得る脆弱性（XSS、サプライチェーンへの混入、ログへの断片の漏えい）を最優先で扱います。
MUST：バージョン管理による進化（cryptoVersion）を実装し、互換性、移行、廃止の方針を定めます。

11.1 脆弱性の報告窓口と連絡先

11.1.1 公開の窓口

MUST：脆弱性の報告窓口、有効期限、ポリシーへのリンクを /.well-known/security.txt で公開します。
MUST：連絡のつくセキュリティ担当のメールアドレスを用意します（例：support@filebolt.net、または専用の security@filebolt.net）。
SHOULD：セキュリティとプライバシーのページに、簡単な案内と報告のガイドラインを掲載します。

11.1.2 暗号化された報告と機微な情報の取り扱い

SHOULD：研究者が再現手順の詳細を安全に送れるよう、PGP公開鍵（または同等のもの）を用意します。
MUST：脆弱性の詳細は社内でも最小権限で閲覧できるようにし、修正に必要な担当者にのみ開示します。
MUST：研究者に対し、報告にユーザーの平文、CEK、URLフラグメント、導出可能な鍵素材を含めないよう求めます。誤って含まれていた場合、チームはそれを機微なインシデントとして扱い、拡散を最小限に抑えなければなりません。

11.2 対応のスケジュールとコミュニケーションの原則

スケジュールはチームの規模や案件の複雑さによって変わりますが、プロジェクトは予測しやすい目標を示し、目標を守れない場合は速やかに連絡する必要があります（SHOULD）。推奨する目標は次のとおりです（実情に合わせて調整でき、/security または security.txt で公開します）。

初回の応答：例：48時間以内に受領を通知し、管理IDを割り当てます。
初期評価：例：7日以内に深刻度の判定と影響範囲の評価を完了します。
修正のリリース：深刻度に応じて進めます。P0/P1は修正とリリースを優先して迅速に行います。

SHOULD：対応中は必要な連絡を続け（再現できた／できなかった、追加情報が必要、修正までの見込み時期など）、悪用可能な詳細を公に開示しないようにします。

11.3 開示プロセス

受領：報告内容、再現手順、影響、研究者の連絡先を記録し、担当者を割り当てて追跡します。
検証：隔離された環境で再現し、影響範囲、悪用の可能性、影響を受けるコンポーネント（フロントエンド／バックエンド／エッジ／ストレージ）を評価します。
修正：パッチを実装し、テストや回帰ケースを追加し、必要に応じて防御ルール（WAF／レート制限／ポリシーの厳格化）を追加します。
リリース：カナリアリリースで主要な指標を監視し、回帰や新たなリスクがないことを確認してから全面リリースします。
お知らせ：攻撃面を広げない範囲で、影響、修正内容、ユーザーに必要な対応（ある場合）を公表します。

重大な脆弱性やユーザーへの影響が大きい事象については、第10章のインシデント対応プロセスに沿って、 /status で状況の更新や事後検証レポートを公開します（SHOULD）。

11.4 ゼロナレッジの境界に影響する脆弱性

ゼロナレッジの約束の核心は、サーバーがCEKにアクセスできないこと、そしてダウンロード／復号の環境をサードパーティのスクリプトなしで可能な限り隔離することです。そのため、次の種類の脆弱性は最優先で扱わなければなりません（MUST）。

XSS／インジェクション：ダウンロード／復号のページで任意のスクリプトを実行され、フラグメントやメモリ上の鍵素材を読み取られること。
サプライチェーンへの混入：依存パッケージの汚染、ビルド成果物のすり替え、CDN／エッジでの注入によるスクリプトの改ざん。
ログ／監視からの漏えい：URLフラグメント、CEK、トークン、平文が誤ってログに記録され、参照できる状態になること。
リソース読み込みポリシーの誤り：ダウンロード／復号のページがサードパーティのスクリプトを読み込むこと、CSPの緩和によって実行可能な範囲が広がること。

対処には、即時の封じ込め（危険なコードの停止／ポリシーの強化／攻撃経路の遮断）、修正の迅速なリリース、影響の事後分析を含め、お知らせでは「鍵素材または平文が露出した可能性があるかどうか」を明確に記載します。

11.5 セキュリティアップデートと回帰検証

MUST：セキュリティに関わる変更（認証、アクセス制御、CSP、ログのフィルタリング、暗号化フロー）について、回帰テストケースを整備します。
SHOULD：重要なページ（ダウンロード／復号）に対して自動チェックを行い、サードパーティのスクリプトがなく、ヘッダーポリシーが期待どおりであることを確認します。
SHOULD：修正のリリース後に、外部から検証できる項目（TLS／セキュリティヘッダーのスキャンなど）を再テストします。
SHOULD：修正によって生じる互換性の変更（古いリンクや古いマニフェストなど）をドキュメントに明記します。

第12章と同様に、第三者によるスキャンは一部のWebの基準を検証できますが、ゼロナレッジやE2EEの実装の詳細全体を直接証明することはできません。そのため、回帰検証はプロトコルの実装と、外部から見える基準の両方を対象とする必要があります。

11.6 プロトコルと暗号のバージョン管理（cryptoVersion）

FileBoltの暗号とプロトコルの実装は、アルゴリズムのアップグレード、実装上の不具合の修正、より強力な隔離の導入を進めやすくするため、バージョン管理に対応しなければなりません（MUST）。マニフェストやメタデータに紐づけた明示的なフィールド（例：cryptoVersion）を使うことを推奨します。

明示的なバージョン：すべての転送／マニフェストは、アルゴリズム、パラメーター、エンコード規則を判別するために cryptoVersion を宣言しなければなりません（MUST）。
暗黙の推測の禁止：クライアントは、推測やフォールバックのヒューリスティックではなく、マニフェストの明示的なフィールドに基づいて解析と復号のロジックを決定しなければなりません（MUST）。
フェールクローズ：未知のバージョンや整合しないパラメーターに遭遇した場合はフェールクローズとし、安全でないモードへ格下げしてはなりません（MUST）。

11.7 互換性、移行、廃止

11.7.1 後方互換性

SHOULD：ユーザーの過去のリンクへの影響を最小限にするため、移行期間中は古いバージョンの転送を読み取れるようにします。
MUST：古いバージョンのセキュリティ上の境界、制限、廃止計画を公に明示します。

11.7.2 移行（ゼロナレッジの維持）

SHOULD：古いバージョンから新しいバージョンへの移行が必要な場合は、ユーザー側で行える「再アップロード／再暗号化」の手順を用意します。
MUST：移行中もゼロナレッジを維持します。再暗号化はクライアントで行い、サーバーはCEKや平文にアクセスできません。

11.7.3 廃止とEOL

MUST：安全ではなくなったと判断したバージョンについて、明確なサポート終了（EOL）のスケジュールを示します。
SHOULD：UIやドキュメントでユーザーに再アップロードを促し、十分な移行期間を確保します。
MUST：EOLの後、廃止されたバージョンに遭遇したクライアントは、その旨を明確に表示し、復号を試みてはなりません。

11.8 関連するクレーム ID（予約）

本章は「脆弱性の開示窓口、ワークフロー、バージョン管理、廃止」を扱います。対応するクレーム IDは、唯一の正式な情報源として付録：クレーム ID総覧に追加されます。