security-updates

Composer を使用した Drupal のセキュリティ更新

以下の場合に使用します：

• Drupal プロジェクトのセキュリティ監査を実施する
• composer audit で指摘されたパッケージを修正する
• 特定のセキュリティアドバイザリを適用する
• 既知の脆弱性が残っていないことを確認する

---

開始前 — ブランチを作成する

この手順は必須です。新しいブランチを作成して確認するまで、composer コマンドを実行しないでください。 main または master に直接パッケージを更新しないでください。

最初に現在のブランチを確認します：

git branch --show-current

ユーザーが main、master、または保護されたブランチにいる場合は停止して、次のように尋ねます：「これらのセキュリティ修正用の新しいブランチ名は何にしますか？」

迷っている場合は、デフォルト名を提案します（例：security/drupal-updates-YYYY-MM-DD）。

git checkout -b <branch-name>

次に進む前に、新しいブランチがアクティブであることを確認します：

git branch --show-current

出力で保護されていないブランチが確認できた場合にのみ、次の手順に進みます。

---

脆弱性を監査する

composer audit

出力には、既知のアドバイザリがあるパッケージ、CVE ID、およびアドバイザリへのリンクが一覧表示されます。

JSON 出力（スクリプト用）

composer audit --format=json

開発用依存関係を除外して監査する

composer audit --no-dev

---

特定の脆弱なパッケージを修正する

composer update drupal/package --with-all-dependencies

更新に必要な推移的依存関係のバージョン変更を許可するには、--with-all-dependencies を使用します。

例 — drupal/core の既知のアドバイザリを修正する

composer update drupal/core-recommended drupal/core-composer-scaffold --with-all-dependencies

---

アドバイザリがあるすべてのパッケージを修正する

composer.json のバージョン制約の範囲内で、監査により指摘されたパッケージのみを更新します：

composer update --with-all-dependencies $(composer audit --format=json 2>/dev/null \
  | python3 -c "import sys,json; data=json.load(sys.stdin); print(' '.join(set(a['packageName'] for a in data.get('advisories', {}).values() if isinstance(a, dict)) or [v[0]['packageName'] for v in data.get('advisories', {}).values()]))" 2>/dev/null)

または、監査結果を確認したうえで手動で更新します：

# List vulnerable packages from audit output, then update each
composer update drupal/package1 drupal/package2 --with-all-dependencies

---

脆弱性が残っていないことを確認する

composer audit

すべての修正後に期待される出力：

No security vulnerability advisories found.

更新後のバージョンがインストールされていることを確認する

composer show drupal/package | grep versions

インストール済みのバージョンが、修正済みとして期待されるリリースと一致していることを確認します。Drupal コアの場合：

composer show drupal/core | grep versions

Drupal のブートストラップが成功することを確認する

Drush がローカルで利用できる場合：

drush status

期待される結果：Drupal bootstrap: Successful。ブートストラップに失敗した場合は、コミットせず、先に原因を調査してください。

監査で問題がないことを確認した後、必ず次の質問を順番にユーザーに尋ねてください：

1. 「これらの変更をコミットしますか？」

• はいの場合：

  git add composer.json composer.lock
  git commit -m "Apply Drupal security updates"
  

• いいえの場合 → 続行する前に、composer.json と composer.lock が未コミットであることをユーザーに伝えます。

2. 「これらの変更を Acquia 環境にデプロイしますか？」

• はいの場合 → Drupal の更新とデプロイのプレイブック に従って、コードをプッシュし、環境を切り替え、必要に応じてパイプラインビルドを開始します。
• いいえの場合 → 完了です。

3. デプロイ後： 作業を完了とする前に、対象環境でデータベース更新を実行します：

drush updb --yes
drush cr

---

トラブルシューティング

「要件を解決できませんでした」

アドバイザリの修正に必要なバージョンが、別の制約と競合しています。選択肢：

# Check what requires the package
composer why drupal/package

# Check what prevents the update
composer why-not drupal/package 2.x

# Relax the constraint in composer.json if safe, then retry
composer update drupal/package --with-all-dependencies

更新後もアドバイザリが残る

Composer のローカルアドバイザリデータベースが古い可能性があります。更新してください：

composer audit --update-cache
composer audit

他のパッケージを壊さずにパッケージを更新できない

競合するパッケージのバージョンを一時的に固定し、後続対応として起票します：

# Check the full dependency tree
composer depends drupal/conflicting-package

再試行する前に、composer.json の制約を解決してください。

問題のある更新をロールバックする

更新によってリグレッションが発生した場合は、バージョン管理から以前の状態を復元して、再インストールします：

git checkout composer.json composer.lock
composer install

更新をすでにコミットしている場合は、そのコミットを取り消します：

git revert HEAD
composer install

---

ベストプラクティス

1. デプロイの前に毎回 composer audit を実行する — 新しいアドバイザリを早期に検出します。
2. --with-all-dependencies を使用する — セキュリティ修正には、推移的依存関係の更新が必要になることがよくあります。
3. composer.lock の差分を確認する — 想定したパッケージのみが変更されていることを確認します。
4. アドバイザリのリンクを確認する — 更新する前に、脆弱性の内容を把握します。