脆弱性を修正する
ほとんどの脆弱性は、パッケージを影響のないバージョンに更新すれば修正されます。このページでは、報告書の脆弱性のページから、 修正してデプロイするまでと、最新に保ち続ける方法を説明します。
1. アドバイザリを読む
脆弱性のページには、パッケージ、導入バージョン、影響するバージョン、アドバイザリへのリンクがあります。影響する バージョンは Composer の制約の書き方です。, は「かつ」、| は「または」です。
| 影響するバージョン | 意味 |
|---|---|
<6.5.0 | 6.5.0 より前のすべて。6.5.0 で修正されています |
>=5.0.0,<5.2.27|>=6.0.0,<6.0.6 | 5.0.0〜5.2.26 と 6.0.0〜6.0.5。5.2.27 と 6.0.6 で修正されています |
>=2.0.0 | 2.0.0 以降のすべて。まだ修正されたバージョンはありません |
アドバイザリ (ページの最初のリンク) を開いて、次を読みます。
- 修正されたバージョンと、導入バージョンからそこまでのパッケージの CHANGELOG
- 何が脆弱か: 機能、関数、設定であることが多いです。アプリケーションがそれを使っているかで、どれだけ急ぐかを 判断します。使っていなくても修正してください。あとでコードが使い始めることがあります。
- 回避策: まだ修正されたバージョンがない場合
報告書のリスクは、アドバイザリのもの (critical、high、medium、low) です。緊急と高を先に、次のリリースまでに 修正してください。
2. パッケージを更新する
composer.jsonの制約の範囲で更新します。パッチリリースやマイナーリリースで修正されることがほとんどです。bashcomposer update vendor/package --with-dependencies制約が修正されたバージョンを許さないときは、パッケージの変更 (CHANGELOG やリリースノートの、アプリケーションを 壊す変更) を読んでから、制約を上げます。
bashcomposer require vendor/package:^2.4アプリケーションではなく、ほかのパッケージがそのパッケージを必要としているときは、どのパッケージか、何が修正された バージョンを妨げているかを調べます。
bashcomposer why vendor/package # それを必要とするパッケージ composer why-not vendor/package 2.4.1 # このバージョンを妨げているものそれを必要とするパッケージを更新します。そのパッケージが修正されたバージョンを許していて、ロックファイルにないだけなら、
composer update vendor/packageで足ります。まだ許していないなら、そのパッケージが修正されたバージョンで動く場合 (そのテストや issue で確かめて) だけcomposer.jsonで直接要求するか、そのリリースを待ち、それまでは理由を書いて 除外します。修正されたバージョンがないときは、アドバイザリの回避策 (設定、使わない機能) を適用するか、開発が終了したパッケージ なら置き換えるか、アプリケーションに当てはまらない脆弱性なら理由を書いて除外します。
そのあとテストを実行し、composer.lock をコミットしてデプロイし、もう一度チェックします。報告書からその脆弱性が 消えます。
CakePHP
pieceofcake2/cakephp の脆弱性は、2.12 の最新のリリースに更新してください。そのリリースはアプリケーションの API を 変えず、セキュリティの修正は リポジトリのアドバイザリ で公開されます。
composer update pieceofcake2/cakephp修正のために足す設定など、リリースの注意は CHANGELOG をご覧ください。pieceofcake2 のプラグインも同じように更新します。
開発が終了したパッケージ
作者が開発の終了を示したパッケージには、後で見つかる脆弱性も含めて、修正が出ません。報告書には、作者が示していれば 代わりのパッケージも載ります。たとえば symfony/debug は symfony/error-handler に置き換えます。
- 何が使っているかを調べます:
composer why symfony/debug。 - アプリケーションが要求しているなら、
composer.jsonとコードで置き換えます (composer remove、新しいパッケージのcomposer require、変わった名前空間と呼び出し)。 - ほかのパッケージが要求しているなら、そのパッケージを更新します。新しいバージョンでは置き換えが済んでいることが 多いです。
開発が終了したパッケージで不合格にはなりませんが、置き換えを計画してください。開発が終了したパッケージの次の脆弱性には、 修正が出ません。
開発用のパッケージ
開発用のパッケージ (require-dev: PHPUnit、ビルドやチェックのツール) はデプロイされませんが、開発者のマシンや CI で、 コードや CI のシークレットにアクセスできる状態で動きます。これも修正してください。--no-dev は、デプロイするものの一覧と してのリリースの報告書などで、開発用のパッケージを除きます。
最新に保つ
アドバイザリは、すでにインストールしたバージョンについて公開されます。何も変えていないアプリケーションにも、新しい 脆弱性が見つかります。パッケージを最新に保ってください。
CI で毎週チェックします。何も変えていなくても実行します (GitHub Actions での CI)。ワークフローの
scheduleが、最後の push 以降に公開されたアドバイザリを見つけます。pull request で更新します。GitHub の Dependabot が、パッケージの新しいバージョンの pull request を開き、CI が テストします。
yaml# .github/dependabot.yml version: 2 updates: - package-ecosystem: composer directory: / schedule: interval: weekly遅れているものを見ます。
composer outdated --directは、新しいバージョンのあるcomposer.jsonのパッケージを 一覧にします。アプリケーションの
composer.lockをコミットします。チェックはそれを読み、デプロイはチェックしたのと同じ バージョンをインストールします。