セキュリティ監査：監査レポートが本当に教えてくれること

「〇〇による監査済み」は、暗号資産の世界で最もよく見かけるバッジのひとつです。ウェブサイトや投資家向けピッチ資料、トークンのローンチなどに登場し、まるでそれだけで「安全かどうか」という問いに決着がついたかのように扱われがちです。実際にはそうではありません。しかし、本物の監査レポートを正しく読めば、非常に多くのことがわかります。大切なのは、どこを見ればよいかを知っておくことです。

監査とは何か

セキュリティ監査とは、外部の企業が特定のコードを期間を区切ってレビューすることです。監査人はコードを読み、テストし、壊そうと試み、見つけたことを文書にまとめます。スマートコントラクトの場合は、通常、手作業によるレビューと自動化ツールの組み合わせになります。ウォレットの場合は、アプリ、暗号処理、アプリが通信するサーバー、そしてそれらがどう連携しているかまでが対象になることがあります。

成果物はレポートです。何をレビューしたのか、いつ行ったのか、何が見つかったのか、各指摘の深刻度はどの程度か、そしてチームがそれを修正したかどうかが記されています。

この説明の中で、特に重要な言葉が三つあります**。特定のコード****、期間を区切って**、そして何が見つかったかです。

まず監査範囲を読む

監査範囲（スコープ）には、監査人が何を調べたのかが正確に書かれています。通常は名前を挙げたリポジトリ、コントラクト、コンポーネントで、多くの場合は特定のコミットに固定されています。

誤解を招く「監査済み」という主張の大半は、ここで崩れます。あるプロジェクトは小さなコントラクトをひとつ監査しただけで、プロトコル全体を監査済みとして宣伝しているかもしれません。あるウォレットはスマートコントラクトのレビューを受けていても、実際にあなたの取引を組み立てて署名するアプリは一度も調べられていないかもしれません。あなたが信頼しているものが監査範囲に含まれていなければ、その監査はそれについて何も語っていません。

自問してみてください。監査範囲は、自分の資金に関わる部分をカバーしているだろうか、と。

日付とバージョンを確認する

監査が示しているのは、レビューされた当日の時点でのコードです。その後にリリースされたもの、つまり新機能、新しいチェーン、リファクタリングなどは、改めてレビューされない限り対象外です。

それ自体はごく普通のことです。ソフトウェアは常に変わり続けるものだからです。しかし、開発の速いプロジェクトにとって、2年前の監査は歴史的な資料にすぎないということでもあります。役に立つ問いは、監査がいつ行われたのか、どのバージョンが対象だったのか、そしてその後の大きな変更が個別にレビューを受けているかどうかです。

スマートコントラクトには、さらに注意すべき点があります。コントラクトがアップグレード可能な場合、現在動いているコードは監査されたコードとは異なるかもしれません。誰がアップグレードを管理しているかは、監査そのものと同じくらい重要です。

要約だけでなく指摘事項を読む

レポートは指摘事項を深刻度で分類します。一般的には「クリティカル」「高」「中」「低」「情報」の段階に分かれ、それぞれが修正済みなのか、認識済みなのか、そのまま残されたのかが記録されます。

• クリティカルと高の指摘は、資金の損失につながりうるものです。そうした指摘はあったのか、あったなら修正されて再確認されたのかを見てください。
• 認識済みは修正済みではありません。「認識済み」とは、チームがそのリスクを受け入れたという意味です。それが妥当な場合もあるので、理由を読みましょう。
• 指摘ゼロが自動的に朗報とは限りません。優れたコードを意味することもあれば、狭い監査範囲と短い契約期間を意味することもあります。
• 再テストは重要です。良いレポートには、チームが修正したと述べただけでなく、監査人自身が修正を検証したことが書かれています。

監査では分からないこと

徹底した監査であっても、はっきり言っておくべき限界があります。

• 監査は注意を向けた範囲の一部分にすぎず、証明ではありません。監査人は多くのバグを見つけますが、すべてを見つけられるわけではありません。監査を受けたプロトコルが攻撃された例もあります。
• 対象はコードであって、運用ではありません。鍵の保管方法、誰がデプロイできるのか、チームがインシデントにどう対応するのかといった点は、通常は範囲外です。
• 経済設計は対象外です。ただし、明示的に監査範囲に含まれていた場合は別です。コントラクトが書かれたとおりに正しく動作していても、価格やインセンティブ、他のプロトコルを通じて悪用される可能性があります。
• あなたがインストールするものは対象外です。ソースコードの監査は、同じ名前を持つ偽アプリについては何も語りません。公開されたコードと、あなたが実際に動かしているソフトウェアを結びつけるのは、再現可能なビルドです。

「監査済み」という主張に潜む危険信号

• 実際のレポートへのリンクがない、またはレポートがプロジェクト自身のサイトにしか置かれていない。
• 監査会社が見つからない、またはその会社のサイトに該当の監査案件が載っていない。
• 監査範囲が、宣伝されている内容と一致していない。
• 修正されていない高深刻度の指摘が「対応済み」と説明されている。
• 何年も前に一度だけ監査を受けたきりで、製品はその後すっかり変わっている。

SSP の取り組み

SSP のコードはオープンソースなので、誰でも読むことができます。ただし、オープンなコードと監査済みのコードは同じではないため、私たちは両者を分けて扱っています。

独立系セキュリティ企業の Halborn が、SSP の ERC-4337 スマートコントラクトと、SSP Wallet 拡張機能・SSP Key アプリ・SSP Relay の全体を監査しました。どちらのレポートも Halborn のサイトで公開されており、クリティカルや高の指摘はなく、低および情報レベルの指摘には対応済みです。2025年の監査振り返り記事に、各監査の範囲と日付をまとめています。

誰にでも当てはまる注意点は、私たちにも同じく当てはまります。これらの監査が対象としているのは、レビュー時点でのコードです。それ以降に追加された機能やチェーンは対象外なので、古いバッジを無理に広げて当てはめるのではなく、新しいコードがどのようなレビューを受けたのかを明示するようにしています。

正直なまとめ

監査は証拠であって、保証ではありません。監査が教えてくれるのは、特定のコードが、特定の時点で、特定の企業によってレビューされたこと、そして何が見つかったかです。

監査範囲を読み、日付とバージョンを確認し、深刻度とそれぞれがどう解決されたかを見て、監査会社自身のサイトでレポートを探してください。そうすれば、「監査済み」は単なるバッジではなく、意味のある情報に変わります。