AIは組織に導入されるソフトウェアを決定するものが誰かを変えている

AIは、日常のソフトウェア開発の一部になりました。APIの生成、テストの記述、全体のアプリケーションのスケルトン化など、コーディングアシスタントは、エンジニアリングチームが問題を解決し、ソフトウェアを以前よりも迅速に配信するのを助けています。生産性の向上は明らかであり、組織は急速にソフトウェア開発ライフサイクル全体でAIを採用しています。

会話の多くは、AIが生成するコードに焦点を当てています。開発者はAI生成コードを信頼できますか？それは脆弱性を導入しますか？セキュリティチームはそれをどのようにレビューするべきですか？それらの質問は重要ですが、AIがソフトウェア開発にもたらす最も大きな変化ではありません。AIは単にコードを生成すること以外に進化し、組織に導入されるソフトウェアを決定する最初の決定に影響を与えるようになっています。

AIコーディングアシスタントは、ほとんどの場合、アプリケーションをスクラッチから構築しません。代わりに、既存のフレームワーク、オープンソースライブラリ、SDK、コンテナイメージ、パッケージエコシステムを使用してソリューションを構成します。各推奨は、アプリケーションのソフトウェア基盤を形作り、開発者が生成されたコードの最初の行をレビューする前に、しばしば決定されます。

数十年間、ソフトウェア開発における最初の信頼決定はほとんど開発者に属していましたが、現在その前提は変わり始めています。 AIは、開発者が結果を後で検証する一方で、最初の推奨を行うようになっています。その微妙な変化は、ソフトウェアサプライチェーンのセキュリティに重大な影響を及ぼします。なぜなら、各推奨は暗黙の信頼決定を伴うからです。

組織は、ソフトウェアが構築され、テストされ、デプロイされる方法を規定してきました。次の課題は、AIネイティブ開発環境におけるソフトウェアの選択を規定することです。

最初の信頼決定

各アプリケーションは、数千のコントリビューターが作成した無数のオープンソースプロジェクトによって作成されたソフトウェアに依存しています。新しい依存関係を導入する前に、開発者は通常、ドキュメントを評価し、フレームワークを比較し、コミュニティの採用をレビューし、リリースの頻度を調べ、プロジェクトがプロダクションに適しているかどうかを検討しました。開発者は常に正しい選択をしなかったかもしれませんが、各依存関係は故意に導入されました。

今日、開発者は単にAIアシスタントに「認証とPostgreSQLサポートのあるセキュアなREST APIを構築してください」と依頼できます。 数秒以内に、AIは動作するプロジェクトを生成します。その間、ランタイムを推奨し、フレームワークを選択し、ベースコンテナイメージを参照し、認証ライブラリをインポートし、SDKを選択し、依存関係マニフェストを生成します。パッケージマネージャーは、ビルドプロセス中にそれらの依存関係と推移的依存関係を解決します。

ほとんどの開発者は、AIが生成するアプリケーションをレビューしますが、AIが推奨するソフトウェアの決定をすべて調べる開発者はほとんどありません。AIは、かつて数時間の研究に費やされたソフトウェアの選択を数秒に圧縮し、開発者の代わりに最初の推奨を行うようになっています。

各推奨は信頼決定です

各ソフトウェアアーティファクトには独自の信頼チェーンがあります。ライブラリにはメンテナー、コントリビューター、リリースプロセス、署名の慣行、依存関係、出典があります。コンテナイメージは、上流のディストリビューションからソフトウェアを継承し、SDKは追加のパッケージを導入し、それぞれ信頼チェーンを拡張します。

1つのAI推奨は、数百のソフトウェアアーティファクトがアプリケーションの一部になるようにすぐに拡張する可能性があります。オープンソースは常にこのように動作します。変化しているのは、誰が最初にそれらの信頼決定を行うかです。歴史的に、開発者は信頼するコンポーネントを評価し選択しました。AIシステムは、開発者が結果を後で検証する一方で、初期の推奨を行うようになっています。

それは小さな変化のように聞こえるかもしれませんが、組織がソフトウェアサプライチェーンのセキュリティについて考える方法を根本的に変えます。

AIは動作するソフトウェアを最適化しますが、組織の信頼を最適化しません

これは、AIが悪い推奨を行っていることを意味するのではなく、むしろその逆です。

AIコーディングアシスタントは、ソフトウェアを推奨するのが上手です。なぜなら、開発者が類似の問題を解決するために使用した数百万の例から学んだからです。その結果、人気のあるフレームワーク、よくサポートされているライブラリ、馴染みのある実装パターンが自然に推奨されることになります。これが、これらのツールが非常に有用である理由です。

しかし、これらの最適化目標は、エンタープライズのセキュリティチームが回答を必要とする質問とは根本的に異なります。AIは、パッケージが組織のソフトウェアポリシーに準拠しているかどうか、コンテナイメージがソースから再構築されたかどうか、ソフトウェアの出典が検証されたかどうか、依存関係が承認されたソフトウェアソースから来ているかどうかを評価しません。

機能、人気、確率はコードを生成するための有用な信号ですが、検証の代わりとして使用されるべきではありません。

なぜ左に統合する必要があるのか

数年間、ソフトウェアサプライチェーンのセキュリティは、ソフトウェアが開発プロセスに入った後にリスクを特定することに焦点を当ててきました。脆弱性スキャナー、ソフトウェアコンポジション分析、SBOMは、アプリケーションが含むソフトウェアの可視性を大幅に改善しました。

これらのツールは依然として重要ですが、別の問題に対処しています。

AIはソフトウェアの選択を開発ライフサイクルの早い段階に移動します。したがって、従来のセキュリティコントロールが分析を開始するまでに、生成されたプロジェクトはすでに数十の依存関係を参照する可能性があり、それらは評価、修復、または置き換えが必要になります。組織は、すでに開発ワークフローに導入されたソフトウェアの選択に反応しています。

これが、私が組織が左に統合する必要があると信じる理由です。

左に統合するという考えはシンプルです。信頼は、ソフトウェアがアプリケーションの一部になる前に、ではなく、後に確立されるべきです。AIがソフトウェア開発に参加するようになると、この原則はさらに重要になります。ガバナンスは、ソフトウェアが選択される地点に、最終的にスキャンされる地点ではなく、移動する必要があります。

組織は、信頼できるソフトウェアソースを定義し、AIが推奨できるソフトウェアアーティファクトを確立し、開発ワークフローの一部になる前にそれらのアーティファクトを検証する必要があります。目的は、AIが組織のセキュリティ、コンプライアンス、エンジニアリング基準を反映するガイドライン内でソフトウェアの配信を加速することを保証することです。

AI時代のソフトウェア選択のガバナンス

組織はすでに、ソフトウェアが実行される場所、デプロイ方法、リリースを承認する人物を定義しています。組織は、AIが推奨できるソフトウェアも定義する必要があります。

これは、ソフトウェアサプライチェーンのポストが重要になる場所です。組織は、自分たちが構築するソフトウェアだけでなく、AIが自分たちの代わりに推奨するソフトウェアに対しても信頼性を持つ必要があります。その信頼性は、検証、信頼できるソフトウェアソース、開発パイプラインに入る前に開始されるガバナンスから来ます。

AIは、ソフトウェア開発を変え続けるでしょう。それは正しいことです。生産性の向上は無視できないからです。しかし、組織がAIネイティブ開発を採用するにつれて、ソフトウェアの選択が自動化されるようになっていることを認識する必要があります。

成功する組織は、信頼できるソフトウェアソースを確立し、AIが推奨するソフトウェアアーティファクトを検証し、ソフトウェアの選択にガバナンスを最初から統合する組織です。

AIは、ソフトウェアが書かれる方法を変えますが、今、より重要なのは、ソフトウェアが選択される方法を変えていることです。なぜなら、AI時代には、信頼するソフトウェアは、AIが最初に選択するソフトウェアに依存するからです。