ほとんどの創業者は、セキュリティとはスマートコントラクトを守ることだけだと考えている。 しかし、以下の一般的な誤解と現実を、すべての創業者が理解する必要がある。 > 誤解：監査を通過すれば、安全だとみなせる。 現実： 私にとって、これはWeb3で最も大きな誤解の一つである。 監査はセキュリティの保証書ではなく、特定の時点でのコードレビューにすぎない。 新しい機能をリリースしたり、他のプロトコルを統合したり、オラクルを更新したり、バックエンドインフラを変更したりした瞬間、リスクプロファイルは変化する。 監査はリスクを軽減する助けにはなるが、その後のすべての更新にも同様の注意を払う必要がある。 > 誤解：ハッカーはスマートコントラクトのみを攻撃する。 現実： 私はもはやそうは思わない。 過去数年間で見られた最大規模の損失の多くは、Solidityのバグではなく、プライベートキーの漏洩、フィッシング、アクセス制御の失敗、バックエンドインフラ、オラクル署名者、運用ミスから生じている。 フロントエンド、API、デプロイパイプライン、ウォレット、インフラストラクチャはすべて攻撃面の一部である。 私の見解では、創業者はスマートコントラクトを超えて考える必要がある。インフラ、キー、運用プロセスも同様に重要である。 > 誤解：私たちのような小規模なプロジェクトはターゲットにならない。 現実： 攻撃者はあなたのプロジェクトのフォロワー数がどれだけ多いかには関心がない。 彼らが気にするのは一つだけ——価値を抽出できるかどうかだ。 あなたのプロトコルが資産を保有しているか、ユーザーが存在するなら、すでに誰かにとって興味の対象である。 セキュリティに投資するのに「大きくなりすぎた」段階まで待つのは、しばしば遅すぎる。 > 誤解：信頼できる署名者や管理者キーが一つあれば十分だ。 現実： 私の見解では、すべての特権キーを財務庫のように扱うべきである。 オラクルキー、デプロイキー、アップグレードキー、マルチシグ署名者、バックエンド認証情報——これらすべてが単一障害点になり得る。 一つの compromized 認証情報で、全体のプロトコルが危険にさらされる可能性がある。 > 誤解：リリース後にセキュリティを改善する。 現実： 攻撃者はその時点まで待ってくれない。 創業者はセキュリティを後から追加できると考えがちだが、残念ながら攻撃は製品のタイムラインに従わない。 モニタリング、インシデント対応、運用セキュリティを構築する最良のタイミングは、ユーザーがあなたに資産を預ける前である。 > 誤解：内部テストだけで十分だ。 現実： あなたのチームはプロトコルがどう動くべきかを知っている。 一方、外部の研究者はどうやって失敗するかを考える。 だからこそ、監査、競合レビュー、バグバウンティ、継続的なテストはそれぞれ異なる役割を果たす。 セキュリティには新鮮な視点が不可欠である。 > 誤解：オープンソースなら誰かがバグを見つけてくれる。 現実： オープンソースは透明性を高めるが、すべてのコード行がレビューされ、すべての脆弱性が責任を持って報告されるという保証にはならない。 コードを公開することは、検証することとは異なる。 > 誤解：セキュリティは監査人の責任だ。 現実： これは創業者が最も意識を変える必要がある点かもしれない。 監査人はリスクを軽減する手助けをするだけだ。 セキュリティは誰もが築くもの——製品判断をする創業者、コードを書く開発者、インフラを管理するDevOpsチーム、アクセスを守る運用チームすべてが関与する。 私は常に、セキュリティは「完了するもの」ではなく、「継続的に改善し続けるもの」だと信じてきた。 最終的な教訓： セキュリティの状況は変わった。 そして私たちのセキュリティに対するマインドセットもそれに合わせて変える必要がある。 スマートコントラクトだけに注目するだけではもはや十分ではない。 創業者として、契約からインフラ、キー、アクセス制御まで、プロトコットを動かすすべてのシステムを守ることを考えなければならない。