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