一、本次改动的背景上一篇里我主要补了函数调用传播和作用域处理让 SQL 注入检测不再只停留在函数定义本身而是可以根据真实调用点的实参状态继续进入函数体做分析。这一轮没有新增新的漏洞类型也没有大幅调整整体架构而是继续沿着 SQL 注入这条主线把检测结果里的“传播过程”记录得更完整一些。之前后端已经可以输出source_line、sql_build_line、sink_line这类字段能够说明用户输入、SQL 构造和execute(...)大概分别出现在哪几行。但这些信息还是比较粗。它们能说明“风险发生在哪”却不能完整说明“数据是怎么一步步传过去的”。对于后续 AI 解释来说如果只拿到SQLInjection标签和几个行号生成的解释就容易比较泛。所以这次的重点是先由后端把传播链事实记录清楚再交给后续 AI 模块组织成用户能看懂的说明和修复建议。二、新增 flow_trace 传播链这次主要新增了一个结构化字段flow_trace它用来记录从 source 到 sink 的关键传播步骤。目前主要记录source assign function_call parameter_bind sql_build sink对于涉及返回值传播的场景也会继续记录return相关步骤。也就是尽量把下面这条链路记录下来用户输入 - 变量赋值 - 函数调用 - 参数绑定 - SQL 构造 - execute 执行这里我没有选择在 B 阶段直接生成一大段中文解释而是先保留结构化事实。因为 B 阶段更适合做静态分析和证据提取比如哪一行识别到了用户输入、哪个变量被污染、实参绑定到了哪个形参、SQL 在哪里构造、最终在哪里进入execute(...)。这些信息本身不一定适合直接展示给用户但很适合交给后续 AI 解释模块使用。三、传播链记录了什么这次在后端新增了EvidenceStep用来表示传播链上的一步。它大致记录kind line symbol from_symbol to_symbol function_name source_kind source_label source_selector sink_label sql_shape其中kind表示当前步骤的类型例如source、assign、function_call、parameter_bind、sql_build、sink。例如下面这段代码defrun_query(uid):sqlfSELECT * FROM users WHERE id {uid}cursor.execute(sql)user_idrequest.args.get(id)run_query(user_id)内部可以记录出类似这样的传播链source5 - assign5 - function_call6 - parameter_bind6 - sql_build2 - sink3对应含义是第 5 行识别到用户输入并赋值给user_id第 6 行user_id被传入run_query并绑定到形参uid第 2 行uid被拼接进动态 SQL第 3 行 SQL 进入cursor.execute。这样后端输出的结果就不只是“这里有 SQL 注入风险”而是能把风险形成过程记录下来。后续 AI 可以根据这些步骤生成更自然的解释例如说明用户输入如何进入函数、如何参与 SQL 构造、最后如何到达执行点。四、和前端、AI 模块的关系这里我做了一个边界区分。flow_trace目前主要保留在 B 阶段的中间结果里也就是RiskCandidate.flow_trace它主要服务后续 AI 解释模块和结果整理层。最终返回给 VS Code 插件的RiskItem暂时不直接暴露完整传播链。因为前端当前更需要展示的是风险类型、风险说明、修复建议和最终解释而不是底层的每一个传播步骤。目前分工大致是B 阶段记录结构化传播链 AI 解释模块根据传播链生成解释和修复建议 前端插件展示最终整理后的检测结果这样职责会清楚一些也方便后续继续扩展。五、测试情况与目前边界这次补充了函数调用传播链相关测试重点验证函数调用场景下能够记录source assign function_call parameter_bind sql_build sink运行命令为python-m unittest discover-s tests当前测试结果Ran 35 tests OK目前flow_trace主要还是服务 Python SQL 注入检测主线已经可以覆盖普通变量传播、函数调用、参数绑定、返回值传播和executesink。不过它还没有完整覆盖跨文件调用、类方法、对象属性、容器元素、高阶函数等复杂情况。这些后续可以继续通过补充新的EvidenceStep.kind或扩展字段来完善。整体来看这一轮改动不算大重点也不是新增检测能力而是让已有 SQL 注入检测结果更适合后续 AI 解释。之前后端更多是输出几个关键行号现在则开始记录更细的传播链事实source - assign - function_call - parameter_bind - sql_build - sink这样后续 AI 模块在生成漏洞解释时就不需要只根据风险标签和行号进行推测而是可以基于后端给出的结构化传播路径生成更准确、更贴近代码实际执行过程的说明和修复建议。