Neatsun ZivのOX Security、AI時代のAppSecをPromptからRuntimeまでつなぐ

OX Securityは、AIがコードを書き、依存関係を呼び込み、cloudまで立ち上げる開発環境に対して、従来の人間中心のAppSecでは境界を追い切れないという問題から出発した。

現在の公式サイトは、PromptからRuntimeまでを一つの安全性のループとして扱う方針を掲げ、200社超の顧客と120以上のnative integrationsを示している。出典

人間の速度で作られたセキュリティへの違和感

Neatsun Zivは、AI時代の攻撃が単一のCVEではなく、prompt、MCP server、agent、commit済みコード、cloud、dataをまたぐchainになると説明している。

OXはこの変化を、既存ツールを増やす話ではなく、開発の最初からproduction runtimeまでを連続して見る設計課題として捉えた。出典

Prompt-to-Runtimeへの転換

Neatsun Zivは「The CVE era is over. AI writes the code and commoditizes the exploit」と語り、実際にexploit可能なリスクを証明し、businessへ届く前にchainを断つことを目標に挙げている。出典

この直接的な言葉が、OXの差別化を単なるscannerの追加ではなく、文脈をつないだ判断とremediationとして示している。

認識から運用へ

公式サイトは、AIによるrisk prediction、AI-assisted remediation、cloud exposureの継続的な探索、agentic pentestingを同じplatformの要素として説明する。

顧客事例とintegrationの広がりを前面に出すことで、導入後の運用へ価値を接続している。出典

現在地

200+ customers、70〜90%のsecurity incidents reduction、120+ native integrationsという数字は、OXが単一の検査機能ではなく、既存の開発・運用環境に入り込むplatformを目指していることを示す。

ただし、売上や調達額は今回確認した公開一次情報からは確定できないため、非公開として扱う。出典

AIで開発速度が上がるほど、security teamは個別のalertを追うだけではsoftware supply chain全体を守れない。

OXはpromptからruntimeまでを同じ文脈で扱い、risk predictionとremediationを接続する。

公式サイトは200+ customersと120+ integrationsを示しており、単発scannerより既存workflowへの統合がPMFの核だと考えられる。出典

一方、公開情報だけでは顧客別の定着率や売上は判断できない。

導入効果はsecurity incidents reductionという会社公表値とcustomer storiesの範囲で読むべきだ。

OXのmoatは単一モデルではなく、application lifecycle、integration、customer contextを横断して蓄積するrisk graphにある。

120+ integrationsを運用へ組み込めれば、検査結果を別ツールへ移す摩擦が上がる。出典

ただし、integrationの数だけでは防御力は証明できない。

実際の検知精度とremediationの履歴が継続して価値を生む。

ネットワーク効果は強いソーシャル型ではなく、弱いdata-and-workflow型だ。

顧客のrepository、cloud、ticketingの接続が増えるほど組織固有の文脈は厚くなるが、同時に導入・移行コストも増える。出典

顧客間の直接ネットワークではなく、接続されたworkflowの蓄積が効く。

主な対象は、AIを含むsoftware developmentを大規模に進め、security programが開発速度に追いつかない企業のsecurity leadersとplatform teamsだ。

特に複数のrepository、cloud、開発者向けAI toolをまたぐ組織に適合しやすい。出典

小規模チームが単一scannerだけを求める場合は、機能範囲が過剰になりうる。

第一に、AI開発の変化をpromptからruntimeまでという一つの問題設定にまとめたこと。

第二に、120+ native integrationsで既存の開発・cloud環境へ接続すること。

第三に、customer storiesとtrust centerでenterprise導入の不安を下げることだ。出典

機能数の多さだけでなく、security判断を開発フローへ戻す設計が再現可能な要因になる。

最大のリスクは、Prompt-to-Runtimeという広い約束が、導入時の運用設計を重くする可能性だ。

AI生成コードとruntime exposureを一つに扱うほど、誤検知・優先順位・責任分界の説明が難しくなる。出典

また、公開一次情報ではARR、調達額、価格表を確認できなかった。

定量的な事業規模を外部から比較しにくい点も、購入判断では要確認である。

成長戦略は、contentとsecurity recognitionで課題を言語化し、customer storiesとintegrationでenterprise導入へ進める組み合わせに見える。

公式サイトはGartner recognition、customer stories、trust centerを並べ、検討段階から購買・審査までを一つの導線にしている。出典

AI開発の急速な変化は追い風だが、広い製品メッセージを具体的なincident reductionへ落とせるかが継続課題になる。

主要チャネル: content, partnerships, customerStories

新しいsecurity productは、脆弱性の件数を増やすより、開発の変化で既存の境界が壊れたことを一文で示す方が強い。

OXのPrompt-to-Runtimeは、AI開発を入口にapplication securityを再定義するメッセージだ。出典

ただし、広い約束は数字と導入例で具体化して初めて信頼になる。

公表されていない売上や価格を推測せず、確認できる顧客・integration・security evidenceに絞る姿勢が重要だ。

日本企業では、AI coding toolの導入とsecurity reviewが別部署に分かれやすい。

Promptからruntimeまでを一つのrisk chainとして棚卸しする考え方は、開発部門とsecurity部門の共通言語になりうる。出典

展開時は、日本の委託開発、個人情報、クラウド利用規程に沿ったデータ境界と監査証跡を先に示す必要がある。