サプライチェーン攻撃の対策

背景: 何が起きているか

攻撃パターンは3系統に集約される:

1. アカウントハイジャック — メンテナの認証情報を窃取し正規パッケージに毒入りバージョンをpublish

3. Dependency Confusion — 内部パッケージと同名の公開パッケージを登録し、レジストリの名前解決を悪用

いずれも「ビルドシステムが自動的に未検証のコードを取得・実行する」点を突いている。

npm以外の主要攻撃事例

npm以外のエコシステムでも同種の攻撃が継続的に発生している。

具体例はnpmエコシステムが中心だが、原則は他のソフトウェアサプライチェーンにも共通して適用できる。原則は以下の6つ。

install時任意コード実行を止める

リリース後の猶予を置く

lockfileで完全性を担保する

信頼シグナル(署名・Provenance)を検証する

権限とネットワークを最小化する

事後に即応できる状態を保つ

対象はPyPI、Maven Central、crates.io、Go modules、RubyGems、NuGet、コンテナイメージ、AI開発支援ツール等。各章末に他エコシステムでの等価手段を示す。

1. lifecycleスクリプトの無効化

code: (bash)

npm config set ignore-scripts true

npm config set allow-git none

個別installで無効化:

code: (bash)

npm install --ignore-scripts --allow-git=none <package>

code: (yaml)

# pnpm-workspace.yaml

onlyBuiltDependencies:

- esbuild

- fsevents

code: (yaml)

allowBuilds:

esbuild: true

core-js: false

code: (json)

{

}

他エコシステムでの等価手段

2. クールダウン(最小リリース経過時間)

攻撃は公開から数時間〜数日で検知・削除されることが多い。新規公開バージョンのインストールを遅延させれば攻撃ウィンドウを回避できる。Axios攻撃の汚染時間は4〜5時間だった。

code:_

# .npmrc

min-release-age=7d

code: (yaml)

# pnpm-workspace.yaml

minimumReleaseAge: 20160 # 分単位 = 2週間

minimumReleaseAgeExclude:

- '@types/react'

- typescript

code: (toml)

minimumReleaseAge = 259200 # 秒 = 3日

code: (yaml)

# .yarnrc.yml

npmMinimalAgeGate: "3d"

npmPreapprovedPackages:

- "@types/react"

code: (yaml)

version: 2

updates:

- package-ecosystem: "npm"

directory: "/"

schedule:

interval: "weekly"

cooldown:

default-days: 7

semver-minor-days: 3

semver-patch-days: 3

他エコシステムでの等価手段

3. SemVerレンジの制御とバージョン固定

table:table

指定 解決範囲 リスク

他エコシステムでの等価手段

盲目的アップグレードの回避

code: (bash)

# やってはいけない

npm update

npx npm-check-updates -u

これらは侵害されたアカウントから公開された悪意あるバージョン、未テストの破壊的変更、namespace hijackingを無差別に取り込むリスクがある。

代わりに:

Snyk / Dependabot / Renovateの自動PRでchangelogとCVE情報付きのレビュー可能なPRを受け取る

4. lockfileの厳格な運用

CI/CD及び本番ビルドでは必ず:

code: (bash)

bun install --frozen-lockfile # Bunの場合

yarn install --immutable # Yarnの場合

チェックリスト:

lockfileの変更を含むPRには差分レビューを実施している

他エコシステムでの等価手段

5. lockfileインジェクション対策

code: (bash)

npm install --save-dev lockfile-lint

npx lockfile-lint \

--path package-lock.json \

--type npm \

--allowed-hosts npm yarn \

--validate-https

CI上でpreinstallフックとして組み込む:

code: (json)

{

"scripts": {

"lint:lockfile": "lockfile-lint --path package-lock.json --type npm --allowed-hosts npm --validate-https",

"preinstall": "npm run lint:lockfile"

}

}

他エコシステムでの等価手段

6. 新規依存+installスクリプトの検知

検知ロジック

CIに以下のチェックを追加:

3. 該当があればPRにフラグを立てて手動レビューを要求

全スクリプトを一律無効化するよりも、ビルドパイプラインを壊さずにピンポイントで危険なパターンを捕捉できる。

実装例 (GitHub Actions)

code: (yaml)

name: detect-new-install-scripts

on: pull_request

jobs:

check:

runs-on: ubuntu-latest

steps:

- uses: actions/checkout@v4

with:

fetch-depth: 0

- uses: actions/setup-node@v4

- name: Diff lockfile

run: |

git diff origin/${{ github.base_ref }}...HEAD -- package-lock.json > lock.diff

node scripts/flag-install-scripts.mjs lock.diff

より強力な検知シグナル

初登場 (過去ビルドのlockfileに存在しない)

作成者の過去publish数が極端に少ない

パッケージ年齢が短い(2クールダウンと連携)

repositoryフィールドがない、またはprivate/dead GitHub

README/LICENSE/homepageが欠落

他エコシステムでの等価手段

7. インストール前の事前監査ツール

npq

Snyk CVEデータベースによる脆弱性チェック

パッケージ年齢(22日未満は新規フラグ)

バージョン年齢(7日未満はフラグ)

タイポスクワッティング検出

npmレジストリ署名の検証

ビルドprovenanceアテステーション検証

pre/postinstallスクリプトの有無

README/LICENSE/リポジトリURL/DL数などのヘルスチェック

メンテナのドメイン有効期限チェック

code: (bash)

npm install -g npq

alias npm='npq-hero' # npmのラッパーとして常用

Socket Firewall (sfw)

Socket独自の脅威インテリジェンスでリアルタイム分析し、悪意あるパッケージのfetch/installをブロックする:

code: (bash)

npm install -g sfw

sfw npm install express

難読化コード検出、Dependency Confusion検出、環境変数アクセス検出、不審なネットワーク/ファイルシステム操作の検出に対応。

他エコシステムの監査ツール

各エコシステムで「インストール前」に使える監査ツールを整理する。

Python (PyPI)

code: (bash)

pip install pip-audit

pip-audit # 現在の仮想環境を監査

pip-audit -r requirements.txt # ファイル指定

pip-audit --fix # 修正可能なものを自動アップデート

code: (bash)

pip install safety

safety check -r requirements.txt

code: (bash)

pip install guarddog

guarddog pypi verify <package> # PyPIパッケージを検査

guarddog pypi scan <package> # ローカルソースを静的解析

Go

code: (bash)

go install golang.org/x/vuln/cmd/govulncheck@latest

govulncheck ./...

code: (bash)

guarddog go verify <module> # Go moduleを検査

Rust

code: (bash)

cargo install cargo-audit

cargo audit

cargo audit fix # 自動修正

code: (toml)

# deny.toml

ignore = []

code: (bash)

cargo deny check

Ruby

code: (bash)

gem install bundler-audit

bundle-audit check --update

.NET (NuGet)

code: (bash)

dotnet list package --vulnerable # 既知脆弱性

dotnet list package --deprecated # 非推奨パッケージ

dotnet list package --outdated # 更新可能なパッケージ

Visual Studio / Rider のセキュリティ警告との統合も可。Snyk for .NET はPRごとのSCA検査に使える。

Java (Maven / Gradle)

code: (xml)

<!-- pom.xml -->

<plugin>

<groupId>org.owasp</groupId>

<artifactId>dependency-check-maven</artifactId>

<version>10.0.3</version>

<executions>

<execution>

<goals><goal>check</goal></goals>

</execution>

</executions>

</plugin>

code: (bash)

mvn org.owasp:dependency-check-maven:check

code: (bash)

trivy fs --scanners vuln .

横断ツール

table:table

ツール 対応エコシステム 特徴

代表的ツールの比較(何をどのフェーズで検知するか)

サプライチェーン対策ツールは「いつ」「何を」「どうやって」検知するかで性格が大きく異なる。同じ「脆弱性検知」と銘打っていても守備範囲は重ならない。

読み方の要点:

レイヤー図

code: (text)

┌─────────────────────────────────────────────────────────────┐

│ パッケージ入手前 │

│ └─ Takumi Guard / Socket / npq / pnpm trustPolicy │ ← 未知攻撃に強い

├─────────────────────────────────────────────────────────────┤

│ dev / CI │

│ ├─ Snyk / Dependabot / Renovate (CVE + 自動PR) │

│ ├─ OSV-Scanner / govulncheck / cargo-audit (CVE 多言語) │ ← 既知CVE中心

│ ├─ cargo-vet / cargo-crev (監査署名) │

│ └─ YARA (パターン) │

├─────────────────────────────────────────────────────────────┤

│ post-deploy(稼働系) │

│ ├─ Trivy / Vuls / Grype (OS・コンテナの脆弱性) │ ← CVE依存度最大

│ └─ EDR / SIEM (C2検知・ふるまい) │

└─────────────────────────────────────────────────────────────┘

カバーできないものを意識する

どのツールも単独では不十分である。次の穴は組み合わせで埋める:

8. Provenanceアテステーションとnpm audit signatures

先に用語を整理する:

code: (yaml)

# GitHub Actions

permissions:

id-token: write

steps:

- run: npm publish --provenance

code: (bash)

npm audit signatures

pnpm trustPolicy

code: (yaml)

# pnpm-workspace.yaml

trustPolicy: no-downgrade

trustPolicyExclude:

- 'chokidar@4.0.3'

pnpmが参照するチェック対象(いずれも付いていた履歴があるバージョンより信頼度の低いpublishを拒否):

Trusted Publisher binding (OIDC経由のpublish)

Provenance attestation (Sigstore + in-toto)

レジストリ署名 (npm registry signing)

他エコシステムでの等価手段

9. OIDC Trusted Publishing(長期トークンの排除)

code: (yaml)

# GitHub Actions

permissions:

id-token: write

steps:

- run: npm publish

npmjs.comでパッケージのTrusted Publishingを設定すると、承認されたワークフロー(Trusted Publisher)からのみpublish可能になる。provenanceも自動生成される。

他エコシステムの対応状況

他エコシステムの具体的な設定手順

PyPI Trusted Publishing (GitHub Actions)

1. PyPIのパッケージ設定画面で「Add a new trusted publisher」→ GitHub Actions を選択し、リポジトリ名・ワークフローファイル名・環境名を登録

2. GitHub Actionsワークフローを設定:

code: (yaml)

name: Publish to PyPI

on:

push:

jobs:

publish:

runs-on: ubuntu-latest

environment: pypi-publish # PyPIに登録した環境名と一致させる

permissions:

id-token: write

steps:

- uses: actions/checkout@v4

- uses: actions/setup-python@v5

with:

python-version: '3.12'

- run: pip install build && python -m build

- uses: pypa/gh-action-pypi-publish@release/v1

# PYPI_API_TOKENは不要。OIDCで自動認証される

RubyGems Trusted Publishing (GitHub Actions)

code: (yaml)

permissions:

id-token: write

steps:

- uses: rubygems/release-gem@v1

# GEM_HOST_API_KEYは不要

crates.io Trusted Publishing (GitHub Actions)

crates.ioの「Trusted Publishing」設定でリポジトリ・ワークフロー・環境を登録:

code: (yaml)

permissions:

id-token: write

steps:

- uses: cargo-bins/release-pr@v1

# あるいは手動publish

- run: cargo publish

env:

CARGO_REGISTRY_TOKEN: "" # OIDC使用時は空でよい

Maven Central / OSSRH

Maven CentralはOIDC Trusted Publishingを直接サポートしていないが、Central Publisher Portal (2024年3月以降) で以下のトークン運用ができる:

1. Central Publisher Portalでユーザートークン(短命)を発行

2. トークンをGitHub Actions Secretにセット(従来より短い有効期限で運用)

code: (xml)

<!-- ~/.m2/settings.xml -->

<servers>

<server>

<id>central</id>

<username>${env.CENTRAL_USER}</username>

<password>${env.CENTRAL_TOKEN}</password>

</server>

</servers>

code: (yaml)

# GitHub Actions

- name: Publish to Maven Central

run: mvn --no-transfer-progress deploy -P release

env:

CENTRAL_USER: ${{ secrets.CENTRAL_USER }}

CENTRAL_TOKEN: ${{ secrets.CENTRAL_TOKEN }}

GPG_PASSPHRASE: ${{ secrets.GPG_PASSPHRASE }}

NuGet.org Trusted Publishing

code: (yaml)

permissions:

id-token: write

steps:

- run: dotnet pack -c Release

- uses: nuget/setup-nuget@v2

# NUGET_API_KEYは不要。OIDCで認証

10. アカウント保護(2FA / Passkey)

npm

code: (bash)

npm profile enable-2fa auth-and-writes

npmは段階的に2FAを必須化してきた:

PyPI

GitHub

GitHub側の追加対策:

不要なGitHub Apps / OAuthアプリを削除

リポジトリwebhookとsecretsを監査

branch protectionルールを有効化

Secret Scanningアラートを有効化

Dependabotセキュリティアップデートを有効化

Passkey (WebAuthn)

他エコシステムの2FA/Passkey状況

11. プライベートレジストリプロキシ(Dependency Confusion対策)

対策

承認済み公開パッケージのホワイトリストを管理

CI/CDから公開npmレジストリへの直接アクセスをブロック

Virtual / Group repositoryで「ローカル → リモート」の解決順序を明示固定する

これによりクールダウン・悪意あるパッケージのブロック・依存変更の監査を一箇所で制御できる。

他エコシステムの代表的プロキシ/ミラー

table:table

エコシステム プロキシ/ミラー

npm Verdaccio、JFrog Artifactory、Sonatype Nexus、GitHub Packages

Python DevPi、Artifactory PyPI、AWS CodeArtifact

Maven Nexus、Artifactory、Cloudsmith

Rust 公式サポートは限定的。Artifactoryのcrates.io mirror / Cloudsmith

コンテナ Harbor、Artifactory Docker、GHCR、ECR pull-through cache

他エコシステムの具体的な設定

Python: DevPi

code: (bash)

pip install devpi-server devpi-client

devpi-server --start --init

devpi login root --password=

devpi index -c company/stable bases=root/pypi # PyPIプロキシに内部インデックスを重ねる

クライアント側:

code: (bash)

# pip.conf

# --index-url で唯一のインデックスを指定。--extra-index-url は使わない(Dependency Confusion防止)

Go: Athens

code: (yaml)

# athens/config.toml

Port = ":3000"

Fallthrough = "direct" # 未キャッシュは公式モジュールプロキシへfallback

Type = "disk"

Disk.RootPath = "/var/lib/athens"

code: (bash)

# 環境変数でGoクライアントを向ける

export GONOSUMCHECK=*.internal.example.com # 社内モジュールのsumdbチェックを除外

Dependency Confusion対策:

code: (bash)

# 社内モジュールはATHENS_NOSUMでsumdb不要にし、公開registryには解決させない

export GONOSUMCHECK=github.com/mycompany/*

export GONOPROXY=github.com/mycompany/*

export GOFLAGS=-mod=readonly

Maven/Gradle: Nexus Repository Manager

code: (xml)

<!-- Maven settings.xml -->

<mirrors>

<mirror>

<id>nexus</id>

<mirrorOf>*</mirrorOf> <!-- 全リクエストをNexus経由に -->

</mirror>

</mirrors>

<servers>

<server>

<id>nexus</id>

<username>${env.NEXUS_USER}</username>

<password>${env.NEXUS_PASSWORD}</password>

</server>

</servers>

Gradle:

code: (kotlin)

// settings.gradle.kts

dependencyResolutionManagement {

repositories {

maven {

credentials {

username = System.getenv("NEXUS_USER")

password = System.getenv("NEXUS_PASSWORD")

}

}

}

// mavenCentral() は削除し、すべてNexus経由に

}

Rust (crates.io): 代替レジストリ

crates.ioは現時点でネイティブのプロキシ機能を持たない。代替手段:

code: (toml)

offline = false

code: (toml)

# Cargo.toml で社内パッケージを内部レジストリから指定

my-internal-lib = { version = "1.0", registry = "my-company" }

12. ad-hoc実行の安全化 (npx / pipx / uvx / go run)

npmの設定で未インストールパッケージの自動実行を禁止:

code: (bash)

npm config set yes false

Python側の同等機能

ad-hoc実行の全体整理

同類の「リモートから取得して即実行」パターンは他エコシステムにも広がっている:

他エコシステムの追加詳細

Python: pipx / uvx の安全な使い方

安全な運用:

code: (bash)

# 悪い例: 最新バージョンを直接実行

pipx run black .

# 良い例: バージョンを固定してインストール後に実行

pipx install black==24.4.2

black .

# 組織管理の内部PyPIからのみ取得

code: (bash)

# バージョン固定してuv toolとして管理

uv tool install ruff==0.4.5

ruff check .

# 一時実行時はバージョン明示

uvx ruff@0.4.5 check .

code: (bash)

# 悪い例

go run golang.org/x/tools/cmd/goimports@latest .

# 良い例: バージョン固定

go run golang.org/x/tools/cmd/goimports@v0.22.0 .

# さらに良い例: go.sum+go.modで管理されたツールとして使う

# tools.go に blank import で依存させてgo.sumに記録

code: (bash)

# 悪い例

cargo install cargo-watch

# 良い例: バージョン固定

cargo install cargo-watch@8.5.2

# 最も安全: Cargo.lockがあるプロジェクトから--lockedで

cargo install cargo-watch@8.5.2 --locked

code: (bash)

# 悪い例

gem install bundler

# 良い例: バージョン固定

gem install bundler -v 2.5.10

# extconf.rb(ネイティブ拡張ビルド)がある場合は--ignore-extensionsで回避できる場合も

gem install nokogiri -v 1.16.4 --platform ruby # ソースビルドを強制

gem install nokogiri -v 1.16.4 -- --use-system-libraries # システムライブラリ使用

13. シークレットの保護(.envファイルの扱い)

シークレットマネージャへの参照化

code:_

DATABASE_PASSWORD=op://vault/database/password

API_KEY=infisical://project/env/api-key

実行時にCLIで注入:

code: (bash)

シークレットの実体がファイルシステムや環境変数に残らないため、窃取されても無価値になる。

dotenv脆弱性の系譜

他エコシステムのシークレット管理

どのエコシステムでも「長期シークレットをコードやファイルシステムに直書きしない」原則は同一。窃取経路と緩和策がエコシステムごとに異なる。

code: (bash)

# gitleaks: Git履歴全体をスキャン

gitleaks detect --source . --report-format json --report-path gitleaks.json

# trufflehog: エントロピー解析で高精度検出

trufflehog git file://. --only-verified

# GitHub Secret Scanning: org設定でpushへのリアルタイムブロックも可能

pre-commitフックとして統合:

code: (yaml)

# .pre-commit-config.yaml

repos:

rev: v8.18.4

hooks:

- id: gitleaks

14. Dev Container / サンドボックス開発

見落とされやすいのがAIコーディング支援ツールの認証情報である。GitHub Copilot、Cursor、Claude Code、Clineなどは広範なシークレットにアクセスする:

GitHub OAuthトークン(リポジトリ全体の読み書き権限)

Anthropic / OpenAIのAPIキー

ローカルに設定されたMCPサーバ経由で到達可能な外部リソース(Slack、Linear、DB等)

ホストで悪意あるnpm/pipパッケージを実行すると、これらが一括で窃取される。サンドボックス化はホストOS保護にとどまらず、AI時代の認証情報防衛線として機能する。

code: (json)

{

"name": "Node.js Dev Container",

"image": "mcr.microsoft.com/devcontainers/javascript-node:20",

"postCreateCommand": "npm ci",

"runArgs": [

"--security-opt=no-new-privileges:true",

"--cap-drop=ALL",

"--cap-add=CHOWN",

"--cap-add=SETUID",

"--cap-add=SETGID"

],

"mounts": [

"source=${localEnv:HOME}/.ssh,target=/home/node/.ssh,type=bind,readonly"

]

}

ポイント:

GitHub Codespaces / Devboxのようなリモート開発環境ではホスト分離が最初から強制される

AIエージェント向けの公式サンドボックス

他エコシステムのサンドボックス開発

サンドボックス開発の考え方はエコシステムを問わず共通だが、Dev Containerのpostinstall/postCreateCommandで呼ばれるコマンドがエコシステムごとに異なる。

code: (xml)

<!-- settings.xml (コンテナ内) -->

<servers>

<server>

<id>nexus</id>

<username>${env.NEXUS_USER}</username>

<password>${env.NEXUS_PASS}</password>

</server>

</servers>

15. 依存ツリーの削減

モダンJavaScriptで代替可能な典型例:

code: (jsx)

// lodash.uniqの代わり

// 単純なHTTP GETならaxiosの代わりにfetch(retries/timeout/interceptors等の機能が不要な場合に限る)

const response = await fetch(url);

// ユーティリティライブラリの代わり

const isEmpty = obj => Object.keys(obj).length === 0;

新規依存の追加前の確認項目:

その機能は本当にnon-trivialか?

セキュリティとメンテナンスコストに見合うか?

標準APIで代替できないか?

他エコシステムの依存削減アプローチ

「依存を増やさない」原則はすべてのエコシステムに共通。各エコシステムでの典型的な肥大パターンと削減手段:

Python (pip/Poetry/uv)

code: (python)

# 悪い例: requests, httpx を使わず標準ライブラリで済む場合

import requests

response = requests.get(url)

# 良い例: シンプルなGETならurllibで十分

import urllib.request

with urllib.request.urlopen(url) as resp:

data = resp.read()

依存数の把握:

code: (bash)

pip install pipdeptree

pipdeptree --warn silence # ツリー形式で推移的依存を可視化

pipdeptree --json | python -m json.tool | grep "package_name" | wc -l # 総依存数

不要な依存を特定:

code: (bash)

pip install deptry

deptry . # 使われていない依存を検出

Go (modules)

code: (bash)

# 推移的依存の確認

go mod graph | wc -l # 依存の総数

go mod why <module> # なぜその依存が必要かを確認

# 未使用モジュールの削除

go mod tidy

Java/Maven (依存ツリー分析)

code: (bash)

mvn dependency:tree -Dverbose # 競合・除外の詳細を表示

mvn dependency:analyze # 使われていない依存を検出

code: (xml)

<dependency>

<groupId>org.springframework</groupId>

<artifactId>spring-web</artifactId>

<exclusions>

<exclusion>

<groupId>commons-logging</groupId> <!-- 使わないロガーを除外 -->

<artifactId>commons-logging</artifactId>

</exclusion>

</exclusions>

</dependency>

Rust (cargo feature フラグ)

code: (bash)

cargo install cargo-machete

cargo machete

featureフラグを活用して必要な機能のみをコンパイルする:

code: (toml)

Ruby (Bundler 依存管理)

code: (bash)

bundle viz # Gemfile.lockの依存グラフをDOT形式で出力

bundle exec bundler-leak # メモリリークの可能性がある依存を検出

16. ネットワーク監視とIOCフィードの運用

攻撃が分析されるとC2ドメイン/IPがIOCとして公開されるが、具体的な値は短期間で陳腐化する。個別のIOC値を追うより、最新IOCを継続的に取り込みブロックする仕組みを整備する。

IOCフィードの主な入手経路:

CISAの緊急アラート(Known Exploited Vulnerabilities Catalog、脅威情報勧告)

取り込み先(ブロック適用層):

ネットワーク境界: ファイアウォール、プロキシ、DNSシンクホール(Pi-hole / NextDNS / Cisco Umbrella)

エンドポイント: EDR(CrowdStrike、SentinelOne、Defender for Endpoint)

CI egress制御の実例(GitHub Actions):

code: (yaml)

- uses: step-security/harden-runner@v2

with:

egress-policy: block

allowed-endpoints: >

registry.npmjs.org:443

github.com:443

objects.githubusercontent.com:443

これにより、postinstallスクリプトが未許可の外部ホストへ認証情報を送信しようとしても接続自体が失敗する。Shai-Hulud・Axios型攻撃の窃取フェーズを決定的に止められる。

EDR/SIEMでの検知ルール(内容は陳腐化しにくい抽象的パターンを優先):

他エコシステムのネットワーク監視

ネットワーク監視とegress制御は言語・エコシステムを問わず同じインフラ層で実施できるため、本セクションの対策は横断的に適用可能。ただし各エコシステムのビルド・実行プロセスで「何が正当な外部通信か」が異なる。

code: (yaml)

# GitLab CI: network制限(GitLab.com SaaSではRunner設定依存)

job:

variables:

PIP_NO_CACHE_DIR: "false"

before_script:

- pip config set global.trusted-host pypi.internal

Kubernetes環境ではCiliumまたはIstioでPod単位のegress制御が可能:

code: (yaml)

# CiliumNetworkPolicy: Mavenビルドポッドのegress制限

apiVersion: cilium.io/v2

kind: CiliumNetworkPolicy

metadata:

name: maven-build-egress

spec:

endpointSelector:

matchLabels:

app: maven-builder

egress:

- toFQDNs:

- matchName: "nexus.internal"

- toFQDNs:

- matchName: "repo1.maven.org" # 社内プロキシが落ちた場合のfallback

17. SBOM(ソフトウェア部品表)の生成と管理

制度的背景

フォーマット

どちらを選んでも良いが、脆弱性管理重視ならCycloneDX、ライセンスコンプライアンス重視ならSPDXが使われることが多い。

生成ツール

table:table

ツール 特徴

VEX: 「影響あり」と「悪用可能」の分離

運用ワークフロー:

1. CI/CDでSBOM生成(syft / cdxgen 等)

2. Dependency-Track等の集中管理基盤にupload、OSV / NVD / GitHub AdvisoryとCVEマッチング

これによりSBOMだけ運用した場合に典型的に発生する「CVEの山に埋もれる」問題を抑制できる。

SLSAとの組合せ

運用のポイント

CI/CDで毎ビルドSBOMを生成し、成果物としてリリースに添付

署名(cosign等)付きで配布し改ざんを検知可能にする

脆弱性DBとのマッチングを定期ジョブ化(osv-scanner, grype, trivy)

社内のSBOMリポジトリに集約し、新規CVE公表時に影響範囲を横断検索

他エコシステムのSBOM生成

SBOMは「何を使っているか」を機械可読で記録するものであり、エコシステムを問わず同じ目的で使える。エコシステムごとにSBOMを生成するツールが異なる。

table:table

エコシステム SBOMツール コマンド例

Maven CycloneDX プラグインの詳細設定

code: (xml)

<!-- pom.xml -->

<plugin>

<groupId>org.cyclonedx</groupId>

<artifactId>cyclonedx-maven-plugin</artifactId>

<version>2.8.1</version>

<executions>

<execution>

<phase>package</phase>

<goals>

<goal>makeAggregateBom</goal>

</goals>

</execution>

</executions>

<configuration>

<projectType>library</projectType>

<schemaVersion>1.5</schemaVersion>

<includeBomSerialNumber>true</includeBomSerialNumber>

<includeCompileScope>true</includeCompileScope>

<includeTestScope>false</includeTestScope> <!-- テスト依存はSBOMに含めない -->

<outputFormat>json</outputFormat>

</configuration>

</plugin>

Dependency-Track への自動アップロード

CIでSBOMを生成してDependency-Trackに集中管理する:

code: (yaml)

# GitHub Actions (Maven)

- name: Generate SBOM

run: mvn org.cyclonedx:cyclonedx-maven-plugin:makeAggregateBom

- name: Upload SBOM to Dependency-Track

run: |

-H "X-Api-Key: ${{ secrets.DTRACK_API_KEY }}" \

-F "autoCreate=true" \

-F "projectName=${{ github.repository }}" \

-F "projectVersion=${{ github.ref_name }}" \

-F "bom=@target/bom.json"

18. YARA / 静的解析によるパッケージスキャン

CVE DBに登録されていない未知の悪性パッケージを検出するには、パターンマッチと静的解析でソースを事前に審査する必要がある。

YARA

検出対象パターンの例:

異常なGitHub Actionsワークフロー(奇妙なパス、新規ワークフローファイル)

webhook.site、discord.com/api/webhooks 等の既知の窃取エンドポイント

OSS検出ツール

主要ベンダーの検出事例

現実にどんなパターンで攻撃が来ているかは、各社の脅威リサーチブログが豊富な実例を提供している:

運用上の注意

静的解析は難読化との「軍拡競争」になりやすい。pyminifier, obfuscator.io, webpack minified bundleに埋め込まれたコードはYARAだけでは捕捉が難しく、動的解析(サンドボックス実行 + ネットワーク挙動観測)や、2のクールダウンによる時間軸の防御と組み合わせる必要がある。

他エコシステムのパッケージ静的解析

静的解析・パターンマッチの考え方はnpm以外のエコシステムにも適用できる。GuardDog(Datadog)はPyPI・npmに対応済みで、他エコシステムへの拡張が進んでいる。

Python (PyPI) のパッケージ静的解析

GuardDogはPyPIパッケージの静的解析をサポート:

code: (bash)

guarddog pypi verify requests # PyPIの公開パッケージを検査

guarddog pypi scan ./my-package/ # ローカルに展開したソースを検査

検出するパターン(npm版と共通の多くが適用される):

code: (bash)

pip download --no-deps suspicious-pkg==1.2.3 -d /tmp/pkgs/

cd /tmp/pkgs && unzip *.whl -d extracted/

grep -r "subprocess\|os\.system\|eval\|base64" extracted/

Go モジュールの静的解析

Goモジュールはソースコード配布が基本のため、テキストベースの静的解析が直接適用できる。

code: (bash)

# govulncheck: 呼び出しグラフを追って到達可能な脆弱性のみ報告

govulncheck ./...

# semgrep: YARAに相当するコードパターンマッチ

semgrep --config "p/golang" ./...

GoモジュールのProxy経由ダウンロードはsum.golang.orgで整合性検証される。ソースコードはGoのProxyサーバにキャッシュされるため、npmのように「publish直後に削除」して証拠を消す攻撃はGoでは難しい。

Java/Maven の逆コンパイル解析

code: (bash)

# jadx: Javaバイトコードの逆コンパイル

jadx -d output/ suspicious.jar

# grep疑わしいパターン

grep -r "Runtime.exec\|ProcessBuilder\|URLClassLoader\|Base64.decode" output/

Rust crate の静的解析

Rustはコンパイル言語だが、ソースとして配布されるためsemgrepやgrepが使用可能:

code: (bash)

# build.rsを持つcrateをlockfileから抽出してリストアップ

cargo metadata --format-version 1 | \

# cargo-deny でアドバイザリチェック

cargo deny check advisories

19. CIパイプラインのハードニング

GitHub Actions

self-hosted runnerはエフェメラル(使い捨て)構成にする。SHA1-Huludは被害者のrunnerを攻撃基盤に転用した

他CIでの等価対策

共通原則

19 エコシステム別CIハードニングの追加詳細

Maven/Gradle (Java)

code: (xml)

<!-- pom.xml: pluginManagement で全pluginをバージョン固定 -->

<pluginManagement>

<plugins>

<plugin>

<groupId>org.apache.maven.plugins</groupId>

<artifactId>maven-compiler-plugin</artifactId>

<version>3.13.0</version> <!-- 固定 -->

</plugin>

<plugin>

<groupId>org.cyclonedx</groupId>

<artifactId>cyclonedx-maven-plugin</artifactId>

<version>2.8.1</version> <!-- 固定 -->

</plugin>

</plugins>

</pluginManagement>

CIでの完全オフライン化(Nexusキャッシュ利用時):

code: (bash)

mvn --offline dependency:resolve # 社内Nexusのキャッシュから解決

mvn --offline verify # ビルド+テスト。外部アクセス禁止

code: (properties)

distributionUrl=https\://services.gradle.org/distributions/gradle-8.7-bin.zip

distributionSha256Sum=194717442575a6f96e1c1befa2c30e9a4fc90f701d7aee33eb879b79e7ff05c0

Python (GitHub Actions)

code: (yaml)

- uses: actions/setup-python@v5

with:

python-version: '3.12'

cache: 'pip'

- name: Install dependencies (hashed)

run: pip install --require-hashes -r requirements.txt

# --require-hashes: lockfileのhashと照合。改ざんは即失敗

- name: Audit

run: pip-audit -r requirements.txt --require-hashes

Rust (GitHub Actions)

code: (yaml)

- uses: dtolnay/rust-toolchain@stable

with:

toolchain: stable

# SHA pinning: dtolnay/rust-toolchain はタグを使う設計だが

# uses: dtolnay/rust-toolchain@a54c7afa936d023c4b72093a2b3c47f7c96a4b85 で固定可

- name: cargo audit

run: cargo audit

- name: cargo vet

run: cargo vet # 未監査crateがあれば失敗

Ruby (GitHub Actions)

code: (yaml)

- uses: ruby/setup-ruby@v1

with:

ruby-version: '3.3'

bundler-cache: true # Gemfile.lockからキャッシュ復元

- name: Security audit

run: bundle exec bundle-audit check --update

- name: Install frozen

run: bundle install --frozen # Gemfile.lockの書き換えを禁止

20. コンテナイメージのサプライチェーン

対策の要点

code: (dockerfile)

# 悪い例(タグは可変)

FROM node:20

# 良い例(digest固定)

FROM node:20@sha256:2e8e5e8b0f7d...

code: (bash)

# publish側

cosign sign --yes ghcr.io/myorg/app:v1.2.3

# consume側(Kubernetes Admission Controllerで強制)

cosign verify \

ghcr.io/myorg/app:v1.2.3

20 コンテナビルドとアプリ言語の接点

コンテナはベースイメージ层とアプリ依存层の2層のサプライチェーンを持つ。node/python/java等のベースイメージには各言語エコシステムのパッケージマネージャが含まれており、ビルド時のパッケージ取得も攻撃面になる。

Node.js コンテナのベストプラクティス

code: (dockerfile)

FROM node:20@sha256:<digest> # digest固定

WORKDIR /app

COPY package.json package-lock.json ./

RUN npm ci --ignore-scripts # 1: install scriptを無効化

COPY . .

RUN npm run build

# ---マルチステージ---

FROM node:20-alpine@sha256:<digest>

COPY --from=0 /app/dist ./dist

COPY --from=0 /app/node_modules ./node_modules

USER node # rootで動かさない

Python コンテナのベストプラクティス

code: (dockerfile)

FROM python:3.12-slim@sha256:<digest>

WORKDIR /app

COPY requirements.txt .

RUN pip install --no-cache-dir --require-hashes -r requirements.txt

# --require-hashes: ダウンロードしたwheelのhashをrequirements.txtと照合

COPY . .

USER nobody

Java/Maven コンテナのベストプラクティス

code: (dockerfile)

# ビルドステージ: Maven公式イメージ(digest固定)

FROM maven:3.9-eclipse-temurin-21@sha256:<digest> AS builder

WORKDIR /build

COPY pom.xml .

# 依存を先にダウンロードしてキャッシュ層を分離

RUN mvn dependency:go-offline -B

COPY src ./src

RUN mvn package -DskipTests -B --offline

# 実行ステージ: distroless Java(シェルなし)

FROM gcr.io/distroless/java21-debian12@sha256:<digest>

COPY --from=builder /build/target/app.jar /app.jar

コンテナイメージの脆弱性スキャン比較

table:table

ツール 対応言語エコシステム 特徴

trivy npm/pip/gem/cargo/Maven/NuGet + OS SBOM生成も兼ねる

grype 同上 syftと組み合わせが一般的

Snyk Container 同上 PR連携、自動修正提案

Docker Scout 同上 Docker Desktop統合

Clair OS層中心 Quay.io統合

21. IDE拡張機能・開発ツール

VSCode Marketplace、JetBrains Plugin Repository、vim-plugなどのエディタ拡張機能はパッケージ管理と同等の供給源でありながら、セキュリティ対策が軽視されがちである。拡張機能はエディタプロセスの権限で動作し、開いているファイル、ターミナル、git credentials、環境変数にアクセスできる。

過去事例:

2023年 VSCode Marketplace上の「Prettier - Code formatter」等のtyposquatting拡張で数十万ダウンロード

2024年 悪意あるPythonリンター拡張がOAuthトークンを窃取

IDE拡張への対策

21 IDE別のサプライチェーンリスクと対策

VS Code・JetBrains・Eclipse の3大IDEはそれぞれ異なる拡張配布モデルを持ち、リスクプロファイルが異なる。

code: (bash)

# JetBrains IDE: pluginの自動更新を無効化して変更を管理者がコントロール

# idea.properties / vmoptions に追加:

idea.plugins.path=/opt/company/jetbrains-plugins/ # 共有の承認済みpluginディレクトリ

code: (ini)

# eclipse.ini

-Declipse.p2.queryContactAllSites=false

-Declipse.p2.updatePolicy=Never

22. AIコーディング支援・MCPサーバ

主な攻撃経路

AIエージェントへの対策

22 AIツールのエコシステム別リスク

AIコーディング支援がnpm以外のエコシステムでどう使われるかによってリスクが変わる。

table:table

言語/エコシステム AIツールでの典型的なリスク 緩和策

code: (bash)

# 悪い例: バージョン未指定で最新をインストール

uvx mcp-server-git

# 良い例: バージョン固定して内部ミラー経由

uv tool install mcp-server-git==1.2.3 \

Javaエコシステム向けのMCPサーバ(Spring AI MCP等)はMaven Central経由で配布される。11のNexusプロキシを経由させることでクールダウンとwhitelistが適用される。

23. インシデント対応ランブック

初動(発覚から1時間)

# 例: axios 1.14.1 を全リポジトリで検索

fd 'package-lock.json|pnpm-lock.yaml|yarn.lock' | xargs rg 'axios.*1\.14\.1'

封じ込め(1〜4時間)

認証情報ローテーション(4〜24時間)

侵害されたマシン・CIで触れた可能性のある認証情報を機械的にローテする。優先順位:

クラウドアクセスキー(AWS/GCP/Azure)、特に長期IAM User access key

GitHub PAT、OAuth App、GitHub App installation token

データベース接続文字列、APIキー(Stripe、SendGrid等)

SSH鍵、GPG鍵

通知と報告(24〜72時間)

社内ステークホルダー(エンジニアリング、法務、セキュリティ、CS)への状況共有

必要に応じて顧客・規制当局への通知(GDPR 72時間ルール等)

公表する場合の素案ドラフト。影響範囲・封じ込め状況・ユーザーが取るべきアクションの3点を明記

ポストモーテムの予約(インシデントから1-2週間以内)

ランブック化の要点

各ステップの責任者(名前ではなくロール)、使用するツール、判断基準を事前に合意

定期的に机上演習(table-top exercise)で手順をなぞる

他エコシステムの初動コマンド集

code: (bash)

# Python: pip requirements.txtから特定パッケージを全リポジトリで検索

fd 'requirements.*\.txt' | xargs rg 'requests==2\.31\.0'

# Python: Poetry lockfileから検索

fd 'poetry\.lock' | xargs rg '"requests"' -A2 | grep 'version = "2.31.0"'

# Go: go.sumから特定モジュールを検索

fd 'go\.sum' | xargs rg 'github.com/user/repo v1.2.3'

# Java/Maven: pom.xmlとGradle lockfileから検索

fd 'pom\.xml' | xargs rg '<version>1\.2\.3</version>' -B3 | grep 'artifactId'

fd 'gradle\.lockfile' | xargs rg 'com.example:library:1.2.3'

# Rust: Cargo.lockから検索

fd 'Cargo\.lock' | xargs rg 'name = "serde"' -A2 | grep 'version = "1.0.197"'

# Ruby: Gemfile.lockから検索

fd 'Gemfile\.lock' | xargs rg ' rails \(7\.1\.3\)'

# .NET: packages.lock.jsonから検索

fd 'packages\.lock\.json' | xargs rg '"Newtonsoft.Json"' -A3 | grep '"resolvedVersion": "13.0.3"'

table:table

レジストリ token取り消し方法 優先度

PyPI pypi.org → Account Settings → API tokens 最高

crates.io crates.io → Account Settings → API Tokens 最高

Maven Central Central Publisher Portal → Token管理 高

RubyGems rubygems.org → Edit Profile → API Key 高

NuGet nuget.org → API keys 高

GitHub Settings → Developer settings → Personal access tokens 最高(全レジストリに影響)

24. ブラストレイディアス評価

可視化の軸

判断テンプレート

運用のコツ

SBOMは成果物(デプロイされているバージョン)ベースで保存。ソースのlockfileだけでは不十分

Dependency-Trackのような集中管理ツールに全サービスのSBOMを集約し、CVE / 悪性パッケージのマッチングを継続的に走らせる

参考: 近年の侵害事例とブラストレイディアス

他エコシステムのブラストレイディアス評価軸

「汚染パッケージがどこまで影響するか」はエコシステムごとに構造が異なる。

Maven/Gradle のブラストレイディアス

評価手順:

code: (bash)

# 特定パッケージに依存するプロジェクトをDependency-Trackで逆引き

# Dependency-Track API: /api/v1/component/project で逆引き検索

curl -H "X-Api-Key: $DTRACK_KEY" \

# Mavenリポジトリ内で依存しているpomを検索

mvn dependency:resolve-plugins # pluginの依存ツリー確認

Python のブラストレイディアス

code: (bash)

# インストール済みパッケージがどのvenvで使われているか確認

pip show <pkg> # インストール場所の確認

# 全プロジェクトのrequirements.txtを横断検索

fd 'requirements.*\.txt|pyproject\.toml|Pipfile\.lock' \

~/workspace | xargs rg '<pkg_name>'

Go のブラストレイディアス

code: (bash)

syft binary ./myapp -o cyclonedx-json > sbom.json

grype sbom:sbom.json # バイナリ内のモジュール脆弱性をスキャン

Rust のブラストレイディアス

code: (bash)

# ビルド時にSBOMをバイナリに埋め込む

cargo install cargo-auditable

cargo auditable build --release

# 任意のタイミングで監査

cargo audit bin target/release/myapp

対策の層構成

汎用的原則(全エコシステム共通)

table:table

原則 防止する攻撃 導入コスト

バージョン完全固定+lockfile厳格化 悪意あるバージョンへの自動解決、lockfileドリフト 低

リリース経過時間の猶予(クールダウン) 攻撃ウィンドウ中のインストール 低

installスクリプト/ビルド時任意コードの無効化または限定許可 install時の任意コード実行 低〜中

署名・Provenance検証(レジストリ・コンテナ・CI出力) 信頼ワークフロー外からのpublish 低

事前監査ツール(脆弱性・悪性・新規依存) 既知の悪性、postinstallパターン 低

長期トークンの排除(OIDC Trusted Publishing / 短命credentials) アカウント乗っ取りからの二次被害 中

プライベートレジストリプロキシ Dependency Confusion、大規模侵害時の即時遮断 中

実行環境サンドボックス(Dev Container / ephemeral runner) ホストマシン・AI認証情報への横展開 中

egress制御 + SBOM + インシデントランブック 侵害後の能動的搾取、ブラストレイディアス拡大 中〜高

npm特化の即効対策(上位5つ)

これら5つはいずれも低コストで即日導入でき、過去1年の主要攻撃(Shai-Hulud / SHA1-Hulud / Axios)の全てを防止または緩和できた。

参考資料

エコシステム別

インシデント対応・フレームワーク