セキュリティ 2026.08.31 N

Web 開発者が知っておきたいサプライチェーン攻撃

こんにちは。
福岡オフィス所属の Rails エンジニアの N です。

当社では定期的に、技術力向上を目的とした社内勉強会を開催しています。
おかげさまで勉強会には社内外問わずたくさんの方々にご参加いただき、2026年5月度の開催で第39回目を迎えることができました。
第39回目は、「サプライチェーン攻撃と Web 開発」をテーマに、近年実際に発生したセキュリティインシデントを題材にしながら、Web アプリケーション開発者が知っておきたいポイントを紹介しました。

近年は OSS（オープンソースソフトウェア）や GitHub Actions などを活用することが当たり前になり、開発効率は飛躍的に向上しています。一方で、それらを悪用したサプライチェーン攻撃も年々増加しており、「自分たちの開発現場にも関係するテーマ」として取り上げることにしました。

サプライチェーン攻撃とは

サプライチェーン攻撃とは、企業や開発者を直接攻撃するのではなく、信頼して利用しているソフトウェアやサービスを経由して侵入する攻撃です。
Web 開発では、例えば次のようなものが対象になります。

npm package
RubyGems
GitHub Actions
Docker Image
CI/CD
OSSライブラリ

これらは日常的に利用しているため、「安全なもの」という前提で扱ってしまいがちです。しかし、その「信頼」こそが攻撃者に狙われるポイントになります。

なぜ今、サプライチェーン攻撃が増えているのか

Web 開発はここ数年で大きく変化しました。
以前は、アプリケーションが依存するライブラリは数十個程度ということも珍しくありませんでした。しかし現在では、React や Next.js などを利用したプロジェクトでは、直接インストールしているパッケージは数十個でも、その依存関係を含めると数百〜数千ものパッケージが利用されることがあります。

例えば、Next.js をインストールすると、その裏では React や Webpack をはじめ、多数のライブラリが自動的に取得されます。

my-app
  ├─ next
  ├─ react
  ├─ webpack
  ├─ ...
  └─ dozens of packages

開発者がこれらすべてのソースコードをレビューすることは現実的ではありません。
つまり、「自分で追加した覚えのないライブラリ」が、実際にはアプリケーションの一部として動作しているという状態が当たり前になっています。
これが、サプライチェーン攻撃が成立しやすい理由の一つです。

勉強会で紹介した事例

今回の勉強会では、実際に発生した4つの事例を紹介しました。

事例1: GitHub Actions "tj-actions/changed-files" の侵害

2025年には、多くのプロジェクトで利用されていた GitHub Actions の tj-actions/changed-files に悪意のあるコードが混入した事例がありました。
GitHub Actions では、次のようにバージョンタグを指定して利用することがあります。

uses: tj-actions/changed-files@v44

あるいは、

uses: tj-actions/changed-files@latest

のような指定もよく見かけます。

一見するとバージョンを固定しているように見えますが、実は Git のタグは後から別のコミットへ付け替えることができます。
そのため、昨日取得した v44 と今日取得した v44 が、同じ中身である保証はありません。
この事例では、その仕組みを悪用することで、CI/CD 実行時に GitHub Token や AWS Credentials などの機密情報が流出する可能性がありました。

このようなリスクを避けるためには、タグではなくコミットハッシュを指定して Action を利用することが推奨されています。
例えば、

uses: tj-actions/changed-files@e052d30e1c0bdf27cd806b01ca3b393f47b50c62 # v44.1.0

のように、特定のコミットを指定します。コメントでバージョンも添えておくと管理がしやすいと思います。

コミットハッシュは不変であり、タグのように別のコミットへ付け替えられることはありません。そのため、レビューしたソースコードと実際に実行されるコードが一致することが保証されます。
もちろん、アップデートしたい場合はコミットハッシュを書き換える必要がありますが、その変更は Git の差分として残るため、どのタイミングでバージョンを更新したのかを把握しやすいというメリットもあります。
GitHub でも、サードパーティ製の GitHub Actions を利用する場合は、コミットハッシュによるバージョン固定が推奨されています。

事例2: npm malware "Shai-Hulud"

JavaScript のパッケージ管理システムである npm では、悪意のあるパッケージが公開される事例が継続的に発生しています。
その中でも2025年に確認された Shai-Hulud は、従来のマルウェアとは少し異なる特徴を持っていました。

多くのサプライチェーン攻撃は「悪意のあるパッケージを公開して終わり」です。
しかし Shai-Hulud は、感染した開発環境からさらに別のプロジェクトへ感染を広げることを目的としていました。
イメージすると、次のような流れになります。

悪意のある npm package
  ↓
npm install
  ↓
postinstall script が実行される
  ↓
GitHub Token や npm Token を窃取
  ↓
GitHub Repository を改ざん
  ↓
別の npm package に悪意コードを混入
  ↓
さらに別の開発者が npm install

このように、感染した開発者自身が次の感染源になってしまう点が大きな特徴です。

なぜ npm install だけで感染するのか

npm パッケージには、インストール時に実行されるライフサイクルスクリプトを定義できます。
例えば、

{
  "scripts": {
    "postinstall": "node setup.js"
  }
}

という設定があると、 npm install を実行したタイミングで node setup.js が自動的に実行されます。
この仕組み自体は、ネイティブライブラリのビルドや初期設定など、正当な用途で広く利用されています。
しかし、攻撃者が postinstall に悪意のあるコードを仕込んだ場合、そのコードも同じように実行されてしまいます。

「依存ライブラリを取得しているだけ」と思っていた処理が、実際には外部コードを実行する処理でもあることを、勉強会で改めて注意喚起しました。

狙われたのは "CI/CD"

Shai-Hulud が特に危険だったのは、開発者の PC よりも CI/CD 環境を狙っていたことです。
CI/CD には、

GitHub Token
npm Publish Token
AWS Credentials
各種 API キー

など、デプロイやパッケージ公開に必要な認証情報が保存されています。
もしこれらが窃取されると、

GitHub Repository の改ざん
npm パッケージの乗っ取り
新しい悪意のあるバージョンの公開

など、さらに広範囲へ攻撃を拡大できます。

攻撃が成立する条件

Shai-Hulud の攻撃が成立するには、いくつかの条件があります。

悪意のあるパッケージを依存関係として取り込む
npm install を実行する
postinstall などのライフサイクルスクリプトが有効
GitHub Token や npm Token などの認証情報が利用可能
パッケージ公開やリポジトリ更新の権限を持っている

これらが揃うと、一人の開発者が感染するだけで、複数のプロジェクトや OSS へ攻撃が連鎖する可能性があります。

この事例から学べること

Shai-Hulud の事例で最も印象的だったのは、「npm install は依存ライブラリをダウンロードするだけではない」ということです。
私たちは普段、「ライブラリを追加する」という感覚で npm install を実行しています。しかし実際には、そのライブラリに含まれるスクリプトも実行しています。
つまり、便利な OSS を利用するということは、その OSS を自分たちの環境で実行することでもあるという点を改めて認識する必要があります。

事例1が「GitHub Actions を信頼する危険性」を示した事例だとすると、この事例は「npm install の意味を再認識すべき」と気付かせてくれるものと言えます。

事例3: Axios の侵害

Axios は、ブラウザや Node.js で HTTP 通信を行うためのライブラリです。
React や Vue、Next.js はもちろん、Node.js のバックエンドでも広く利用されており、ダウンロード数も非常に多い代表的な OSS の一つです。
2026年には、この Axios の npm パッケージに悪意のある依存ライブラリが追加されるというインシデントが発生しました。

攻撃の流れは次のようになります。

Axios maintainer の npm アカウント侵害
  ↓
悪意のある dependency を追加
  ↓
新しい Axios が公開される
  ↓
npm install
  ↓
postinstall 実行
  ↓
マルウェア感染

この事例で特徴的なのは、Axios 自身に脆弱性があったわけではないという点です。
問題となったのは、maintainer の npm アカウントが侵害され、正規のリリースとして悪意のある依存ライブラリが公開されてしまったことでした。

利用者から見ると、npm update あるいは npm install を実行しただけです。

「公式パッケージだから安心」という前提が崩れた象徴的な事例と言えます。

この事例から学べること

多くの開発者は、「OSS が侵害される = ソースコードが書き換えられる」というイメージを持っています。
しかし実際には、

maintainer アカウントの侵害
npm publish 権限の奪取

だけでも同じことが起こります。

つまり、OSS を公開する仕組み自体も攻撃対象であることが分かります。

事例4: TanStack の侵害

TanStack は、

TanStack Query（旧 React Query）
TanStack Router
TanStack Table

など、多くの React プロジェクトで利用されている OSS 群です。

この事例では、npm パッケージそのものではなく、GitHub Actions を利用した CI/CD の仕組みが攻撃対象になりました。
攻撃のイメージは次のようになります。

fork から Pull Request
  ↓
GitHub Actions 実行
  ↓
CI の権限を悪用
  ↓
GitHub Token を取得
  ↓
Repository 改ざん

この攻撃は、ライブラリではなくライブラリを公開する CI/CDが狙われたという点に特徴があります。

なぜ攻撃が成立したのか

GitHub Actions には、

pull_request
pull_request_target

という似たイベントがあります。

pull_request_target は便利な反面、設定によっては Repository への書き込み権限を持った状態で実行されることがあります。

さらに、

Actions Cache
OIDC Token
write permission

などが組み合わされることで、攻撃者に権限を奪われる可能性があります。

そのため、GitHub Actions の Workflow は、「動けばよい」ではなく、「どの権限で実行されるのか」まで理解して設計する必要があるということを認識しなければなりません。

この事例から学べること

GitHub Actions は CI/CD を実現する便利なツールですが、一方で

GitHub Token
AWS Credentials
npm Publish Token

などの多くの認証情報を扱います。つまり、CI/CD は攻撃者にとっても非常に価値の高い環境なのです。

アプリケーションのコードだけでなく、CI/CD の設定そのものもレビュー対象であることを、この事例は教えてくれます。

Axios や TanStack は、多くの Web アプリケーションで利用されている有名な OSS です。
これらの事例から分かるのは、「有名な OSS だから安全」というわけではないということです。
利用者が多い OSS ほど攻撃対象として魅力的であり、一度侵害されれば非常に広範囲へ影響が及びます。

最後に

今回の勉強会で紹介した事例は、いずれも実際に発生したインシデントです。
どれも高度なゼロデイ攻撃というより、普段から利用している OSS や CI/CD を狙った攻撃である点が共通しています。

現代の Web 開発は、「OSS を利用している」のではなく、「OSS を実行している」と言っても過言ではありません。
便利な OSS やクラウドサービスを活用することは、開発効率を高める上で欠かせません。その一方で、それらが攻撃対象になり得ることを理解し、公式の Advisory やセキュリティ情報を継続的にキャッチアップしていくことも、これからの Web 開発者に求められる重要なスキルだと感じています。

当社では今後も、このような社内勉強会を通じて技術や知識を共有し、チーム全体の技術力向上に取り組んでいきます。
今後も勉強会の内容や技術的な取り組みについて、このブログで発信していく予定です。ぜひご覧ください。

ブログ一覧に戻る