Composerの依存関係の脆弱性チェック：WordPressでcomposer auditを使う手順

Composer で WordPress 本体やプラグイン、PHP ライブラリを管理していると、vendor/ の中に自分で書いていないコードが大量に入ります。その中に既知の脆弱性を持つ版が混じっていないかを調べるのが composer audit です。この記事では、WordPress のプロジェクト（Bedrock 構成や、Composer を使うテーマ・プラグイン開発）で composer audit を使い、見つかった問題を直すまでの手順をまとめます。情報は2026年10月時点の Composer 公式ドキュメントに基づきます。

composer audit で分かること・分からないこと

composer audit は、インストール済み（または composer.lock に記録された）パッケージを、セキュリティアドバイザリ（既知の脆弱性情報）と照合するコマンドです。照合先は既定で Packagist.org の API で、composer.json の repositories に書いたリポジトリがアドバイザリを提供していればそれも使います。Composer 2.4 で追加されたコマンドなので、それより古い Composer では使えません。

つまり、composer audit が「問題なし」でも、WordPress プラグインの脆弱性まで点検できたことにはなりません。プラグインは別の方法でも確認します（後半で説明します）。

手順1: Composer の版を確認する

composer --version

Composer 2.4 より古い場合は、更新します。公式インストーラーで入れた Composer なら次のコマンドで最新版になります。

composer self-update

OS のパッケージ（apt install composer など）で入れた Composer は版が古いことがあります。その場合は Composer 公式のダウンロードページ の手順で入れ直してください（インストーラーのハッシュ値は更新されるため、公式ページに書かれたものを使います）。

手順2: composer audit を実行する

composer.json と composer.lock があるディレクトリ（Bedrock ならプロジェクトのルート）で実行します。

cd /path/to/project
composer audit

よく使うオプションは次のとおりです。

問題が見つかると、パッケージ名、深刻度、CVE 番号、影響を受ける版の範囲、詳細ページの URL が表示され、終了コードが 0 以外になります。問題がなければ終了コードは 0 です。スクリプトや CI ではこの終了コードで判定します。

composer audit --no-dev --locked
echo $?

手順3: 見つかったパッケージを更新する

どのパッケージが引き込んでいるかを調べる

脆弱性が見つかったパッケージを自分で直接 require しているとは限りません。composer why で依存の経路を確認します。

composer why vendor/package

修正版に更新する

修正版が出ていれば、そのパッケージと依存先をまとめて更新します。

# 対象パッケージと、その依存パッケージを更新
composer update vendor/package --with-dependencies

# 共有している依存まで含めて更新が必要な場合
composer update vendor/package --with-all-dependencies

更新できない場合は、どの制約が邪魔をしているかを composer why-not で調べます。修正版の番号を指定します。

composer why-not vendor/package 2.0.5

composer.json の版の制約（例: ^1.2）が修正版を許していないなら制約を見直し、別のパッケージが古い版を要求しているならそちらの更新を検討します。

更新後は、もう一度 composer audit を実行して解消を確認し、ステージング環境で動作を確かめてから composer.lock をコミットします。

本番への反映

本番サーバーで composer update を実行すると、確認していない版が入る可能性があります。更新は手元や CI で行って composer.lock を確定させ、本番では lock ファイルどおりに入れます。

composer install --no-dev --optimize-autoloader

手順4: すぐに直せないアドバイザリを記録して除外する

修正版がまだ無い、または該当する機能を使っていないと確認できた場合は、理由を付けて除外できます。2026年10月時点の公式ドキュメント（Composer 2.10 以降）では、config.policy に書きます。

{
    "config": {
        "policy": {
            "advisories": {
                "ignore-id": {
                    "CVE-2026-0000": "該当機能を使っていない。修正版の公開後に更新する"
                }
            }
        }
    }
}

CVE-2026-0000 の部分は、実際に除外する CVE 番号またはアドバイザリ ID に置き換えます。2.10 より前の Composer では config.audit.ignore に書きます（対応している形式は、お使いの版のドキュメントで確認してください）。2.10 以降でも config.audit の設定は互換のため読まれますが、非推奨です。

除外は「見なかったことにする」設定なので、理由と見直す時期をコメントやチケットで残し、定期的に外せるかを確認してください。

更新時に脆弱な版を入れない設定

Composer 2.10 以降は、composer update・require・remove のときに、アドバイザリがある版を依存解決の候補から外す動作が既定で有効です（config.policy.advisories.block の既定値が true）。ただし、すでに composer.lock に記録されている版を composer install で入れる場合は止まりません。lock ファイルに残っている古い版は composer audit で見つけて更新する必要があります。

また、composer install は既定では監査を行いません。インストール後に監査も実行したい場合は --audit を付けます。

composer install --no-dev --audit

WordPress プラグイン・テーマも点検する

Composer で入れている場合

WPackagist などで入れたプラグイン・テーマは、Packagist.org のアドバイザリには含まれません。Roots（Bedrock の開発元）のドキュメントでは、第三者が運営する WP Sec Adv というリポジトリを追加すると、Wordfence Intelligence の脆弱性情報で composer audit がプラグイン・テーマ・WordPress 本体を照合できるようになると案内されています。

composer repo --append add wpsecadv composer https://repo-wpsecadv.typist.tech
composer audit

照合はプラグインのスラッグで行われます。外部サービスに依存するため、導入前に Roots のドキュメント で最新の手順と提供元を確認してください。

管理画面から入れている場合

Composer の管理外なので、WPScan などの脆弱性データベースを使って確認します。手順は次の記事を参照してください。

• WordPressのWPScanで脆弱性を発見する方法
• WordPressプラグインの脆弱性をWPScanとNVDで追跡する方法

定期的に実行する

GitHub Actions で実行する

リポジトリに composer.lock をコミットしているなら、プッシュ時と週1回、自動で監査できます。.github/workflows/composer-audit.yml の例です。

name: composer-audit
on:
  push:
  schedule:
    - cron: '0 0 * * 1'   # 毎週月曜 0:00（UTC）
jobs:
  audit:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: shivammathur/setup-php@v2
        with:
          php-version: '8.3'
          tools: composer
      - run: composer audit --locked --no-dev

--locked を付けているので、composer install をしなくても lock ファイルの内容で照合できます。脆弱性が見つかるとジョブが失敗し、GitHub の通知で気付けます。依存パッケージの更新プルリクエストを自動で作りたい場合は Dependabot も使えます（GitHub Dependabotで依存関係を自動更新する方法）。

サーバーの cron で実行する

CI が無い場合は、サーバーの cron で週1回実行し、結果をログに残します。

# crontab -e で追加（毎週月曜 6:00）
0 6 * * 1 cd /path/to/project && composer audit --no-dev --locked --format=plain > /var/log/composer-audit.log 2>&1 || echo "composer audit で問題を検出" | mail -s "composer audit" admin@example.com

mail コマンドが使えない環境では、ログを監視ツールで拾うなど、気付ける仕組みに置き換えてください。

注意点

• composer audit は既知の脆弱性しか見つけられません。公開前の脆弱性や、自分で書いたコードの問題は対象外です。
• 照合には Packagist.org などへの通信が必要です。通信できないリポジトリがあると監査が失敗します。CI で一時的な障害を無視したい場合は --ignore-unreachable があります。
• 開発が終了したパッケージ（abandoned）も報告されます。すぐに危険というわけではありませんが、今後修正が出ない可能性が高いので、後継パッケージへの移行を計画します。
• 依存の更新はサイトの動作を変えることがあります。バックアップとステージングでの確認を済ませてから本番に反映してください。

まとめ

• Composer 2.4 以降の composer audit で、vendor/ や composer.lock のパッケージを既知の脆弱性と照合できる。
• 見つかったら composer why で経路を調べ、composer update 対象 --with-dependencies で修正版に上げ、lock ファイルをコミットして本番では composer install で反映する。
• すぐ直せないものは理由を付けて config.policy.advisories.ignore-id（2.10 より前は config.audit.ignore）で除外し、定期的に見直す。
• WordPress プラグイン・テーマは既定では照合されないので、WP Sec Adv の追加や WPScan など別の方法で点検する。
• CI や cron で定期実行し、結果に気付ける仕組みを作る。

関連記事:

• composer.jsonとcomposer.lockの管理方法：installとupdateの使い分け