第 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: に関する簡単な説明と提出ガイドラインを提供します。セキュリティとプライバシー page.

11.1.2 暗号化された送信と機密情報の処理

SHOULD: 研究者が複製の詳細を安全に送信できるように、PGP 公開キー (または同等のもの) を提供します。
MUST: 内部で脆弱性の詳細に対する最小権限の可視化を実施し、修復に必要な担当者のみに開示します。
MUST: 研究者がレポートにユーザー平文、CEK、URL フラグメント、または導出可能な鍵マテリアルを含めることを禁止します。誤って含まれている場合、チームはそれを機密性の高いインシデントとして扱い、拡散を制限しなければなりません。

11.2 応答タイムラインとコミュニケーション原則

タイムラインはチームの規模と複雑さによって異なりますが、プロジェクトは予測可能な目標のペースを提供し、目標を達成できなかった場合は直ちに連絡する必要があります。推奨されるターゲット (現実に基づいて調整可能、/security または security.txt で公開):

最初の対応: 例: 受信を確認し、48 時間以内に追跡 ID を割り当てます。
初期評価: 例: 7 日以内に重大度のグレーディングと影響範囲の評価を完了します。
修正リリース: 重大度に基づいた進行状況。 P0/P1 は迅速な修正とリリースのために優先されます。

SHOULD: 処理中は必要なコミュニケーションを維持し (例: 再現されたかどうか、さらに情報が必要か、修正期間の推定など)、悪用可能な詳細が公に公開されることを避けます。

11.3 開示プロセス

Receipt: レポート情報、再現手順、影響、研究者との連絡先を記録します。所有者と追跡を割り当てます。
Verification: 隔離された環境で繁殖します。影響範囲、悪用可能性、影響を受けるコンポーネント (フロントエンド/バックエンド/エッジ/ストレージ) を評価します。
Remediation: パッチを実装し、テスト/回帰ケースを追加し、必要に応じて保護ルールを追加します (WAF/レート制限/ポリシー強化)。
Release: Canary は主要なメトリクスをリリースおよび監視します。回帰や新たなリスクがないことを確認した後、完全にリリースします。
Announcement：攻撃対象領域を拡大することなく、影響、修正内容、および必要なユーザーアクション（ある場合）を公的に説明します。

重大な脆弱性またはユーザーに大きな影響を与えるイベントの場合、 SHOULD イベントの最新情報や事後分析を公開する /status 第 10 章の IR プロセスに沿ったもの。

11.4 ゼロ知識境界に影響を与える脆弱性

Zero-Knowledge コミットメントの核心は、サーバーが CEK にアクセスできないこと、ダウンロード/復号化環境はサードパーティのスクリプトなしで可能な限り分離されることです。したがって、次のカテゴリは最高の優先度として扱われなければなりません。

XSS / インジェクション: ダウンロード/復号化ページで任意のスクリプトを実行し、フラグメントまたはメモリキーマテリアルを読み取る機能。
サプライチェーンインジェクション: 依存関係ポイズニング、ビルドアーティファクトの置換、スクリプトの改ざんにつながる CDN/エッジインジェクション。
ログ/監視漏洩: URL フラグメント、CEK、トークン、またはプレーンテキストが誤ってログに記録され、アクセス可能になりました。
間違ったリソース読み込みポリシー: サードパーティのスクリプトをインポートするダウンロード/復号化ページ、CSP 緩和により実行領域が拡大。

廃棄には以下を含める必要があります: 即時封じ込め (オフラインの危険なコード/ポリシーの強化/禁止ベクトル)、迅速な修正リリース、遡及的影響分析、そして、「鍵素材または平文が暴露された可能性があるかどうか」についての発表での明確な声明。

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

MUST: セキュリティ関連の変更 (認証、アクセスコントロール、CSP、ログフィルタリング、暗号化フロー) に対する回帰ケースを確立します。
SHOULD: 重要なページ (ダウンロード/復号化) で自動チェックを実行し、サードパーティのスクリプトやヘッダーポリシーが期待と一致しないことを確認します。
SHOULD: 修正リリース後に外部の検証可能な項目の再テスト (TLS/セキュリティヘッダースキャンなど) を実行します。
SHOULD: 修正 (古いリンク/古いマニフェストなど) によって導入された互換性の変更をドキュメントに明確に文書化します。

第 12 章と一致: サードパーティのスキャンは一部の Web ベースラインを検証しますが、完全なゼロナレッジ/E2EE 実装の詳細を直接証明することはできません。したがって、回帰検証はプロトコルの実装と目に見えるベースラインの両方をカバーする必要があります。

11.6 プロトコルと暗号化のバージョン管理 (cryptoVersion)

FileBolt の暗号化とプロトコルの実装は、アルゴリズムのアップグレードを容易にし、実装の欠陥を修正し、より強力な分離を導入するために、バージョン管理をサポートしなければなりません。明示的なフィールドを使用することをお勧めします (例: cryptoVersion) マニフェスト/メタデータにバインドされています。

明示的なバージョン: すべての転送/マニフェストは、その転送/マニフェストを宣言しなければなりません(MUST)。 cryptoVersion アルゴリズム、パラメータ、エンコード規則を決定します。
暗黙的な推論はありません: クライアントは、推測やフォールバックヒューリスティックではなく、明示的なマニフェストフィールドに基づいて解析および復号化ロジックを決定しなければなりません。
フェールクローズ: 不明なバージョンまたは一貫性のないパラメータが発生した場合はフェールクローズしなければならず、安全でないモードにダウングレードしないでください。

11.7 互換性、移行、および非推奨

11.7.1 下位互換性

SHOULD: ユーザーの履歴リンクへの影響を最小限に抑えるために、移行期間中の古い転送バージョンの読み取りをサポートします。
MUST: 古いバージョンのセキュリティ境界、制限、非推奨計画を公に述べます。

11.7.2 移行 (ゼロ知識の維持)

SHOULD: 古いバージョンから新しいバージョンへの移行が必要な場合は、「再アップロード/再暗号化」ユーザー側パスを提供します。
MUST: 移行中にゼロ知識を維持します: 再暗号化はクライアントで行われ、サーバーは CEK またはプレーンテキストにアクセスできません。

11.7.3 非推奨と EOL

MUST: 安全でなくなったとみなされるバージョンについては、明確なサポート終了タイムラインを提供します。
SHOULD: ユーザーに UI/ドキュメントで再アップロードするよう促し、十分な移行期間を提供します。
MUST: EOL の後、非推奨バージョンに遭遇したクライアントは明確にプロンプトを表示する必要があり、復号化を試行してはなりません。

11.8 関連クレーム ID (予約済み)

この章では、「脆弱性開示チャネル、ワークフロー、バージョニング、非推奨」について説明します。対応するクレーム ID が付録: クレーム ID のマスターリスト唯一の信頼できる情報源として。