10月10日、Bruce Gainが「AI coding tools run riot over SBOM controls as EU CRA looms」と題した記事を公開した。AIコーディングツールの普及がSBOM（Software Bill of Materials）管理を形骸化させ、EU CRA（サイバーレジリエンス法）への対応をさらに困難にしている実態について詳しく報じている。
AIエージェントはSBOMに映らないまま脆弱なコードを持ち込む
問題の核心はシンプルだ。AIコーディングツールはCVE（既知の脆弱性）を抱えた古いオープンソースコードを拾い上げ、アプリケーションに組み込む。しかしそのコンポーネントはSBOMに記載されない。
OmdiaのアナリストTorsten Volkはこの問題をOpen Source Summit Europeの場でこう説明した。
「エージェントはCVEが付いた古いオープンソースコードを引っ張ってきてアプリに貼り付け、その脆弱性をそのまま持ち込む。しかし元のコンポーネントはSBOMに一切現れない」
SBOMとは、ソフトウェア製品に含まれる全コンポーネントのリストであり、依存関係やライセンス情報を一元管理するための仕組みだ。NTIA（米国国家電気通信情報局）やCISAが標準化を推進しており、SPDXやCycloneDXといったフォーマットが広く使われている。EU CRAは2027年12月までにSBOMの提出を義務付けるが、AIが生成・参照したコードに対してはこの仕組みが根本的に機能しない、というのがVolkの主張だ。
「AIエージェントがアプリに様々なコードを挿入できる以上、『他から再利用したコードは全て開示せよ』という指示に従うという前提に頼る静的解析だけでは不十分だ。この課題を解決するには、既存コードベースの文脈の中で新しいコードを継続的にスキャンし続ける必要がある」（Volk）
Linux Foundationが600人超のグローバルな回答者を対象に実施した調査では、94%の組織がGenAIコーディングツールを利用中またはパイロット中と回答。さらに48%がオープンソースソフトウェアの利用が増えたと答えている。AIツールによって、開発者はライブラリのセットアップやAPIドキュメントの精読なしに、以前より広範囲のライブラリを手軽に本番環境に持ち込めるようになった。その利便性の裏側に、この問題がある。
「スロップスクワッティング」という新手の攻撃
AIが引き起こすサプライチェーンリスクは、既存コードの脆弱性取り込みだけではない。スロップスクワッティング（Slopsquatting）と呼ばれる攻撃手法が実例として挙がった。
手口はこうだ。攻撃者がClaudeなどのAIに「使えるライブラリを列挙せよ」と指示すると、AIは存在しないライブラリ名を「でっち上げ」て回答する。攻撃者はその名前でnpmやPyPIにパッケージを公開し、悪意あるコードを仕込む。別の開発者がAIの回答を信じてそのパッケージをインストールすると、キー窃取やデータ盗難などの被害に遭う。SBOMは「AIが発明した名前のライブラリ」を正しく追跡できないため、ここでも機能不全に陥る。なお、スロップスクワッティングは従来のタイポスクワッティング攻撃のAI時代版とも言える手口で、AIの「幻覚（ハルシネーション）」を悪用する点が新しい。
Linuxカーネルでも顕在化
Linuxの生みの親Linus Torvaldsも同じSummitのキーノートでこの問題に言及した。元記事によれば直近のLinuxリリースでは、過去最多となる2,652人の開発者が60万行のコードを追加した。コミット中「Assisted-by」タグ（AI使用の開示）が付いたものは1,111件に上り、それ以前のリリースの31件から急増している。
「非常に重要なセキュリティ問題に関するパッチが届く一方で、誰も20年間触っていないコードへのパッチも来る。AIボットに『メモリリークはあるか？』と聞けば、『そのドライバを誰も使っていなくても構わない。エラーレポートを全部出す』と答える」（Torvalds）
パッチの増加はメンテナーを疲弊させており、Torvaldsはレビュー支援にAIを活用することの重要性も認めた。
CNFCのSBOMプロジェクトメンテナーでもあるKubermaticのMario Fahlandtは、「自分たちの環境の中に何が入っているか把握できていない。全ての依存関係は、メンテナーも含めて誰にとっても謎だ」と述べた。PR（プルリクエスト）がAI生成になるほど、メンテナーの負担が増し、脆弱性やサプライチェーン攻撃の見落としリスクも高まるという。
対策として浮上している2つのアプローチ
Fahlandt自身は現実的な対策として、毎週日曜に走るGitHub Actionを紹介した。2,500のワーカーがCNCFプロジェクトのリポジトリをスキャンし、リリースタグに基づいたSBOMを生成してAmazon S3に格納する。現在16,000件のSBOMが蓄積されている。
もう一つの方向性はコンテナワークロードの分離強化だ。コンテナセキュリティベンダーのEderaはKubernetes上でAIエージェントとコンテナワークロードをハードウェア分離型のmicroVMで包む仕組みを提案している。
「すべてのエージェントに、文字通り全てに、専用のmicroVMとプライベートなLinuxカーネルを割り当てる。既存のKubernetesクラスター上で動作する」（Edera VP of Engineering、Kavitha Daula）
ただしKata Containersのようなオープンソースの分離アプローチはスケール時のコストが課題とされており、解決策は一枚岩ではない。
EU CRAの脆弱性報告義務は2026年9月に発効済みであり、SBOM義務化の期限は2027年12月に迫る。AIツールの利用を前提とした新しいサプライチェーン管理の仕組みを、今から設計し直す必要がある局面だ。
詳細はAI coding tools run riot over SBOM controls as EU CRA loomsを参照していただきたい。
