2026年、サプライチェーン攻撃とその対策
読了の目安: 約 6 分
2026年に入って、毎日のようにサプライチェーン攻撃のニュースを目にするようになりました。
なかでも驚きを与えたのは、開発者が日常的に信頼して使っている「VS Code（Visual Studio Code）」の拡張機能が悪用され、GitHubなどの内部リポジトリから重要なデータが流出してしまったという事件です。
GitHub内部リポジトリへの不正アクセス、「悪意あるVS Code拡張機能」が関与と特定 約3800件流出か
※ （例: Nx Console拡張機能事件）
今回は、近年Web業界やシステム開発の世界で最も大きなリスクのひとつとして警戒されている 「サプライチェーン攻撃」 について、私たちLenzが会社としてどのように向き合い、具体的にどのような対策を講じているのかを少し掘り下げてご紹介します。
サプライチェーン攻撃とは？「信頼の隙」を狙う新しい手口
「サプライチェーン」とは、もともと製品が原材料から工場、流通を経て消費者に届くまでの「供給リレー」のことを指す言葉です。
これをWebサイトやシステム開発に置き換えると、私たちがプログラムを組み立てる際、世界中の優秀なエンジニアたちが公開してくれている「便利な部品（オープンソースのライブラリやパッケージ）」を取り寄せて組み込む一連の流れになります。
現代のモノづくりにおいて、こうした外部の部品を一切使わずに、すべてをゼロから自作することは現実的ではありません。コストやスピード、そして全体のクオリティの面から考えても、すでにある実績のあるパーツを組み合わせてつくるのが定石です。
しかし、自社で開発しているシステムのセキュリティをどれだけ強固に固めていても、
仕入れた外部の部品に、最初から悪意のあるプログラム（ウイルスなど）がこっそり仕込まれていたとしたら？
当然、システムは内側から簡単に突破されてしまいます。これが、サプライチェーン攻撃の恐ろしさです。
昨今、Microsoftなど絶対的な信頼の厚い大手企業ですらターゲットになっています。その侵入経路をたどると、実は「信頼して使っていた海外の小さなプログラム部品や拡張ツール」が裏で乗っ取られていた、というケースが非常に多くなっています。
Lenzが行った対策
Lenzでは、主に以下の対策を取りました。
pnpmの導入
Lenzでは従来npmを使っていましたが、pnpmに切り替えました。
npm（Node Package Manager）とは、JavaScriptのプログラム部品（パッケージ）をインターネット上からダウンロードして、自分のプロジェクトに組み込んで管理するためのツールです。世界中で最も広く使われている標準的な管理ツールです。
pnpmとは「performant npm（パフォーマンスが良いnpm）」の略で、npmが持つ「インストールが遅い」「同じ部品を何度もダウンロードしてディスク容量を圧迫する」「意図しない部品が裏で勝手に混入する（幽霊依存）」といった弱点を、パフォーマンスと安全性の両面で改善した進化系のツールです。
信頼が置けないパッケージの排除
プログラムの部品（パッケージ）をインターネットからダウンロードして使う際、これまでの一般的な仕組み（初期のnpmなど）では、その部品が裏側でさらに必要としている別の部品（孫やひ孫にあたるパーツ）を、エンジニアの目に見えない形で自動的かつごちゃ混ぜにインストールしてしまう構造になっていました。これでは、どの部品にリスクが潜んでいるかを完全に把握することができません。
パッケージ管理ツールを 「pnpm」 へ全面的に移行することで、部品ごとの依存関係（つながり）が厳格に分離され、エンジニアが許可していない「正体不明の幽霊パッケージ」が裏側で勝手にサイトへ滑り込んでくる隙をシステム的にシャットアウトしています。
VS Code の怪しい拡張機能の排除
自動更新の停止
先述の流出事件でも問題になったのが、開発ツールの「プラグイン（拡張機能）の自動更新」です。公式の便利な拡張機能であっても、ある日突然、作者のアカウントがハッカーに乗っ取られ、不正なアップデートが配信されてしまうリスクがあります。
自動更新がオンになっていると、エンジニアが気づかないうちにウイルス入りのツールに化けてしまうのです。
このリスクを防ぐため、Lenzでは社内の開発環境におけるVS Codeの拡張機能の自動更新をすべて停止しました。セキュリティ監査ツール（Snyk）を導入し、組織の検問をクリアしたことを確認してから手動でアップデートを行う運用に変更しました。
フォルダの確認を自動で行う
VS Codeには、開こうとしているプログラムのフォルダが安全かどうかを判定する「ワークスペースの信頼（Workspace Trust）」という保護機能が備わっています。サプライチェーン攻撃の中には、「配布されたプログラムのフォルダを開いただけで、裏でこっそりウイルス入りのコマンドを自動実行させる」という手口もあります。
Lenzでは、外部から提供されたコードや過去のデータを読み込む際、この確認を自動で行うとともに、エディタ側で「外部のプログラムを勝手に自動実行しない」という安全設定を適用しています。これにより、人間の許可（手動実行）がない限り、裏側でスクリプトや自動タスクが勝手に動くのをシステム的に禁止し、開発者のパソコンが乗っ取られるリスクを未然に防いでいます。
GitHubリポジトリの保護
今回の事件ではGitHub内部リポジトリが狙われたため、GitHub側のセキュリティ強化も重要です。Lenzでは現在、以下の対策を基本的に実施しています。
- 組織レベルの2FA必須化
※ Webサービスやアプリにログインする際、従来のパスワード（知識情報）に加えて、別の認証要素（所持情報や生体情報など）を組み合わせることでセキュリティを大幅に強化する本人確認の仕組み - Fine-grained Personal Access Tokenの使用
※ アクセス権限や有効期限を最小限の範囲で厳密に制御できる新しい認証トークン - 最小権限原則に基づくアクセス制御
GitHub Advanced SecurityやDependabotの高度な設定については、弊社のリポジトリ規模では現時点で必須と判断していませんが、継続的に状況を監視し必要に応じて導入を検討しています。
終わりに
Lenzはこれからも、目に見えるデザインの美しさだけでなく、見えないツールの安全性にまで徹底的にこだわり、お客様に「ここに任せておけば、裏側まで本当に安心だ」と感じていただける誠実な開発を続けてまいります。
今後とも、どうぞよろしくお願いいたします。