セーフガード概要

レジストリについて

FlareWatchの歴史における再発性のあるすべてのバグクラスは、番号付きのセーフガードに凝縮されています。それぞれは1段落のルール、根拠、およびそれを強制するコード内の場所へのポインタで構成されています。バグクラスまたはパターンが出現し、再発を防止すべき場合は、新しいセーフガードが追加されます。

レジストリは実務文書であり、マーケティングコピーではありません。その目的は、チーム、およびチームが使用する監査優先のレビュープロセスに対して、どのルールがどこに適用されるかについて誠実に保つことです。レジストリはインラインコードコメント（例：// Safeguard 24）から参照されているため、任意のファイルの読者は周囲の行を統治するルールを見つけることができます。

このページは公開概要です。完全なレジストリはソースリポジトリ内にそれを統治するコードと共に存在します。ここでの目的は、セキュリティ研究者、助成金レビューアー、または将来の貢献者に対して、レジストリがカバーするカテゴリーと強制する規律の種類についての理解を提供することです。

レジストリが必要な理由

セーフガードレジストリは、同じバグを2回防ぐことによってのみその価値を証明します。レジストリの実績がその答えです：

• 各セーフガードは、それが防止するバグに名前を付けます。背後に記憶された出来事のないルールはセーフガードではなく、スタイル設定の好みです。スタイル設定の好みはレジストリではなくlintルールに属します。
• セーフガードはドキュメントからだけでなく、コードから参照されます。セーフガードに違反するコード変更は、周囲のコメントにセーフガード番号があるため、レビュー時にフラグとして読まれます。
• 一部のセーフガードは自動的に強制されます。ESLintルールまたはCI内で実行されるシェルスクリプトを通じて強制されるサブセットがあります。残りは作成者の規律と監査優先のレビューパターンに依存しており、実務では十分に機能しています。
• レジストリはテストによって信頼性が保たれます。複数のセーフガードは、ソースファイルを文字列として読み取り、アンチパターンが出現しないことをアサートする回帰テストによってピン留めされています。脆弱性は機能です。アンチパターンに戻る将来のリファクタリングはテストに失敗し、回帰が本番環境に到達する前に検出されます。

カテゴリー

レジストリはドメインごとに整理されています。以下のカテゴリは安定的であり、新しい障害モードが発見されるにつれて各カテゴリ内の特定のセーフガードが追加されます。

代表的なルールいくつか

これらはレジストリの特性を示すセーフガードの公開安全なサマリーです。言い換えられ、短縮されています。正規テキストはコードの隣に存在します。

オンチェーン読み取りの単一の真実のソース

スマートコントラクトから読み取られるすべての値（請求可能な報酬、残高、ステーク状態、エポックデータ、価格）は、サービスレイヤーの正確に1つの関数によって計算されます。その値が必要なすべての機能は同じ関数をインポートします。2つの関数が同じ値を計算する場合、そのうちの1つは間違っています。ルールは3番目を追加するのではなく、1つを削除することです。

セッション検証の単一の絞られたポイント

FlareWatchのすべての認証済みルートは、単一のヘルパーを通じてセッションクッキーを検証します。ルートハンドラーはセッショントークンを独立して検証しません。この不変性こそが、サーバー側の取り消しを普遍的にするもの—チェックをバイパスするサイドドアはありません。

ウォレットごとの所有権ゲーティング、両側

ウォレットごとのルートはサーバー側で所有権を検証し、クライアント側ではありません。元の監査がこのルールを確立したのは、以前の作業がクライアント側のゲートを閉じていたが、サーバー側のエンドポイントは完全にゲーティングされていなかったためです。2つの部分は現在、別々の明示的な成果物として追跡されています—クライアントで閉じられ、サーバーで閉じられています—その失敗モードが再発するのを防ぐため。

一元化されたフォーマッターを使用し、インラインは使用しない

すべての数値、通貨、および日付のフォーマッティングは、小さな一元化されたヘルパーセットを通じて行われます。コンポーネントはインラインでフォーマットしません。このルールはスタイルとは関係がありません。単一のロケールまたは通貨定義が変更されると、アプリケーション内のすべてのサーフェスがそれに応じて更新されます。サーフェス間のドリフトはサイレントで、ユーザーが気付くまで検出が困難です。

単位変換は両端で文書化されている

システムの2つの部分が単位が曖昧な可能性がある値を交換する場合（秒対ミリ秒、小数対パーセント、小文字対チェックサム付きアドレス）、慣例はプロデューサーとコンシューマーの両方で文書化されています。片方の端のコメントだけでは劣化します。両端で主張される境界コントラクトだけがリファクタリングを生き残ります。

ユーザーアクションあたり1つの実装

すべてのユーザーが開始したアクション—監視対象ウォレットの追加、税率の変更、アラートの却下、サインアウト—は正確に1つの実装があります。このルールが存在するのは、UI の異なる部分からトリガーされたアクションが微妙な方法でドリフトしていたためです。1つのエントリーポイントはキャッシュをクリアし、別のポイントはそうしません。「操作 X 後のステイル値」バグのクラスが発生します。

失敗モードは明示的であること

一部の失敗モードは本来的に無音です。例えば、報酬の誤分類、ユニット不一致による通知の無効化、キー・バリュー・ストアに保存されない却下レコードです。可能な限り、レジストリは、これらの値の生成者が将来の変更が契約に違反する場合は本番環境に到達する前に、テストで大きな音で失敗することを宣言することを要求しています。

レジストリの進化

• 新しいセーフガード。バグのクラスが繰り返される場合、または単一のバグが永続的なルールを正当化するのに十分なコストがかかった場合に追加されます。
• 廃止されたセーフガード。「廃止」マーカーと置き換え先へのポインタ付きでレジストリに保持されるため、コード内の過去の参照は解釈可能なままです。
• 作業ノートから昇格。一部のセーフガードはセッション引き継ぎドキュメント内の非公式なルールとして始まり、その重要性が証明されるとレジストリに昇格します。
• 四半期ごとのスイープ。一時的なリント例外と「翌四半期までに完了」マーカーは四半期ごとのペースで確認されます。有効期限が切れたものは、解決されるか明示的に延長されます。

これが公開されている理由

FlareWatchは完全な内部レジストリではなく、このオーバービューを公開しています。理由は2つあります。

• 内部レジストリにはコードレベルの詳細情報（ファイルパス、キー・バリュー・スキーマ名、インシデント・タイムスタンプ）が含まれており、これはチームとコード・アクセス権を持つセキュリティ・レビュアーにとって有用ですが、そのようなアクセス権なしに公開するのは適切ではありません。
• カテゴリと規律が実際のストーリーです。助成金レビュアーやFlareWatchを評価するセキュリティ研究者は、どのようなプロジェクトなのか、正確性にどの程度真摯に取り組んでいるのか、どのような作業ループが機能しているのかを知りたいと考えています。ルール#91がどのファイルに含まれているかではなく。

特定のセーフガードについて議論したい、新しいセーフガードを提案したい、またはギャップを報告したい研究者は、[email protected]までお気軽にお問い合わせください。.

関連資料

• アーキテクチャ — FlareWatchの構築方法。
• セキュリティ機能 — 認証、認可、ヘッダー、監査履歴。