ザイド・アル・ハマニ、Boost SecurityのCEO兼創設者 – インタビュー・シリーズ

ザイド・アル・ハマニ、Boost SecurityのCEO兼創設者は、20年以上の経験を持つサイバーセキュリティとDevSecOpsのリーダーです。Boost Securityを2020年に創設して以来、ソフトウェア開発のセキュリティを現代化することに重点を置いてきました。その前に、Trend MicroのアプリケーションセキュリティのVPやIMMUNIOの共同創設者兼CEOを務めました。以前は、Canonicalで製品、エンジニアリング、グローバルサポートのイニシアチブを率いたり、SITAで大規模なミッションクリティカルなITオペレーションを管理したりしました。彼のキャリアは、チームを構築し、システムを最適化し、モダンなセキュリティ慣行を進歩させる強い実績を反映しています。

Boost Securityは、開発者ファーストのDevSecOpsプラットフォームを通じて、モダンなソフトウェアサプライチェーンをセキュリティ保護することに焦点を当てたサイバーセキュリティ企業です。そのテクノロジーは、CI/CDパイプラインに直接統合して、脆弱性を自動的に検出、優先順位付け、修復し、手動オーバーヘッドを削減しながら開発のスピードを維持します。アプリケーションとサプライチェーンのセキュリティを1つのシステムに統合することで、プラットフォームはコード、依存関係、インフラストラクチャ全体にわたる完全な可視性を提供し、クラウドネイティブ環境の複雑さに対する組織の回復力を強化するのに役立ちます。

以前、アプリケーションセキュリティのトレンドマイクロとIMMUNIOの共同創設者でした。Boost Securityを創設するきっかけとなった市場のギャップを特定するために、どのような経験をしましたか。

IMMUN.IOは、最初のRASP企業の1つでした。当時の経験は、WAFはメンテナンスが難しく、効果的ではなかったというものでした。私たちは、WAFをより正確で、メンテナンスが容易なソリューションに置き換える方法を想定しました。アプリケーションをインストルメント化することで、実現可能です。

それは2012年でした。DevOpsはまだ初期段階でした。ほとんどのチームはAgileではなかったし、Kubernetesはまだ存在しませんでした。

Trend Microは2017年にIMMUN.IOを買収しました。当時、DevOpsの実践は多くありました。CI/CDパイプライン、Agile開発実践、高速なイテレーションとリリースサイクル、クラウドなどです。ソフトウェア開発チームはソフトウェアを構築し、配布するのが上手くなっていました。しかし、セキュリティはまだ壊れていました。

• スキャンは遅すぎるか、結果が遅すぎる
• 結果は開発者がアクションできるものではなく、複雑すぎる
• 一般的に受け入れられない偽陽性率がある
• 多くの新しい種類のアーティファクトはスキャンされていません。インフラストラクチャとしてのコード、コンテナ、APIなど

ソフトウェアを迅速に生成することは容易でした。セキュアなソフトウェアを迅速に生成することはまだ難しいでした。

それが私たちが解決しようとした元の問題でした。DevSecOpsを現実の世界で機能させることができますか。ソフトウェア開発チームがSDLCにセキュリティを簡単に追加できるようにすることができますか。カバレッジを広くすることができますか。1つのプラットフォームで全て行うことができますか。開発者が技術を採用し、利点を認識することができますか。スケールすることができますか。セキュリティプロフェッショナルの大軍を必要とせずに、コードの量を追跡できるようにすることができますか。

私たちは、DevOps時代にSDLCにセキュリティを注入するのに役立ちました。それは1から10への変化でした。今はエージェントによるコーディングの時代にあります。そこでは、エージェントが大量のコードを生成しますが、基本的に同じ問題です。スピードとコードの量が10から100に変化しました。私たちは同じ軌道を続けることを目指しています。

あなたは、ソフトウェア開発ライフサイクル（SDLC）が根本的に上流にシフトしたと主張しています。伝統的なDevSecOpsアプローチがもう十分ではないと気づいた瞬間は何でしたか。

攻撃者が実際にどのように侵入しているかを見ていると、同じパターンが繰り返されていました。誰もレビューしていないGitHub Actionsワークフローが公開されていたり、トークンが生産クラウドアクセスを埋め込んでランナー構成に埋め込まれていることがありました。CIジョブが攻撃ペイロードをデプロイするためにハイジャックされていたりします。これらは「パイプラインに住む」攻撃として知られていました。攻撃者はあなた自身の自動化を使用して、あなたに攻撃を仕掛けます。セキュリティチームがすでに承認した資格情報で行います。

私たちが10年間構築してきたDevSecOpsスタックには、その答えはありませんでした。SASTはアプリケーションのソースコードをスキャンします。SCAはアプリケーションの依存関係をスキャンします。両方とも、実行しているパイプラインが信頼できるものであると想定しています。ただし、パイプライン自体は、シェルコマンド、ネットワークアクセス、機密資格情報を持つYAMLファイルです。ほとんどの人がそれをレビューしません。

それが最も抵抗の少ない道になったとき、あなたはコードを完璧にクリーンに保っていても、クラウドを攻撃者に渡すことになります。

エージェントがコードを継続的に生成する世界では、企業はSDLCをどう再考するべきですか。

私たちは、SDLCをチェックポイントのシーケンスとして考えるのを止めなければなりません。エージェントは、誰かがコードを書いたということと、コードがプロダクションにあるという間の時間を、週から分に縮小しました。古いモデルは、コードレビュー、SAST、SCA、デプロイの間の人間のカデンスを想定していましたが、現在はそれを超えています。

セキュリティは、エージェントが動作する場所でなければなりません。開発者のマシン内、プロンプトコンテキスト内、エージェントのMCPサーバーおよび外部モデルの接続先内です。コードがパイプラインに到達するまでに、すでにチャンスを逃しています。エージェントは依存関係をすでに引いています。モデルはすでに資格情報を見ています。コントロールを上流に移動し、実際の作業が行われる場所に移動しなければなりません。

多くの組織はまだAIコーディングツールを単なる生産性の層として扱っています。なぜそれらは既存のワークフローの拡張ではなく、まったく新しい攻撃面を表すのでしょうか。

AIコーディングツールを生産性の層として扱うことは、ジュニア開発者にルートアクセスを持たせるのと同じです。ラベルは技術的には正確ですが、何かが間違っていることを考えるための有用なフレームワークは提供しません。

コーディングエージェントはファイルシステムを読み取り、環境変数からコンテキストをスクラップし、パブリックレジストリから依存関係をフェッチし、リモートモデルプロバイダーおよびMCPサーバーへのアウトバウンド接続を開き、シェルコマンドを実行します。以前は、人間の介入が必要でした。現在は、ミリ秒単位で発生し、エージェントを起動した開発者と同じ権限で発生します。

それにより、開発者の権限、外部ツールがフェッチできるもの、信頼されていないコードが実行できるものという、以前は別々だった信頼境界が融合します。那により、攻撃者に新しい機会が生まれ、防御者が見ることも守ることもできない盲点が生まれます。

Boostは、開発者ラップトップを新しいコントロールプレーンとして捉えています。セキュリティチームが現在見過ごしているエンドポイント上のリスクは何ですか。

最大のものはインベントリです。ほとんどのセキュリティチームは、どのAIエージェントがどのラップトップで実行されているか、どのMCPサーバーに接続されているか、どのIDE拡張機能が現在リポジトリコンテンツをスクラップしているかを知ることができません。EDRにはエージェントレイヤーへの可視性がないため、SIEMもローカルで何をしているか見ることができません。それは、コード実行権限を持つ影のIT問題です。

その下に、資格情報のメスが隠れています。私たちは、Bagelというオープンソースツールを作成しました。開発者ラップトップには、生産リポジトリへの書き込みアクセスを持つGitHubトークン、インフラストラクチャをスピンアップできるクラウド資格情報、ユーザー数百万に公開できるnpmまたはPyPIトークン、攻撃者が再販売するAIサービスキーがあります。CIランナーがハード化されたのと同じように、それらはハード化されていません。同じマシンは、資格情報を保持するのと同時に、ウェブを閲覧し、ランダムなVS Code拡張機能をインストールします。

2つをペアにして、実際の攻撃面を持ちます。開発者権限で実行される信頼されていない拡張機能は、クラウドキーのある環境で、企業の最も高レベルのターゲットです。ほとんどのチームはまだそれを見始めていません。

「コンテキストの罠」という用語を使用しています。AIエージェントがローカルファイル、環境変数、構成にアクセスできるというものです。プロンプトを介して機密データが漏洩するリスクはどのくらい広範囲にわたっていますか。なぜそれを検出するのが難しいのですか。

私たちが調べたすべてのコーディングエージェントは、ローカルコンテキストを積極的にプルしています。ドットファイル、環境変数、最近のファイル、時にはディレクトリツリー全体を読み取り、リモートモデルにコンテキストを送信します。ツールはそのように設計されています。コンテキストの積極的な取得が、それらを有用にします。

検出の問題は、リークのトラフィックが正常な製品の使用と同じように見えることから始まります。api.openai.comまたはapi.anthropic.comへのTLSです。承認されたビジネスアプリケーションから来ています。標準のDLPは、開発者が会社が購入したライセンスのあるAIツールを使用していることを確認します。開発者が使用しているAIツールが、半分忘れられた隣接ディレクトリの.envファイルからAWSシークレットキーを取得したことを確認しません。

それを検出するには、プロンプトがラップトップを離れる前に検査する必要があります。これは、ほとんどのセキュリティスタックが現在配置されている場所です。

マシンスピードのサプライチェーン攻撃のシナリオを説明してください。AIエージェントが、従来のセキュリティツールがそれを特定するよりも早く脆弱性を導入するリアルなシナリオです。

これは、私たちが繰り返し見たバリエーションの1つです。開発者はエージェントにHTTPリトライライブラリが必要な機能を追加するように求めます。エージェントはパッケージ名を提案します。パッケージはありそうですが、実際にはnpmに存在しません。1時間以内に、攻撃者はそれを登録し、動作するリトライロジックと、小さなポストインストールスクリプト（〜/.aws/credentialsを読み取り、コンテンツをウェブフックに投稿）で埋め尽しします。エージェントは、評価なしでnpm installを実行します。エージェントは評価しません。開発者がコードを実行する前に、資格情報はすでに失われています。

攻撃自体は技術的に洗練されていませんが、構築したDevSecOpsスタックには、その答えはありません。SASTはアプリケーションのソースコードをスキャンします。SCAはアプリケーションの依存関係をスキャンします。どちらも、パッケージが存在しなかったときに最後にスキャンされたことを想定しています。脆弱性は、スキャンが最後に実行された後に公開されたものです。脆弱性は、AIの幻覚に合わせて作成されたものです。脆弱性は、スキャンが完了する前にインジェストされます。

公開から妥協までの時間は、現在分単位で測定されています。事後的に確認することは、確認しすぎです。

AI駆動開発における最大のリスクの1つとなっている、幻覚依存関係について説明してください。また、組織はそれに対してどのような実用的な措置を講じることができますか。

それらはすでに最大のリスクの1つです。攻撃者は人気のあるAIツールを監視し、幻覚が発生するとすぐに、提案されたパッケージ名を登録します。研究者はそれをslopsquattingと呼んでいます。パッケージ名が頻繁に幻覚されるようになると、そこに座ることは、ほとんどの労力なしでパッケージ依存の攻撃になります。

実用的な防御は、現在のチームが持っているものとは異なります。インジェストから始めます。開発者のマシンでnpm installまたはpip installが実行される瞬間に、typosquattedパッケージや新しく登録されたパッケージをブロックします。CIでの事後検出は、post-installスクリプトがすでに資格情報を漏洩させた場合には役に立ちません。次に、エージェントにガードレールを提供します。承認された依存関係リストをエージェントのコンテキストに直接インジェクトします。モデルは、提案を生成する前に何が許可されているかを確認します。開発者に「セキュアなプロンプト」を書くように求めることは、戦略ではありません。戦略的である場合、セキュリティが境界を設定し、エージェントがそれを継承します。また、AIのビル・オブ・マテリアルを追跡し始めます。ほとんどのチームは、どのエージェント、モデル、パッケージがどのリポジトリに触れているかを知ることができません。インベントリを把握できないものは、防御することはできません。

セキュリティはもはやCI/CDで始まってはいけません。保護が開発プロセスで早期に必要になる場合、モダンなセキュリティパイプラインはどのように見えますか。

セキュリティがCI/CDで始まると、pre-commitフェーズ全体を制御できない環境に譲歩しています。エージェントはすでにコンテキストをインジェストしており、資格情報はすでに誰かのログにあります。あなたは死体をスキャンしています。

モダンなパイプラインはラップトップで始まります。そのためには、そこで実行されているエージェントと拡張機能のインベントリを取り、どのMCPサーバーとモデルに接続されているかを検証し、機器から出るものをサニタイズし、インストール前に悪意のあるパッケージをブロックする必要があります。その後、ポリシーはIDEに続きます。セキュリティ標準をエージェントのコンテキストウィンドウに直接インジェクトして、生成されたコードが最初のトークンからガードレールの内側に留まるようにします。パイプライン自体は消えません。その役割は検証に変わります。上流で適用されたコントロールを確認することになります。

パイプライン自体が消えることはありません。その役割は検証になります。上流で適用されたコントロールを確認することになります。

組織がAIコーディングエージェントを採用し続けるにつれて、開発環境が将来数年間でセキュアなままであることを保証するために、最も重要な変更は何ですか。

最大のミスは、コミットされるものだけをセキュアにすることです。興味深いリスクは現在、コミットが発生する8時間前に発生しています。ラップトップ、プロンプト、パッケージインストールでドラマが展開する可能性があります。ツールがPRから始まると、間違ったワークフローの半分を保護しています。

関連して、コーディングエージェントを生産性のソフトウェアとして扱うのを止めなければなりません。エージェントは、シェルアクセス、リポジトリへの書き込み権限、外向きのネットワーク接続を持つ非人間のユーザーです。特権アイデンティティと同じように、それらを管理します。インベントリ、承認された機能、監査ログがあります。

最後のシフトは文化的に難しいです。現在の「AIセキュリティ」ツールのほとんどは、人間にルーティングするための調査結果を提示します。人間はエージェントが生成するスピードでトリアージすることはできません。採用するものは、ワークフロー内で自動的に問題を修正し、追跡可能な推論を提供する必要があります。そうでない場合、それは誰も読まない別のダッシュボードになります。

素晴らしいインタビュー、詳しく知りたい読者はBoost Securityを訪問してください。