# 执行原则与环境

## 执行原则

- 先收集证据，再下结论。
- 只在 `groupId:artifactId:version` 与受影响版本范围同时匹配时，才将漏洞标记为已确认命中。
- 扫描器结果只能作为线索，不能直接当作最终事实。
- 任何无法确认的版本、模块关系或漏洞影响范围，都要明确写出不确定性，不要补全假设。
- 默认优先关注运行时会生效的依赖风险，除非用户明确要求扩大范围。

## 环境要求

- JDK: 8+ (建议 11+ 以支持最新特性和安全更新)
- Maven: 3.6+
- Gradle: 7.0+ (如使用版本目录需 8.0+)

## 证据权重

在分析过程中，不同来源的证据有不同的可信度。按以下权重参考：

| 证据类型 | 权重 | 说明 |
|---------|------|------|
| lockfile (gradle.lockfile, libs.versions.toml) | 最高 | 精确版本锁定，构建时实际解析结果 |
| mvn dependency:tree 输出 | 高 | 实际构建解析结果，反映 version override |
| pom.xml / build.gradle 声明 | 中 | 声明值，可能被 dependencyManagement 或 BOM 覆盖 |
| 用户提供的依赖清单、扫描报告 | 低 | 需交叉验证，可能是片段式信息 |

**核心原则**：优先使用 lockfile 和 dependency:tree 作为权威证据，pom.xml 声明仅作参考。

## 漏洞匹配标签

仅在以下条件同时成立时，才认定为"已确认"：

- 依赖坐标可确认到具体组件
- 当前使用版本落入权威公告定义的受影响区间

匹配时必须检查：

- `groupId`
- `artifactId`
- `version`
- 受影响版本范围
- 修复版本或安全版本范围
- 是否存在撤销、争议、拒绝受理或误报说明

同时要区分：

- 直接依赖问题
- 传递依赖问题
- JAR 内嵌依赖问题
- POM 声明存在的问题与仅在打包产物里出现的问题

如果证据不完整，使用以下标签：

- `已确认`：证据充分，影响关系成立
- `疑似受影响`：依赖存在，但版本或生效路径尚未完全还原
- `需要验证`：漏洞信息、版本范围或项目依赖事实还未核实完整
- `证据不足`：无法将当前项目与漏洞影响范围建立可靠映射

## 严重级别

优先采用公告本身给出的严重级别。若需要统一口径，可使用下表：

| Severity | Score |
| --- | --- |
| Critical | 9.0 - 10.0 |
| High | 7.0 - 8.9 |
| Medium | 4.0 - 6.9 |
| Low | 0.1 - 3.9 |

如果官方未提供分级，可以谨慎给出推断，并说明依据。

## 常见误区

- 不要在没有确认实际版本时直接报告漏洞命中。
- 不要把有问题的传递依赖误写成上层库自身存在同一漏洞。
- 不要忽略 `dependencyManagement`（Maven）、父 POM 或 BOM 带来的版本覆盖。
- 不要忽略 Gradle 中的 `implementation` vs `api` 配置差异——`implementation` 不传递依赖。
- 不要凭经验假设第三方 JAR 一定内嵌了某个组件。
- 不要跳过 CVE 官方数据库或官方公告校验。
- 不要在涉及 Spring 生态时跳过 [Spring Security Advisories](https://spring.io/security) 的交叉核验。
- 不要输出只有漏洞列表、没有修复优先级和修复路径的空泛报告。

## 常见误报场景

以下情况容易导致扫描器误报，务必核验：

1. **版本覆盖未反映**：扫描器基于 pom.xml 声明版本报告漏洞，但实际被 `dependencyManagement` 或 BOM 覆盖到安全版本
2. **传递依赖被排除**：漏洞组件出现在依赖树中，但被上层依赖显式 `exclude`
3. **运行时不会加载**：CVE 针对的是库的开发/测试功能（如代码生成、单元测试），运行时不会触发
4. **数据库未更新**：漏洞已在较新补丁版本中修复，但扫描器漏洞数据库未同步更新
5. **非可利用版本**：CVE 描述的漏洞在特定条件下才能利用（如需要特定配置），项目实际不受影响
6. **scope 不涉险**：漏洞组件仅在 `test` 作用域或 `testImplementation` 配置中，项目运行时不会加载

**核对方法**：始终使用 `dependency:tree` 或 lockfile 确认实际生效版本，不要仅凭 pom.xml 声明下结论。

## 默认修复优先级

除非用户指定其他排序方式，按以下优先级建议处理：

1. 已确认的 `Critical` 和 `High` 级运行时漏洞
2. 涉及外部暴露面、反序列化、远程代码执行、身份绕过等高风险路径的问题
3. 被多个模块复用的公共传递依赖
4. 难以后续治理的第三方 JAR 内嵌组件问题
5. 利用条件较高的 `Medium` 和 `Low` 级问题