发布前审计是做什么的？

对应用进行审计，避免被黑客攻击或面临诉讼。工作分为四个参考文件——仅读取适用于你当前技术栈的文件（及章节）：

文件	用途
`references/prelaunch-checklist.md`	20 项关键门控检查点。快速检查从此开始。
`references/security.md`	完整安全审查：密钥、认证、访问控制、注入、浏览器/传输、供应链、AI 功能、运维。
`references/legal-compliance.md`	政策、同意、隐私权、诚实营销、儿童保护、电子邮件、知识产权、无障碍。
`references/stack-notes.md`	特定平台陷阱：Supabase、Firebase、Next.js、Express、Django、Rails、Laravel、移动端、Stripe、LLM 应用。

每个检查项都有一个 ID（SEC-*、LEG-*、A11Y-*）。在报告中请使用这些 ID，以便发现项可追溯。

选择模式

快速检查（“发布检查表”、“我准备好发布了吗？”、时间紧张）→ 仅 prelaunch-checklist.md。
安全审计（“安全审计”、“避免被黑客攻击”、“这个安全吗？”）→ security.md + 相关 stack-notes.md 章节。
法律合规审计（“避免被起诉”、“GDPR”、“Cookie 横幅”、“隐私政策”）→ legal-compliance.md。
全面审计（当用户仅在发布前说“审计我的应用”时默认使用）→ 以上所有文件。

工作流程

1. 范围界定 — 大部分自动完成

在提问之前，先从仓库中确定以下信息：

技术栈：框架、语言、后端/BaaS（Supabase、Firebase、自建服务器）、数据库、认证提供商、托管方式、Web 与移动端或两者兼顾。查看 package.json、lockfiles、requirements.txt/pyproject.toml、Gemfile、composer.json、pubspec.yaml、supabase/、firebase.json、vercel.json、Dockerfile、CI 文件。
数据清单：收集了哪些个人数据（表单、注册字段、分析工具）、存储在何处、哪些第三方 SDK/服务接收了这些数据（分析、广告、崩溃报告、支付、邮件、AI API）。
资金：支付、订阅、试用、应用内购买。
攻击面：公开页面、API 路由、服务器操作、边缘/云函数、Webhook、管理后台、文件上传、AI/LLM 功能。

然后，在一条消息中询问用户——仅询问代码无法告知的事项：目标市场（欧盟/英国/美国/巴西/其他）、未成年人能否使用、正式或预发布环境的 URL（如果有）、以及他们是希望您直接应用修复还是只提供报告。

如果用户无法联系，则假设为欧盟 + 美国、仅限成年人、先提供报告，并在报告顶部说明。

2. 自动化扫描

python3 scripts/scan.py <repo-path>              # 工作树
python3 scripts/scan.py <repo-path> --history    # 同时扫描 git 历史中的密钥
python3 scripts/check_live.py https://staging.example.com   # 实时头部、Cookie、CORS、暴露文件

两个脚本仅依赖 Python 3 标准库。check_live.py 会发送少量无害的 GET 请求——请仅针对用户拥有或授权测试的站点运行。

此外，在可用时运行生态系统的依赖审计工具（npm audit、pnpm audit、pip-audit、osv-scanner、bundle audit、composer audit、cargo audit）；scan.py 会根据它找到的清单文件输出正确的命令。

将脚本输出视为线索，而非定论。通过阅读代码确认每个命中点，排除误报。扫描结果干净并不意味着安全：最严重的漏洞（访问控制失效、缺少服务端验证、租户数据泄露）是逻辑错误，只有阅读代码才能发现。

3. 人工审查

按以下顺序阅读：

认证设置和中间件；服务端如何识别调用者身份。
每个 API 路由、服务器操作、边缘/云函数和 Webhook 处理程序。
数据库访问规则：RLS 策略、Firebase 规则、ORM 作用域、数据库用户权限。
任何根据输入构建 SQL、shell 命令、HTML、文件路径或 URL 的代码。
文件上传和下载处理程序。
AI/LLM 功能：有哪些不受信任的文本到达模型、模型可以调用哪些工具。
法律页面、Cookie 横幅、注册和结账流程、营销文案、邮件。

对于每个端点，回答四个问题：调用者是谁？服务端是否验证了该身份？该记录（或租户）是否属于调用者？调用者可以写入哪些字段？ 回答“否”或“不知道”均视为发现项。

4. 分类

每个项的状态：FAIL · WARN · PASS · MANUAL（需要人工处理：法律文案审查、恢复演练、律师） · N/A。切勿将未经实际检查的项标记为 PASS——应使用 MANUAL。

失败的严重性分级：

严重 — 现时可利用或已暴露：代码/包/历史记录中存在实时密钥、数据库无需认证即可读写、包含用户数据的表禁用了 RLS、认证绕过、个人数据的 IDOR、SQL/命令注入、RCE。
高 — 在一定前提条件下严重：登录/重置缺少限流、存储型 XSS、缺少 Webhook 签名验证、弱密码哈希、带凭证的宽松 CORS、生产环境开启调试模式、无备份。法律方面：对已声明的市场有硬性要求但未满足（收集个人数据时无隐私政策；欧盟/英国在获得同意前进行了非必要的跟踪；应用商店应用中无账户删除功能）。
中 — 纵深防御缺失：缺少安全头部、详细错误信息、无审计日志、过时但不可利用的依赖。法律方面：政策内容不完整、知情同意用户体验问题、无障碍失败。
低 — 代码卫生和细节完善。

5. 报告

填写 templates/report.md。以结论开头：

🔴 未准备好 — 存在任何严重项，或涉及个人数据/资金的高项。
🟡 需修复后上线 — 存在高/中项，但计划本周内修复。
🟢 已就绪 — 无严重/高项；中项已跟踪。

每个发现项：ID、严重性、证据（文件:行号 或 URL + 头部）、一行风险描述、具体修复措施（简短时附代码）。按严重性分组，而非按检查表顺序。PASS 项以紧凑表格呈现。

切勿在报告或对话中粘贴完整密钥。仅显示前 4 个字符，其余用星号掩码（sk_l****）。

6. 修复

按严重性顺序提供修复。仅在用户要求修复或同意时修改代码。修复后，重新运行 scan.py（部署后还需运行 check_live.py）并更新报告。

发生密钥泄露时，始终按此顺序处理：在提供商处撤销/轮换密钥 → 从代码中移除并移至服务端环境变量 → 从 git 历史中清除（使用 git filter-repo 或 BFG）并强制推送。仅清除是不够的：密钥已存在于克隆、分支、CI 日志和缓存中。

基本原则

非法律建议。 您可以起草隐私政策、服务条款、Cookie 政策和退款政策，但草稿必须描述应用实际所做的工作（步骤 1–3 中发现的数据、SDK 和处理器），不得从其他公司复制，并且必须标注为需由目标市场的律师审查。
仅防御性测试。 仅测试用户拥有或授权测试的系统。解释漏洞和修复措施；不要针对第三方构建可用的漏洞利用。
仅提供 URL，无代码库？ 运行 check_live.py，检查站点（页脚法律链接；跟踪器是否在同意前触发；“拒绝”选项是否与“接受”一样容易；表单和结账），并将代码级别项标记为 MANUAL。
移动应用： 任何随应用二进制包发布的内容都是公开的。移动应用中的密钥即为泄露的密钥。
优先使用平台原生修复方式（RLS 策略、框架中间件、提供商设置），其次才是自定义解决方案。

发布前审计