---

name: production-audit description: "审计已上线仓库的生产就绪性差距，涵盖 RLS、webhooks、密钥、权限、Stripe 幂等性、移动端 UX 和部署健康状况。" category: security risk: critical source: community source_repo: commitshow/production-audit source_type: community date_added: "2026-05-04" author: commitshow tags: [security, audit, production, vibe-coding, rls, webhook, stripe, supabase, mobile] tools: [claude, cursor, gemini, codex, antigravity] license: "MIT" license_source: "https://github.com/commitshow/production-audit/blob/main/LICENSE"

生产环境审计

概述

一个对已上线仓库的部署状态进行外部审计的技能——包括线上 URL、GitHub 信号、密钥暴露、RLS 缺口、webhook 幂等性、索引、可观测性、提示注入，以及 AI 辅助项目经常遗漏的其他十多种故障模式。

这是对会话内安全技能（security-review、OWASP 风格、VibeSec、Trail of Bits）的补充。那些技能在编写时扫描编辑器缓冲区。本技能在你提交后扫描已部署的产品。不同的时机、不同的输入、不同的发现。正式发布时两者都应运行。

本技能通过公共 CLI（npx commitshow@0.3.23 audit . --json）封装了 commit.show 审计引擎。稳定的 JSON 信封（schema_version: "1"，仅追加）。写入 .commitshow/audit.{md,json} 附属文件，以便未来的 agent 会话可以读取先前状态而无需重新运行引擎。

何时使用此技能

• 当用户询问"这个能上生产吗"、"生产环境会出什么问题"、"给我的项目打分"、"我遗漏了什么"、"审计我的仓库"、"准备好发布了吗"时使用。
• 在将功能分支合并到 main 后立即使用（作为部署前的检查门）。
• 在公开发布 / Show HN 帖子 / 投资人演示之前使用。
• 当 git log 显示自上次 .commitshow/audit.md 写入以来有超过20次提交时使用。

跳过条件

• 在活跃的会话内编码期间——使用 security-review / OWASP 风格进行行级模式检查。本技能用于合并后/发布前审查。
• 对于库/脚手架形式的仓库——引擎最适合处理应用形式；库会得到部分替代评分。
• 如果 .commitshow/audit.json 已存在且不到1小时，直接读取而不是重新运行。审计有速率限制（匿名：20次/IP/天 · 5次/仓库/天 · 2000次/天全局）。
• 在私有/非 GitHub 仓库内——审计会拉取公共 GitHub 信号，因此私有仓库会返回 not_found 错误。

工作原理

步骤 1：运行审计

从仓库根目录执行。CLI 固定到一个经过审查的确切版本，这样未来的 npm 发布不会被静默选中。因为 npx 会以当前用户权限在本地下载并运行 npm 包代码，所以只有在用户明确批准此外部执行后，且仅在本地文件和环境变量对该进程安全的仓库中才运行。附属目录预先创建，stderr 被分离以防安装/弃用警告破坏 JSON 信封：

mkdir -p .commitshow
npx commitshow@0.3.23 audit . --json \
  > .commitshow/audit.json \
  2> .commitshow/audit.stderr.log

这也会在旁边写入人类可读的 .commitshow/audit.md。后续调用应与先前的 audit.json（如果存在）进行差异比较，这样你可以以"+5 since yesterday's audit"开头而不仅仅是绝对数字。

如果用户指向远程 URL 而不是 .，将 . 替换为 URL——保持相同的 mkdir -p + 版本固定 + stderr 分离：

mkdir -p .commitshow
npx commitshow@0.3.23 audit github.com/owner/repo --json \
  > .commitshow/audit.json \
  2> .commitshow/audit.stderr.log

步骤 2：解析信封

JSON 信封是稳定的（schema_version: "1"，仅追加）。读取以下字段：

| 字段 | 含义 | |---|---| | score.total | 0-100 生产就绪性评分 | | score.delta_since_last | 与上次快照的变化 · 正值 = 改善 | | score.band | strong（80+）· mid（60-79）· early（<60） | | concerns[] | 主要问题，按影响排序 · 每个包含 axis + bullet | | strengths[] | 前3个优势 · 仅供参考 | | standing | 可选 · 仅当项目在 commit.show 上参与评审时 | | snapshot.created_at / trigger_type | 审计运行时间 |

问题按决策影响排序，而非严重性。位置1是应首先展示的要点。

步骤 3：向用户展示

以评分 + 趋势一句话开头，然后是主要问题。不要转储完整 JSON。格式：

Score: 82/100 (+5 since yesterday) · band: strong

Top concerns:
  ↓ [Security] No API rate limiting on /auth — IP cap missing
  ↓ [Infrastructure] webhook handler at api/stripe.ts — signature verified, but no
    idempotency-key check (replay attack window open)

Want me to fix the webhook idempotency gap first?

规则：

• 使用 concerns[].bullet 中的确切要点——审计引擎已经写好了