这一轮主要完成了 Python XSS 检测初版，也让 Python 方向基本覆盖了任务书中的四类核心风险：SQL 注入、XSS、危险函数调用和硬编码密钥。建立轻量数据流判断。只有不可信输入参与 HTML 构造，并最终进入 HTML 输出点时，才作为 XSS 风险候选。同时，这轮也处理了几个容易误报或漏报的边界：普通响应不直接扩大成 XSS，经过escape()的输入不直接报，文件模板暂时不直接报

这一轮完成的是 JavaScript 四类核心风险的轻量闭环。它的重点不是把 JS 做成完整成熟的深度分析器，而是验证当前可插拔 detector 架构可以扩展到第二种语言，并让 JS 侧四类风险都有可运行、可测试的版本。Python：主线，承担更完整的数据流和上下文分析JavaScript：轻量版，覆盖常见写法，验证多语言扩展能力后续重点会放在联调、测试矩阵、文档整理和答辩材料上，而不是继续把

本文记录了 CodeGuard Tutor 从“关联文件逐个扫描”升级到“Python 跨文件污点分析”的过程。原有流程只能分别分析入口文件和 import 关联文件，无法确认不可信输入是否真的跨文件流向敏感操作。本次新增 `/analyze-project` 接口，后端通过 `PythonProjectIndex` 建立文件表、import 表和函数表，并在原有检测器基础上支持跨模块调用解析、参

简要介绍

这次改动把已有的跨文件交互补成了真正的联合分析能力。关联文件中是否各自存在风险？入口文件中的不可信输入，是否经过 import、函数参数和返回值，最终到达另一个文件中的敏感操作？-> 文件内上下文补全-> import 文件收集-> 跨模块调用解析-> 参数与返回值传播-> 带文件路径的 RiskItem-> 可选大模型解释项目索引和调用解析只实现一次，SQL 注入、XSS 和危险函数继续复用各自

这样后续 AI 模块在生成漏洞解释时，就不需要只根据风险标签和行号进行推测，而是可以基于后端给出的结构化传播路径，生成更准确、更贴近代码实际执行过程的说明和修复建议。上一篇里，我主要补了函数调用传播和作用域处理，让 SQL 注入检测不再只停留在函数定义本身，而是可以根据真实调用点的实参状态，继续进入函数体做分析。这一轮没有新增新的漏洞类型，也没有大幅调整整体架构，而是继续沿着 SQL 注入这条主线

上一篇博客里，我主要完成的是安全分析引擎的 MVP：先把最小闭环跑通，也就是：用户输入 → 动态拼 SQL →execute()执行 → 输出一条 SQL 注入候选结果那一版最重要的目标，是让检测链路先跑起来。而这一轮迭代，我开始真正进入分析引擎内部结构的收敛阶段。source这一层能不能统一建模SQL 表达式能不能分得更清楚sink规则能不能更稳地识别安全执行污点传播逻辑能不能收成统一入口vis

代码安全分析引擎。前面的工作更多是在打通链路，比如后端框架、插件传参和接口通信；而从这一篇开始，真正关心的问题变成了：后端到底怎么开始分析代码。代码安全分析引擎这一部分可以做很多东西。安全分析当然可以一下子铺很大，比如多语言、多漏洞类型、项目级扫描、AI 解释。但如果第一步就把目标铺满，很容易让功能乱飞、结构失控，最后看似什么都支持，却没有一条风险检测链路真正跑通。语言：Python漏洞类型：SQ

插件交互层（VS Code Extension）本地分析服务层（Python + FastAPI）上下文增强与 AI 层现阶段我不想把结构搞得太复杂，但这三层至少要先分清楚。先把接口定义清楚，比马上写复杂逻辑更重要。原因主要有两个。modelanguagefile_pathcode这样插件以后发请求时，就必须按这个格式来，接口不容易乱。schema 不是额外工作，而是协作基础。code: str。