auditing-pre-release-security

# Pre-Release Security Audit (Between Any Two Git Refs) This skill compares **any two git refs** (tag/branch/commit SHA) and audits: - Source-code diffs for security regressions - Dependency changes (direct + transitive) and lockfile determinism - Newly introduced package behaviors inside `node_modules` - CI/CD workflow risks in `.github/workflows` and build configs (Expo/EAS) The output is a **Chinese** Markdown report, with a unique title and filename containing the refs to avoid overwrites. ## 0) Mandatory: confirm audit range (BASE_REF, TARGET_REF) ### Ref rules - Accepted: tag / branch / commit SHA - `BASE_REF` = starting point, `TARGET_REF` = ending point (release candidate) ### If refs are not explicitly provided by the user Ask exactly once before doing any work: > Which two git refs should I compare? (e.g. `v5.19.0` → `release/v5.20.0`, or `main` → `feature/xxx`) ### If only one ref is provided Ask for the missing ref. Do **not** assume defaults unless the user explicitly says: - “latest tag → HEAD” - or provides an equivalent instruction. --- ## 1) Output requirements (hard constraints) - Report language: **Chinese** - Report filename must include refs to avoid collisions: - `security-audit__${BASE_REF_SAFE}__to__${TARGET_REF_SAFE}.md` - `BASE_REF_SAFE`/`TARGET_REF_SAFE` must replace `/` with `__` (or `-`) for filesystem safety. - Report title must include refs: - `# 安全预审报告（${BASE_REF} → ${TARGET_REF}）` - Evidence must be traceable: file path + line numbers (when possible) + short snippet. --- ## 2) Safety rules (must follow) - Never print or paste secrets: mnemonics/seed phrases, private keys, signing payloads, API keys, tokens, cookies, session IDs. - If command outputs may contain secrets (env dumps, logs), redact before writing to the report. - Prefer short excerpts; do not paste large bundles. --- ## 3) Execution checklist ### Step A — Verify refs and collect context - [ ] Verify both refs exist: - `git rev-parse --verify "${BASE_REF}^{commit}"` - `git rev-parse --verify "${TARGET_REF}^{commit}"` - [ ] Record: - BASE_SHA, TARGET_SHA - Working tree clean? `git status --porcelain` - [ ] List changed files: - `git diff --name-status "${BASE_REF}..${TARGET_REF}"` ### Step B — Collect key diffs Focus on: - [ ] Source: `**/*.{js,ts,tsx}` - [ ] Dependencies: `**/package.json`, `yarn.lock` - [ ] CI: `.github/workflows/**` - [ ] Expo/EAS configs: `eas.json`, `app.json`, `app.config.*`, build scripts ### Step C — Dependency delta (direct deps) - [ ] For each changed `package.json`, compute: - Added / removed / updated deps (include workspace path) - [ ] Version range policy checks: - Flag `*` / `latest` as High risk - Flag `^` / `~` as Medium risk (explain why this matters for release determinism) - [ ] If deps changed but `yarn.lock` did not, flag as High risk. ### Step D — Lockfile determinism (best-effort) - [ ] Detect Yarn flavor: `yarn -v` - [ ] Try one: - Yarn Berry: `yarn install --immutable` - Yarn Classic: `yarn install --frozen-lockfile` - [ ] Record anomalies: `resolutions`, `patches`, non-registry sources, unexpected downloads. ### Step E — Known vulnerability scanning (best-effort) - [ ] `yarn audit` (if available) - [ ] `osv-scanner` against `yarn.lock` (if available) - [ ] If missing tools, note “not run + reason”. ### Step F — New dependency deep inspection (node_modules) For each newly added **direct dependency**: - [ ] Inspect `<pkg>/package.json`: - `preinstall`, `install`, `postinstall` scripts - entry points (`main`, `module`, `exports`) - binary/native artifacts (`bin/`, `.node`) - [ ] Keyword scan (case-insensitive) in its installed code: - Sensitive: `privateKey|mnemonic|seed|keystore|passphrase` - Storage: `localStorage|indexedDB|AsyncStorage|keychain|keystore` - Network: `fetch|axios|XMLHttpRequest|http|https|WebSocket|ws` - Dynamic exec: `eval|new Function|child_process|spawn|exec` - Install hooks: `preinstall|install|postinstall` - [ ] If hits exist: include **path + line + short snippet** and explain expected vs suspicious behavior. - [ ] Assign risk rating: Low / Medium / High. ### Step G — Source diff security review (AI reasoning step) Within `${BASE_REF}..${TARGET_REF}` diffs, prioritize: - signing flows / key handling / mnemonic - network layer / RPC / telemetry - storage layer (local/secure storage) - logging / analytics / error reporting Output: suspicious changes list (each with summary, impact, evidence excerpt). ### Step H — CI/CD & build pipeline risks Inspect `.github/workflows/**` and build configs: - [ ] Flag `uses: ...@latest` (High) - [ ] Flag floating tags not pinned to SHA (Medium, note risk) - [ ] Check `permissions:` for over-broad scopes - [ ] Flag remote script execution patterns (curl|bash, remote downloads) - [ ] Note install safety (`--ignore-scripts`, etc.) - [ ] Expo/EAS: flag hooks that download remote code, run arbitrary scripts, or leak env into logs --- ## 4) Report template (must follow; Chinese output) Write the report to: `security-audit__${BASE_REF_SAFE}__to__${TARGET_REF_SAFE}.md`