·6 分サプライチェーン攻撃SCAオープンソース
オープンソース供給網攻撃、私たちのチームも例外ではない
npm/PyPIのパッケージが一つ感染すれば、それを使うすべてのプロジェクトが感染します。供給網攻撃が実際にどう起こるかと、3段階の防御。
「自分でコードを書いていないのに、なぜサービスが破られたのか」——供給網攻撃の典型的な問いです。問題は自分が書いたコードではなく、自分がインストールした他人のコードにありました。
供給網攻撃とは
私たちのプロジェクトは通常、数十〜数百のオープンソースパッケージ（npm、PyPI、RubyGemsなど）に依存しています。攻撃者がそのうちたった一つだけを感染させれば、それをインストールするすべてのプロジェクトが自動的に感染します。自分のコードを直接攻撃するよりはるかに効率的なため、ここ数年でこの手口は大きく増えています。
実際にはこう起こる
- タイポスクワッティング：人気パッケージの名前に似せた偽パッケージ（例：
lodash→iodash）を公開し、誤ってインストールされるのを待つ - メンテナーアカウントの乗っ取り：古いパッケージの管理者アカウントを乗っ取り、既存の正規パッケージにこっそり悪意あるコードを追加した新バージョンを配布
- 依存関係の混同（dependency confusion）：社内向けパッケージと同じ名前を公開レジストリに登録し、ビルドシステムが社内版の代わりに公開（悪意ある）版を取得するよう仕向ける
いずれの場合も、開発者がいつも通り`npm install`を実行するだけで感染します。何か不審な操作をしたわけではありません。
なぜ小規模チームほど脆弱か
大企業は社内レジストリのミラーリングやパッケージ承認プロセスを備えていることが多いです。一方、個人開発者や小規模チームは通常、依存関係をインストールした後、二度と見返しません。 さらにAIコード生成ツールは、必要な機能があるとあまり検証せずに新しいパッケージを提案することが多く、露出面をさらに広げています。
3段階の防御
- ロックファイルをコミットし、固定バージョンでインストールする —
package-lock.json/pnpm-lock.yamlがなければ、同じコードでも毎回異なるバージョンがインストールされる可能性があります。 - 依存関係の脆弱性を自動スキャンする — 既知の脆弱性（CVE）があるバージョンを使っていないか、定期的に、理想的にはデプロイのたびに確認してください。
- バージョンを上げる際は変更内容に目を通す — 特に最近メンテナーが変わった、あるいはダウンロード数の割に履歴が浅いパッケージは、アップデート前に一度diffを確認する習慣が大きな事故を防ぎます。
供給網攻撃は「自分が何か間違えたから」起こるのではなく、信頼していた他人のコードに裏切られる事故です。だからこそ防御も「自分のコード」だけでなく、「自分が使っている他人のコードすべて」を対象にする必要があります。
WhiteHat Codeはリポジトリの依存関係をスキャンし、既知の脆弱性があるパッケージを見つけ出し、アップグレード経路を教えてくれます。自動スキャンは無料です。