サプライチェーン攻撃とは何ですか？

ソフトウェアの依存関係（npmパッケージ、Pythonライブラリ等）やCI/CDパイプラインを悪用して、正規の開発・配布プロセスにマルウェアを混入させる攻撃手法です。

サプライチェーン攻撃を防ぐ最も効果的な方法は？

複数レイヤーの防御が必要です。(1)依存関係の自動更新（Renovate/Dependabot）、(2)悪意あるパッケージの検出（Socket.dev）、(3)GitHub ActionsのSHA固定、(4)SBOMの生成と管理が基本です。

RenovateとDependabotの違いは？

Dependabotは設定不要でGitHub統合が強みです。Renovateは90+エコシステム対応、グループ化、minimumReleaseAge（リリース直後のバージョンを避ける）等の高度な制御が可能です。

SBOMとは何ですか？

Software Bill of Materials（ソフトウェア部品表）の略で、ソフトウェアに含まれるすべてのコンポーネントとそのバージョンを一覧化した文書です。EU CRA規制で2027年12月から義務化されます。

SLSAフレームワークとは？

Supply-chain Levels for Software Artifacts（SLSA、サルサ）はビルドの完全性を保証するフレームワークです。L0〜L3の4レベルがあり、L3ではハーメティックビルドと改ざん不可能な来歴証明が要求されます。

サプライチェーンセキュリティ完全ガイド2026｜攻撃手法・防御ツール・実践チェックリスト

2026年3月、人気HTTPクライアント「Axios」のサプライチェーンが攻撃され、895以上のリポジトリが数時間で感染した。自動マージされたPRの60%にマルウェアが混入していた——。

ソフトウェアサプライチェーン攻撃は、IPA「情報セキュリティ10大脅威2026」で2位（4年連続）にランクされ、開発者にとって最も身近な脅威の一つとなった。Sonatypeの報告によれば、2025年にブロックされた悪意あるパッケージは45万4,600件に達し、累計123万件を超えている。

本記事は「サプライチェーン攻撃とは何か」を解説するだけでなく、Renovate/Dependabotの設定、GitHub ActionsのSHA固定、SBOMの生成コマンドまで、開発者が今日から実装できる防御策をコード付きで提供する。

サプライチェーン攻撃とは——開発者が直面するソフトウェアの信頼崩壊

ソフトウェアサプライチェーン攻撃とは、ソフトウェアの依存関係やビルドプロセスを悪用して、正規の開発・配布経路にマルウェアを混入させる攻撃手法だ。直接的なハッキングではなく、開発者が信頼している「パッケージ」「ツール」「CI/CDパイプライン」を経由するため、検出が極めて難しい。

攻撃手法の分類

攻撃手法	仕組み	実例
タイポスクワッティング	人気パッケージの名前を微妙に変えて偽パッケージを公開	`axois`（axiosの偽物）、PyPIで5,000件超
依存関係混乱	パブリックレジストリに社内パッケージと同名のパッケージを公開	Alex Birsan（2021年）の研究で発覚
メンテナ侵害	ソーシャルエンジニアリングで正規メンテナのアカウントを奪取	xz-utils（Jia Tan、2年間の潜伏工作）
CI/CDパイプライン汚染	GitHub Actions等のタグを書き換えてマルウェアを注入	Trivy（2026年3月、76/77タグが改ざん）
不可視コード注入	Unicodeの不可視文字でソースコードにバックドアを埋め込む	GlassWorm（433以上のアーティファクト）
悪意あるパッケージ公開	正規パッケージの新バージョンにマルウェアを混入	Axios CVE-2026-40175、LiteLLM

flowchart TD A["攻撃者"] --> B["パッケージレジストリ
（npm / PyPI）"] A --> C["CI/CDパイプライン
（GitHub Actions）"] A --> D["メンテナアカウント
（ソーシャルエンジニアリング）"] B --> E["開発者が
npm install"] C --> F["ビルド時に
マルウェア注入"] D --> G["正規アップデートに
バックドア混入"] E --> H["本番環境に
マルウェア到達"] F --> H G --> H style A fill:#ef4444,color:#fff style H fill:#ef4444,color:#fff

Sonatypeの2026年Q1レポートによると、npmレジストリだけで1日平均46件の悪意あるパッケージが公開されており、全OSSマルウェアの99%がnpmに集中している。

なぜ開発者がターゲットなのか

サプライチェーン攻撃は従来のサイバー攻撃と異なり、信頼関係を悪用する。開発者は npm install や pip install を日常的に実行し、依存パッケージの中身を毎回検証することはない。攻撃者にとっては、1つのパッケージを汚染するだけで、そのパッケージに依存する数千〜数万のプロジェクトに一斉にマルウェアを配布できる。

この「1対多」の攻撃効率が、サプライチェーン攻撃を最も費用対効果の高い攻撃手法にしている。実際、Axiosの攻撃では1つのパッケージの侵害で895以上のリポジトリが連鎖的に感染した。現代のソフトウェアプロジェクトは平均して数百の依存パッケージを持っており、その一つ一つが潜在的な攻撃経路（アタックサーフェス）になる。この規模の依存関係を人手でレビューすることは現実的ではなく、自動化された防御ツールの導入が不可欠だ。

2025-2026年の重大インシデントから学ぶ実態

Axios サプライチェーン攻撃（2026年3月）

人気HTTPクライアント「Axios」（週間ダウンロード5,000万以上）のサプライチェーンが攻撃され、CVE-2026-40175（CVSS 9.9）が発行された。895以上のリポジトリで自動マージされたPRの60%にマルウェアが含まれていた。

GlassWorm（2026年）

Unicode不可視文字を使った攻撃で、151以上のGitHubリポジトリと72のVS Code拡張機能が汚染された。Solanaブロックチェーンを使ったC2（Command and Control）通信により、従来のネットワーク検知を回避した。

Trivy GitHub Actions改ざん（2026年3月）

TeamPCPと呼ばれる攻撃者グループがtrivy-actionの76/77のGitタグを強制プッシュで書き換え、Docker Hubイメージに認証情報窃取マルウェアを注入した。3〜12時間の暴露期間で影響を受けたプロジェクトは数千に及ぶ。Microsoft、Wiz、Palo Alto Networksが詳細な分析レポートを公開し、GitHub Actionsのタグベース参照の危険性が業界全体で認識された。

LiteLLM PyPIパッケージ侵害（2026年3月）

LLMプロキシツール「LiteLLM」のPyPIパッケージ（バージョン1.82.7および1.82.8）が侵害され、AES-256暗号化された通信で認証情報を外部サーバーに送信するマルウェアが混入した。正規のメンテナアカウントが侵害されたケースであり、パッケージの「発行元」だけでは安全性を判断できないことを示した。

xz-utils バックドア事件の教訓（2024年、影響は2026年まで継続）

2024年に発覚したxz-utilsバックドア（CVE-2024-3094）は、「Jia Tan」を名乗る攻撃者が2年間にわたり正規メンテナとして信頼を築き、最終的にバックドアを仕込んだ事件だ。2025年8月時点でDebian Docker Hubイメージに依然としてバックドア入りのxzが含まれていたことが判明し、OpenSSF/OpenJSは類似の攻撃パターンに対する共同警告を発出した。この事件は「オープンソースの信頼モデル」そのものに疑問を投げかけた。

**この事件から得られる教訓**：GitHub ActionsのタグはGitの仕組み上、いつでも書き換えが可能だ。`uses: aquasecurity/trivy-action@master`のようにブランチ名やタグ名で参照するのは危険であり、**SHA（コミットハッシュ）で固定する**ことが唯一の防御策となる。

防御ツール比較——Renovate・Dependabot・Snyk・Socket.dev

サプライチェーン防御は単一のツールでは完結しない。依存関係の更新、脆弱性の検出、悪意あるパッケージの検出をレイヤーで組み合わせる必要がある。

ツール	種類	対象	料金	強み
Dependabot	依存関係更新	GitHub限定、30+言語	無料	設定不要。GitHub標準搭載
Renovate	依存関係更新	90+言語、マルチプラットフォーム	OSS無料	グループ化、minimumReleaseAge
Snyk	SCA + SAST	マルチ言語	Freemium	CVE検出がNVDより47日早い
Socket.dev	悪意パッケージ検出	npm、PyPI	Freemium	インストールスクリプトの挙動分析
OpenSSF Scorecard	上流リスク評価	GitHubリポジトリ	無料	CIに組み込み可能

Renovateの設定例

{
  "$schema": "https://docs.renovatebot.com/renovate-schema.json",
  "extends": ["config:recommended"],
  "minimumReleaseAge": "3 days",
  "vulnerabilityAlerts": { "enabled": true },
  "packageRules": [
    {
      "matchUpdateTypes": ["minor", "patch"],
      "automerge": true,
      "automergeType": "pr"
    },
    {
      "matchUpdateTypes": ["major"],
      "automerge": false,
      "reviewers": ["team:security"]
    }
  ]
}

minimumReleaseAge: "3 days" は最も重要な設定の一つだ。Axiosの攻撃のように、悪意あるバージョンがリリース直後に自動マージされるリスクを大幅に下げる。3日間の「冷却期間」で、コミュニティが異常を検出する時間を確保できる。

GitHub Actionsセキュリティ強化——SHA固定・OIDC・最小権限

GitHub Actionsのセキュリティ対策は、サプライチェーン防御の中でも最も即効性が高い。

SHA固定（最重要）

タグではなくコミットSHAでアクションを参照する。Trivy事件はこの対策で完全に防げた。

# ❌ 危険：タグは書き換えられる
- uses: actions/checkout@v4

# ✅ 安全：SHAは不変
- uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11 # v4.1.1

最小権限の原則

# ジョブレベルで最小限の権限を指定
permissions:
  contents: read      # リポジトリ読み取りのみ
  pull-requests: write # PR操作のみ許可
  # 未指定の権限はすべて拒否される

OIDCキーレスデプロイ

長期有効なシークレット（AWS_SECRET_ACCESS_KEY等）をGitHub Secretsに保存する代わりに、OIDC（OpenID Connect）で短期トークンを動的に取得する。

permissions:
  id-token: write  # OIDCトークン取得を許可

steps:
  - uses: aws-actions/configure-aws-credentials@e3dd6a429d7300a6a4c196c26e071d42e0343502
    with:
      role-to-assume: arn:aws:iam::123456789:role/github-actions-deploy
      aws-region: ap-northeast-1

CodeQLによるワークフロー解析

GitHubのCodeQLはワークフローYAMLのセマンティック解析が可能で、コマンドインジェクションのパス（$ の未サニタイズ利用等）を検出する。

# .github/workflows/codeql.yml
name: CodeQL Analysis
on: [push, pull_request]
jobs:
  analyze:
    runs-on: ubuntu-latest
    permissions:
      security-events: write
    steps:
      - uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11
      - uses: github/codeql-action/init@b4ffde65f46336ab88eb53be808477a3936bae11
        with:
          languages: javascript
      - uses: github/codeql-action/analyze@b4ffde65f46336ab88eb53be808477a3936bae11

zizmor：ワークフローの静的解析

# zizmor: Rust製のGitHub Actions脆弱性スキャナー（OSS）
pip install zizmor
zizmor .github/workflows/*.yml
# → SHA未固定、権限過剰、シークレット露出等を検出

GitHub Actionsの2026年セキュリティロードマップ

2026年にGitHub Actionsに導入される（または導入予定の）セキュリティ機能は以下の通りだ。

機能	ステータス	効果
ワークフロー依存関係ロック	プレビュー	Actionsのバージョンをロックファイルで固定
ネイティブL7エグレスファイアウォール	開発中	ワークフローからの外部通信を制御
スコープ付きシークレット	GA	シークレットの利用範囲を限定
Actions Data Stream	プレビュー	ワークフロー実行のリアルタイム監査
カスタムプロパティクレーム（OIDC）	GA	OIDC トークンにカスタム属性を付与

SBOM・SLSA・Sigstore——ソフトウェアの信頼基盤を構築する

SBOM（Software Bill of Materials）

ソフトウェアに含まれるすべてのコンポーネントとバージョンを一覧化した「部品表」だ。EU CRA規制では2026年9月から脆弱性報告が義務化され、2027年12月からSBOMの提供が義務化される。

# syftでSBOMを生成（Anchore製、40+エコシステム対応）
# SPDX形式（ISO準拠、コンプライアンス向け）
syft dir:. -o spdx-json > sbom.spdx.json

# CycloneDX形式（OWASP、セキュリティ向け）
syft dir:. -o cyclonedx-json > sbom.cdx.json

# Dockerイメージから生成
syft docker:myapp:latest -o spdx-json > sbom.spdx.json

形式	標準化団体	焦点	用途
SPDX	Linux Foundation	ライセンスコンプライアンス	ISO/IEC 5962、法務部門向け
CycloneDX	OWASP	セキュリティ・脆弱性管理	開発チーム・セキュリティ部門向け

SLSA（Supply-chain Levels for Software Artifacts）

ビルドの完全性を保証するフレームワーク（読み方：サルサ）。v1.1が安定版で、4段階のレベルで段階的にセキュリティを強化する。

レベル	要件	効果
L0	なし	ベースライン
L1	ビルドプロセスの文書化	改ざん検出の基盤
L2	ホスティングされたビルドプラットフォーム	ビルドの再現性
L3	ハーメティックビルド + 改ざん不可能な来歴証明	高い信頼性

# GitHub ActionsでSLSA来歴証明を生成
- uses: slsa-framework/slsa-github-generator/.github/workflows/[email protected]
  with:
    base64-subjects: "$"

Sigstore / cosign

コンテナイメージの署名と検証をキーレス（鍵管理不要）で実現する。

# コンテナイメージに署名（Fulcio CAが短期証明書を発行）
cosign sign myregistry/myapp:v1.0.0

# 署名を検証
cosign verify myregistry/myapp:v1.0.0 \
  --certificate-identity=[email protected] \
  --certificate-oidc-issuer=https://accounts.google.com

flowchart LR A["ソースコード"] --> B["ビルド
（SLSA L3）"] B --> C["SBOM生成
（syft）"] C --> D["コンテナ署名
（cosign）"] D --> E["来歴証明
（in-toto）"] E --> F["レジストリに
公開"] F --> G["デプロイ時に
署名検証"] style B fill:#10b981,color:#fff style D fill:#10b981,color:#fff

ロックファイルのセキュリティ——見落としがちな盲点

ロックファイル（package-lock.json、yarn.lock、poetry.lock等）は依存関係のバージョンを固定するためのものだが、セキュリティの観点で見落とされがちな盲点がある。

2026年1月に公開されたPackageGateの研究では、主要なJavaScriptパッケージマネージャーで6つのバイパス手法が発見された。たとえばpnpmでは、git/HTTP依存がインテグリティハッシュなしで格納される脆弱性（CVE-2025-69263）が報告されている。

ロックファイルの安全な運用

# npmの場合：CIでは必ず ci コマンドを使う（package-lock.jsonに厳密に従う）
npm ci  # ✅ ロックファイルに一致しなければ失敗
npm install  # ❌ ロックファイルを書き換える可能性がある

# ロックファイルの変更をPRで必ずレビュー対象にする
# .github/CODEOWNERS に追加
package-lock.json @security-team
yarn.lock @security-team

パッケージマネージャー	ロックファイル	インテグリティハッシュ	注意点
npm	package-lock.json	SHA-512	`lockfileVersion: 3` を推奨
yarn	yarn.lock	SHA-512	Berry（v2+）はより厳密
pnpm	pnpm-lock.yaml	SHA-512	git/HTTP依存のハッシュ欠如に注意
pip	requirements.txt + –hash	SHA-256	`--require-hashes` フラグ必須
Go	go.sum	SHA-256	チェックサムと依存を分離（最も安全な設計）

Goのgo.sumはセキュリティ設計の手本だ。依存関係の定義（go.mod）とチェックサム（go.sum）を分離し、Google運営のsumデータベースで第三者検証を行う仕組みになっている。他の言語のエコシステムもこの方向に進化しつつある。

npmは2025年11月にクラシック長期トークンを廃止し、細粒度トークン + 2FA の強制に移行した。パッケージの publish 権限管理がより厳密になっている。PyPIも同様の方向に進んでおり、Trusted Publishers（OIDC連携）でCI/CDから直接パッケージを公開する方式が推奨されるようになっている。

実践チェックリスト——今日からできるサプライチェーン防御

以下のチェックリストを上から順に実装していけば、サプライチェーンセキュリティの基盤を構築できる。

優先度：高（今すぐ実施）

GitHub ActionsのすべてのサードパーティActionをSHA固定に変更
ワークフローの permissions をジョブレベルで最小限に設定
Renovate/DependabotでminimumReleaseAge（3日以上）を設定
npm audit / pip audit をCIに組み込む

優先度：中（1-2週間以内）

Socket.devを導入し、悪意あるパッケージの自動検出を有効化
OpenSSF Scorecardで主要な依存ライブラリのスコアを確認
OIDCキーレスデプロイへ移行（AWS/GCP/Azureシークレットの廃止）
zizmor でワークフローの静的解析を実施

優先度：低（1ヶ月以内）

syftでSBOM生成をCIパイプラインに組み込む
cosignでコンテナイメージの署名を自動化
SLSA来歴証明の生成をビルドプロセスに統合
依存パッケージのOpenSSF Scorecardスコアが5未満のものをリストアップし、代替を検討

防御レイヤーの全体像

単一のツールで完璧な防御はできない。以下のように多層防御（Defense in Depth）で組み合わせることが重要だ。

レイヤー	目的	ツール
予防	脆弱・悪意あるパッケージの混入を防ぐ	Renovate（minimumReleaseAge）、Socket.dev
検知	既知の脆弱性を検出する	Snyk、`npm audit`、CodeQL
検証	ビルドの完全性を証明する	SLSA、cosign、SBOM
監査	事後の追跡・対応を可能にする	GitHub Audit Log、SBOM、Actions Data Stream
評価	上流のリスクを事前に把握する	OpenSSF Scorecard

**日本の規制動向**：経済産業省は2026年度下期にSCS（サプライチェーン・サイバーセキュリティ）評価制度の星3・星4の運用を開始する。NIST CSF 2.0をベースにした制度で、星3が最低基礎水準となる。取引先からの要請でSBOMの提供を求められるケースが増えているため、早めの対応を推奨する。