Giovanni Vignone、Octane Security の CEO & 創業者 – インタビューシリーズ

Giovanni Vignone, CEO 兼創業者の Octane Security は、2022 年に同社を立ち上げ、Web3 における予防的サイバーセキュリティの高まるニーズに取り組みました。わずか 22 歳で、リアルタイムにスマートコントラクトのコードベースを分析し、CI/CD パイプラインに直接統合し、従来の監査では見落としがちな脆弱性を検出する、24 時間体制のセキュリティエンジニアのように機能する AI 搭載プラットフォームの構築に挑みました。

この対話では、Octane のミッションである継続的で説明可能な脆弱性検出をソフトウェア開発ライフサイクルに組み込むこと、そして スマートコントラクト の未来を守るために必要なことを探ります。

デューク大学を離れ、Octane をフルタイムで立ち上げる決断の背後にあったインスピレーションは何ですか？機会を明確にした特定の瞬間はありましたか？

デューク大学の3年生の時、OpenAI のプラットフォームへの早期ベータアクセスを得て、暗号領域のスマートコントラクトに大規模言語モデルを試し始めました。その結果は、可能性がどれほど広がるかを実感させてくれました。

特に印象に残っている瞬間があります。スマートコントラクトをチャットインターフェースに入力し、問題点を探すように依頼しました。結果はまだ改善の余地がありましたが、LLM を使って見つけにくい脆弱性を検出できる大きな可能性をすぐに感じました。これは 2023 年 3 月のことです。

同時期に業界全体で多数のハックやエクスプロイトが頻発しているのを目の当たりにし、これらのセキュリティ問題を早急に解決する必要性を実感しました。これらのモデルが独自の対処方法を提供してくれることに気づき、Octane に全力投資するのが正しいタイミングだと直感しました。

Octane をコンセプトから主要な暗号企業に採用されるまでに至らせる際、最大の技術的または運用上の課題は何でしたか？

最大の技術的課題は、脆弱性を特定し、ユーザーが実際に活用できる形で提示する方法を見つけることでした。脆弱性は白黒はっきりしておらず、複数の側面を持つため、非常に困難でした。

潜在的な脆弱性を見る際には、以下の点を考慮する必要があります: 影響は何か（資金や重要な状態が失われる可能性があるか）、攻撃の容易さ、修正策、そして根本的な原因。これらすべてを同時に扱い、明確に提示するには多大な作業が必要でした。

これらの各コンポーネントを製品化するために多大な努力を注ぎ、顧客が Octane を使って脆弱性を検出し、その深刻度を迅速に把握し、すぐに修正を開始できるようにしました。さまざまなコードベースで一貫して問題を検出できるシステムを構築するには、技術的なノウハウと、あらゆる種類の脆弱性に関する膨大なデータが必要でした。

Octane はすべての開発チームに組み込まれた AI セキュリティエンジニアのように機能することを目指しています。その目標を業界全体で実現するために必要なマイルストーンは何ですか？

最初の大きなマイルストーンは、開発者のセキュリティに対する考え方を変えることです。リリース直前に数週間前から付け加えるのではなく、最初から組み込むよう促します。これにより、セキュリティを最初に取り入れることで、問題を早期に修正でき、結果的に時間を節約できることを示す必要があります。

また、ユーザーが脆弱性を早期に検出した際に何が起こるかを実感できるようにし、実際にそのメリットを体験できるよう支援する必要があります。

製品面では、Solidity だけでなく、他のスマートコントラクト言語、さらには最終的に一般的なプログラミング言語もサポートする必要があります。モデルの精度向上と、検出できる脆弱性の種類を増やすために常に取り組んでいます。

プラットフォームは、フィッシングやマルウェアベースのエクスプロイトなど、コードベースではない複雑な脅威にどのように対応していく予定ですか？

実際、現在すでにこれらの脅威の一部に対応しています。集中化リスクをフラグ付けし、チームがどのプライベートキーやロールが特に機密性が高いかを把握できるようにしています。

また、スマートコントラクトにおける一般的なフィッシングパターン、例えば tx.origin を呼び出し元検証ロジックに使用するケースなど、フィッシング攻撃につながるものを検出し、ユーザーに指摘しています。

現在、Octane は主にデプロイ前のセキュリティツールとして機能しており、リアルタイムで脅威を検出するものではありません。今後はコードが本番に入る前に検出できる範囲を拡大し、開発者が潜在的な問題を実際の攻撃になる前に修正できるツールを提供していく計画です。

教師なし機械学習、特にクラスタリングが、従来のルールベースシステムよりもスマートコントラクト脆弱性の分類に効果的な理由は何ですか？

教師なし機械学習は、存在するバグの種類をマッピングするのに大いに役立ちました。教師ありモデルを構築する際にルールベース手法は引き続き使用していますが、特にクラスタリングといった教師なし学習は、どのモデルを構築すべきか、そしてどのように優先順位付けすべきかを判断するのに役立ちます。

このアプローチにより、モデルを脆弱性タイプごとにより専門的な分析パイプラインに分割できるようになります。

実際には、教師ありと教師なしの機械学習を組み合わせて使用しています。教師なし学習で全体像を把握し、教師あり手法で正確な検出機能を構築します。この組み合わせは、従来のルールベースシステムだけに依存するよりも効果的です。

クラスタリングが、監査やセキュリティレビューで以前は認識されていなかった新たな脆弱性クラスを浮き彫りにした例を教えていただけますか？

クラスタリングは脆弱性の新しいカテゴリをゼロから作り出すわけではなく、既存のデータを有意義にグループ化します。我々のデータは、実際のオンチェーンエクスプロイト、公開された脆弱性レポート、その他のスマートコントラクトバグの情報源から得ています。

教師なし学習が得意とするのは、既存の脆弱性カテゴリの理解を洗練させることです。異なる脆弱性間のパターンやつながりを見つけ出し、見落とされがちな点を明らかにすることで、より優れた検出手法を構築できます。

このパターン認識とデータのグルーピングにより、既知の脆弱性タイプの微妙なバリエーションを検出できる、より微細なモデルを作成しました。完全に新しい脆弱性クラスを発見するというよりも、既存のものをより正確に捉えることができるようになっています。

Octane は、脆弱性が既存のタクソノミー内のカテゴリに明確に当てはまらないエッジケースをどのように扱いますか？

タクソノミーの具体性と汎用性のバランスを取ろうとしています。カテゴリやモデルが汎用的であればあるほど、どこにもきれいに収まらない奇妙なエッジケースを検出しやすくなります。一方、より具体的なカテゴリはユーザーに対してより良い説明を提供し、既知のバグタイプを一貫して検出できるようにします。

Octane が見逃す、または既存のカテゴリに明確に合致しない脆弱性に直面した場合、その脆弱性に関するデータを既存モデルに追加すべきか、将来的にその種のバグを検出するために全く新しいモデルを作成すべきかを検討します。

この柔軟なアプローチにより、検出能力を継続的に向上させつつ、ユーザーにとって理解しやすいフレームワークを維持できます。

数千件のバグを分析した結果、スマートコントラクトの脆弱性に共通して見られるパターンや根本原因は何ですか？

繰り返し現れるいくつかの厄介なパターンが見られます。再入可能性（Reentrancy）は依然としてスマートコントラクトの大きな問題です。もう一つの大きなカテゴリは、トランザクションがメンプールで公開されていることに起因し、攻撃者が保留中のトランザクションを見て情報を盗んだり、トランザクションを失敗させたりする脆弱性を生み出します。これは一般にフロントランニングと呼ばれますが、さまざまな形で発生します。

また、単純な開発者のミスから生じる多くの重大な脆弱性も見つかっています。以前は総称して「ロジックエラー」と呼ばれていましたが、あまりにも曖昧です。よくあるミスの一つは、開発者が特定のコードパスで状態変数の更新を忘れることです。

これらはほんの一例に過ぎません。データ分析を通じて作成した、すべてのバグに関するはるかに詳細な非公開の内訳があります。

スマートコントラクトはエコシステムや言語によって大きく異なりますが、Octane はこれら多様な環境でもモデルの有効性をどのように保っていますか？

多くの脆弱性は、特定の言語やエコシステムに関係なく共通のパターンに従います。これにより、さまざまなコードベースで効果的に脆弱性を検出できるモデルを構築できます。

モデルは、スマートコントラクトシステム全体に広く適用できる基本的なセキュリティ原則に焦点を当てつつ、言語ごとの固有機能も考慮して設計しています。このアプローチにより、新しい言語ごとにすべてを作り直すことなく、さまざまな環境で有効性を保つことができます。

脆弱性の表面的な詳細ではなく、根本的なパターンに焦点を当てることで、スマートコントラクト開発の多様な世界に適応できるモデルを構築しました。

AI ベースのセキュリティツールは説明可能性に対する懐疑的な見方を受けがちです。Octane は脆弱性の分類やアラートが開発者にとって実行可能であることをどのように保証していますか？

脆弱性を追加チェックで検証するバックエンドのバリデーションプロセスに多大な労力を注いできました。

検出結果を慎重に分類し、コードベースに実際に影響を与える可能性のある重大な脆弱性と、ベストプラクティスを示す軽微な問題や警告とを分けています。この分類により、開発者は最も重要な点に集中できます。

UI はシンプルで分かりやすく設計されており、最も深刻な問題を強調表示して即座に注意を引くようにしています。重要度の低いアラートに埋もれないようにするためです。明確な説明と実行可能なポイントに焦点を当てることで、開発者が検出した脆弱性を迅速に理解し、修正できるようにしています。

素晴らしいインタビューをありがとうございました。詳しく知りたい読者は Octane Security をご覧ください。