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)
• Codex cross-validation — independent AI review via official Codex plugin

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) Pre-flight: Codex readiness check

Before starting any audit work, verify that Codex is operational. This is a hard prerequisite — the audit relies on Codex for cross-validation, so a broken Codex means a degraded audit.

Check procedure

Confirm Codex CLI is installed and authenticated. You can verify this by checking whether the codex:codex-rescue subagent type is available for dispatch.

If uncertain, invoke /codex:setup to check readiness.

Outcome handling

Result	Action
Codex CLI ready	Log: “✅ Codex 就绪。” Set CODEX_AVAILABLE = true.
Codex CLI not installed or not authenticated	Warn user: “⚠️ Codex CLI 未就绪，请运行 /codex:setup 检查配置。审计将以降级模式继续（无交叉验证）。” Set CODEX_AVAILABLE = false.

Record the Codex status in the report header. Proceed with the audit regardless — Codex enhances but does not gate the audit.

---

4) 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

Step I — Codex cross-validation audit

Skip this step if CODEX_AVAILABLE = false.

The purpose of this step is to get an independent second opinion from Codex. Codex reviews the same diff without seeing your primary findings, so its conclusions serve as genuine cross-validation — agreement strengthens confidence, disagreement flags areas needing human attention.

I.1 — Dispatch audit to Codex

Use the Agent tool to dispatch an independent security review to Codex:

Agent(
  subagent_type = "codex:codex-rescue",
  prompt = "Security audit for OneKey crypto wallet monorepo.
Comparing ${BASE_REF} (${BASE_SHA}) → ${TARGET_REF} (${TARGET_SHA}).

Changed files:
${CHANGED_FILES_LIST}

Full diff:
${FULL_DIFF or chunked sections if too large}

Review focus areas:
1. **Secret/PII leakage** — mnemonic, private key, seed, API key exposure via logs, network, storage
2. **Supply-chain risks** — new/updated dependencies, install scripts, suspicious package behavior
3. **Auth/signing flow changes** — any modification to key handling, transaction signing, vault logic
4. **Network layer** — new RPC endpoints, telemetry, outbound requests, WebSocket changes
5. **Storage layer** — changes to local/secure storage, encryption, keychain access
6. **CI/CD pipeline** — workflow permission changes, unpinned actions, remote script execution
7. **Dynamic execution** — eval, new Function, child_process patterns in new code

For each finding report:
- File path and line number
- Severity: Critical / High / Medium / Low
- Category: secret-leak / supply-chain / auth-bypass / network / storage / ci-cd / dynamic-exec / other
- Description of the risk
- Suggested remediation"
)

If the diff is too large (>50KB), prioritize including in the prompt:

1. Dependency changes (package.json + yarn.lock diffs)
2. Security-critical source diffs (vault, signing, crypto, auth)
3. CI/CD and build config changes
4. Note which areas were omitted from the prompt.

I.2 — Parse Codex findings

The Agent result returns Codex's output as a text string. If the result is empty or the Agent fails, log it and continue without Codex findings.

Extract structured findings from the response. For each finding, record:

• File path + line
• Severity
• Category
• Description
• Codex's suggested fix (if any)

Step J — Merge and cross-validate findings

Combine findings from the primary audit (Steps C–H) with Codex findings (Step I) into a unified list.

Cross-validation rules

Scenario	Action	Confidence
Both found same issue (same file, same category)	Mark {Cross-validated ✅}	Auto-promote to 🔵 High
Primary-only finding	Include normally	Keep original assessment
Codex-only finding	Include with [Codex] tag, review against source to assign confidence	Default 🟠 Medium, adjust after manual review
Conflicting assessment (one says safe, other flags risk)	Include both perspectives, flag for human review	⚪ Low with note

Deduplication

When primary and Codex flag the same issue with different descriptions, keep the more detailed description and note both sources. Do not list the same issue twice.

Confidence levels

Tag	Meaning	When to use
🔵 High	Confirmed from code or cross-validated	Clear vulnerability, both reviewers agree, or verifiable from source
🟠 Medium	Likely issue, single reviewer or needs context	Pattern suggests risk, might be intentional
⚪ Low	Possible issue, needs human judgment	Heuristic match, conflicting signals, depends on business logic

---

5) Report template (must follow; Chinese output)

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

# 安全预审报告（${BASE_REF} → ${TARGET_REF}）

## 审计概要
- **审计范围**: ${BASE_REF} (${BASE_SHA}) → ${TARGET_REF} (${TARGET_SHA})
- **变更文件数**: X 个文件, +Y / -Z 行
- **Codex 交叉验证**: ✅ 已启用 / ⚠️ 降级模式（原因）
- **审计日期**: YYYY-MM-DD

## 风险总览

| 等级 | 数量 | 交叉

---

*Content truncated.*