WordPress公式のセキュリティチームが、2か月前に始めた「Core Security Initiative(コア・セキュリティ・イニシアチブ)」の中間報告を公開しました。ここ数か月、WordPress本体のセキュリティリリースが立て続けに出ていた背景が、数字で説明されています。
取り組みの3本柱
投稿では、この取り組みを「3つの柱、1つの目標」と説明しています。
- A: より良いリリースプロセス
- B: 滞留した報告の解消
- C: AIを使った脆弱性対策
報告数の急増
投稿によると、WordPressのHackerOneプログラムは約10年にわたり、月に20〜30件の報告を受けるペースでした。それが7月は450件、8月は773件に増え、直近90日では2,306件に達しています。今年の報告数は3,000件超で、過去12年分の合計を上回るとのことです。
セキュリティリリースの頻度
41日間に4回のセキュリティリリース(7.1.1〜7.1.4)が出ており、7月中旬からでは7回、CriticalまたはHighの脆弱性を50件以上修正したと説明されています。修正は、セキュリティ更新の対象となっている古いブランチ(4.7まで)にも反映されました。直近の7.1.4については、「WordPress 7.1.4」セキュリティリリース、アップグレード処理の弱点によるRCEなど12件を修正でも取り上げています。
リリース作業の自動化とAI活用
- セキュリティリリースの109工程のうち73%に自動化を導入。以前は最大25ブランチに手作業でバックポートしていた
- リリースごとに役割を決めた担当チームを編成し、広く使われているバージョンから先に、古いブランチを後から出す2段階で公開
- 届いた報告を読み、安全に再現して、妥当性や重大度の要約と推奨を投稿するAIトリアージを構築(最終判断は人間)
- 未トリアージの報告は359件から2桁台に減少
- AnthropicのOSS Scannerに参加し、最初のスキャン結果で指摘された問題への対応を開始
また、一部の手間はあえて残しているとも述べられています。たとえばリリースのパッケージ作成を少人数に限るのは、サプライチェーン攻撃への備えのためです。
サイト運営者が受け止めたいこと
報告が増えれば修正の頻度も上がります。「大きなリリースだけ追う」運用では、取りこぼしが出やすくなります。
- 自動更新(少なくともマイナー/セキュリティ更新)を有効にしておく
- 更新情報を見たら、本体・プラグイン・テーマをまとめて確認する習慣をつける
- 実際に攻撃が始まった事例はWordPress 7.1.4で修正されたRCE、公開後24時間で約6.3万件の攻撃試行で紹介しています
投稿は今後について、未トリアージの報告を少ない水準に保つことや、人手の拡充を呼びかけています。研究者には、影響が明確な報告を1件出すほうが、範囲外の報告を10件出すより役立つと案内しています。
出典: Make WordPress「The Core Security Initiative: two months in」
