java-vuln-scanner

name: java-vuln-scanner description: 当用户要求审计 Java 项目的第三方依赖、pom.xml/build.gradle/WEB-INF/lib/JAR 中的组件版本、CVE/组件风险命中、SCA 风险或 pipeline 需要组件版本证据时使用；只要求证明某个业务风险是否真实成立、生成可复制验证材料、审计 SQL/XXE/文件/上传/反序列化/鉴权/调用链时不要使用。

Java Vulnerability Scanner

当前定位

java-vuln-scanner 是 Java 审计技能集中的组件版本证据层。它负责从 Maven、Gradle、JAR、WEB-INF/lib 或部署包中提取依赖版本，用本地规则库匹配 CVE/组件风险，并判断哪些命中需要交给专项 skill 继续确认触发面。

本 skill 只输出“版本命中”和“触发面待核查”结论，不直接证明业务风险真实成立，不输出可复制验证请求、攻击字符串、通用评分、维护版本承诺或未验证的具体版本建议。组件命中要提交给开发单位时，应明确证据来源、规则局限、受影响模块、需要补证的入口/配置/运行条件，以及应转交的专项审计。

上下游边界

上游输入可以是：

• Java 项目源码目录、部署包、WEB-INF/lib、pom.xml、build.gradle、.jar、.war。
• pipeline 前序阶段提供的项目路径、模块清单或构建产物路径。
• 用户给出的单个组件名、版本或疑似 CVE。

下游通常读取：

• 组件版本命中清单、来源文件和模块归属。
• CVE/规则命中是否需要业务触发面验证。
• 应交给 java-route-mapper、java-route-tracer、java-auth-audit、java-deserialization-audit、java-xxe-audit、java-file-upload-audit、java-sql-audit 等专项 skill 的事项。

相邻 skill 边界：

• java-route-mapper：提取路由；本 skill 只引用路由证据，不负责完整路由枚举。
• java-route-tracer：追踪入口到 sink；本 skill 只指出哪些组件命中需要调用链验证。
• java-auth-audit：确认 Shiro/Spring Security/Filter 鉴权绕过等业务可达性；本 skill 只做版本命中。
• java-deserialization-audit：确认 Fastjson、Jackson、XStream、Shiro RememberMe、Commons Collections 等反序列化触发链；本 skill 不生成反序列化利用材料。
• java-xxe-audit：确认 XML 解析组件的 XXE 触发面。
• java-file-upload-audit：确认 Struts2 multipart、Commons FileUpload 等上传入口是否可触发。
• java-file-read-audit：确认 Commons IO、文件路径工具、下载/预览/导出入口是否形成文件读取或路径穿越触发面。
• SQL、文件读取等业务漏洞专项：只有当组件命中需要具体 sink/入口证明时才交接。

触发条件

满足任一条件时触发：

• 用户要求扫描 Java 依赖、组件版本、CVE、SCA、Log4j/Fastjson/Shiro/Spring/Struts2/Jackson/XStream 等组件风险。
• 用户提供 pom.xml、build.gradle、JAR/WAR、WEB-INF/lib 或部署包，要求判断是否存在已知组件风险。
• pipeline 需要组件版本命中清单，作为后续专项审计输入。
• 用户给出组件名和版本，要求按本地规则库判断是否命中。

不触发条件

以下情况不要触发本 skill：

• 用户要求证明具体接口风险真实成立、输出可复制验证请求或攻击字符串。
• 用户要求审计 SQL 注入、XXE、文件上传、文件读取、反序列化、鉴权、命令执行或调用链，且不是从组件版本入手。
• 用户要求最新官方安全公告、具体升级版本或实时 CVE 状态；本 skill 的本地规则库不是实时情报源。
• 只需要路由清单、API 文档或调用链证据。
• 用户要求对线上目标做未授权验证或利用。

成功标准

合格输出必须同时满足：

• 依赖来源可追溯到具体文件、模块和版本，区分 Maven/Gradle/JAR/MANIFEST/pom.properties 来源。
• 依赖来源路径必须是可复核的相对路径或绝对路径，不得用 ...、… 或省略写法截断。
• 统计数字必须来自脚本结果或可复核清点，不能使用约数、范围数或“多项/若干”；第 2 节 版本命中 和 未命中 必须使用同一口径的依赖实例数，唯一组件版本数量只放在说明或第 3 节。
• 正式报告的组件命中、规则名和 CVE 必须来自 scripts/scan_dependencies.py JSON 结果；脚本未输出的 CVE/规则不得凭记忆补写。
• 同一组件存在更多公开公告或历史 CVE 时，正式报告也只能列脚本 JSON 实际返回项；额外 CVE 只能写成“需复核官方公告或企业 SCA”，不能列编号。
• 清楚说明本地规则库命中的是版本证据，不等于业务风险真实成立。
• 将命中项标为 版本命中、触发面待核查、环境条件待确认、不可确认 或 未命中，不得写业务风险成立结论。
• 对每个命中项说明触发面需要哪些入口、配置、JDK/容器、序列化/XML/上传/日志等运行条件。
• 输出应交给哪个专项 skill 继续确认；没有触发面证据时不输出可复制验证材料。
• 报告严格使用 references/OUTPUT_TEMPLATE.md 的 6 个编号章节，不添加额外内部检查、技能源校验、测试提示词或模型验收信息。
• 面向用户的最终对话回复必须只使用固定格式：第一行 报告路径：<path>；第二行只写 发现组件版本命中，详见报告。、未发现组件版本命中，详见报告。 或 组件版本命中不可确认，详见报告。 三选一；不得描述 QA 过程、校验结果或组件摘要。
• 不编造通用评分、具体版本建议、验证成功、真实攻击链、可复制利用材料、线上影响范围或不存在的依赖。
• 明确本地规则库的时间/覆盖局限：规则命中需结合官方公告或企业 SCA 平台复核。

工作流

1. 确定扫描范围：读取用户指定路径，识别 pom.xml、build.gradle、.jar、.war、WEB-INF/lib 和模块边界。
2. 选择 references：规则解释读 RULE_USAGE.md；触发面分流读 TRIGGER_SURFACE_GUIDE.md；报告读 OUTPUT_TEMPLATE.md。
3. 运行确定性脚本：必须使用 scripts/scan_dependencies.py <目标路径> --rules references/java-vulnerability.yaml --format json --no-save 获取依赖和规则命中；需要保存中间结果时放到临时目录，不作为正式报告。
4. 去重和归并：同一组件、同一版本、同一 CVE/规则在多个模块出现时按模块列证据，按根因聚合说明。
5. 做触发面初筛：只读取必要配置和入口证据，判断是否需要交给专项 skill；不要在本 skill 内补写漏洞利用链。
6. 生成报告：按 OUTPUT_TEMPLATE.md 写单个最终报告文件，文件名为 {project_name}_vuln_scan_{YYYYMMDD_HHMMSS}.md。
7. 可运行仓库级维护脚本 tools/skill-maintenance/validators/validate_vuln_output.py <输出目录> 检查报告格式和禁止项；检查结果只用于内部修正，不写入报告，也不告诉用户“已通过检查”。
8. 面向用户的最终回复只给报告路径和一句固定结论，不输出 QA 过程、脚本日志、内部规则编号、组件命中数量、组件清单或额外漏洞摘要。

Hard Rules

• 组件版本命中不等于业务风险真实成立；不得写成立结论。
• 没有依赖来源文件和版本，不得输出 CVE/规则命中。
• 脚本 JSON 未输出的 CVE/规则命中不得写入正式报告；模型记忆和外部常识不能覆盖本地规则结果。
• vulnerabilities[].name 是正式报告中 规则/CVE 命中 的唯一来源；不得把同一组件的其他历史 CVE、别名规则或修补记录合并到表格。
• 本地 java-vulnerability.yaml 不是实时漏洞情报；不得声称“最新”“完整覆盖”或“官方确认当前维护版本”。
• 不输出通用评分，除非用户提供了权威来源并明确要求引用。
• 不输出具体版本建议；规则描述中的升级建议必须忽略，只保留组件、当前版本、命中规则、证据路径和需复核官方公告或企业 SCA 的限制说明。
• 不输出可复制验证请求、攻击字符串、反序列化链对象、JNDI 地址、恶意 XML、上传利用包或可执行利用步骤。
• 如果用户要验证某个命中是否真实成立，切换到对应专项 skill；本 skill 只输出交接方向和补证清单。
• JAR 文件名解析、MANIFEST、pom.properties 都可能不完整；无法确认 groupId/version 时标为 不可确认。
• 规则正则可能重复命中同一组件多个 CVE；报告要去重聚合，避免把重复规则当作多个独立依赖。
• 不把测试依赖、provided 依赖、插件依赖和运行时 WEB-INF/lib 混为一谈；不确定 scope 时写限制说明。
• 正式报告不得出现额外内部检查章节、技能源校验、测试提示词、模型运行状态、脚本异常堆栈、审批/权限信息或内部规则编号。
• 最终状态枚举只使用：版本命中、触发面待核查、环境条件待确认、不可确认、未命中。
• 最终对话回复不得描述 QA 过程、校验通过、内部检查、命中数量、最高等级，也不得在报告路径之外复述组件清单。
• 依赖总数、已解析依赖、版本命中、未命中 等统计项必须使用精确数字；无法精确统计时写 不可确认 并说明缺失证据，不得写 约、~、大约。
• 解释聚合逻辑时只写“按同一组件/版本/规则聚合”，不得写 规则 #N、脚本内部序号或规则库位置。
• 报告表格只保留真实信息，不得为了凑序号、补齐表格或避免空表而添加占位行；没有内容时在已有章节中写“无”并说明原因。
• 来源文件、模块和证据路径不得使用省略号或截断路径；路径太长时写相对于扫描根目录的完整相对路径。
• 如果第 5 节列出各模块未命中数量，模块数量之和必须等于第 2 节 未命中；不能混用“唯一组件版本数”和“JAR 实例数”。

Gotchas

• artifactId-version.jar 可能是重打包、厂商改名或 shade 包，版本命中要写来源局限。
• 一个组件旧版本可能命中多个 CVE；这通常是一个升级治理事项，不是多个已确认业务漏洞。
• Spring4Shell、Struts2、Shiro、Fastjson 等 CVE 都有运行条件；版本命中缺少入口/配置时只能待核查。
• Log4j 1.x/2.x 命中需要看实际日志调用和可控输入，不要直接给 JNDI 验证字符串。
• Fastjson/Jackson/XStream 命中应交给反序列化或 XML 专项确认是否解析用户输入。
• Commons FileUpload/Struts multipart 命中应交给上传专项确认是否有可达上传入口。
• Shiro 命中应交给鉴权或反序列化专项确认 RememberMe、密钥、filter chain 和可达性。
• 只扫描源码 pom.xml 可能漏掉部署包实际 JAR；只扫描 WEB-INF/lib 可能缺少父 POM 版本管理。
• 规则库描述中出现“RCE”“SQL 注入”等是组件公告类型，不代表当前项目已出现该漏洞。

停止、确认或切换条件

• 找不到依赖文件或 JAR 版本：停止命中结论，输出不可确认和需要补充的构建/部署材料。
• 用户要求可复制验证请求、攻击字符串或利用验证：停止在组件版本证据，切换到对应专项 skill。
• 用户要求最新 CVE、具体升级版本或官方公告：说明本地规则库局限，建议使用官方公告或企业 SCA 复核。
• 命中项需要路由、鉴权、调用链或 sink 证据：交给 route/auth/tracer 或对应漏洞专项。
• 发现规则库自身明显过期或无法解析：记录规则局限，不临时编造新规则。

Eval