コードの外側に潜むリスク
第2回では、AIが生成する「コードそのもの」に潜む脆弱性（インジェクションやアクセス制御の不備など）を解説しました。しかし、現代のアプリケーション開発におけるセキュリティリスクは、あなたが書いたコードの外側にも存在します。
OSSライブラリやクラウドサービス（PaaS, BaaSなど）を使ってアプリケーションを構築することは今や一般的です。 私たちは「車輪の再発明」を避けるため、無数の外部コンポーネントに依存し、「巨人の肩に乗って」日々開発を進めています。
この「依存」は開発を加速させる一方、AIの利便性が「何を信頼し、何を取り込んでいるのか」という最も重要な確認作業を忘れさせる危険性をはらんでいます。AIへの過信が、この古くからあるリスクを新たな形で増幅させるのです。
今回は、AIが開発プロセスに持ち込みがちな「ソースコードの外側」のリスク、すなわち「依存関係の脆弱性」と「サプライチェーン攻撃」に焦点を当てます。
AIは学習時に存在しなかった脆弱性は考慮できない
これは、既知の脆弱性（CVE）が含まれるライブラリ、フレームワーク、その他のソフトウェアコンポーネントを使用することによるリスクです。 攻撃者は、既知の脆弱性をスキャンするツールを使い、パッチが適用されていない「脆弱なコンポーネント」を利用しているシステムを見つけ出します。
コーディングエージェントは悪意なく、脆弱性を含む古いコードを開発者のプロジェクトに持ち込むことがあります。それは、 AIはインターネット上の膨大な公開コード（過去のブログ記事、GitHubリポジトリ、Stack Overflowの回答など）を学習データにしているためです。
その中には、学習時点では安全でも、現在では脆弱性（CVE）が発見されている古いライブラリの利用方法や、非推奨になったライブラリ、最新のライブラリと相性が悪いコードなどが含まれている可能性が当然あります。
具体例
私自身、このケースで脆弱性を生み出してしまったことがあります。
特定の環境で特定のバージョンでないと動かないライブラリを使っていましたが、そのバージョンにはデフォルト値が不適切だというCVEがありました。
AIは、私が使用している特定バージョンの脆弱性を知る由もありません。そのため、正しい回避策を提案できないのは当然です。これはAIの「欠陥」というより、現時点での「限界」として理解する必要があります。 ライブラリを使う以上、その脆弱性を定期的にチェックするのは開発者の責務です。そして、AIが提案するコードにも、その観点で疑いの目を持つ必要があるということです。
対策
専用のツールやサービスの活用が不可欠です。
例えば、Githubの「Dependabot Security Updates」を利用すると、リポジトリのセキュリティタブから、利用中の依存関係に問題があるかを簡単にチェックできます。
他にも「OSV」や「Trivy」を使い、依存関係が記されたファイルをスキャンし、既存のCVEと照合させることが可能です。これらをCI/CDパイプラインに組み込むことで、脆弱な依存関係の混入を継続的にチェックできます。
.png)
