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

The output is a 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 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:
  • •# Security Audit Report (${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

Write the report to: security-audit__${BASE_REF_SAFE}__to__${TARGET_REF_SAFE}.md