「npm install」や「cargo build」を、中身をたしかめずに打っていませんか。
じつは今、そのコマンド1回で攻撃が成立する事件が起きました。2026年8月20日、Rustのライブラリ配布サイトで「組み立てただけで外部のプログラムが動く」仕掛けが見つかったのです。
この記事では、サプライチェーン攻撃という手口の仕組みと、新社会人エンジニアが明日から気をつけられることをお伝えします。
結論を先に言います。依存ライブラリは「他人が書いた実行コード」です。自分のコードから1行も呼び出していなくても、ビルドの時点で相手のコードは動きます。
サプライチェーン攻撃とは?信頼している部品をねらう手口
サプライチェーン攻撃とは、あなた自身ではなく、あなたが信頼している部品のほうをねらう攻撃のことです。サプライチェーンとは、部品が手元にとどくまでの流れを指す言葉です。
なぜこの手口が成り立つのか。今のアプリは、ほとんどが他人の書いたライブラリの組み合わせでできているからです。小さなアプリでも、依存のつながりをたどれば数百個の部品が入っていることはめずらしくありません。それを1つずつ読む人はいません。
工場でたとえてみます。あなたの工場の門をどれだけ厳重にしても、毎日とどく部品の箱に細工がされていたら意味がありません。攻撃者は門を破らず、部品を作る側にまわりこむわけです。
守るべき範囲が「自分のコード」から「自分が使うすべての部品」に広がった。これがサプライチェーン攻撃のやっかいなところです。
arrayref事件で何が起きたのか:86分だけ存在したわな
今回のサプライチェーン攻撃は、Rustでよく使われる arrayref というライブラリで起きました。
公開されている事実を並べます。
- 2026年8月20日の7時15分(協定世界時)に arrayref 0.3.10 が公開された
- およそ86分後の8時41分に削除された
- arrayref の累計ダウンロードは、約2億4500万回にのぼる
- 同じ作者の internment 0.8.7 と append-only-vec 0.1.9 にも同じ仕掛けが入っていた
ただし、作者本人が犯人というわけではなさそうです。Rustの公式チームは、作者のパソコンかログイン用の鍵が乗っ取られたとみて、アカウントを止めました。
長年信頼されてきたライブラリでも、アカウントが1つ乗っ取られればわなに変わる。ここが今回のこわさです。
なぜ「ビルドしただけ」で危ないのか:ビルドスクリプトという盲点
危ないのは、多くの言語のパッケージが「取りこむときに走るコード」を持てるからです。
Rustには build.rs というビルドスクリプトの仕組みがあります。本来はC言語で書かれた部品を一緒にコンパイルするなど、まっとうな目的のためのものです。今回はそこが悪用されました。
流れはこうです。
- arrayref 0.3.10 が、proc-macro1 という部品を新たに読みこむようになる
- proc-macro1 は、有名な proc-macro2 に1文字だけ寄せた偽物だった
- ビルドすると、その偽物のビルドスクリプトが動きだす
- 外部のサーバーからプログラムを落としてきて、そのまま実行する
大事なのは、あなたのコードが arrayref を呼んでいるかどうかは関係ない、という点です。cargo build と打った時点で成立します。npm の postinstall や、Pythonの setup.py も同じ性質を持っています。
「呼び出さなければ安全」は通用しません。取ってきた時点、組み立てた時点が、すでに危険地帯なのです。
サプライチェーン攻撃の巧妙な誘導:取り下げの警告を悪用する
今回いちばん学びが多いのは、技術ではなく人の心理をついた部分です。
攻撃者は、arrayref の古い版(0.3.5から0.3.9まで)をまとめて yank しました。yank とは「この版はもう使わないでください」という取り下げの印のことです。
取り下げられると、cargo は「取り下げられていない版への更新を検討してください」と警告を出します。開発者はその警告を消したくて、素直に版を上げます。そして、取り下げられていない唯一の版が、悪意のある 0.3.10 だったわけです。
つまり、ツールが出す親切な警告が、そのままわなへの案内板になりました。警告に従うこと自体は、まったく正しい行動です。正しい行動だからこそ、この誘導はよく効きます。
新社会人エンジニアが今日からできるサプライチェーン攻撃への備え
完全に防ぐ方法はありませんが、被害を減らす習慣はあります。むずかしい道具はいりません。
- ロックファイルをコミットする: package-lock.json や Cargo.lock をリポジトリに必ず入れる。版が勝手に上がらなくなります
- 更新の差分をたしかめる: 依存を上げるときは、何が新しく増えたかを見る。今回も「見慣れない部品が1つ増えた」が唯一のサインでした
- 出たての新版にすぐ飛びつかない: 数日おくらせるだけで、86分で消えるような事故はほぼ避けられます
- 公式のお知らせを追う: 使っている言語のセキュリティ情報を購読しておく
そして、もう1つ。自分のアカウントを守ることも、この鎖の一部です。あなたが将来ライブラリを公開する側になったとき、2段階の認証を切っていたら、今回の作者と同じ立場に立たされます。
ロックファイル、差分の確認、少し待つ。この3つだけでも、じゅうぶんに効果があります。
インフラ運用の立場では、サプライチェーン攻撃をどう守るか
開発者向けの対策は本文のとおりですが、筆者のようにサーバーやCI/CD基盤を運用する側から見ると、守るポイントが少し変わります。「開発者のPCで防ぎ切る」前提を捨て、ビルドが走る環境の側に壁を作るのが定石です。セキュリティ製品の導入・管理を担当してきた経験も踏まえ、筆者が実務で確認している項目を挙げます。
- ビルド環境の外向き通信を絞る: CIランナーから任意のドメインへ通信できる状態は、今回のような「ビルド時に外部へ接続する」型の攻撃にそのまま効いてしまう。許可先をパッケージレジストリ等に限定する
- lockfileの固定とレビュー: 依存の更新は自動で入れず、lockfileの差分をレビュー対象にする。「バージョンが変わっただけの差分」を読み飛ばさない
- ビルド用の権限を分離する: ビルドジョブに本番の認証情報を渡さない。取られて困るものが手の届く場所にあるかどうかで、同じ攻撃でも被害が桁で変わる
- EDR/監視のアラートを「開発マシンだから」で無視しない: ビルドサーバーからの不審な外部通信は、まさに今回の型の兆候
新人の方へ筆者からの一言はこれです。会社のPCや検証サーバーで「とりあえず sudo でインストール」をしないこと。依存を1つ足すことは、他人のコードに自分の環境の鍵を1本渡すことと同じ——この感覚を最初に持てるかどうかが、数年後のセキュリティ意識の土台になります。
まとめ:サプライチェーン攻撃から学ぶ「依存の重さ」
- サプライチェーン攻撃は、あなたではなく、あなたが信頼する部品をねらってくる
- ビルドスクリプトがあるため、コードを呼び出さなくても被害を受けることがある
- ロックファイルの管理と、更新の差分をたしかめる習慣が、いちばん手軽な防御になる
まずは今の仕事のリポジトリを開いて、ロックファイルがきちんとコミットされているか見てみてください。そこが第一歩です。
あわせて読みたい
「信用していたものが汚染される」という攻撃は、以下の記事にも共通します。
コメント