1. はじめに：城門を固めても「仕入れ業者」から侵入される時代
Webセキュリティといえば、何を思い浮かべますか？
- SQLインジェクション
- クロスサイトスクリプティング（XSS）
- パスワードリスト攻撃
これらはすべて、「自分の城（アプリやサーバー）の守りを固める」** ことで防げる攻撃でした。
しかし今、世界中の企業を震え上がらせているのが 「サプライチェーン攻撃（ソフトウェア・サプライチェーン攻撃）」です。
自社のセキュリティがどれほど鉄壁でも「仕入れた部品（外部ライブラリ）」に毒が仕込まれていたら一発で突破されてしまうという、非常に厄介で恐ろしい攻撃です。
今回は、このサプライチェーン攻撃の仕組みと、なぜ現代のフロントエンド開発で pnpm への移行やロックファイルの厳格化 が進んでいるのかを分かりやすく解説します！
2. サプライチェーン攻撃とは？（レストランに例えてみる）
日常の例えで考えると一発でイメージできます。
-
従来のハッキング:
泥棒がレストランの金庫を直接こじ開けようとする（セキュリティ対策で防ぎやすい）。 -
サプライチェーン攻撃:
レストランの金庫は固いので諦めて、レストランが信頼して仕入れている「食材の問屋」に毒を盛る。
これを Web 開発（JavaScript / TypeScript エコシステム）に置き換えるとこうなります：
「あなたの会社を直接ハッキングするのは難しいから、あなたの会社が
package.jsonで読み込んでいるオープンソース（npmパッケージ）を乗っ取って、そこにウイルスを仕込んでおこう」
3. なぜ現代の Web 開発は狙われやすいのか？
私たちが普段作っているモダンな Web アプリは、「膨大なオープンソースの積み木」 の上で動いています。
あなたが直接書いたコード: たった 1,000 行
インストールしたライブラリ: 数十万〜数百万行（node_modules）
自分が直接 yarn add したライブラリは 20〜30 個程度でも、そのライブラリが別のライブラリを呼び出し、それがさらに別のライブラリを呼び出し…と連鎖した結果、パソコンの中には 1,000 個以上の見知らぬパッケージがダウンロードされています。
攻撃者は、この「誰も1行1行中身を読んでいない大量の依存パッケージ」のどこか1つに不正なコードを忍ばせるのです。
4. 実際に起きた背筋の凍る実例
決して映画の話ではありません。npm の世界では実際に重大事件が起きています。
事件①：有名パッケージ event-stream 乗っ取り事件
- 概要: 週に数百万回ダウンロードされる超有名パッケージの作者が、多忙を理由に親切そうに近づいてきた見知らぬ開発者にメンテナンス権限を譲渡した。
- 結末: その開発者はハッカーであり、特定のビットコインウォレットから暗号資産を盗み出す悪意あるコードがこっそりアップデートとして配信されてしまった。
事件②：タイポスクワッティング（打ち間違い狙い）
-
手口: 有名ライブラリ
lodash（ローダッシュ）に対して、スペルミスしやすいloadashという名前の偽パッケージを勝手に公開する。 -
結末: エンジニアがうっかりタイプミスして
npm install loadashと打つと、裏でパソコンのパスワードや秘密鍵がハッカーのサーバーに盗み出される。
5. 私たち開発者ができる実践的な防衛策
では、私たち現場の開発者はどうやってこの見えない脅威からアプリを守ればいいのでしょうか？
今すぐ現場で導入できる 4つの強力な防御策 を紹介します。
① パッケージマネージャーを pnpm に乗り換える（最重要！）
実は、従来の npm や yarn (v1) には 「幽霊依存（Phantom Dependencies）」 という構造的な弱点がありました。
-
従来の yarn v1 / npm:
自分が直接インストールしていない「ライブラリのライブラリ（孫部品）」まで、node_modulesの平らな場所にバラ撒いてしまう。そのため、コード内から勝手に隠れたパッケージを呼び出せてしまう危険 があった。 -
モダンな
pnpm:
厳格なシンボリックリンク構造を採用しており、「自分がpackage.jsonに明記した安全なパッケージ」以外は、コードから絶対に呼び出せないように物理的に隔離・ブロック してくれる。
pnpm を使うだけで、意図しない不正パッケージの呼び出しを未然に防ぐことができます。
② バージョン指定から ^（キャレット）や ~（チルダ）を消す
package.json を開いてみてください。こんな書き方をしていませんか？
// 危険な書き方（自動で勝手にバージョンが上がってしまう）
"dependencies": {
"axios": "^1.6.0"
}
この ^ がついていると、yarn install や npm install を叩いたときに、「1.6.0 以上で最新のもの（1.6.1 や 1.7.0 など）」を勝手に取ってきてしまいます。
もしそのタイミングでハッカーが不正な悪意あるバージョンを配信していたら、自動で毒を飲み込むことになります。
// 安全な書き方（完全にバージョンを固定する）
"dependencies": {
"axios": "1.6.0"
}
数字をピン留め（完全固定）し、勝手なアップデートを防ぎましょう。
③ ロックファイルをコミットし、CI では --frozen-lockfile を使う
package-lock.json や yarn.lock、pnpm-lock.yaml は、「過去に安全確認が取れた正確なダウンロード記録」 です。
CI/CD（GitHub Actions 等）でビルドするときは、必ず以下のコマンドを使います：
# 勝手な依存関係の更新を一切許可せず、ロックファイル通りにのみインストールする
$ pnpm install --frozen-lockfile
# (yarn の場合: yarn install --frozen-lockfile)
もしロックファイルと異なる不正なパッケージが紛れ込もうとした場合、インストールが即座にエラーで停止します。
④ 定期的に audit（監査）コマンドを回す
脆弱性が報告された危険なパッケージを早期発見するため、コマンドを実行します。
$ pnpm audit
# または
$ npm audit
GitHub を使っているなら、Dependabot を有効にしておくだけでも、危険なライブラリが発見されたときにプルリクエストで自動通知してくれます。
6. まとめ
-
サプライチェーン攻撃とは:
強固な自社システムではなく、「信頼して使っている外部ライブラリ（OSS）」に罠を仕掛ける卑劣な攻撃。 -
防衛の要は「見知らぬコードを勝手に動かさないこと」:
-
pnpmで幽霊パッケージへのアクセスを物理遮断する -
package.jsonでバージョンを完全固定する -
--frozen-lockfileで予期せぬ更新を弾く
-
「ライブラリのアップデート」や「パッケージマネージャーの選定」は、単なるツールの好みの問題ではなく、アプリとユーザーの安全を守る立派なセキュリティ対策 です。
ぜひ皆さんのプロジェクトでも、足元のパッケージ管理を見直してみてください！