发现必须从可达路径开始
审查模型看到字符串拼接便报告注入，若没有追踪它最终是否进入参数化接口，评论只是关键词联想。可复现审查先确定外部输入、传播转换、校验边界和敏感汇点，证明攻击者或普通用户能让具体值抵达危险操作。任一环节被类型、框架编码或权限条件阻断，都要写进结论，不能省略后直接宣布存在漏洞。
阅读范围从变更行向调用者与被调用者扩展，检查类型定义、配置、运行环境和框架默认行为。入口可能不是网络请求，也可能是队列、命令参数或数据库旧数据；汇点可能在另一个模块。搜索所有调用点能发现某函数只接收内部常量，或相反发现一个未预料的公开入口。
审查记录具体文件、行、输入条件和执行步骤，区分静态证据与尚需验证的假设。若缺少生产配置或依赖行为无法确认，应标为条件风险或测试缺口，请求所需证据，而不是用肯定语气填补空白。可达性是严重级别的基础，也是复现脚本的路线图。
区分确认缺陷、条件风险与测试缺口
确认缺陷具备可达路径、违反预期和可观察影响；条件风险说明只有某配置、权限或部署方式成立时触发，并列出验证条件；测试缺口则表示逻辑目前可能正确，但关键边界没有自动保护。三类反馈采用不同措辞与优先级，避免开发者把所有“可能”都当成立即事故。
严重级别依据影响、可利用性、权限、可逆性和暴露范围，而不是看到某个危险函数名就定为最高级。一个仅测试代码可达的异常与公开接口跨租户读取不同；同样，低概率竞态若会重复扣费，优先级可能高于频繁但可恢复的界面错误。评分理由应能由团队复核。
没有触发路径的理论讨论可以转成有针对性的防御测试，例如确认框架始终参数化查询。不要让它与已复现数据丢失排在同一列表。审查报告明确未检查的生成文件、基础设施或外部服务，防止有限范围的无发现被误读为整个系统安全。
复现使用与生产一致的配置
最小复现应保留触发问题需要的输入、版本和配置，删除无关步骤。优先写自动测试调用真实模块边界；若只能使用命令，则固定工作目录、环境前提和预期输出。复现不能为了方便关闭生产中的认证、替换数据库语义或绕过框架中间件，否则证明的是另一个系统的问题。
配置差异经常决定结论：开发模式可能显示详细错误，生产模式启用代理信任，数据库驱动对参数占位符处理不同，构建器会移除某段代码。审查者读取实际部署配置与版本锁定，无法取得时把差异列为条件。第三方框架防护要引用当前使用版本的行为，并通过小测试确认，而非依赖记忆。
并发缺陷需要可控屏障、重复运行和状态断言，不应凭一次未复现就否定。时间问题采用假时钟，网络失败使用明确注入点，随机行为固定种子并保留失败种子。复现输出只含必要合成数据，避免把生产凭据或用户记录复制到测试环境。
数据流证据需要跨越模块边界
从入口变量开始标记每次变换：解析、规范化、编码、校验、权限过滤和持久化。一个值经过 HTML 转义后用于页面可能安全，但同一值再进入脚本上下文仍需不同编码；数据库参数化阻止语法注入，却不自动解决越权对象选择。审查不能用单一“已清理”标签覆盖不同汇点语义。
异步队列会切断直观调用栈。生产者验证过的身份未必在消费者侧仍可信，消息可能被旧版本或其他服务写入。需要检查消息 Schema、签名或授权上下文、重试语义和幂等处理。缓存、数据库触发器和外部 webhook 也可能形成第二条路径，使表面修复只堵住主请求。
类型系统提供有用约束但不是运行时授权。强制转换、反序列化、可选字段和跨语言边界会削弱保证。复现若能在真实边界构造非法值，就比指出某个局部变量类型可疑更有价值；若运行时解析器确实拒绝，则把发现降为覆盖该保证的回归测试建议。
修复建议服从现有架构边界
高质量建议指出最小修复位置和必须恢复的不变量。例如跨租户查询应在仓储层加入主体条件并补接口测试，而不是笼统建议“重写权限系统”。局部补丁需要考虑所有调用点、错误契约和迁移行为，避免修正当前路径却破坏后台任务。若根因确实结构性，再单独提出分阶段方案。
建议不能引入未经需求的大规模抽象。为一个参数边界新增明确校验通常优于创建通用框架；使用现有事务、日志和测试工具，减少审查噪声。安全修复若改变公开错误或状态码，应提醒兼容影响。涉及数据清理或回填的动作单独列出，不在代码建议中假设可以删除生产记录。
修复后的验证首先运行原复现，预期它不再产生问题，同时正常邻近案例仍通过。再加入绕过变体与回归测试，确认不是只匹配一个输入字符串。若修复依靠框架配置，测试断言实际构建产物或运行配置，防止后续默认值变化悄悄撤销保护。
控制审查范围与反馈密度
定向审查从明确变更文件和其必要依赖开始，避免把仓库多年遗留问题全部倾倒到当前提交。每条评论必须与变更引入、暴露或可合理修复的风险相关。未跟踪生成文件、大型依赖锁和格式化噪声可按规则排除，但报告中记录范围，必要时为独立审计另开任务。
重复根因合并成一条主发现并列出受影响位置，不在每行复制相同说明。高优先级反馈数量保持可处理，附最小复现和预期行为；样式偏好与确定缺陷分开。若模型没有足够证据，不应用大量低价值猜测填满报告，因为噪声会延迟真正的并发或授权问题。
审查过程保存所用提交、构建配置、测试命令和失败输出摘要，使他人能在相同基线上验证。工作区已有用户修改时不覆盖或重置，复现补丁保持局部。任何自动修改都需要重新查看差异，避免建议工具在相邻代码引入新的行为变化。
防范模型常见的证据错觉
模型容易把理论可能写成确定事实、忽略框架自动编码、误读语言短路顺序，或根据函数名推断实现。审查提示应要求先引用代码证据，再说明输入如何到达影响；没有证据就降低结论。对依赖行为查本地锁定版本的源码或官方说明，不凭泛化知识断言当前项目。
另一个错觉是复现成功却环境错误，例如测试数据库未启用生产约束，或开发服务器暴露生产不会启用的调试路由。复现记录差异并判断它是否影响触发条件。模型生成的测试也要人工检查断言是否真的观察副作用，而不是只断言请求返回某个自设状态。
自动审查还可能建议庞大重构来显示完整性。评估建议的变更面、迁移成本和新失败模式，优先恢复具体不变量。对于无法安全自动决定的并发策略、产品权限或数据保留，明确提出选择点，不替团队捏造业务要求。
以原复现失效作为闭环证据
验证矩阵为每条高优先级发现保存可执行复现、生产一致前提和预期影响。修复前测试必须确实失败或展示错误状态，修复后原路径与等价变体均被阻断，相关正常流程仍成功。若无法构造触发路径，条目降级为条件风险或测试建议，不能维持确定缺陷级别。
对并发问题运行多次并使用屏障控制关键顺序；对权限问题覆盖未登录、不同租户、撤权和资源转移；对输入问题覆盖编码、边界长度和替代入口。构建、类型检查与相关集成测试验证补丁没有破坏契约。结果记录具体命令与配置，不只写“已测试”。
最终报告列出已确认发现、条件项、已修复证据、审查范围和未检查区域。指标关注高优先级发现的复现率、误报校准和修复后回归，而不是评论数量。审查从“可能有问题”走到输入、路径、汇点、影响和失败测试，开发者才有足够证据迅速修复真正风险。
实现片段
type Finding = { trigger: string; evidence: string; impact: string }
评论 · 0