SuperAPI AI Directory

basercms-security-advisory

Security & auditing

View repository

Updated 10-16 09:51

About this skill

baserCMS Security Advisory Handling Guide

Handle baserCMS repository security advisories (including GHSA and triage) end-to-end, from listing → verification → per-issue fixes → fork/branch/PR → local verification. The scripts are under scripts/ .The base branch is the current branch at runtime(check out the target release branch beforehand).

0. Prerequisites

  • gh CLI is authenticated. The target upstream is BCSA_UPSTREAM(default baserproject/basercms)。
  • Copilot review and GitHub Actions cannot be used on an advisory's private fork. Reviews are local /code-review, tests are local Docker (basercms-unittest) is authoritative.
  • Fork full_name=<owner>/basercms-<小文字GHSA>、remote=sec-<小文字GHSA(先頭ghsa-除去)>, branch=security/<GHSA-ID>。

1. Listing and Classification

scripts/list-advisories.sh [--state triage] to retrieve the count and list by state, and extract triage.

2. Verification of Findings

scripts/fetch-advisory.sh <GHSA-ID> to retrieve details and cross-check against theactual code in the current branchto judge "valid / inaccurate / not applicable." If there are many targets, share the work among read-only parallel subagents. Reject as not applicable anything that cannot be reproduced with the framework's default protections (ORM binding / slug encoding / h() output), and request a concrete PoC.

3. Determining the Fix Policy

Organize duplicate advisories for the same sink, hunk splitting for shared files, and rejection of non-applicable items. Confirm with the user on points requiring judgment, such as how to handle duplicates (same fix to multiple forks / closing one as a duplicate).

4. Per-Issue Fork/Branch/PR

Per advisory:

  1. scripts/create-fork-branch.sh <GHSA-ID> — create fork → add remote → create branch based on the current branch
  2. Apply only the relevant hunk (if multiple advisories touch the same file, do not take everything with git checkout … -- file , but apply manually hunk by hunk)
  3. Commit with a clear message stating which vulnerability was fixed and how
  4. scripts/push-with-retry.sh <remote> security/<GHSA-ID> — push with retry while waiting for the fork to be reflected
  5. scripts/open-pr.sh <GHSA-ID> [--title T] [--body-file F] — create PR with base=current branch

5. Local Verification

  1. scripts/build-integration.sh [統合ブランチ名] — merge the current branch + all security/GHSA-* (stop on conflicts)
  2. scripts/run-tests.sh — all local tests (for details, see basercms-unittest)
  3. If necessary, push the integration branch to a personal fork (<個人フォーク名>) and run GHA (GHA does not run on an advisory fork)

6. Following the Latest Base

When origin/base advances, merge base into each PR branch and push again. Common conflicts:

  • order() → orderBy()(CakePHP 5.2 rename)
  • Merging the path validation realpath() === false bypass fix × $fullPath validation

7. Pitfall Recipes

  • Copilot/GHA Unavailable: Cannot be used in advisory forks. Local verification is authoritative.
  • Waiting for push to take effect: Immediately after a new fork, remote rejected (failure). Retry based on the exit code (do not falsely detect success from strings like-> ).
  • Splitting hunks of shared files: For example, in PluginsService the basename and the php execution path verification are separate advisories. Apply them split by hunk.
  • Duplicate sinks: The same fix to multiple forks, or closing one as a duplicate.
  • Determining non-applicability: Reject anything that cannot be reproduced due to framework default protection. Check back to the branch state at the time of reporting.
  • Full suite flaky: CreateReleaseCommandTest(actual composer run) alone is green. Isolate environmental factors.
  • Authorization boundaries: permission.php の Api/Admin と Admin の auth consistency: before making changes, check the dependencies of the admin panel SPA (down to the built JS).

8. Auxiliary Script List

Script Arguments Role
list-advisories.sh [--state S] Advisory list/aggregation
fetch-advisory.sh <GHSA-ID> Fetch individual details (save to /tmp/bc-advisories)
create-fork-branch.sh <GHSA-ID> Create fork → remote → current branch origin branch
push-with-retry.sh <remote> <branch> [max] Retry push waiting for reflection
open-pr.sh <GHSA-ID> [--title T] [--body-file F] Create PR with base=current branch
build-integration.sh [統合ブランチ名] Merge all PRs into the integration branch
run-tests.sh [--filter X] All local tests (basercms-unittest integration)

9. Existing Skill Integration

  • Communication, recording, and publications are outside the scope of this skill: Replies/comments to reporters, updating GHSA metadata such as acceptance/severity/impact/fixed version/credits/duplicate closure, CVE application status, back-and-forth with JPCERT/JVN, vendor statements, drafting the official site's vulnerability information page, recording in management tables/issues/chat, and release-day checks are handled by the vulnerability handling (coordination/public relations) side procedures. This skill focuses on "code verification, fixes, fork/PR, and local verification" and returns conclusions (applicable/non-applicable, branch name, PR URL, test results).
  • Test execution: basercms-unittest
  • Migration-induced conflicts/deprecations: cakephp-migration / php-migration / basercms-plugin-migration