安全审计很容易陷入两个极端：一种是只依赖规则扫描，把工具告警当成漏洞；另一种是从大量业务代码开始漫无目的地阅读。前者缺少上下文，后者则很难保证覆盖率。
我更习惯把研究过程拆成四个阶段：先建立攻击面地图，再从危险点追踪输入，随后在真实环境中验证，最后整理能够被独立复查的证据。
01 · 建立攻击面地图
在阅读具体实现之前，先识别技术栈、部署方式、认证模型、对外路由和关键依赖。目标不是立即寻找漏洞，而是回答：系统暴露了哪些入口，哪些入口值得优先投入时间。
对 Web 项目，我通常会整理路由、参数来源、鉴权要求和业务敏感度。文件处理、表达式执行、数据库访问、反序列化和外部请求等入口，会被标记为高优先级。
扫描结果只是线索。只有用户输入、危险操作和真实运行条件同时成立，漏洞结论才有意义。
02 · 从 Sink 反向追踪数据流
相比逐文件阅读，从危险函数反向追踪通常更高效。找到文件读取、SQL 执行、命令调用或反序列化等 Sink 后，再检查参数是否来自用户输入，以及中间是否存在净化、类型约束或权限检查。
这个阶段尤其需要记录完整调用链。只截取危险函数附近的几行代码，很容易忽略上层已经存在的限制，也可能把仅限管理员的功能误判为未授权漏洞。
03 · 在真实环境中验证
静态分析确认路径可达后，我会尽可能搭建接近真实部署的环境。验证至少包含基线请求、负向对照、漏洞 Payload 和边界变体，避免因为环境配置或预置数据产生误判。
- 基线请求用于确认功能本身正常；
- 负向对照用于证明现象确实由漏洞条件触发；
- 基础 Payload 验证最短可利用路径；
- 编码、大小写与路径变体用于检查过滤边界。
04 · 保留可复查的证据
报告应该明确区分事实、推断和未验证假设。代码位置能够证明危险路径存在，真实 HTTP 流量能够证明外部输入可达，而环境信息则用于说明复现条件。
一份完整记录至少应包含受影响版本、入口参数、调用链、触发条件、请求与响应、负向对照、影响边界以及经过验证的修复或缓解方案。
结语
工作流的目的不是让研究显得复杂，而是减少自欺。安全结论越重要，就越需要清楚说明它依赖哪些前提，又经过了哪些验证。