アクティブステートのCEO、アビー・カーンズ – インタビュー・シリーズ

アビー・カーンズは、アクティブステートのCEOであり、25年以上のエンタープライズ・ソフトウェア・オーガニゼーションを構築して拡大させる経験を持つテクノロジー・エグゼクティブです。彼女は以前、PuppetのCTOを務め、Perforce Softwareによる同社の買収につながる戦略的変革を主導しました。彼女のキャリアの早期には、Cloud Foundry FoundationのCEOを務め、業界最大のオープンソース・クラウド・プラットフォーム・エコシステムの成長を導きました。アビーは現在、アッカ（旧ライトベンド）の取締役を務めています。彼女は、クラウド、オープンソース、AIの重大な変化を明確な製品戦略とエンタープライズ・成長に翻訳することで企業を支援することで知られています。

アクティブステートは、1997年に設立されたカナダのソフトウェア会社で、オープンソース・ソフトウェアの構築、管理、セキュリティを支援するエンタープライズ・ツールとプラットフォームを提供しています。同社のコア・オファリングであるアクティブステート・プラットフォームは、開発、DevOps、セキュリティ・チームが依存関係の管理を自動化し、脆弱性を検出して修復し、複数のプログラミング・言語（Python、Perl、Tclなど）でセキュアで再現可能な開発環境を作成するのに役立ちます。アクティブステートは、事前に構築された検証済みのオープンソース・コンポーネントを提供し、それらを既存のワークフローに統合することで、ソフトウェア・サプライ・チェーンのセキュリティ・リスクを軽減し、開発者の生産性を向上させ、アプリケーションの配信を加速化することを目指しています。

あなたは、オープンソース、クラウドネイティブ・プラットフォーム、エンタープライズ・トランスフォーメーションの交差点でキャリアを積んできました。クラウド・ファウンドリー・ファウンデーションのリーダーシップやPuppetでのCTOを務めた経験から、アクティブステートのCEO役を引き受けることに何があなたを引き付けたのか、あなたのビジョンは何ですか?

私のキャリアの共通点は、コミュニティとインフラストラクチャーの交差点で業界が将来に影響を与える決定を下すときに動いていることです。クラウド・ファウンドリーはクラウドネイティブのためのその瞬間でした。Puppetはコンフィギュレーション・マネージメントとDevSecOpsの初期段階のためのその瞬間でした。アクティブステートはオープンソース・ガバナンスのためのその瞬間です。

ここに引き付けたのは、私が長い間見てきた問題です。エンタープライズのすべてにオープンソースが使われていますが、ほとんどの組織が自社で使っているオープンソースを把握したり、パッチが適用されているか、誰が使用を決定したかを自信を持って言えることができません。そのギャップ、つまりオープンソースがどれほど基盤的なものになっているかと、ほとんどの組織がそれを管理するための厳格さが不足していることの間で、業界のリスクが蓄積しています。アクティブステートは20年間でそのギャップを埋めるためのインフラストラクチャーを構築してきました。私の仕事は、市場がそのギャップを埋めることの緊急性を理解することを保証することです。

次の段階のビジョンは明確です。アクティブステートは、エンタープライズのオープンソースのデフォルトの答えとなります。スキャナーではありません。レポートではありません。組織がソフトウェア・サプライ・チェーンを管理する際に指し示すことができる、信頼できる検証済みのソースであり、継続的に修復されたソースです。

アクティブステートは、AIがコード生成を加速するときに、ソフトウェア・サプライ・チェーンのセキュリティを確保するための重要なレイヤーとして自己を位置付けている。AIはどのようにしてオープンソース・ソフトウェアのリスク・プロファイルを根本的に変更するのか?

AI支援開発は、オープンソース・ガバナンス・ツールチェーン全体が構築された根本的な前提を破壊します。開発者が依存関係を含めることを意図的に決定したという前提です。

すべてのSBOMマンデート、すべてのSCAツール、すべての脆弱性管理ワークフローは、人間がライブラリをプルすることを選択したという前提に基づいています。AIがコードを生成すると、誰も選択したり、レビューしたり、多くの場合、そこにあることを知らない依存関係がプロダクションに到達します。ガバナンス・ツールは決定を探しています。AIは決定を完全にバイパスするプロダクションの変更を行っています。

2番目の層があります。AIの採用を促進したコーディング・ツール、生産性のベンチマーク、開発者調査、GitHubのスター、どれもセキュリティを第一の評価尺度として含んでいませんでした。業界は速度と正確さを最適化し、セキュリティが安全であるかどうかを尋ねることなくインフラストラクチャーを出荷しました。那はツールの失敗ではありません。那は採用決定が行われたリーダーシップの失敗です。私たちは、リスクを導入した評価が行われなかった基盤で大規模に運用しています。

あなたは、管理されていないオープンソースが大きなエンタープライズの脆弱性になっていると述べています。オープンソース・ガバナンスはなぜ今、取締役会レベルで注目されるようになっているのでしょうか? そして、幹部はまだ何を過小評価していますか?

それは、規制環境が責任構造を変更したためです。EUサイバー・レジリエンス法、SECの開示要件、CISAのセキュア・バイ・デザイン・ガイダンスなどのフレームワークは、質問を「スキャナーを持っているか?」から「ソフトウェアが元で安全だったことを証明できるか?」に変更しています。後者は、ほとんどの組織が答えることができない質問です。

幹部がまだ過小評価しているのは、それが構造的な問題であり、リソースの問題ではないということです。オープンソース・リスクに応じてスキャン・ツールを追加する組織は、根本的な問題を解決していません。スキャンは問題を検出しますが、すでに環境内に存在する場合にのみです。

すべてがフラグ付けされると、優先順位付けは行われず、警報の量自体が運用上の障害となります。問題を解決する組織は、ツールを追加するのではなく、環境内に入るオープンソースについての決定の方法を変更する組織です。誰がその決定に責任を負うか、ということです。

オープンソースがほとんどのエンタープライズ・ソフトウェア・スタックに埋め込まれている場合、組織はオープンソースを開発の便宜ではなくインフラストラクチャーとして再考するべきです。どうすればよいのでしょうか?

ほとんどの組織が動いているメンタル・モデルは10年古いものです。オープンソースは開発の便宜として始まりました。開発者はライブラリをプルし、迅速に進み、基礎的なコンポーネントの再発明を避けることができました。そのフレーミングは、オープンソースがオプショナルで補足的なものであったときには意味をなしました。

それは現在の現実ではありません。オープンソースは現代のソフトウェアの基盤です。96%のアプリケーションにはオープンソース・コンポーネントが含まれています。プロプライエタリ・インフラストラクチャーの上にある便宜的なレイヤーではありません。それはインフラストラクチャーです。インフラストラクチャーは、環境に入るものについての明示的なポリシー、メンテナンスと修復の所有権、組織の適切なレベルに座るアカウンタビリティを持って管理されなければなりません。

先を行っている組織は、意図的なシフトを行っています。オープンソースの消費は、セキュリティと財務の結果を伴う戦略的な決定であり、開発者が個別に管理するデフォルト設定ではありません。そのシフトには、ポリシー、運用プロセス、明確な幹部アカウンタビリティが必要です。ほとんどの組織はまだそのシフトを行っていません。

あなたは複数のテクノロジー・ウェーブを率いてきました。現在のAI駆動のシフトは、クラウドやDevOpsなどの以前の移行と比較して、速度と混乱の点でどのように異なりますか?

現在のAI駆動の動きは、以前のテクノロジー・シフトと非常に似ています。クラウドがデリバリー・モデルとして登場したとき、クラウドを純粋なテクノロジー・選択として扱った組織は、クラウドをアーキテクチャーと運用のシフトとして扱った組織とは異なるミスを犯しました。後者は、シャドウ・IT、コスト・オーバーラン、セキュリティとテクニカル・デットで年間を支払いました。

現在のAI駆動のシフトが異なる点は、速度と不可視性です。クラウドの採用は可視的でした。組織がワークロードをオンプレミスからクラウドに移行していることはわかりました。DevOpsは可視的でした。組織はチームを再構成し、デプロイ・パイプラインを変更し、プロセスを書き直しました。AIコーディング・ツールは、開発者ごとに、ツール・コールごとに採用されています。リスクは、ほとんどの組織がガバナンスの決定が行われたことを認識する前に、コードベース内で蓄積しています。

混乱は非対称的にあり、クラウドやDevOpsとは異なります。クラウドやDevOpsは新しいリスク・カテゴリを作成しましたが、人間が出荷されたコードに責任があるという前提をほとんど保持しました。AIは、最も検出が難しいポイントでその前提を侵食しています。那がこの移行を異なるものにします。露出は不可視です。そうでないときはそうではありません。

多くの企業は、オープンソースの採用を持続可能なビジネス・モデルに変えるのに苦労しています。成功する企業と失敗する企業を何が区別していますか?

オープンソースに基づいた持続可能なビジネスを構築した組織は、1つの特徴を共有しています。彼らは、実際に販売している製品について、規律を持っています。彼らはオープンソース・ソフトウェアを販売していません。それは無料です。彼らは、エンタープライズ・スケールで無料のソフトウェアを有効にするための専門知識、運用サポート、ガバナンス・インフラストラクチャー、または管理サービスを販売しています。

逆に、失敗する組織は、コミュニティの採用と商業的な牽引力を混同しています。開発者がプロジェクトを有用であるとみなすことを示すのは、高いGitHubのスター・カウントまたは大きなコミュニティです。それは、買い手がそれを支払うこと、または開発者が有用であるとみなすものが組織が実際に必要とするものであることを示すものではありません。開発者の採用からエンタープライズ・価値への翻訳には、オープンソース自体の外側に何かを構築することが必要です。明確に、ポジショニング、製品、セールス・モーションでその区別を示さない組織は、スケールへの移行に耐えられません。

開発者ファーストの組織をスケールアップする際のリーダーシップの最大の課題は何ですか?

最大の課題は、製品導入型成長で成功したスキルや直感が、エンタープライズ・スケールではあなたに反対することです。製品導入型成長は、迅速に進み、パブリックで反復し、開発者のエクスペリエンスを最適化し、商業的な動きを導くために採用を使用することを報いました。エンタープライズ・セールスは、慎重なプロセス、幹部の関係、長いサイクル、製品を買い手にとって重要な成果にマッピングする能力を報いました。

最も見られるリーダーシップのミスは、移行が主にセールス・モーションの問題であると仮定することです。那ではありません。那は組織設計の問題です。製品、ポジショニング、初期の顧客関係を構築したチームは、エンタープライズ・モーションを実行することができません。進化する必要がある組織の部分を認識することなく、製品を作成した文化を損なうことなく、新しい機能を構築することが本当に難しいです。うまくやるリーダーは、組織のどの部分が進化する必要があるかを認識し、製品を作成した文化を損なうことなく、新しい機能を構築することができます。

あなたはセキュリティと開発者の生産性の交差点で幅広い経験を持っています。企業は、急速に進化するAIの需要とセキュアで信頼できるソフトウェア・コンポーネントの需要のバランスをとる方法は何ですか?

速度とセキュリティの対立は、ツールがそれを強化したために続いています。セキュリティが開発プロセスの終わりにレビュー・ゲートとして実装されている場合、それはボトルネックです。セキュリティが開発プロセスの始まりに信頼できるコンポーネントの管理されたソースとして実装されている場合、それは何も遅くしません。

それが可能なのは、セキュリティが行われる場所をシフトしたからです。コードを書いた後にコードをレビューするのではなく、開発者とAIツールがプルするカタログを管理するのです。ソースが信頼できる場合、セキュリティのレビューによって速度は制限されません。セキュリティ作業はアップストリームで行われました。那は文化的な決定ではなく、アーキテクチャー的な決定です。ガバナンス・インフラストラクチャーへの投資が必要です。しかし、安全に配信するか、迅速に進むかを選択する必要はありません。

AIツールがコードと依存関係を生成するにつれて、キュレーションされたまたは信頼できるオープンソース・エコシステムの役割は、次の数年でどのように進化するでしょうか?

キュレーションされた信頼できるオープンソース・ソースの役割は、ベスト・プラクティスから基準要件への移行することになります。那は2つの要因によって推進されています。

最初は規制環境です。2026年の景観では、ソフトウェアのプロバンスを示すことが、ますます法的要件となっています。取締役会と規制機関は、組織がソフトウェアが元で安全であることを証明することができない質問をしています。

2番目はAI開発の速度です。AIツールがコードと依存関係を生成するにつれて、組織の手動でのレビュー能力を超える未検証のコンポーネントの量がプロダクションに到達します。開発者とAIツールのためのデフォルト・ソースとしてキュレーションされたポリシー・ガバナンス・カタログを確立した組織は、AIの速度に適切なセキュリティ・ガバナンスで対抗することができます。パブリック・レジストリと手動レビューに依存している組織は、コードの生成速度と評価の徹底性の間で拡大するギャップに直面します。

キュレーションされたエコシステムは、AI開発によって避けられない問題に対するインフラストラクチャーの答えです。

オープンソースとインフラストラクチャーのスペースで女性のCEOの1人として、あなたはリーダーシップの多様性の変化をどのように見てきましたか? まだ改善する必要があるのは何ですか?

実際の変化がありました。私はキャリアを始めたとき、オープンソースとインフラストラクチャーのエグゼクティブ・役割における女性の表現は低く、例外的なものでした。那は今ではそうではありません。エグゼクティブ・役割における女性の数が増えています。組織は、多様性の声明のパフォーマンスを超えて構造的な変化を行っています。リーダーシップのモデルは多様化しています。

残っているギャップを閉じるビジネス・ケースは抽象的なものではありません。業界が現在取り組んでいる問題、ソフトウェア・サプライ・チェーンのリスク、AIのガバナンス、セキュリティを第一の慣行とするために必要な組織の変更は、難しい問題です。多様なチームは難しい問題に対して優れた成果を生み出します。不均一なチームが見逃す仮定を、異なる視点が浮き彫りにします。那は願望の問題ではなく、異なる視点が見逃す仮定を浮き彫りにする方法の問題です。私はそれを直接見てきました。実際の進歩を遂げた組織は、所属感の不均一さを克服しています。所属感は業界全体でまだ不均一です。部屋の中にいることと、視点が真正に評価されていることとは異なります。那が次の進歩の段階で必要な変化です。

素晴らしいインタビュー、ありがとうございます。詳しく知りたい読者は、アクティブステートを訪問してください。