AIによって生成されたコードが脆弱性管理モデルを壊す理由

AIコードジェネレーターは、DevOpsツールがこれまで達成できなかったことを成し遂げました。つまり、週間で実現できた機能を数日で実現できるようにしました。しかし、問題は、速度が脆弱性にも同様に適用されることです。

セキュリティの分野で働いてきた私が見てきたところ、組織は同じ反応的なパターンを繰り返しています。つまり、脆弱性を発見し、その範囲を理解しようとし、修正の所有権をめぐって議論し、数週間または数ヶ月後に修正を適用します。AIはこのパターンを変えていません。ただし、古いモデルが追いつくことができないほどのペースでそれを加速させました。重要なCVEの平均MTTRは60日を超えています。AI支援開発では、60日はありません。毎スプリントで新しいコードベースが生成されます。

依存関係の問題は今やAIの問題です

企業アプリケーションの96%はオープンソースコンポーネントを含みます。大多数は厳格に検証されたものではなく、単に公開レジストリから引き出されたものです。セキュリティチームはこれに対して長年の間苦闘してきましたが、AIコーディングアシスタントはこの状況をより制御不能なものに変えました。

開発者が手動でコードを書くとき、依存関係についての意図的な選択を行います。AIモデルがコードを生成するとき、トレーニングデータから情報を引き出します。つまり、ハルシネーションされたパッケージ、古いバージョン、または既知のCVEを持つコンポーネントが含まれる可能性があります。コードはきれいに見えますが、リスクは依存関係ツリーの数層下に、誰も見ていない場所に埋もれています。

セキュリティレビューで、チームが以前承認したパッケージの間接的な依存関係に重大なCVEを見つけたことがあります。パッケージ自体は問題なかったのですが、それが引き出したものが問題でした。このダイナミクスは、組織のセキュリティポストを理解できないAIツールを使用する数百人の開発者によって、現在機械スケールで発生しています。

事後的なスキャニングは戦略ではありません

オープンソースソフトウェアのセキュリティの一般的なモデルは、スキャニングとパッチ適用です。スキャナーを実行し、結果をトライアージュし、チケットを割り当て、待ちます。このモデルは常に反応的であり、AI加速開発環境では完全に追いつきません。

スキャナーはコードにすでに存在する問題を見つけます。問題が導入されてから発見されるまでの時間差が、脆弱性の Window になります。AIが大規模にコードを生成すると、この時間差が広がり、スキャナーの結果が増え、チームが手動で修正できるよりも速くなります。結果として、CVEのバックログが無限に増え、優先順位付けがあいまいになり、開発者がビジネス価値のない作業に4〜8時間を費やすようになります。

さらに、ガバナンスの崩壊が続き、状況は悪化します。修正の所有権はしばしば不明です。セキュリティチームがCVEをフラグし、エンジニアリングチームが構成問題と呼び、運用チームがコードの問題と呼ぶのを見たことがあります。20年前に見たパターンは今でも続いています。AIはこの曖昧さの結果をより吸収しづらくしています。

実際に機能するシフト：入力するものを制御する

この問題に対処している組織は、セキュリティを確保するためにスキャニングに頼るのを止め、代わりに開発者とAIツールが使用できるオープンソースコンポーネントを最初から制御することにしました。メカニズムは、ソースからビルドされた、ポリシーより管理されたオープンソースコンポーネントのカタログです。これは、PyPI、npm、またはMavenなどのパブリックエコシステムからの直接プルを置き換えるプライベート内部レジストリとして提供され、継続的に監視されます。

このアプローチは、セキュリティを最も直接的な意味で左にシフトします。脆弱性は、ビルドパイプラインに入る前に、消費されるポイントでブロックされます。開発者はいつものようにツールを使用します。AIコーディングアシスタントは、同じ管理されたソースから依存関係を解決します。セキュリティチームはポリシーを一度設定し、それが人間が確認しない2時に出てきたモデルによって生成されたコードにも適用されます。

実践での見方

セキュリティリーダーがこの問題に対処する場合、以下の点が重要です。

1. AIアドプションを拡大する前に、承認されたコンポーネントセットを定義します。AIコーディングツールがパブリックレジストリからの依存関係を解決している場合、承認プロセスは紙上でのみ存在します。管理された内部レジストリを確立し、すべてのものをそれを介してルーティングし、コンポーネントがソースからビルドされ、検証可能な出典を持つことを要求します。
2. 修正を管理されたプロセスとして扱い、チケットキューとして扱わないでください。CVEの負債を先に進める組織は、手動での修正を速めることではありません。手動修正を方程式から除去しました。コミュニティによって承認されたパッチが利用可能な場合、それは自動的にカタログに再構築され、開発者は次にプルするときに更新を受け取ります。誰もチケットを割り当てず、誰も60日間待ちません。
3. コンプライアンス義務に応じてAIツールチェーンをマッピングし、強制される前にします。チームがAIツールを使用して数ヶ月間開発した後、顧客がFedRAMPの整合性やSOC 2の証拠を要求したときに壁に当たったのを見たことがあります。カタログはコンプライアンスの監査証跡でもあります。SBOMと出典レコードは、コンポーネントと一緒に提供されるべきであり、締め切りの下で後から組み立てるべきではありません。
4. ガバナンスレイヤーで、チケットレイヤーでなく、明確な所有権を割り当てます。修正に最も迅速に対応するチームは、最も多くの開発者を持つチームではありません。セキュリティチームがポリシーを所有し、プラットフォームチームが配信を所有し、どちらも他方が行動するのを待っていないチームです。

ブロックするのではなく有効にするセキュリティ

セキュリティと開発の速度が基本的に矛盾していると言う信念があります。しかし、セキュリティがプロセスに組み込まれている場合、つまり後から追加されるのではなく、そんなことは私が見たことがありません。カタログ化されたコンポーネントセットから作業する開発者は、実際にはより迅速に動きます。なぜなら、承認を疑問視したり、セキュリティレビューを待ったり、上流でブロックできる脆弱性を後からクリーンアップしたりする必要がないからです。

AI駆動開発を行う際に、持続不能なセキュリティ負債を蓄積せずに進む組織は、最も多くのスキャナーを実行している組織ではありません。むしろ、ソフトウェアサプライチェーンに何が入るかを事前に管理することを意図的に決定した組織です。那決定はリーダーシップに属します。実行するためのツールは今日存在します。