インタビュー
ザイド・アル・ハマニ、Boost SecurityのCEO兼創設者 – インタビュー・シリーズ
ザイド・アル・ハマニ、Boost SecurityのCEO兼創設者は、サイバーセキュリティとDevSecOpsのリーダーで、2 десяти以上にわたってグローバルなテクノロジー・オペレーションの構築と拡大に携わってきました。2020年にBoost Securityを創設して以来、ソフトウェア開発のセキュリティを現代化することに焦点を当て、Trend Microのアプリケーション・セキュリティのVPやIMMUNIOの共同創設者兼CEOなどの以前の役職を活かしています。以前は、Canonicalでは製品、エンジニアリング、グローバル・サポートのイニシアチブをリードし、SITAでは大規模なミッション・クリティカルなITオペレーションを管理していました。彼のキャリアは、チームの構築、システムの最適化、モダンなセキュリティ・プラクティスの推進における強い実績を反映しています。
Boost Securityは、開発者ファーストのDevSecOpsプラットフォームを通じて、モダンなソフトウェア・サプライ・チェーンのセキュリティに焦点を当てたサイバーセキュリティ・カンパニーです。同社のテクノロジーは、CI/CDパイプラインに直接統合して、脆弱性を自動的に検出、優先順位付け、修復し、手動でのオーバーヘッドを削減しながら開発のスピードを維持します。アプリケーションとサプライ・チェーンのセキュリティを単一のシステムに統合することで、プラットフォームはコード、依存関係、インフラストラクチャ全体で完全な可視性を提供し、複雑なクラウド・ネイティブ・環境で耐久性を強化するのに役立ちます。
以前、アプリケーション・セキュリティをTrend Microでリードし、IMMUNIOを共同創設しました。Boost Securityを創設するきっかけとなった市場のギャップを特定した背景と経緯を教えてください。
IMMUN.IOは、最初のRASPカンパニーの一つでした。当時の経験から、ランタイム・セキュリティ・テクノロジーとしてのWAFは維持が困難で、効果的ではなかったことがわかりました。アプリケーションをインストルメント化することで、WAFをより正確で、維持が容易なソリューションに置き換える方法を想定しました。
それは2012年でした。DevOpsはまだ初期段階で、ほとんどのチームはAgileではなかったし、Kubernetesはまだ存在しませんでした。
Trend Microは2017年にIMMUN.IOを買収しました。その時点では、DevOpsのプラクティスが多くありました。CI/CDパイプライン、Agile開発プラクティス、より速いイテレーションとリリース・サイクル、クラウドなどです。ソフトウェア開発チームはソフトウェアを構築し、出荷するのが上手くなっていました。しかし、セキュリティはまだ壊れていました。
- スキャンは遅すぎるか、結果が遅すぎる
- 結果は開発者がアクションするには複雑すぎる
- 一般的に受け入れられない偽陽性率がある
- 多くの新しい種類のアーティファクトはスキャンされていません。インフラストラクチャとしてのコード、コンテナ、APIなど
ソフトウェアを迅速に生成するのは容易でした。セキュアなソフトウェアを迅速に生成するのはまだ難しかったです。
それが私たちが解決しようとした元の問題でした。DevSecOpsを現実の世界で機能させること。ソフトウェア開発チームがSDLCにセキュリティを簡単に追加できるか。カバレッジを広くして、一つのプラットフォームで全てが必要になるか。開発者が技術を採用し、利点を認識できるか。セキュリティ・プロフェッショナルが大量に必要なくなるようにスケールできるか。
私たちは、DevOps時代に企業がSDLCにセキュリティを注入するのを助けました。那は1から10への変化でした。現在はエージェント・コーディングの時代にあります。コードのスピードとボリュームが10から100に変化しました。私たちは同じトラジェクトリーを続けることを目指しています。
あなたは、ソフトウェア開発ライフサイクル（SDLC）が根本的に上流にシフトしたと主張しています。伝統的なDevSecOpsアプローチがもう十分でないと気づいた瞬間はいつでしたか。
攻撃者が実際にどのように侵入しているかを見ていると、同じパターンが繰り返されていました。誰もレビューしていないGitHub Actionsワークフロー、プロダクション・クラウド・アクセスを埋め込んだトークン、正当なCIジョブが攻撃ペイロードをデプロイするために乗っ取られた。これらは「パイプラインに住む」攻撃として知られました。攻撃者はあなた自身の自動化を利用し、セキュリティ・チームがすでに承認した資格情報で行います。
私たちが10年以上にわたって構築してきたDevSecOpsスタックには、その答えがありませんでした。SASTはアプリケーションのソースをスキャンします。SCAはアプリケーションの依存関係をスキャンします。両方とも、パイプラインが信頼できるものであると仮定します。ただし、パイプライン自体はシェル・コマンド、ネットワーク・アクセス、機密情報を含むYAMLファイルであり、ほとんどの人がレビューしません。
それが最も抵抗の少ない道である場合、あなたはコードを完全にクリーンに保っていても、クラウドを攻撃者に渡すことになります。
企業は、AIエージェントが継続的にコードを生成する世界で、SDLCをどのように見直すべきですか。
私たちはすべて、SDLCをチェックポイントのシーケンスとして考えるのを止める必要があります。AIエージェントは、「誰かがこれを書いた」と「これがプロダクションにある」の間の時間を週から分に縮小しました。古いモデルは、コード・レビュー、SAST、SCA、デプロイの間の人間のカデンスを仮定していましたが、現在はそれを超えています。
セキュリティは、エージェントが動作する場所でなければなりません。開発者のマシン内、プロンプト・コンテキスト内、エージェントのMCPサーバーおよび外部モデルへの接続内です。コードがパイプラインに到達するまでに、すでにチャンスを失っています。エージェントはすでに依存関係をプルしました。モデルはすでに資格情報を見ました。コントロールを上流に移動し、実際の作業が行われる場所に移動する必要があります。
多くの組織はまだAIコーディング・ツールを単なる生産性層として扱っています。なぜそれらは新しい攻撃面を表すのでしょうか。既存のワークフローを単に拡張するのではなく。
AIコーディング・ツールを生産性層として扱うことは、ルート・アクセスを持つジュニア・デベロッパーを生産性層として扱うことと同じです。ラベルは技術的に正確ですが、何かが間違っているかどうか考えるための有用なフレームワークは提供しません。
コーディング・エージェントはファイル・システムを読み取り、環境変数からコンテキストをスクラップし、パブリック・レジストリから依存関係をフェッチし、外部モデル・プロバイダーおよびMCPサーバーへのアウトバウンド・コネクションを開き、シェル・コマンドを実行します。以前は、これらのアクションはすべて人間の介入を必要としました。現在は、ミリ秒単位で、開発者がエージェントを起動したのと同じ権限で行われます。
開発者の権限、外部ツールがフェッチできるもの、信頼されていないコードが実行できるものという、以前は別々だった信頼境界が融合します。那により、攻撃者にとって新しい機会が生まれ、防御者が見ることすらできない盲点が生じます。
Boostは、開発者ラップトップを新しいコントロール・プレーンとして捉えています。セキュリティ・チームが現在見過ごしているエンドポイントにはどのようなリスクがありますか。
最大のものはインベントリーです。ほとんどのセキュリティ・チームは、どのAIエージェントがどのラップトップで動作しているか、どのMCPサーバーに接続しているか、どのIDE拡張機能が現在リポジトリ・コンテンツをスクラップしているかを説明できないでしょう。EDRにはエージェント・レイヤーに対する可視性がなく、SIEMもローカルで何をしているか見ることができません。那はシェル実行権限を持つ影のIT問題です。
その下には資格情報のメスが広がっています。Bagelというオープンソース・ツールを作成したのは、これを具体的にするためです。典型的な開発者ラップトップには、プロダクション・レポジトリへの書き込みアクセスを持つGitHubトークン、インフラストラクチャをスピンアップできるクラウド資格情報、数百万のユーザーに公開できるnpmまたはPyPIトークン、攻撃者が再販売するAIサービス・キーがあります。これらはCIランナーと同じようにハード化されていません。資格情報を保持する同じマシンは、ウェブを閲覧し、ランダムなVS Code拡張機能をインストールします。
両者をペアにすると、実際の攻撃面が得られます。開発者権限で実行される信頼されていない拡張機能は、クラウド・キーの豊富な環境で、現代の企業における最高のレバレッジ・ターゲットです。ほとんどのチームはまだそれを見始めておりません。
「コンテキスト・トラップ」という用語で説明されているように、AIエージェントがローカル・ファイル、環境変数、設定をアクセスできるというリスクはどれくらい広範囲にわたっていますか。機密情報がプロンプトを介して漏洩するリスクはどれくらいですか。なぜそれを検出するのが難しいのですか。
私たちは、未管理の開発環境のデフォルト状態としてそれを扱います。私たちが調査したすべてのコーディング・エージェントは、ローカル・コンテキストを積極的にプルします。ドットファイル、環境変数、最近のファイル、時にはディレクトリ全体を読み取り、コンテキストをリモート・モデルに送信します。ツールはこのように動作するように設計されています。コンテキストの積極的な取得がそれらを有用にします。
検出の問題は、リークのトラフィックが正常な製品の使用と同じに見えることから始まります。那はapi.openai.comまたはapi.anthropic.comへのTLSです。那は承認されたビジネス・アプリケーションからのものです。標準のDLPは、会社がライセンスを購入したAIツールを使用している開発者を見ます。那は、プロンプト内の文字列の1つが、隣接ディレクトリの半分忘れられた.envファイルから取得されたAWSシークレット・キーであることを見ません。
それをキャッチするには、プロンプトがラップトップを離れる前に検査する必要があります。那はほとんどのセキュリティ・スタックが現在配置されていない場所です。
マシン・スピードのサプライ・チェーン・アタックのシナリオを説明してください。AIエージェントが従来のセキュリティ・ツールが識別できるよりも速く脆弱性を導入するリアリスティックなシナリオを。
私たちが繰り返し見たバリエーションの一つです。開発者はエージェントにHTTPリトライ・ライブラリを追加する機能を依頼します。エージェントはパッケージ名を提案します。パッケージはありそうですが、実際にはnpmに存在しません。1時間以内に、攻撃者はそれを登録し、動作するリトライ・ロジックと、小さなポスト・インストール・スクリプト（〜/.aws/credentialsを読み取り、ウェブフックに内容を投稿）でそれを埋めます。エージェントは評価をチェックせずにnpm installを実行します。エージェントは評価をチェックしません。資格情報は、開発者がコードを実行する前にすでに失われています。
攻撃自体は技術的に洗練されていませんが、従来のサプライ・チェーン・セキュリティは、既知のパッケージの既知の脆弱性（CVE、SBOM、ライセンスのスキャン）に基づいて構築されています。那のフレームワークには、存在しなかったパッケージ、AIの幻覚に特に一致するように作成されたパッケージ、スキャンが最後に実行された後にインジェストされたパッケージについては何も言及されていません。
公開から妥協までの時間は現在分単位で測定されます。事実上のチェックは遅すぎます。
幻覚的な依存関係は、AI駆動の開発における最大のリスクの一つになっています。組織はそれに対してどのような実用的な対策を講じることができますか。
すでに最大のリスクの一つです。攻撃者は人気のあるAIツールを監視し、幻覚が発生するとすぐにパッケージ名を登録します。研究者はそれをslopsquattingと呼んでいました。那の名前は残りました。依存関係の名前が頻繁に幻覚されるようになると、そこに座ることはパッシブなサプライ・チェーン・アタックになります。ほとんどの労力は不要です。
実用的な防御策は、現在のチームが持っているものとは異なります。インジェストから始めます。npm installまたはpip installが実行される瞬間に、タイポ・スクワットや新しく登録されたパッケージをブロックします。CIでの事後検出は、ポスト・インストール・スクリプトがすでに資格情報を漏洩させた場合には役に立ちません。次に、エージェントにガードレールを与えます。承認された依存関係リストをエージェントのコンテキストに直接インジェクトします。モデルは、提案を生成する前に何が許可されているかを認識します。開発者に「セキュアなプロンプト」を書くように求めることは戦略ではありません。戦略的である場合、セキュリティが境界を設定し、エージェントがそれを継承します。AIのBill of Materialsの追跡を開始します。ほとんどのチームは、どのエージェント、モデル、パッケージがどのリポジトリに触れているかを説明できないでしょう。インベントリーできないものを守ることはできません。
セキュリティはもうCI/CDで始まらないと述べました。保護が開発プロセスでより早く始まる必要がある場合、モダンなセキュリティ・パイプラインはどのように見えますか。
セキュリティがCI/CDで始まると、全てのプレ・コミット・フェーズをコントロールできない環境に譲歩しています。エージェントはすでにコンテキストをインジェストしています。資格情報はすでに失われているかもしれません。你は死体をスキャンしています。
モダンなパイプラインはラップトップで始まります。那意味するのは、そこで実行されているエージェントと拡張機能のインベントリーを取り、どのMCPサーバーとモデルに話しかけることを許可するかを検証し、出ていくものをサニタイズし、インストールする前に悪意のあるパッケージをブロックすることです。そこから、ポリシーはIDEに続きます。セキュリティ・スタンダードをエージェントのコンテキスト・ウィンドウに直接インジェクトするので、生成されたコードは最初のトークンからガードレールの内側に留まります。パイプライン自体は消えません。その役割は検証に変わり、コントロールがすでに上流で適用されたことを確認します。
パイプライン自体は消えません。その役割は検証に変わり、上流で適用されたコントロールを確認します。
企業がAIコーディング・エージェントを採用し続けるにつれて、開発環境が将来数年間でセキュアなままであることを保証するために、最も重要な変更は何ですか。
最大のミスは、コミットされるものだけをセキュアにすることです。現在の興味深いリスクは、コミットが発生する8時間前にあります。ラップトップ、プロンプト、パッケージのインストールで見えざるドラマが展開する可能性があります。如果你的ツールはPRから始まる場合、間違ったワークフローの半分を保護しています。
密接に関連しています。コーディング・エージェントを生産性ソフトウェアとして扱うのを止めます。彼らはシェル・アクセス、リポジトリの書き込み権限、外向きのネットワーク接続を持つ非人間のユーザーです。彼らを他の特権アイデンティティと同様に管理し、インベントリー、承認された機能、監査ログを保持します。
最後のシフトは文化的に難しいです。ほとんどの現在の「AIセキュリティ」ツールは、結果を人間に提示します。人間はエージェントが生成するスピードでトリアージすることはできません。採用するものは、ワークフロー内で自動的に問題を修正し、追跡可能な推論を提供する必要があります。そうでない場合、それは誰も読まない別のダッシュボードになります。
素晴らしいインタビュー、詳しく知りたい読者はBoost Securityを訪問してください。
