basercms-security-advisory

baserCMS セキュリティアドバイザリ対応ガイド

baserCMS のリポジトリセキュリティアドバイザリ（GHSA・triage 含む）を、一覧→検証→課題別修正→フォーク/ブランチ/PR→ローカル検証まで一気通貫で扱う。スクリプトは scripts/ 配下。base ブランチは実行時の現在のブランチ（事前に対象リリースブランチを checkout しておく）。

0. 前提

• gh CLI 認証済み。対象 upstream は BCSA_UPSTREAM（既定 baserproject/basercms）。
• Copilot レビューと GitHub Actions はアドバイザリのプライベートフォークでは使えない。レビューはローカル /code-review、テストはローカル Docker（basercms-unittest）が正。
• フォーク full_name=<owner>/basercms-<小文字GHSA>、remote=sec-<小文字GHSA(先頭ghsa-除去)>、ブランチ=security/<GHSA-ID>。

1. 一覧と分類

scripts/list-advisories.sh [--state triage] で state別件数と一覧を取得し、triage を抽出する。

2. 指摘の検証

scripts/fetch-advisory.sh <GHSA-ID> で詳細を取得し、現在のブランチの実コードと突き合わせて「的確 / 不正確 / 非該当」を判定する。対象が多い場合は読み取り専用の並列サブエージェントで分担する。フレームワークのデフォルト保護（ORM バインド / slug エンコード / h() 出力）で再現しないものは非該当として却下し、具体的な PoC を要求する。

3. 修正方針の確定

同一 sink の重複アドバイザリ、共有ファイルの hunk 分割、非該当の却下を整理する。重複の扱い（複数 fork へ同一修正 / 片方を重複クローズ）など判断が要る点はユーザーに確認する。

4. 課題別フォーク/ブランチ/PR

アドバイザリ単位で:

1. scripts/create-fork-branch.sh <GHSA-ID> — フォーク作成 → remote 追加 → 現ブランチ起点でブランチ作成
2. 該当 hunk のみ適用（複数アドバイザリが同一ファイルを触る場合は git checkout … -- file で全取りせず hunk 単位で手適用）
3. どの脆弱性をどう直したか明確なメッセージでコミット
4. scripts/push-with-retry.sh <remote> security/<GHSA-ID> — フォーク反映待ちのリトライ付き push
5. scripts/open-pr.sh <GHSA-ID> [--title T] [--body-file F] — base=現ブランチで PR 作成

5. ローカル検証

1. scripts/build-integration.sh [統合ブランチ名] — 現ブランチ＋全 security/GHSA-* をマージ（競合は停止）
2. scripts/run-tests.sh — ローカル全テスト（詳細は basercms-unittest）
3. 必要なら統合ブランチを個人フォーク（<個人フォーク名>）へ push して GHA を回す（アドバイザリ fork では GHA は動かない）

6. 最新 base への追従

origin/base が進んだら各 PR ブランチへ base をマージし、push し直す。定番競合:

• order() → orderBy()（CakePHP 5.2 改名）
• パス検証 realpath() === false バイパス修正 × $fullPath 検証 の併合

6b. リリース後の取り込み確認とブランチ整理

アドバイザリ fork の PR を GitHub 上でマージすると、base ブランチには 「Merge commit from fork」という 1 コミット（squash） として入る。security/<GHSA-ID> ブランチ自体は base の祖先にならないため、git merge-base --is-ancestor や git branch --merged では「未マージ」に見える。取り込み確認は内容差分で行う。

1. 対象ブランチが変更したファイル一覧を取り、そのファイルだけを base と比較する（差分ゼロなら取り込み済み）:

   base=$(git merge-base security/<GHSA-ID> origin/5.4.x)
   files=$(git diff --name-only $base security/<GHSA-ID>)
   git diff --name-only origin/5.4.x security/<GHSA-ID> -- ${=files}   # zsh。bash は $files
   

   差分が残るファイルは git log <branch>..origin/5.4.x -- <file> で「取り込み後に別コミットで触られた」だけかを確認する。
2. 取り込み済みと確認できた security/* は git branch -D で削除する（削除は承認を得てから。10/22 など次回リリース分・顧客向けパッチ（consolidated-5.2.x）・未取り込み分は残す）。
3. 同じファイルを触る複数のアドバイザリ（例 BlogTags API の v9g2 と 636g）は、先にマージした方の fork コミットに後の修正が同梱されていることがある。後の PR をマージしても差分ゼロなら、そのリリースで既に塞がっている。
4. 5.3.x → 5.4.x の系列マージでは VERSION.txt 1 行目・composer.json・composer.lock が必ず競合する。バージョン値は上位系列（ours）を採用し、VERSION.txt には下位系列のリリースブロックだけを 5.4.x のブロックの下に追加する。

7. 落とし穴レシピ

• Copilot/GHA 不可: アドバイザリ fork では使えない。ローカル検証が正。
• push 反映待ち: 新規 fork 直後は remote rejected (failure)。終了コードでリトライ（-> 等の文字列で成功誤検知しない）。
• 共有ファイルの hunk 分割: 例 PluginsService の basename と php 実行パス検証は別アドバイザリ。hunk 単位で分けて適用。
• 同一 sink の重複: 同一修正を複数 fork へ、または片方を重複クローズ。
• 非該当の見極め: framework デフォルト保護で再現しないものは却下。報告時点のブランチ状態まで遡って確認。
• フルスイートのフレイキー: CreateReleaseCommandTest（実 composer 実行）は単体では緑。環境要因を切り分ける。
• 認可境界: permission.php の Api/Admin と Admin の auth 整合は、管理画面 SPA（ビルド済み JS まで）の依存を確認してから変更。
• 古い系列を後からリリースするとき monorepo-builder が止まる: ReleaseGuard は「ローカルタグのうち committer date が最新のもの」より大きいバージョンしか通さない（系列別の比較は無い）。5.4.0 の後に 5.3.1 を出すなら、リリース作業用クローンで git tag -d 5.4.0 してから vendor/bin/monorepo-builder release 5.3.1 を実行し、終わったら git fetch origin --tags で戻す。リモートのタグには影響しない。
• prepare release が未追跡ファイルを巻き込む: monorepo-builder の release は作業ツリーの未追跡ファイルもコミットする。下位系列（5.3.x）の .gitignore に上位系列だけのプラグイン（webroot/bc_burger_editor・webroot/bc_mcp のシンボリックリンク）が無いと、そのままタグに入る。リリース前に git status --short が空であることを確認し、系列ごとの .gitignore を揃える。混入したら git rm --cached と .gitignore 追記で直す。
• Packagist の反映は Web 表示より遅れる: split ワークフロー成功後、packagist.org のページに新バージョンが出ていても、Composer が読む repo.packagist.org/p2/<vendor>/<pkg>.json への反映は数分遅れる。Root composer.json requires ... does not match the constraint はこの遅れが原因なことが多い。composer show --all <pkg> で versions を確認し、数分待って再実行。キャッシュ削除はホストではなくアップデートを実行しているコンテナ内で行う。
• 誤ってタグを出したときの取り下げ: 本体だけでなく split 先の全リポジトリ（split_monorepo.yml の一覧）から gh api --method DELETE /repos/baserproject/<repo>/git/refs/tags/<ver> で消す。Packagist は再クロールで「No longer found in upstream」となり自動で消える。5.x ブランチに残ったリリースコミット（VERSION.txt 1 行目・composer.json）は X.Y.Z-dev に戻すコミットを別途入れる。

8. 補助スクリプト一覧

スクリプト	引数	役割
list-advisories.sh	[--state S]	アドバイザリ一覧・集計
fetch-advisory.sh	<GHSA-ID>	個別詳細取得（/tmp/bc-advisories へ保存）
create-fork-branch.sh	<GHSA-ID>	フォーク作成→remote→現ブランチ起点ブランチ
push-with-retry.sh	<remote> <branch> [max]	反映待ちリトライ push
open-pr.sh	<GHSA-ID> [--title T] [--body-file F]	base=現ブランチで PR 作成
build-integration.sh	[統合ブランチ名]	全 PR を統合ブランチへマージ
run-tests.sh	[--filter X]	ローカル全テスト（basercms-unittest 連携）

9. 既存スキル連携

• 連絡・記録・公開物は本スキルの範囲外: 報告者への返信コメント、GHSA の受理／深刻度／影響・修正版／credits／重複クローズなどメタ情報の更新、CVE 申請状況、JPCERT/JVN との往復、ベンダステートメント、公式サイトの脆弱性情報ページ原稿、管理表／課題／チャットへの記録、リリース当日チェックは、脆弱性ハンドリング（調整・広報）側の手順で扱う。本スキルは「コードの検証・修正・フォーク/PR・ローカル検証」に集中し、結論（該当／非該当、ブランチ名、PR URL、テスト結果）を返す。
• テスト実行: basercms-unittest
• 移行起因の競合・非推奨: cakephp-migration / php-migration / basercms-plugin-migration