96%依存の現実と、生成AIがもたらすOSSサプライチェーンの新しい脆さ

今日の深掘りポイント

• 企業コードベースの大半がOSSに依存する現在、AI生成コードは「量」を押し上げる一方で、メンテナ負荷とトリアージ遅延を通じてリスクの「確率」と「影響」を同時に増幅します。
• 生成AIによる低品質PRの氾濫は、単なるコード品質問題ではなく、サプライチェーン妥協（MITRE ATT&CK: Supply Chain Compromise）に直結する運用課題です。ガバナンス不在は攻撃者の遊び場になります。
• データは、OSSの普及（Synopsys）とAI支援コードの脆弱性傾向（学術研究）、そしてxzバックドアのような現実の侵入事例が、一本の線で結びつくことを示唆します。
• 対応は「人とプロセスと証跡」。AI使用開示ルール、強制レビューと署名・証跡、そしてSLSA/Scorecard/SSDFでの段階的成熟化が、最短で効果の出る投資です。
• 業務インパクトの勘所はMTTT（Mean Time To Triage）とCVEパッチ遅延の二軸。AIが増やす“雑音”を可視化・抑制できる組織ほど、攻撃機会の窓を狭められます。

はじめに

96%のコードベースがオープンソースを含むという現実は、もはや常識の域に達しました。Synopsysの年次レポートは、企業ソフトウェアのほぼすべてがOSSに依拠している事実を繰り返し示しています。一方で、生成AIの普及に伴い、質のばらつきが大きいコードやPRが大量に生まれ、保守負荷とサプライチェーンの露出面を拡大しています。コミュニティ側でもAI生成の「スロップ（粗い提案）」が議論になっており、メンテナによる無償のレビュー・統合工程に負債が乗る構図が鮮明になりつつあります。

このテーマは、技術論（脆弱なコード）と運用論（トリアージ不能）と信頼論（サプライチェーン妥協）の三層問題です。今日は、一次情報に沿って事実と示唆を切り分け、CISO/SOC/Threat Intelの意思決定につながる視点を整理します。

深掘り詳細

事実：OSS依存の規模、AIコードの脆弱傾向、そして実例

• OSS依存の広がり
  • SynopsysのOpen Source Security and Risk Analysis（OSSRA）は、コードベースの96%がOSSを含むと報告しています。企業のアプリケーションは、意識の有無にかかわらずOSSに深く組み込まれていることを示す数字です。Synopsys OSSRA
• 生成AIと脆弱性傾向
  • GitHub Copilot等のAI支援によるコード提案の安全性を評価した研究は、提案の相当割合が脆弱であることを示しています。たとえば「Asleep at the Keyboard? Assessing the Security of GitHub Copilot’s Code Contributions」では、多数のタスクでAI提案にセキュリティ問題が含まれる結果が示されています（攻撃面の誤用例とともに詳細分析）。arXiv:2108.09293
• サプライチェーン侵入の現実例
  • 2024年のxz Utilsバックドア（CVE-2024-3094）は、OSSメンテナ体制の脆弱さ（人手と信頼の集中）を突いた典型例です。圧縮ライブラリの依存連鎖に潜り込み、SSH認証に影響しうる改ざんが仕込まれた一件は、検出・是正の最後の砦が少数のメンテナだったことを露呈しました。NVD CVE-2024-3094、oss-security投稿（発見経緯）
• 政府・重要インフラへの波及認識
  • CISAはOSSセキュリティのロードマップを公表し、OSSの安全性を国家・重要インフラの根幹課題として位置づけています。生成AIにより依存と変更頻度が増す局面では、この方針の重要性が増しています。CISA Open Source Software Security Roadmap

補助線として、コミュニティ側のAIスロップ議論はThe New Stackがわかりやすくまとめています。AI提案の質・量と、メンテナ体力の非対称性が鍵だという視点は示唆的です。The New Stack: AI Slop in Open Source

インサイト：リスクは「コード品質」よりも「運用窒息」で顕在化します

• リスクの一次波は、脆弱なコード断片の流入です。しかし二次波として、低品質PRと議論の洪水がメンテナのMTTT（Mean Time To Triage）を押し上げ、結果として既知脆弱性のパッチ適用が遅れます。攻撃者にとっては“露出時間の延伸”こそが実益で、AIがもたらすのはこの時間的アービトラージです。
• xzの教訓は、攻撃者が「善意の貢献」やメンテナ交代、CI設定変更など社会的・運用的接点を踏み台にしてくることでした。AI生成の提案は、その接点の“数”を爆発的に増やし、ソーシャル・テクニカルの境界を曖昧にします。
• 狙うべきKPIは、コード品質の静的指標だけではありません。以下の“流量・証跡・信頼”の3指標が、AI時代のサプライチェーン健全性を現場で可視化します。
  • 流量：一人当たりトリアージ可能件数に対する外部PR流入量の比率、初回コントリビュータの比率、ファイル種別の変更分布（CI/ビルド・リリース周辺が増えていないか）。
  • 証跡：署名付きコミット率、SBOMの鮮度、ビルドの再現可能性/SLSAレベル、リリースアテステーションの有無。
  • 信頼：Code Owners網羅率、二重レビュー率、権限昇格イベントの頻度、保護ブランチ逸脱イベント。
• メトリクス全体からは、差し迫った実務対応余地が大きい一方、新規性よりも「既知の良い作法をAI時代に拡張適用する」ことの方が効果的だと読めます。過度な恐怖ではなく、標準化された工学的コントロールで“雑音”を制御するのが近道です。

脅威シナリオと影響

以下は仮説に基づくシナリオですが、xz事案や学術知見に照らして十分現実的なリスクプロファイルです。MITRE ATT&CKの関連技法を併記します。

• シナリオ1：AI生成PRを梃子にしたサプライチェーン妥協

  • 仮説：攻撃者がAI生成の小粒PRを継続投入し、信頼を獲得。CI設定や依存定義への変更を段階的に混在させ、メンテナのレビュー疲労を狙って改ざんを通過させる。
  • 関連ATT&CK：Supply Chain Compromise（T1195）、Subvert Trust Controls: Code Signing（T1553.002）、Stage Capabilities: Upload Malware to Repository（T1608.001）
  • 影響：悪性依存の混入、改ざんバイナリの配布、組織内ビルドチェーンの信頼崩壊。下流消費者ではリモート実行や認証回避に波及。

• シナリオ2：AIが量産する低品質コードが攻撃可能面を拡大

  • 仮説：開発現場でAI提案の安易採用が増え、入力検証不足や認可欠落などの古典的欠陥が散発的に混入。SASTやIASTの誤検知増でセキュリティチームのアラート疲労が進行。
  • 関連ATT&CK：Exploitation for Client Execution（T1203）、Exploitation of Remote Services（T1210）、Valid Accounts（T1078）など欠陥悪用の下位連鎖
  • 影響：侵入経路の多様化、検知遅延、平均侵害コストの上昇。

• シナリオ3：レジストリ/パッケージ流通での偽装・信頼迂回

  • 仮説：AIで大量生成した類似名パッケージ（typosquatting）や便利スニペット集を公開し、プロジェクトの依存解決やサンプル追従で下流へ侵入。
  • 関連ATT&CK：Trusted Relationship（T1199）、Masquerading（T1036）、Stage Capabilities（T1608）
  • 影響：開発者端末やCI上でのトークン窃取、サプライチェーン全体の信頼低下。

検知・初動の勘所（横断）としては、GitHub/GitLabの監査ログでの初回コントリビュータ挙動監視、コミット署名の逸脱、CI/CDワークフローの権限変更、依存定義とリリーススクリプトの頻回改変に注視するのが実践的です。

セキュリティ担当者のアクション

今日から90日を目安に、負荷と効果のバランスがよい順で整理します。

• ガバナンスと開示

  • AI使用開示を義務化します。PRテンプレートに「AI補助の有無」「プロンプト要約」「リスク箇所（入力/認可/暗号）」のチェック項目を追加し、未記入はレビュー非対象にします。
  • CODEOWNERSを整備し、ビルド・リリース・依存定義・CI設定は二重承認とします。保護ブランチと必須ステータスチェックを有効化します。
  • SSDF（NIST SP 800-218）のプラクティスを自社・委託先双方に適用し、調達要件にSBOM（SPDX/CycloneDX）と脆弱性対応SLOを明記します。NIST SP 800-218

• 自動化と証跡（“機械で塞ぐ”）

  • OSSF ScorecardとAllstar等でレポ健全性の自動監査を有効化し、スコア閾値を満たさないPRをゲートします。OpenSSF Scorecard
  • 依存・SAST・シークレット・IaCの統合スキャンをPRに必須化し、SARIFで可観測化します。CI成果物にアテステーション（SLSAレベル到達）を付与し、署名（Sigstore/cosign）を徹底します。SLSA / Sigstore
  • 脆弱性管理はOSV連携でCVE識別と修正提案を自動化し、MTTTとパッチ遅延のダッシュボードを運用メトリクスとして可視化します。OSV

• 人の最適化（“疲弊させない”）

  • 初回コントリビュータ向けに「安全な変更の範囲」を明確化し、CIやリリース周辺の変更は原則メンテナ起案とします。
  • セキュリティレビューは「リスクの濃淡」でキューを分離し、CI/依存/ビルド関連にSRE/セキュリティが同席する“赤キュー”を設置します。
  • 重要OSSへの資金・工数支援を意思決定します。自社が重依存する少数レポに対し、レビュー工数のスポンサーやバグバウンティ連携を設定します。（CISAの方針とも整合的です）CISA OSS Roadmap

• インシデント準備

  • xz型イベントの想定で“依存凍結→代替ピン留め→鍵ローテーション→再配布停止”のプレイブックを定義し、レジストリ/アーティファクトの撤回・置換手順を演習します。
  • 署名失効と信頼チェーン再確立のランブックをSREと共有し、ビルドキャッシュの破棄と再現ビルドの手順を自動化します。
  • 監査ログの保持期間を延長し、PR／コミット署名／CI権限変更の相関が取れる形でSIEMに連携します。

最後に、これは恐れるための議論ではないです。メトリクス全体の含意は、課題が実務に近く、手の届く標準策で前進できることです。AIは開発を加速します。そのエネルギーを安全に流すための“護岸工事”を、今日から静かに、しかし着実に積み上げていきたいです。

参考情報

• Synopsys: Open Source Security and Risk Analysis（OSSRA）https://www.synopsys.com/software-integrity/resources/analyst-reports/open-source-security-risk-analysis.html
• Asleep at the Keyboard? Assessing the Security of GitHub Copilot’s Code Contributions（arXiv）https://arxiv.org/abs/2108.09293
• NVD: CVE-2024-3094（xz Utils Backdoor）https://nvd.nist.gov/vuln/detail/CVE-2024-3094
• oss-security: xzバックドア発見経緯（Andres Freund投稿）https://www.openwall.com/lists/oss-security/2024/03/29/4
• CISA Open Source Software Security Roadmap https://www.cisa.gov/resources-tools/resources/open-source-software-security-roadmap
• NIST SP 800-218（SSDF）https://csrc.nist.gov/publications/detail/sp/800-218/final
• OpenSSF Scorecard https://securityscorecards.dev/
• SLSA（Supply-chain Levels for Software Artifacts）https://slsa.dev/
• Sigstore https://www.sigstore.dev/
• OSV（Open Source Vulnerabilities）https://osv.dev/
• The New Stack: AI Slop in Open Source https://thenewstack.io/ai-slop-open-source/