auditing-pre-release-security

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Pre-Release Security Audit (Between Any Two Git Refs)

预发布安全审计（任意两个Git引用之间）

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.

本Skill可对比任意两个Git引用（标签/分支/提交SHA值）并开展以下审计：

源代码差异中的安全退化问题
依赖变更（直接依赖+间接依赖）及锁文件确定性
```
node_modules
```
中新引入包的行为
```
.github/workflows
```
及构建配置（Expo/EAS）中的CI/CD工作流风险

输出为一份中文Markdown报告，包含唯一标题和带有引用信息的文件名，避免文件被覆盖。

0) Mandatory: confirm audit range (BASE_REF, TARGET_REF)

0) 强制要求：确认审计范围（BASE_REF、TARGET_REF）

Ref rules

引用规则

Accepted: tag / branch / commit SHA
```
BASE_REF
```
= starting point,
```
TARGET_REF
```
= ending point (release candidate)

支持类型：标签 / 分支 / 提交SHA值
```
BASE_REF
```
= 起始点，
```
TARGET_REF
```
= 终点（候选发布版本）

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
)

在开展任何工作前，需准确询问一次：

请指定需要对比的两个Git引用？（例如：
v5.19.0
→
release/v5.20.0
，或
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.

请询问缺失的引用。除非用户明确说明，否则不要默认假设：

“最新标签 → HEAD”
或提供等效的指令。

1) Output requirements (hard constraints)

1) 输出要求（硬性约束）

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.

报告语言：中文
报告文件名必须包含引用信息以避免冲突：
- ```
security-audit__${BASE_REF_SAFE}__to__${TARGET_REF_SAFE}.md
```
- ```
BASE_REF_SAFE
```
  /
```
TARGET_REF_SAFE
```
  必须将
```
/
```
  替换为
```
__
```
  （或
```
-
```
  ）以适配文件系统安全要求。

报告标题必须包含引用信息：

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

证据必须可追溯：文件路径 + 行号（如有） + 简短代码片段。

2) Safety rules (must follow)

2) 安全规则（必须遵守）

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.

绝不能打印或粘贴敏感信息：助记词/种子短语、私钥、签名载荷、API密钥、令牌、Cookie、会话ID。
若命令输出可能包含敏感信息（环境变量 Dump、日志），需在写入报告前进行脱敏处理。
优先使用简短摘录；请勿粘贴大段代码包。

3) Execution checklist

3) 执行检查清单

Step A — Verify refs and collect context

步骤A — 验证引用并收集上下文

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}"

验证两个引用是否存在：

git rev-parse --verify "${BASE_REF}^{commit}"

git rev-parse --verify "${TARGET_REF}^{commit}"

记录：
- BASE_SHA、TARGET_SHA
- 工作目录是否干净？
```
git status --porcelain
```

列出变更文件：

git diff --name-status "${BASE_REF}..${TARGET_REF}"

Step B — Collect key diffs

步骤B — 收集关键差异

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

重点关注：

源代码：
```
**/*.{js,ts,tsx}
```
依赖：
```
**/package.json
```
,
```
yarn.lock
```
CI配置：
```
.github/workflows/**
```
Expo/EAS配置：
```
eas.json
```
,
```
app.json
```
,
```
app.config.*
```
, 构建脚本

Step C — Dependency delta (direct deps)

步骤C — 依赖差异（直接依赖）

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.

针对每个变更的
```
package.json
```
，计算：
- 新增/移除/更新的依赖（包含工作区路径）
版本范围策略检查：
- 将
```
*
```
  /
```
latest
```
  标记为高风险
- 将
```
^
```
  /
```
~
```
  标记为中风险（解释为何这对发布确定性至关重要）
若依赖已变更但
```
yarn.lock
```
未更新，标记为高风险。

Step D — Lockfile determinism (best-effort)

步骤D — 锁文件确定性（尽力而为）

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.

检测Yarn版本：
```
yarn -v
```
尝试执行其中一个命令：
- Yarn Berry：
```
yarn install --immutable
```
- Yarn Classic：
```
yarn install --frozen-lockfile
```
记录异常情况：
```
resolutions
```
、
```
patches
```
、非注册表源、意外下载。

Step E — Known vulnerability scanning (best-effort)

步骤E — 已知漏洞扫描（尽力而为）

```
yarn audit
```
(if available)
```
osv-scanner
```
against
```
yarn.lock
```
(if available)
If missing tools, note “not run + reason”.

执行
```
yarn audit
```
（若可用）
针对
```
yarn.lock
```
执行
```
osv-scanner
```
（若可用）
若缺少工具，需注明“未执行 + 原因”。

Step F — New dependency deep inspection (node_modules)

步骤F — 新引入依赖深度检查（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.

针对每个新增的直接依赖：

检查

<pkg>/package.json

：

```
preinstall
```
,
```
install
```
,
```
postinstall
```
脚本
入口点（
```
main
```
,
```
module
```
,
```
exports
```
）
二进制/原生产物（
```
bin/
```
,
```
.node
```
）

对已安装代码执行关键词扫描（不区分大小写）：

敏感关键词：

privateKey|mnemonic|seed|keystore|passphrase

存储相关：

localStorage|indexedDB|AsyncStorage|keychain|keystore

网络相关：

fetch|axios|XMLHttpRequest|http|https|WebSocket|ws

动态执行：

eval|new Function|child_process|spawn|exec

安装钩子：
```
preinstall|install|postinstall
```

若命中关键词：需包含路径 + 行号 + 简短代码片段，并解释预期行为与可疑行为的差异。
分配风险等级：低 / 中 / 高。

Step G — Source diff security review (AI reasoning step)

步骤G — 源代码差异安全评审（AI推理步骤）

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

在

${BASE_REF}..${TARGET_REF}

的差异中，优先关注：

签名流程 / 密钥处理 / 助记词
网络层 / RPC / 遥测
存储层（本地/安全存储）
日志 / 分析 / 错误报告输出：可疑变更列表（每条包含摘要、影响、证据摘录）。

Step H — CI/CD & build pipeline risks

步骤H — CI/CD及构建流水线风险

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

检查

.github/workflows/**

及构建配置：

标记
```
uses: ...@latest
```
（高风险）
标记未固定到SHA值的浮动标签（中风险，注明风险）
检查
```
permissions:
```
是否存在过宽的权限范围
标记远程脚本执行模式（curl|bash、远程下载）
记录安装安全性（
```
--ignore-scripts
```
等）
Expo/EAS：标记下载远程代码、执行任意脚本或在日志中泄露环境变量的钩子

4) Report template (must follow; Chinese output)

4) 报告模板（必须遵守；输出为中文）

Write the report to:

security-audit__${BASE_REF_SAFE}__to__${TARGET_REF_SAFE}.md

将报告写入以下路径：

security-audit__${BASE_REF_SAFE}__to__${TARGET_REF_SAFE}.md