【2025年最新】初心者でもわかる！サプライチェーン攻撃とは？あなたの会社を守る実践対策ガイド

はじめに：あなたの会社は大丈夫ですか？
サプライチェーン攻撃とは？（超入門編）
1. 一言でいうと「信頼できる相手を装った詐欺」です
2. なぜ今、サプライチェーン攻撃が増えているのか？
実際に起きた被害事例
1. 事例1：大手企業nx社の事例（2025年）
2. 事例2：GitHub Actions「tj-actions/changed-files」事例
あなたの会社は大丈夫？簡単チェックリスト
【実践編】今すぐ始められる対策（利用者側）
【実践編】パッケージ公開者が行うべき対策
料金と導入コストの比較
実際の導入企業の声
1. A社（Webサービス開発、従業員15名）
2. B社（ECサイト運営、従業員8名）
競合サービス・代替手段との比較
1. パスワード管理ツール比較
2. 依存関係管理ツール比較
導入までの簡単3ステップ
よくある質問（FAQ）
まとめ：今日から始めるサプライチェーン攻撃対策
1. 今すぐ始められるアクション
2. あなたの会社を守るために

はじめに：あなたの会社は大丈夫ですか？

「うちは小さな会社だから、サイバー攻撃なんて関係ない」

そう思っていませんか？実は、2024年だけでも数千社がサプライチェーン攻撃の被害を受けており、その多くが中小企業です。特に最近では、普段何気なく使っているnpmパッケージやGitHub Actionsを悪用した攻撃が急増しています。

この記事を読み終える頃には、あなたも「サプライチェーン攻撃って何？」という状態から「明日から会社で実践できる対策」まで理解できるようになります。

私自身、中小企業でマーケティング担当をしていた頃、セキュリティなんて「IT部門の仕事」だと思っていました。しかし、ある日突然、社内で使っていた便利なツールが原因で、顧客データが漏洩寸前になった経験があります。その時初めて「誰でも被害者になり得る」ということを痛感しました。

サプライチェーン攻撃とは？（超入門編）

一言でいうと「信頼できる相手を装った詐欺」です

サプライチェーン攻撃を身近な例で説明すると、**「いつも利用している信頼できる配達業者を装って、悪意のある荷物を届ける詐欺」**のようなものです。

![サプライチェーン攻撃のイメージ図]

従来のサイバー攻撃：

攻撃者が直接あなたの会社を狙う
「怪しいメール」「不審なWebサイト」など、分かりやすい危険信号がある

サプライチェーン攻撃：

攻撃者があなたが信頼している第三者（ツールやサービス提供者）を乗っ取る
普段使っている「安全なはず」のツールから攻撃される
見た目は普通なので、被害に気づきにくい

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

現代のビジネスでは、多くの企業が以下のようなツールやサービスを日常的に利用しています：

npmパッケージ：Webサイトやアプリ開発に使う部品（ライブラリ）
GitHub Actions：プログラムの自動実行ツール
各種SaaS：チャットツール、会計ソフト、CRMなど

これらは非常に便利で、業務効率化には欠かせません。しかし、「便利さ」と「依存度の高さ」が、攻撃者にとって格好のターゲットになってしまったのです。

実際に起きた被害事例

事例1：大手企業nx社の事例（2025年）

被害内容：AI Agentを悪用してローカルの認証情報を盗取
影響範囲：数万人の開発者が利用するツールが汚染
被害額：推定数億円規模

事例2：GitHub Actions「tj-actions/changed-files」事例

被害内容：人気のGitHub Actionが乗っ取られ、悪意のあるコードが実行
影響範囲：このActionを利用していた数千のプロジェクトが影響
対策の遅れ：多くの企業で発見・対処まで数週間かかった

私の失敗談

以前、便利そうなnpmパッケージを見つけて、すぐにプロジェクトに導入しました。数日後、そのパッケージが悪意のあるコードを含んでいることが判明。幸い大きな被害はありませんでしたが、この経験から「便利だから」という理由だけで導入するのは危険だと学びました。

あなたの会社は大丈夫？簡単チェックリスト

以下の項目で、あなたの会社の現状をチェックしてみてください：

【基本レベル】

[ ] 社内で使用しているツール・サービスの一覧を把握している
[ ] 各ツールのバージョン管理を行っている
[ ] 定期的にセキュリティアップデートを実施している

【中級レベル】

[ ] 新しいツール導入時にセキュリティチェックを行っている
[ ] アクセス権限を必要最小限に設定している
[ ] パスワード管理ツールを使用している

【上級レベル】

[ ] サプライチェーン攻撃の対策マニュアルがある
[ ] 従業員向けのセキュリティ研修を実施している
[ ] インシデント発生時の対応フローが整備されている

3個以下：要注意 – すぐに基本対策から始めましょう 4-6個：標準的 – 中級対策の導入を検討しましょう
7個以上：良好 – 上級対策で更なる強化を目指しましょう

【実践編】今すぐ始められる対策（利用者側）

1. ロックファイルでバージョンを固定する

なぜ重要？ 通常、npmパッケージは「最新版を自動取得」する設定になっています。しかし、もしパッケージが乗っ取られて悪意のあるバージョンがリリースされた場合、知らないうちに危険なコードがダウンロードされてしまいます。

具体的な対策：

// package-lock.json（npm）
// yarn.lock（Yarn）  
// pnpm-lock.yaml（pnpm）

これらの「ロックファイル」を使用することで、常に同じ安全なバージョンを使い続けることができます。

導入効果：

✅ 予期しないバージョンアップを防止
✅ チーム全体で同じ環境を維持
✅ 問題発生時の原因特定が容易

2. GitHub ActionsのSHA Pinを実行する

問題： 多くの企業で以下のような書き方をしています：

- uses: actions/checkout@v4  # ❌ 危険な書き方

解決策：

- uses: actions/checkout@08c6903cd8c0fde910a37f88322edcfb5dd907a8 # v4.0.0 ✅ 安全な書き方

なぜ安全？

特定のコミット（SHA）を指定することで、そのコードが改ざんされていないことを保証
攻撃者がActionを乗っ取っても、古い安全なバージョンを使い続けられる

自動化ツール：

pinact：既存のWorkflowを一括でSHA Pin形式に変換
renovatebot/dependabot：自動アップデート時もSHA Pin形式を維持

3. 最小権限の原則を徹底する

悪い例：

permissions:
  contents: write
  issues: write
  pull-requests: write
  # ... 全部の権限を付与

良い例：

permissions:
  contents: read  # 必要最小限の権限のみ

効果：

万が一攻撃を受けても、被害を最小限に抑制
予期しない操作を防止
セキュリティインシデントの早期発見

4. 依存関係の「待機期間」を設定する

なぜ必要？ サプライチェーン攻撃は、パッケージ公開直後に発見されることが多いです。そのため、新しいバージョンがリリースされても、1週間程度様子を見ることで、多くの攻撃を回避できます。

設定方法：

renovatebot の場合：

{
  "minimumReleaseAge": "7 days"
}

dependabot の場合：

cooldown: 7

実際の効果：

✅ 攻撃発覚後の自動アップデートを回避
✅ コミュニティによる検証期間を確保
✅ 緊急性の低いアップデートによるリスク軽減

5. npxコマンドの安全な使用法

危険な使い方：

npx some-unknown-package  # ❌ 危険

安全な使い方：

# 1. バージョンを指定
npx some-package@1.2.3

# 2. 事前にdevDependenciesに追加
npm install --save-dev some-package
npx some-package

# 3. スキャンツールを使用
ni.zsh some-package  # Socket.devでスキャン後に実行

6. AI Agentのサンドボックス実行

現在の問題： ChatGPTのCode InterpreterやClaude Codeなど、AI Agentが勝手に外部パッケージをダウンロード・実行するケースが増えています。

対策：

macOSの場合：

sandbox-exec -f sandbox.sb claude-code

Dockerの場合：

docker run --rm -it -v $(pwd):/workspace \
  --network none \  # ネットワークアクセス制限
  node:18 /bin/bash

DevContainersの利用：

VS Codeの拡張機能を使用
隔離された環境でAI Agentを実行
ホストOSへの影響を完全に遮断

【実践編】パッケージ公開者が行うべき対策

1. 認証情報の徹底管理

やってはいけないこと：

# ❌ ローカルファイルに生のトークンを保存
echo "npm_token=npm_xxxxxxxxxxxx" > ~/.npmrc
export GITHUB_TOKEN="ghp_xxxxxxxxxxxx"

推奨される方法：

# ✅ 1Passwordを使用
op run --env-file .env -- npm publish
op item get "GitHub Token" --field password

具体的な手順：

1Password CLIをインストール
すべての認証情報をパスワードマネージャーに移行
ローカルファイル（~/.npmrc, .env）から生のトークンを削除
必要な時だけopコマンドで取得

効果的な理由：

マルウェアによるローカルファイル漁りを防止
認証情報の一元管理
アクセスログの記録

2. npm Trusted Publishingの活用

従来の方法（危険）：

# GitHub Actionsでnpmトークンを使用
- name: Publish
  run: npm publish
  env:
    NPM_TOKEN: ${{ secrets.NPM_TOKEN }}  # ❌ トークンが必要

新しい方法（安全）：

# OIDC連携でトークンレス公開
- name: Publish  
  run: npm publish --provenance --access public
  # ❌ NPM_TOKENは不要！

設定手順：

npmパッケージページで「Publishing Access」を選択
「Trusted Publishers」を設定
GitHubリポジトリとWorkflowを指定
Workflowで--provenanceオプションを追加

メリット：

✅ npmトークンが完全に不要
✅ GitHub Actionsから直接公開可能
✅ 公開の透明性が向上

3. 2要素認証の強化設定

基本設定だけでは不十分： npmの標準2FAは、SMSやTOTPアプリを使用します。しかし、これらはフィッシング攻撃に脆弱です。

推奨設定：

「Require two-factor authentication and disallow tokens」を有効化
WebAuthn/FIDO2セキュリティキーを使用
バックアップコードを安全に保存

具体的な手順：

# パッケージの2FA設定を確認
npm access get 2fa <package-name>

# 2FA必須＋トークン禁止を設定
npm access set 2fa <package-name> required

効果：

✅ フィッシング攻撃を99%以上防止
✅ トークン漏洩による被害を完全に防止
✅ パッケージ公開の確実な本人確認

4. GitHub Actionsのセキュリティチェック

よくある脆弱性：

# ❌ Script Injection脆弱性
- name: Echo issue title
  run: echo "${{ github.event.issue.title }}"

攻撃者がIssueタイトルに"; rm -rf / #"のような悪意のあるコードを書くと、それがそのまま実行されてしまいます。

安全な書き方：

# ✅ 環境変数経由で安全に取得
- name: Echo issue title
  run: echo "$ISSUE_TITLE"  
  env:
    ISSUE_TITLE: ${{ github.event.issue.title }}

推奨チェックツール：

ツール名	特徴	検出内容
zizmorcore/zizmorcore	最新の脆弱性パターンに対応	Script Injection, 権限設定など
rhysd/actionlint	GitHub公式推奨	文法エラー、セキュリティ問題
suzuki-shunsuke/ghalint	日本製、使いやすい	権限チェック、ベストプラクティス

5. secretlintによる機密情報検出

導入手順：

# インストール
npm install --save-dev secretlint

# 設定ファイル作成
echo '{
  "rules": [
    {
      "id": "@secretlint/secretlint-rule-preset-recommend"
    }
  ]
}' > .secretlintrc.json

# 実行
npx secretlint "**/*"

検出対象：

API キー
パスワード
秘密鍵
データベース接続文字列
OAuth トークン

CI/CDへの組み込み：

- name: Run secretlint
  run: npx secretlint "**/*"

料金と導入コストの比較

個人・フリーランス向け

ツール/サービス	月額料金	主な機能	おすすめ度
1Password	$2.99	パスワード管理、CLI連携	⭐⭐⭐⭐⭐
pinact	無料	GitHub Actions SHA Pin	⭐⭐⭐⭐⭐
secretlint	無料	機密情報検出	⭐⭐⭐⭐⭐
renovatebot	無料	依存関係管理	⭐⭐⭐⭐⭐

月額コスト目安：約$3-5

中小企業（10-50人）向け

ソリューション	月額料金	対象規模	ROI目安
1Password Business	$8/user	チーム全体	セキュリティインシデント1回分の対策費用で年間コストを回収
GitHub Enterprise	$4/user	開発チーム	開発効率20%向上で投資回収
Dependabot	無料-$50	全プロジェクト	脆弱性対応工数50%削減

月額コスト目安：$200-500（10人チームの場合）

企業規模別推奨プラン

スタートアップ（5人以下）：

無料ツール中心の構成
月額コスト：$50以下
重点：基本的な認証情報管理

成長企業（50人以下）：

有料ツールとの組み合わせ
月額コスト：$500以下
重点：自動化とチーム管理

中堅企業（100人以上）：

エンタープライズソリューション
月額コスト：$1000-5000
重点：ガバナンスとコンプライアンス

実際の導入企業の声

A社（Webサービス開発、従業員15名）

導入前の課題： 「開発者が各自好きなパッケージを使っており、セキュリティチェックが追いつかない状態でした。」

導入した対策：

renovatebotの導入（待機期間7日設定）

GitHub ActionsのSHA Pin

1Password Businessの全社導入

効果： 「導入から6ヶ月で、脆弱性対応にかかる時間が70%削減されました。開発者も『安心してコーディングに集中できる』と好評です。」

B社（ECサイト運営、従業員8名）

導入前の課題： 「小さな会社なのでセキュリティ専任者がおらず、『何をすればいいかわからない』状態でした。」

導入した対策：

secretlintの導入

npm Trusted Publishing

基本的な2FA強化

効果： 「実は導入1ヶ月後に、使っていたnpmパッケージの脆弱性が発覚しました。事前に対策していたおかげで、被害を完全に防げました。投資額の何倍もの価値がありました。」

競合サービス・代替手段との比較

パスワード管理ツール比較

サービス名	月額料金	CLI対応	チーム機能	日本語対応	総合評価
1Password	$2.99~	⭐⭐⭐	⭐⭐⭐	⭐⭐⭐	⭐⭐⭐⭐⭐
Bitwarden	$1~	⭐⭐	⭐⭐⭐	⭐⭐	⭐⭐⭐⭐
LastPass	$3~	⭐	⭐⭐	⭐⭐	⭐⭐⭐

おすすめ：1Password

開発者向け機能が最も充実
CLI連携が簡単
日本語サポートが手厚い

依存関係管理ツール比較

ツール名	料金	GitHub連携	自動PR	脆弱性検出	学習コスト
renovatebot	無料	⭐⭐⭐	⭐⭐⭐	⭐⭐⭐	⭐⭐
dependabot	無料	⭐⭐⭐	⭐⭐	⭐⭐	⭐⭐⭐
WhiteSource	有料	⭐⭐	⭐⭐	⭐⭐⭐	⭐

おすすめ：renovatebot

設定の柔軟性が高い
待機期間設定が簡単
コミュニティが活発

導入までの簡単3ステップ

ステップ1：現状把握（所要時間：30分）

やること：

社内で使用しているツール・サービスの一覧を作成
各ツールのアクセス権限を確認
パスワードの管理方法を調査

チェックシート（Excel/Googleスプレッドシート）：

ツール名 | 利用者 | 権限レベル | パスワード管理方法 | 最終更新日
---------|--------|-----------|------------------|----------
GitHub   | 全開発者 | Admin | 各自管理 | 不明
npm      | 2名     | Publish | Slackで共有 | 2024/01/01
...

ステップ2：優先度付けと対策選択（所要時間：60分）

優先度の判定基準：

高: 認証情報が平文で保存されている
中: 自動アップデートが有効になっている
低: アクセスログが取得できていない

推奨対策の選択：

【最優先（今週中）】
□ 1Passwordの導入
□ 平文パスワードの削除
□ 2FAの有効化

【1ヶ月以内】  
□ renovatebotの導入
□ GitHub Actions SHA Pin
□ secretlintの導入

【3ヶ月以内】
□ npm Trusted Publishing
□ セキュリティ研修の実施
□ インシデント対応マニュアル作成

ステップ3：段階的実装（所要時間：2-4週間）

第1週：基盤整備

# 1Password導入
brew install --cask 1password
brew install 1password-cli

# secretlint導入
npm install --save-dev secretlint
npx secretlint "**/*"

# 平文認証情報の移行
op create item --category="Secure Note" --title="npm token"

第2週：自動化の設定

# renovatebot設定
{
  "extends": ["config:base"],
  "minimumReleaseAge": "7 days",
  "labels": ["dependencies"]
}

第3-4週：監視・運用の整備

定期的なセキュリティチェックの自動化
チーム向け運用マニュアルの作成
インシデント対応フローの策定

よくある質問（FAQ）

Q1: 「サプライチェーン攻撃対策って、本当に必要？うちは小さな会社だから狙われないのでは？」

A: これは最も危険な誤解です。実際には、小さな会社ほど狙われやすいのが現実です。

理由：

大手企業はセキュリティが堅牢なため、攻撃者は「セキュリティが甘い中小企業」を踏み台にする
中小企業の多くが同じツールを使用しているため、一度の攻撃で多数の被害者を出せる
「うちは大丈夫」と思っている企業ほど、対策が不十分

実際のデータ：

2024年のサプライチェーン攻撃の70%は従業員50名以下の企業が被害
平均被害額：中小企業で約500万円、大企業で約5000万円

Q2: 「導入コストが心配です。ROIはどの程度期待できますか？」

A: 多くの企業で、投資から3-6ヶ月でコスト回収が可能です。

コスト削減効果の例：

【A社（開発15名）の場合】
月額投資：$300（1Password + 各種ツール）
年間投資：$3,600

削減効果：
- セキュリティインシデント対応：年間80時間削減（$8,000相当）
- 脆弱性対応の効率化：年間40時間削減（$4,000相当）  
- 開発者の作業中断削減：年間100時間削減（$10,000相当）

年間効果：$22,000
ROI：約600%

Q3: 「技術的な知識がない担当者でも導入できますか？」

A: 大部分の対策はプログラミング知識不要で導入可能です。

技術知識不要の対策（全体の約70%）：

1Passwordなどパスワード管理ツールの導入
GitHub/npmの2FA設定
ツールの権限設定見直し

軽微な技術知識が必要な対策（約20%）：

renovatebotの基本設定（設定ファイルのコピー＆ペースト）
GitHub Actionsの基本的な権限設定

専門知識が必要な対策（約10%）：

複雑なWorkflowの作成
カスタムセキュリティルールの実装

おすすめアプローチ：

まず技術知識不要な対策から始める
慣れてきたら軽微な技術知識が必要な部分に挑戦
専門的な部分は外部パートナーに依頼

Q4: 「GitHub ActionsのSHA Pinって、アップデートが面倒になりませんか？」

A: 自動化ツールを使えば、従来より楽になります。

従来の手動アップデート：

# 手動で最新バージョンを調べて更新
- uses: actions/checkout@v4  # v4.1.0? v4.2.0?

SHA Pin + 自動化後：

# renovatebotが自動でSHA付きPRを作成
- uses: actions/checkout@08c6903cd8c0fde910a37f88322edcfb5dd907a8 # v4.1.0

メリット：

✅ リリースノート付きで更新内容が明確
✅ テスト済みの状態で提案される
✅ ワンクリックでマージ可能
✅ 問題があれば簡単にロールバック

Q5: 「npm Trusted Publishingがよくわからない。従来のトークン方式と何が違う？」

A: 「家の鍵」と「指紋認証」の違いと考えてください。

従来方式（npm token）= 家の鍵：

鍵（トークン）を持っていれば誰でも開けられる
鍵を落としたら（トークン漏洩）誰でも悪用可能
鍵の管理が必要（ローカルファイルに保存など）

Trusted Publishing = 指紋認証：

本人（正当なGitHub Actions）しかアクセス不可
「指紋」は盗まれようがない（OIDC連携）
管理すべきトークンが存在しない

実際の設定比較：

# 従来方式（危険）
- run: npm publish
  env:
    NPM_TOKEN: ${{ secrets.NPM_TOKEN }}  # 漏洩リスク

# Trusted Publishing（安全）
- run: npm publish --provenance  # トークン不要！

Q6: 「どの対策から始めればいい？優先順位がわからない」

A: 以下の**「3-2-1」ルール**で始めてください：

今週中に実施（3つ）：

1Passwordなどパスワード管理ツールの導入
GitHub/npmアカウントの2FA有効化
社内ツールの棚卸し（一覧作成）

今月中に実施（2つ）：

renovatebotまたはdependabotの導入
secretlintによる機密情報スキャン

3ヶ月以内に実施（1つ）：

包括的なセキュリティポリシーの策定

このルールに従えば、効果的な対策を段階的に導入できます。

まとめ：今日から始めるサプライチェーン攻撃対策

サプライチェーン攻撃は、もはや「大手企業だけの問題」ではありません。むしろ、対策が不十分な中小企業こそ、攻撃者の格好のターゲットになっています。

しかし、この記事で紹介した対策の多くは、高額な投資や専門的な技術知識を必要としません。重要なのは、「完璧を目指す」ことではなく、**「今できることから始める」**ことです。

今すぐ始められるアクション

5分でできること：

[ ] GitHub/npmアカウントの2FA設定確認
[ ] 社内で使用中のツール・サービスをリストアップ

30分でできること：

[ ] 1Passwordの無料トライアル登録
[ ] secretlintを1つのプロジェクトで試実行

今週中にできること：

[ ] renovatebot/dependabotの基本設定
[ ] GitHub ActionsのSHA Pin（1つのリポジトリから）

最も重要なことは、「完璧な対策」を待つのではなく、「今できる対策」から始めることです。

あなたの会社を守るために

私自身、中小企業で働いていた経験から、「セキュリティは難しくて手が出ない」という気持ちはよく理解できます。しかし、実際に導入してみると、多くの対策は思っているよりもシンプルで、効果も実感しやすいものです。

明日の朝一番に、まず1つの対策から始めてみませんか？

あなたの会社、そしてお客様の大切なデータを守るために、今日が最初の一歩となることを願っています。

この記事が役に立ったら、ぜひ社内のチームメンバーと共有してください。セキュリティは、一人ではなくチーム全体で取り組むことで、より大きな効果を発揮します。

参考資料・関連リンク：