サプライチェーン攻撃は、標的そのものではなく、標的が信頼して取り込んでいるものを汚染する攻撃です。 1つ汚染すれば、それを使っている全員に一度に届くため、効率が桁違いに高いのが特徴です。
主な手口
| 手口 | やり方 |
|---|---|
| アカウント乗っ取り | 人気ライブラリの管理者アカウントを奪い、悪意あるバージョンを公開する |
| タイポスクワッティング | 正規パッケージと1文字違いの名前で公開し、打ち間違いを待つ |
| 依存混乱 | 社内用パッケージと同名のものを公開レジストリに置き、そちらが優先されるのを狙う |
| ビルド環境の汚染 | CI やビルドサーバーを侵害し、正規のソースから悪意ある成果物を作らせる |
4つ目が最も厄介です。ソースコードを見ても何も見つかりません。 配布されているものだけが汚染されているためです。
なぜ防ぎにくいのか
通常のセキュリティ対策は「外から入ってくるもの」を疑いますが、依存ライブラリはこちらから取りに行って、自分で実行しています。ファイアウォールも認証も関係ありません。
さらに多くのパッケージ管理ツールは、インストール時にスクリプトを実行できます。install した時点で任意のコードが動くため、アプリを起動していなくても被害が発生します。
現実的な対策
完全に防ぐことはできないので、被害の範囲と気づくまでの時間を縮めるのが実務的な目標です。
- ロックファイルで版とハッシュを固定する。勝手に新しい版が入る状態にしない
- CI では通常のインストールではなくロック厳守のコマンドを使う
- 依存の自動更新は、必ずレビューを挟んでから取り込む
- SBOMを出しておき、事故公表時に自分が影響を受けるか即座に判定できるようにする
- ビルド時の権限を最小化する（本番の認証情報をCIに置かない）
実務で見るポイント
- 依存を減らすこと自体が対策になる。数行のために依存を増やさない
- 更新を止めるのも危険（既知の脆弱性が残る）。止めるのではなく、確認して入れる
- 事故は公表から対応まで数時間の勝負になる。平時に何を使っているか分かる状態にしておく