セキュリティパッチ対応を継続的に回す運用の作り方

半年前に外部に依頼して脆弱性警告を一掃してもらったはずなのに、久しぶりにDependabotのタブを開いたら赤い件数がまた二桁になっている。そんな経験はないでしょうか。パッチ対応は「一度きれいにすれば終わり」ではなく、依存ライブラリが日々更新される限り、放っておけば必ずまた溜まります。この記事では、単発の一掃作業ではなく、パッチ対応を継続的に回す仕組みそのものをどう作るかを発注者向けに整理します。

なぜ一度片付けても、また溜まるのか

単発対応が「その場しのぎ」で終わってしまうのには、明確な理由があります。

• 対応した人がいなくなると止まる。外注や特定の担当者が一括対応した場合、その人が離れた瞬間に「誰も見ていない状態」に逆戻りします。属人的な一掃は、仕組みとして根付かないと数ヶ月で元に戻ります。
• 検知の仕組みが対応後に外れている。一時的にDependabotやbundle auditを走らせて対応したものの、CIへの組み込みや通知設定まではせず、次に誰かが気づくのは「また溜まってから」になりがちです。
• 「見る時間」が業務として確保されていない。機能開発のスプリントには工数が割り当てられるのに、パッチ対応は「空いた時間にやる」扱いのままだと、忙しい時期に真っ先に後回しにされます。
• トリアージの基準が個人の頭の中にしかない。「これは緊急、これは様子見」の判断が前回対応した人の勘に依存していると、担当が変わるたびに基準がリセットされ、結局また全件を一から見直す羽目になります。

つまり単発対応で足りないのは技術力ではなく、検知・判断・実行・記録を回し続ける仕組みです。単発でパッチを当てる進め方自体は放置されたセキュリティパッチ対応を進める方法で扱っているので、そちらは「今溜まっているものをどう片付けるか」、この記事は「片付けた後どう回し続けるか」に焦点を当てます。

継続的な運用に必要な4つの要素

パッチ対応を仕組みとして回すには、次の4つが揃っている必要があります。どれか一つでも欠けると、数ヶ月単位で元の放置状態に戻ります。

1. 自動検知(気づく仕組み)

• Dependabot alerts(GitHub)やrenovateを有効化し、新しい脆弱性が公開された時点でPRやIssueが自動生成される状態にします。手動でツールを都度実行する運用は、実行し忘れた時点で検知が止まります。
• Rubyであればbundle audit、Node.jsであればnpm auditをCIパイプラインに組み込み、新しいコードがマージされるたびに機械的にチェックが走る状態を作ります。手元でたまに実行する運用と、CIで毎回強制される運用では、放置される確率が大きく変わります。
• 検知結果はSlack通知などで人が意識せずとも目に入る場所に流します。ダッシュボードを見に行く運用は、忙しいと見に行かなくなります。

2. トリアージのルール(判断を属人化させない)

• 深刻度(CVSSスコア)と到達可能性(外部公開されている箇所に関わるか)のかけ算で優先度を決める基準を、個人の頭の中でなく文書として残します。担当者が変わっても同じ基準で判断できることが重要です。
• 「Critical・Highかつ外部到達可能」は即時対応、「Medium以下または内部限定」は次回定期対応にまわす、といったしきい値を事前に決めておくことで、警告が出るたびに一から検討する手間を減らせます。
• 判断に迷うケース(影響範囲が読みにくい、パッチ適用がメジャーバージョンアップを伴う)は、誰にエスカレーションするかも決めておきます。

3. 定期対応の時間確保(仕組みを回す燃料)

• 「気づいたときにやる」ではなく、週次または隔週で「パッチ・依存更新の時間」をスケジュールに組み込みます。30分〜1時間程度の枠でも、定期的に回っていれば警告が数十件に膨れ上がることはありません。
• 外部の保守契約に含める場合は、「月◯時間はパッチ・依存更新の監視と対応に充てる」という形で契約条項に明記します。曖昧な「随時対応します」という契約は、結局対応されないまま契約更新を迎えることが多くあります。
• 定期対応の担当が個人に紐づいていると、退職・異動で仕組みごと止まります。チームやロールに紐づける(例:週次のインフラ当番が兼務する)ほうが継続性が高まります。

4. 記録(次に活かす・説明責任を果たす)

• 何を・いつ・なぜ対応した(またはしなかった)かを簡潔にでも記録に残します。CHANGELOGやIssueのクローズコメント程度で構いません。記録がないと、次に似た警告が出たときに「これは前も見た気がするが対応したかどうか分からない」という状態になります。
• 経営層や取引先からセキュリティ対応状況を問われたとき、記録があれば即座に説明できます。記録がないと、都度過去のPRやコミット履歴を掘り起こす調査コストが発生します。
• 「対応不要と判断した」警告についても、判断理由を残しておくことが重要です。後から見返したときに「なぜ対応しなかったのか」が分からないと、同じ議論を繰り返すことになります。

誰が・いつ見るかを決める(体制の作り方)

仕組みを作っても、それを実行する体制がなければ機能しません。規模別に現実的な体制の作り方を整理します。

• エンジニア1〜2名の小規模チーム:週次の定例(スタンドアップなど)の冒頭5分でDependabot alertsを確認する運用が現実的です。専任担当を置く余裕がない前提で、既存の定例に組み込むのがポイントです。
• エンジニア3名以上のチーム:週替わりまたは月替わりの「セキュリティ当番」を回す形にすると、特定の個人に負荷と知識が集中するのを防げます。当番の引き継ぎ時に前述のトリアージルールを参照させれば、判断基準がぶれません。
• 専任のインフラ・セキュリティ担当がいないチーム:外部の保守契約に組み込むのが現実的です。ただし前述の通り「月◯時間・対応範囲・エスカレーション条件」を契約書レベルで明文化しないと、なあなあの対応になりがちです。

規模を問わず共通するのは、「誰かがやるはず」という曖昧な状態を作らないことです。担当が決まっていない仕組みは、緊急時以外は誰も動かしません。

外部保守に組み込む場合の見極めポイント

継続的なパッチ運用を外部委託・外部保守契約に組み込む場合、次の点を確認すると「結局また溜まる」事態を避けやすくなります。

• 検知の自動化まで含んだ提案か。パッチを当てる作業だけでなく、Dependabot/renovateの設定・CIへの組み込みまで契約範囲に含まれているかを確認します。検知が自動化されていなければ、委託先も気づけません。
• トリアージ基準を明文化して共有してくれるか。「弊社が適宜判断します」ではなく、深刻度と到達可能性の基準を発注側にも見える形で示してくれるかは、説明責任を果たせるかどうかに直結します。
• 定期対応の頻度が契約に明記されているか。「随時対応」ではなく「週次で確認・月次で棚卸し」のように頻度が具体的に書かれているかを確認します。
• 対応記録を定期的に共有してくれるか。月次レポートなどの形で「何件検知し、何件対応し、何件は様子見と判断したか」が可視化される運用であれば、社内での説明責任も果たしやすくなります。

私たちは保守・運用で、Dependabotやbundle audit/npm auditのCI組み込みから、深刻度に応じたトリアージルールの策定、週次〜月次の定期対応、対応記録の月次共有までを継続的な運用として提供しています。単発の一掃作業だけでなく「その後どう回し続けるか」まで含めて設計するのが、私たちが単発対応と切り分けている理由です。すでに溜まっている警告を今すぐ片付けたい場合は放置されたセキュリティパッチ対応を進める方法、依存ライブラリの更新自体の優先順位づけは放置された依存ライブラリ更新を進める優先順位もあわせてご覧ください。既存プロダクトの改善に着手する際に最初に見るべき観点全般は既存プロダクトの改善、外部チームが最初に見る観点で整理しています。

まとめ

• パッチ対応が一度片付けてもまた溜まるのは、検知・トリアージ・実行時間・記録のいずれかが仕組みとして根付いておらず、属人的な一掃で終わっているため
• 継続的に回すには「自動検知(Dependabot/CI組み込み)」「文書化されたトリアージ基準」「定期対応の時間確保」「対応記録」の4要素をセットで整える必要がある
• 外部保守に組み込む場合は、検知の自動化・トリアージ基準の明文化・対応頻度・記録の共有が契約レベルで具体化されているかを見極める

「一度は対応してもらったが、また警告が溜まってきた」という状態であれば、単発対応ではなく仕組みそのものを見直すタイミングです。torcheees では既存プロダクトの診断から、継続的な改善支援(継続的なパッチ運用の設計を含む)まで対応しています。お問い合わせフォームからご相談ください。