# 脆弱性を修正する

ほとんどの脆弱性は、パッケージを影響のないバージョンに更新すれば修正されます。このページでは、報告書の脆弱性のページから、
修正してデプロイするまでと、最新に保ち続ける方法を説明します。

## 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. パッケージを更新する

1. **`composer.json` の制約の範囲で更新します**。パッチリリースやマイナーリリースで修正されることがほとんどです。

   ```bash
   composer update vendor/package --with-dependencies
   ```

2. **制約が修正されたバージョンを許さないとき**は、パッケージの変更 (CHANGELOG やリリースノートの、アプリケーションを
   壊す変更) を読んでから、制約を上げます。

   ```bash
   composer require vendor/package:^2.4
   ```

3. **アプリケーションではなく、ほかのパッケージがそのパッケージを必要としているとき**は、どのパッケージか、何が修正された
   バージョンを妨げているかを調べます。

   ```bash
   composer why vendor/package             # それを必要とするパッケージ
   composer why-not vendor/package 2.4.1   # このバージョンを妨げているもの
   ```

   それを必要とするパッケージを更新します。そのパッケージが修正されたバージョンを許していて、ロックファイルにないだけなら、
   `composer update vendor/package` で足ります。まだ許していないなら、そのパッケージが修正されたバージョンで動く場合
   (そのテストや issue で確かめて) だけ `composer.json` で直接要求するか、そのリリースを待ち、それまでは理由を書いて
   [除外](https://pieceofcake2.github.io/security-sca/ja/index.md#アドバイザリを除外する)します。

4. **修正されたバージョンがないとき**は、アドバイザリの回避策 (設定、使わない機能) を適用するか、開発が終了したパッケージ
   なら置き換えるか、アプリケーションに当てはまらない脆弱性なら理由を書いて除外します。

そのあとテストを実行し、`composer.lock` をコミットしてデプロイし、もう一度チェックします。報告書からその脆弱性が
消えます。

## CakePHP

`pieceofcake2/cakephp` の脆弱性は、2.12 の最新のリリースに更新してください。そのリリースはアプリケーションの API を
変えず、セキュリティの修正は [リポジトリのアドバイザリ](https://github.com/pieceofcake2/cakephp/security/advisories)
で公開されます。

```bash
composer update pieceofcake2/cakephp
```

修正のために足す設定など、リリースの注意は CHANGELOG をご覧ください。pieceofcake2 のプラグインも同じように更新します。

## 開発が終了したパッケージ

作者が開発の終了を示したパッケージには、後で見つかる脆弱性も含めて、修正が出ません。報告書には、作者が示していれば
代わりのパッケージも載ります。たとえば `symfony/debug` は `symfony/error-handler` に置き換えます。

1. 何が使っているかを調べます: `composer why symfony/debug`。
2. アプリケーションが要求しているなら、`composer.json` とコードで置き換えます (`composer remove`、新しいパッケージの
   `composer require`、変わった名前空間と呼び出し)。
3. ほかのパッケージが要求しているなら、そのパッケージを更新します。新しいバージョンでは置き換えが済んでいることが
   多いです。

開発が終了したパッケージで不合格にはなりませんが、置き換えを計画してください。開発が終了したパッケージの次の脆弱性には、
修正が出ません。

## 開発用のパッケージ

開発用のパッケージ (`require-dev`: PHPUnit、ビルドやチェックのツール) はデプロイされませんが、開発者のマシンや CI で、
コードや CI のシークレットにアクセスできる状態で動きます。これも修正してください。`--no-dev` は、デプロイするものの一覧と
してのリリースの報告書などで、開発用のパッケージを除きます。

## 最新に保つ

アドバイザリは、すでにインストールしたバージョンについて公開されます。何も変えていないアプリケーションにも、新しい
脆弱性が見つかります。パッケージを最新に保ってください。

- **CI で毎週チェックします**。何も変えていなくても実行します ([GitHub Actions での CI](https://pieceofcake2.github.io/security-sca/ja/ci.md))。ワークフローの
  `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` をコミットします**。チェックはそれを読み、デプロイはチェックしたのと同じ
  バージョンをインストールします。