用途：以实现者（而非安全审计角色）身份，对项目依赖中的已知 CVE 执行“扫描→修复→验证”闭环，按分组处理该组的依赖清单，产出修补后的清单和审计轨迹。重扫属于自检，不是质量门禁，不替代安全门禁。
主要能力：优先调用共享工具 appmod-cve-assessment，它查询 GitHub Security Advisories API，支持若干包生态并把结构化结果写入文件；工具不可用或其生态参数不接受该项目生态时，改用 LLM 兜底扫描，并写入相同 findings schema。扫描同时用于检测：结果为空数组即无已知 CVE。支持 Maven、Gradle、.NET、Node.js 等常见生态的坐标收集与修复，可处理传递依赖、BOM/父 POM 覆盖等情况，循环比对按 CVE id 判断是否仍有可修复项，只把无可修复版本（无 Recommended fix 行）的漏洞记为不可修复。
使用方式：先做预检，识别项目类型与构建工具，优先使用项目本地包装器（./mvnw、./gradlew、mvnw.cmd、gradlew.bat），缺少所需工具则停止并报错。收集依赖坐标及声明位置后调用 appmod-cve-assessment，传入 cveResultFilePath（如 {{ARTIFACT_PATH}}/cve-report-N.json，从 1 递增）、ecosystem、dependencies、dependencyLocations；大批量依赖可分批次写入编号报告。按严重度 critical>high>medium>low 排序，优先修复高危；修复遵循直接升级而非框架迁移、尊重用户指定的锁定版本、最小改动、合并同源修复。Java 可改 pom.xml/build.gradle，注意覆盖 BOM 的 <version>；.NET 改 csproj 或 Directory.Packages.props；Node.js 改 package.json 并重生成 lockfile，传递依赖用 overrides/resolutions 强制版本。随后重扫，再用对应构建命令（./mvnw clean verify、./gradlew clean build、dotnet build && dotnet test、npm install && npm test 等）构建测试，失败可修最多 3 次，仍失败则保留已扫描干净的依赖改动并记录。最后写 {{ARTIFACT_PATH}}/cve-fix-summary.md 和 final-cve-report.json。
适用场景：需要在现代化改造流程中批量修复依赖 CVE 的 Java、.NET、Node.js 等项目。
限制：资料未提供具体价格、平台支持范围或效果保证；LLM 兜底受训练截止时间限制，可能漏掉新披露公告，仅在工具不适用时使用；需安装构建工具与 Node 包管理器，可选设置 GITHUB_TOKEN 以提升 GitHub 安全公告速率限制；若遇到速率限制或 HTTP 403 的处理步骤在资料中被截断，暂未完整提供；无上游补丁的 CVE 与需大版本升级的修复记为后续项，不强制静默升级。