审计维度与发现分级
审计维度与发现分级
阶段 1(深度审计)的操作手册。目标是证据可复现的发现,不是印象清单。
维度清单
按仓库类型选取相关维度,不强行全覆盖:
- 正确性与契约
- 安全与隐私
- 架构与模块边界
- 代码质量与可读性
- 数据模型与迁移
- 性能与可扩展性
- 可靠性与失效模式
- 可观测性与诊断
- 测试与覆盖率
- CI/CD 与发布自动化
- 文档与上手体验
- 开发者体验
- 品牌与资产一致性
- 依赖健康度
- 配置与环境处理
- 错误处理与恢复
- 并发与状态管理
- 缓存与失效
- 领域能力覆盖(对标 benchmark.md 的能力清单)
证据纪律
- 每条发现附
file:line或可复现命令,二选一,不可都没有 - 数字必须带口径:什么硬件、什么输入规模、warm/cold、用什么命令测的
- 区分事实、推断、假设;假设必须标注为假设
- 用户给的病因一律视为假设:先设计可否证它的量化实验,报数字,再修真因
- 发现摘要在对话中交付,不止写进文档
系统问题 vs 硬件限制
测试暴露的每个问题必须先归因,再处置:
| 归因 | 判据 | 处置 |
|---|---|---|
| 系统问题 | 算法、架构、配置、并发、缓存、索引、批处理、序列化导致的瓶颈或错误 | 必须修,列入计划 |
| 硬件限制 | 同条件下换更好硬件即消失,且系统侧无可见浪费 | 如实标注,写入硬件需求,不假装已优化 |
禁双向伪装:把系统问题甩给硬件是逃避,把硬件限制包装成「已优化」是造假。
真实测试纪律
- 使用真实数据与真实执行路径;mock 结论必须标注其作用域,不冒充端到端结论
- 失败如实报告,不重跑到通过为止再报喜
- 性能对比给基线与变量,单次数字不做结论
硬 bug 排查:可变红门
审计中确认 bug 类发现、或执行阶段修硬 bug 时,遵守硬门:造不出一条对该问题能变红的命令,不进入假设阶段。
- 回路要求:确定可复现、运行快、agent 可执行、已实际跑过
- 构造方式按场景选:失败测试 / 脚本复现 / CLI 快照 / 无头浏览器 / 回放捕获痕迹 / 一次性线束 / 属性或模糊测试 / 二分线束 / 差分对照;都不可行才退到人工操作脚本,并承认回路不在 agent 手里
- 非确定性问题先把复现率调到可调试区间,再谈根因
- 插桩带唯一可检索前缀(如
[DEBUG-xxxx]),修复完成 = 回路变绿 + 回归固化 + 插桩清场 - 找不到可测试的接缝,本身记为一条架构发现
私有化部署实测
「能否流畅私有化部署」只能用实验回答:
- 干净环境(新容器 / 新 venv / 新机器)从零执行:clone → install → configure → run
- 记录每个卡点:隐性全局依赖、未文档化的环境变量、外部服务假设、硬件假设、网络假设
- 文档声明的硬件与系统需求必须有实测依据
- 卡点归因:系统问题 → 修复后再发布;环境固有限制 → 写进部署文档的前置条件
交付物视角预检
「本地能跑」与「别人拿到能跑」之间,隔着七类只在另一台机器上暴露的差异。它们共同的形状是:决定别人那台机器行为的属性,并不存在于你的工作目录里。逐项在新检上验证:
| 类别 | 失守形状 | 判据 |
|---|---|---|
| 权限元数据 | 工作树有执行位而索引里没有,本地全绿、别人 Permission denied |
枚举交付集合里每个可执行文件的索引模式,不看磁盘 |
| 集合成员 | 磁盘上有而版本控制里没有 | 对每个被引用的资源问:它在不在克隆出来的树上 |
| 自动准备 | 由流水线创建的目录/文件一旦缺失,流水线本身永不暴露 | 空检跳过所有预备步骤直接跑生产命令 |
| 通配收集 | 空匹配照样构建成功,产出自认成功却打不开的交付物 | 把被通配的目录清空后跑一次,必须失败 |
| 工具差异 | 同名工具在别的系统上不给错、只给空值 | 每条测量加「取不到值即红」分支 |
| 时间与速度 | 拿 mtime 新旧或「至少 N 个」做闸,换环境随机翻脸 | 断言结构性下限,不断言经验计数 |
| 单机绿 | 只在一台机器上跑通过 ≠ 多平台可用 | 从未执行过的流水线按零证据计,单列未验证 |
判据权威在 axiom 11.3(判据自报分母、平坦样本致恒假、兜底下须指名通道)与三十二(批量改写的落盘门);跨环境项按四十一登记为未验证,不许由「本机全绿」推出。
发现分类
- bug:行为与意图不符
- 安全漏洞:可越权、可注入、可泄漏
- 死代码:无引用、无触发路径
- 未使用资产/依赖:存在但无消费点
- 未完成实现:有入口无落地、有承诺无兑现
- 缺失功能:领域能力清单中有而本仓无
- 薄弱抽象:重复、泄漏、错层
- 重构机会:同构可合并、复杂度可下降
- 待讨论项:方向性分歧,须用户拍板
- 可替换组件:有更简单或更成熟的替代
- 可撤销组件:删掉更好
- 可丰富项:值得做深的方向
优先级
| 级别 | 含义 |
|---|---|
| P0 | 安全、数据丢失、发布阻塞 |
| P1 | 正确性、契约破坏、严重可维护性风险 |
| P2 | 架构、性能、测试缺口、DX |
| P3 | 文档、品牌、打磨 |
| P4 | 可选丰富 |
发现记录格式
| 优先级 | 分类 | 位置 | 发现 | 证据 | 影响 | 建议 | 改动风险 |
|--------|------|------|------|------|------|------|----------|
| P1 | bug | src/x.ts:42 | … | 复现命令 | … | … | 低 |
报告结尾必须能回答:下一轮只修三个,修哪三个,为什么。