Composerの脆弱性管理、納品時のvendorのまま止めない──composer auditの位置づけ、lockファイル、更新の方針

この記事は、Composerの脆弱性管理、つまりPHPのサイトが使っているライブラリの弱点を、納品後にどう見つけて、どう更新するかを扱います。

「PHPは更新しています」で、ライブラリは止まっている

PHPの本体は、サーバーの更新で新しくなっていきます。
けれど、Composerで入れたライブラリは、誰かが更新の命令を打たない限り、納品した日の版のままです。

Laravelなどのフレームワークで作ったサイトは、数十から百を超えるライブラリに支えられています。
その一つに弱点が見つかっても、サイトの見た目は何も変わりません。

Composerの脆弱性管理とは、lockファイルに記録された版を、公開された弱点の情報と定期的に照らし合わせ、方針を決めて更新することである

黒字化の外科医です。Composerで入れたライブラリの、納品後の管理を解剖します。

管理の仕組みが必要な理由は、三つあります。

第一に、ライブラリの版は、lockファイルで固定されているから。
Composerの公式の説明では、composer.lock をリポジトリに含めることで、開発者も本番も同じ版を使える、とされています。固定されているからこそ、誰かが動かさない限り古いままです。

第二に、弱点の照合は、命令一つでできるから。
composer audit という命令で、入っているライブラリを、公開された弱点の情報と照らし合わせられます。やらない理由は、手間ではなく、決めごとがないことです。

第三に、更新には「当ててよい範囲」の判断が要るから。
すべてを最新にすれば、互換性の問題で動かなくなることがあります。どこまで上げるかを方針で決めておかないと、毎回その場の判断になります。

composer audit とは何か：公式の説明で確かめたこと

Composerの公式のドキュメントで、2026年10月に確かめた内容です。

・composer audit：入っているパッケージを、弱点の情報と照らし合わせる
　情報の取得元は、標準では Packagist.org の API
・放棄された（abandoned）パッケージも報告の対象になる
・--locked：vendor ではなく composer.lock の内容を調べる
・--no-dev：開発用（require-dev）のパッケージを除く
・--format：表、プレーン、JSON、要約の形式で出せる
・問題がなければ終了コード0、該当があれば1
・update、require、remove などの命令では、標準で監査の手順が動く

また、Composerの設定の説明では、弱点の情報があるパッケージの版を、update などで使えないようにする設定（policy.advisories.block）が、標準で有効と書かれています。

ただし、これは「これから入れる版」を止める仕組みです。
すでに lockファイルに書かれ、本番で動いている版は、誰かが照合しない限り見つかりません。ここが、制作会社の保守の出番です。

更新の方針は、3段階に分ける

① 弱点の修正（audit で該当が出たもの）
　→ 該当のパッケージだけを更新し、検証して反映する
② 同じ大きな版の中の更新（互換性を壊さない範囲）
　→ 月次や四半期にまとめて更新する
③ 大きな版をまたぐ更新（互換性が変わるもの）
　→ 見積もりを出し、案件として扱う

特定のパッケージだけを上げるときは、composer update にパッケージ名を付けます。そのパッケージが依存するものも一緒に上げる指定（--with-dependencies）もあります。
実行前に、--dry-run で変更の内容だけを確かめられます。

どの更新が③にあたるかは、composer outdated（composer show -lo と同じ）の表示で目安がつきます。公式の説明では、互換性を壊す新しい版と、互換性のある新しい版を、色で分けて示すとされています。

今すぐ試せる：composer audit の結果を顧客向けに訳すプロンプト

私はWeb制作会社の経営者です。composer audit の結果を、顧客向けの報告と社内の作業に分けてください。

【前提】
・サイト名と、使っているフレームワークと版：〔記載〕
・composer audit の出力（JSON形式または表）：〔貼り付け〕
・保守契約で引き受けている範囲：〔記載〕

1. 該当したパッケージを、深刻度の高い順に並べる。
2. それぞれ、上の「更新の方針」の①〜③のどれにあたるかを示す。
3. 社内の作業として、検証で確かめる画面や機能を挙げる。
4. 顧客向けに、専門用語を使わない3行の報告文を作る。

出力にない弱点の内容を推測で書かないこと。不明な点は「要確認」と書くこと。

依存関係の点検工場：月1回の流れとかかる時間

月1回の流れ

□ 各案件のリポジトリで composer.lock が管理されているか
□ composer audit --locked を実行し、結果を保存したか
□ 該当があれば、方針①として作業の予定日を決めたか
□ 放棄されたパッケージがあれば、代わりを検討する案件として記録したか
□ 結果を、月次報告の一行にまとめたか

計算例

例：Composerを使う保守案件 12件
　　1件あたりの実行・記録：15分
　　12件 × 15分 ＝ 180分 ＝ 月3時間

時間単価 8,000円（例）
　　3時間 × 8,000円 ＝ 月24,000円
　　24,000円 ÷ 12件 ＝ 1件あたり月2,000円

これは照合と記録だけの時間です。該当が出たときの更新と検証は、別の工数として見積もります。

構造的なリスク

逆説を指摘しておきます。

composer audit が何も出さなかった月に、「問題ありませんでした」と報告するのは危険です。
照合できるのは、公開された弱点の情報があるものだけで、まだ知られていない弱点や、情報の登録が遅れているものは出てきません。

報告では「〇月〇日時点で、公開された弱点の情報に該当はありませんでした」と、範囲と日付を書きます。言い切らないことが、保守の信頼を守ります。

よくあるQ&A

Q. 本番のサーバーで composer update を実行してよいか？

おすすめしません。更新は開発の環境で行い、変わった lockファイルを検証してから、本番では composer install で同じ版を入れます。流れはパッチ適用の検証と本番反映の記事で扱っています。

Q. 納品時に lockファイルを渡していなかった。

まず本番の vendor と composer.lock の有無を確認してください。lockファイルがなければ、今の状態を正として記録し直すところから始めます。

Q. フレームワーク本体の更新も、同じ扱いでいいか？

本体には独自のサポート期間があります。フレームワークのセキュリティ更新の記事で分けて扱いました。

最後に

Composerで入れたライブラリは、誰かが照合しない限り、納品した日のまま止まっています。

lockファイルを月に一度照らし合わせ、更新の範囲を方針で決めた会社だけが、見えない部品の弱点まで保守の価値に変えられるのです。

台帳の列と月次の報告の型は、こちらにまとめました。

▶ パッチ管理台帳のテンプレート、制作会社の保守キット──列設計、月次運用表、月次報告の型、緊急パッチの判断表、告知文例、AIプロンプト

これまでの記事は、メンバーシップ「黒字化オペ室」でまとめて読めます。月額1,980円、記事2本分の金額です。詳しくはプロフィールから。

#Web制作会社 #Composer #脆弱性対策 #PHP #Laravel #依存関係 #制作会社経営 #中小企業 #保守契約 #セキュリティ