audit-context-building

監査コンテキストの構築

判定を下すのではなく、理解を深めます。これは誰かがバグを探し始める前に実行し、その作業に情報を引き継ぎます。

使用するタイミング

コードに詳しくない場合は、監査、脅威モデリング、アーキテクチャレビューの開始時に使用します。また、システム全体の構成を誰も把握していなかったため、以前の調査で誰も判断できない指摘が出た場合にも使用します。

使用しないタイミング

脆弱性を挙げたり、修正を提案したり、概念実証を書いたり、深刻度を評価したりしないでください。それらは次に行う調査フェーズの役割であり、システム全体を把握したうえで実施します。コードが何かを前提としているのに、それを確認するものがない場合は、その事実をそのまま記録して先へ進みます。それが重要かどうかは後で判断します。

すでに理解しているコードにトークンを費やす価値はありません。

このコンテキスト内では分析しない

分析は長く、このコンテキストを保ったまま活用する必要があります。分析を委任してください。

• コードベース、または複数の関数 — /audit-context-building:audit-context <path> を実行します。全体の状況を把握し、各関数を個別のサブエージェントで分析して、audit-context/DOSSIER.md と audit-context/functions/ 以下に関数ごとのファイルを作成します。ここに戻るのは簡潔な記録だけです。
• 単一の関数 — audit-context-building:function-analyzer エージェントにその関数を分析させます。分析内容をディスクに書き込み、記録を返します。

返された内容をもとに作業します。索引、強制されていない前提、未解決の疑問を確認してください。詳細が必要になったら、該当する関数のファイルを読みます。

これを強制するのはこの文章ではなく、ワークフローです。返却スキーマに従うサブエージェントは、文章のまま返すことができません。このセクションは振り分けのためのものです。適切に振り分けてください。

返される内容と読み方

各記録には、常に成立していなければならないこと（それを示す行とともに）、関数が前提としていること（それを裏付けるものがあれば併記）、呼び出す関数とそれぞれに必要とするもの、そして未解決の点が記載されています。ドシエにはさらに、複数の関数にまたがるルール、各要素にアクセスできる主体、複雑な処理が集中している箇所が追加されます。

特に重要なのは、次の2点です。

• nothing found と記された前提。 コードは何かが真であることを前提としていますが、それを真にするものがどこにもありません。これは調査フェーズに渡す情報として最も有用です。
• 未解決の疑問。 自信たっぷりの誤った回答よりも、未解決の点を正直に列挙するほうが有益です。解決済みにせず、次の作業に引き継いでください。

2つの記録が食い違う場合は、ひそかに整合させるのではなく、両方を引用します。それは分析の欠陥ではなく、コードに関する事実です。

フォーマット

ANALYSIS_FORMAT.md でフォーマットを定義し、FUNCTION_MICRO_ANALYSIS_EXAMPLE.md で C と Solidity の例を示しています。このプラグインを拡張するときや、記録を信頼できるか判断するときに参照してください。

対象が何であってもフォーマットは同じです。変わるのは各項目に入る内容と、内部を確認できない呼び出しと見なすものです。DOMAIN_NOTES.md では、スマートコントラクト、C と C++、逆コンパイルされたファームウェア、ウェブサービスにおける違いをまとめています。対象が通常のソースコードではない場合は参照してください。

最も重要なルールは、呼び出しを追うことです。 関数が正しいかどうかは、多くの場合、別の関数の動作に左右されます。呼び出し元だけを見ても、それは分かりません。検証済みであるかのように見える制限値が、検証されたことを示唆する名前の関数から返されている場合があります。そこで、呼び出される関数を読み、成功する経路だけでなく、そこを通るすべての経路をたどり、各前提を何が真にしているのかを明記してください。何もない場合は、そのまま nothing found と記してください。すべての主張には行番号を付けてください。そうでなければ、未解決の疑問として扱います。