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