目次
はじめに
現代のアプリケーション開発では、コードの大半がインターネット経由で取得するオープンソースコンポーネントで構成されるケースが一般的です。
開発スピードを上げるために不可欠な一方で、その「入手経路」そのものが、いまサイバー攻撃の主要ターゲットになっています。
近年のサプライチェーン攻撃は、完成したソフトウェアを後からスキャンして検知するのではなく、開発者の端末やCI/CD環境に“最初から入り込む”方向へ進化しています。
本記事では、npmエコシステムを狙う攻撃トレンドを踏まえながら、なぜSBOM整備だけでは守りきれないのか、そしてなぜ「入口で止める仕組み（リポジトリ・ファイアウォール）」が必要なのかを整理します。
npmエコシステムで何が起きているのか（攻撃が“開発者”を狙う理由）
npmは依存関係の連鎖が深く、開発現場では自動的に大量のパッケージが取得されます。
攻撃者にとっては、プロダクト本体よりも「依存を引き込む入口」を汚染したほうが、影響範囲を一気に広げやすい構造です。
さらに厄介なのは、攻撃の狙いが「脆弱性の悪用」だけでなく、開発者やCI/CDが持つ“鍵（シークレット）”を奪うことに寄っている点です。
一度でもトークンや認証情報が抜かれると、以降はパッケージ公開権限の乗っ取りや、組織のリポジトリ・CIへの横展開が現実になります。
開発者を狙う最新の攻撃手口：トークン窃取と破壊活動
1：インストール時の即時実行（postinstall等）
かつては「脆弱性が見つかったらパッチを当てる」が中心でしたが、現在はインストールした瞬間に実行されるタイプの攻撃が問題になります。
つまり、脆弱性スキャンやSBOMの確認を“後で”やっている間に、すでに被害が始まっている可能性がある、ということです。
2：認証情報・シークレットの窃取（トークン／SSHキー等）
近年のnpm攻撃では、GitHubトークン、npmトークン、クラウド資格情報、SSHキーなど、開発者PCやCI/CDに置かれがちな秘密情報の探索・送信が主目的になるケースが報告されています。
いわば「コードを壊す」のではなく「鍵を盗んで、正規の顔で侵入する」タイプです。
3：破壊活動（“遮断したら削除”のような脅し）
さらに悪質なケースとして、拡散や送信経路が塞がれた場合に、ユーザー環境のデータ破壊を示唆する仕組み（いわゆるデッドマンズスイッチ）が指摘される事例もあります。
「止めようとすると被害が増える」構造を作られると、初動が遅れるほど損失が膨らみやすくなります。
ここまでくると、“後で見つける”では間に合いません。
危険なコンポーネントをダウンロードさせない（少なくとも安全性が確認できるまで止める）という入口対策が現実的になります。
「SBOM（部品表）」と「入口防御」の決定的な違い
サプライチェーン対策としてSBOM（ソフトウェア部品表）の整備が進んでいますが、ここで重要な誤解があります。
SBOMはあくまで「目録（Inventory）」であり、防御システムではないという点です。
-
SBOMが得意：
「何が含まれているか」を可視化し、影響範囲を追いやすくする（監査・取引先要件への説明にも有効） -
SBOMが苦手：
“ダウンロードそのもの”や“インストール時実行”を止めることはできない（事後確認になりやすい）
だからこそ、SBOMは重要ですが、それ単体では不十分になりやすいのです。
必要なのは、SBOMを「作る」だけでなく、入口（取得）・工程（利用）・証跡（説明）をつないで運用する設計です。
解決策：「リポジトリ・ファイアウォール」で入口を守る
そこで重要になるのが、組織のリポジトリ（例：Nexus Repositoryなど）の入口で、
取得時点のリスクを評価し、危険なものを“持ち込ませない”考え方です。
Sonatypeが提唱する Sonatype Repository Firewall は、まさにこの入口防御を狙ったアプローチです。
1：Fail Close（判定中は止める／隔離する）
現代の攻撃は「公開されたばかり」「突然ふるまいが変わった」など、初動での判定が重要になります。
入口での評価を前提に、安全性が確認できるまでダウンロードを止める（または隔離する）運用は、
“後から火消し”を減らすうえで効果的です。
2：悪意あるコンポーネントを“開発者に届く前”に遮断
既知の脆弱性だけでなく、マルウェア混入や不審な挙動が疑われるコンポーネントを、 開発者PCに届く前にブロック／隔離できれば、インストール時実行型の被害を構造的に減らせます。
3：後追い対応を減らし、証跡を残す
入口で止めた理由や判断履歴が残ると、現場の運用はラクになります。
「なぜ止めたのか」「どこで止めたのか」が整理されれば、例外運用も“属人化”しにくくなり、
結果として説明責任（監査・取引先要件）にも転用しやすくなります。
リモートワーク時代の死角「Shadow Download」をどう塞ぐか
もう一つの落とし穴が、開発者やビルドがリポジトリを経由せず、
直接インターネットから依存を取得してしまう Shadow Download（シャドーダウンロード） です。
この経路が残ると、入口対策をしていても“横から入られる”状態になります。
対策としては、開発端末やネットワーク境界での制御と、リポジトリ側の統制を組み合わせ、
「どこで開発していても同じポリシーが効く」状態を作るのがポイントです。
たとえば、境界型の仕組みと連携して、リポジトリを迂回する取得経路にもマルウェア対策を適用する考え方があります。
失敗しない評価（PoC）の進め方
PoCで重要なのは、「全部やる」よりも、1つの運用課題に絞って成果を見える化することです。
-
ステップ1：課題を1つに絞る
例：npm依存の入口対策を固める／Shadow Downloadを塞ぐ／SBOM提出の作業を減らす など。 -
ステップ2：KPIを先に置く
例：危険コンポーネントの流入件数／検出〜封じ込め時間／例外運用の回数／説明資料作成工数。 -
ステップ3：入口→工程→証跡の順で整える
入口で止める（流入削減）→工程で直す（手戻り削減）→証跡で説明する（監査対応の平準化）。
この順番は、現場負荷が増えにくく効果が見えやすいです。 -
ステップ4：ポリシーは“最小”から
最初から厳しすぎると例外運用が増えます。まずは「止めるべき最重要条件」から始め、段階的に強化します。
実務での活用アイデア（すぐ効く運用パターン）
-
入口（リポジトリ）で“危険な流入”を構造的に減らす：
インストール時実行型の被害は、届く前に止めるのが最も効率的です。 -
CI/CDで“止める基準”を統一する：
チームごとの判断ブレを減らし、例外運用の属人化を抑えます。 -
SBOMを「作る」から「運用する」へ：
SBOM/AIBOMを集約し、継続監視と説明資料作成を“仕組み化”すると、対応が平準化します。 -
Shadow Downloadの塞ぎ込み：
迂回経路を潰す設計を入れると、入口対策の効果が安定します。
まとめ
SBOMはサプライチェーンの透明性を高める重要な仕組みですが、それ自体は“防御装置”ではありません。
インストール時に実行され、シークレットを奪い、場合によっては破壊活動まで伴う攻撃が現実になっている今、
事後対応ではなく「入口で止める」発想が不可欠です。
開発スピードを落とさずにセキュリティを担保するには、 入口（止める）→工程（直す）→証跡（説明する）をつないで運用することが鍵になります。
当ブログでは今後も、事例を題材に、 「実務でどう使えるか」という観点から情報を発信していきます。 ぜひブックマークのうえ、最新記事をお見逃しなく！