ln-625-dependency-reuse-auditor

路径： 文件路径（references/、../ln-*）均相对于此技能目录。

依赖项与复用审计器（L3 Worker）

类型： L3 Worker

专门审计依赖项健康状况和复用风险的 Worker。

目的与范围

• 支持 vulnerabilities_only 模式，用于仅检查漏洞
• 审计依赖项与复用风险（类别 7+8：中优先级）
• 检查过时／未维护的包、未使用的依赖项、CVE 漏洞，以及应使用原生／现有／开源替代方案的通用自定义工具／集成模块
• 输出 PATCH_DEPENDENCY、REMOVE_DEPENDENCY 或 REPLACE_CUSTOM_UTILITY
• 计算合规评分（X/10）

参数

参数	值	默认值	描述
mode	full / vulnerabilities_only	full	full = 全部 5 项检查，vulnerabilities_only = 仅扫描 CVE

输入

必须读取： 加载 references/audit_worker_core_contract.md 和 references/mcp_tool_preferences.md。 工具策略：你可能会作为独立子 Agent 运行，此时宿主的 AGENTS.md 不在适用范围内，因此读取文件、搜索和编辑时默认优先使用 hex-line MCP。只有在 MCP 行为不明确时，才加载 references/mcp_integration_patterns.md。

接收包含技术栈、包清单路径、代码库根目录和 output_dir 的 contextStore。

默认使用 mode=full。仅在请求漏洞相关包检查结果时使用 mode=vulnerabilities_only。

当依赖项引用或代码复用证据能实质性提升审计质量时，优先使用 hex-graph。本地读取代码时，若 hex-line 可用，则优先使用。若 MCP 不可用、不受支持或未建立索引，则使用内置的 Read/Grep/Glob/Bash 继续，并在报告中说明回退情况。

工作流

检测策略：采用两层检测（候选项扫描，然后上下文验证）；仅在验证方法不明确时加载 references/two_layer_detection.md。

1. 解析上下文、mode 参数和 output_dir
2. 运行依赖项检查（第 1 层：根据 mode 使用审计工具）
3. 按候选项分析上下文（第 2 层）：
   • 可用功能：读取用法——lodash 是仅用于 1 个函数（易于替换），还是深度集成（难以替换）？
   • 自定义工具替换：读取代码——这是通用工具／集成，还是特定领域逻辑？
   • 漏洞：读取代码——项目是否实际调用了存在漏洞的 API？
4. 汇总发现
5. 计算评分
6. 撰写报告： 按照 references/templates/audit_worker_report_template.md 在内存中构建完整的 Markdown 报告，然后通过单次 Write 调用写入 {output_dir}/ln-625--global.md
7. 返回摘要： 返回最简摘要

---

审计规则（5 项检查）

1. 过时的包

模式： 仅限 full

检测：

• 运行 npm outdated --json（Node.js）
• 运行 pip list --outdated --format=json（Python）
• 运行 cargo outdated --format=json（Rust）

严重程度：

• 高： 落后一个主版本（存在安全风险）
• 中： 落后一个次版本
• 低： 落后一个修订版本

建议： 更新到最新版本，并测试是否存在破坏性变更

工作量： S-M（更新版本、运行测试）

2. 未使用的依赖项

模式： 仅限 full

检测：

• 解析 package.json/requirements.txt
• 在代码库中搜索 import/require 语句
• 查找从未导入的依赖项

严重程度：

• 中： 未使用的生产依赖项（会增大打包体积）
• 低： 未使用的开发依赖项

建议： 从包清单中移除

工作量： S（删除对应行、测试）

3. 未使用的可用功能

模式： 仅限 full

检测：

• 当原生 fetch 可用时（Node 18+），检查是否仍使用 axios
• 当 Array 方法已足够时，检查是否仍使用 lodash
• 当 Date.toLocaleString 已足够时，检查是否仍使用 moment

严重程度：

• 中： 不必要的依赖项（会增加打包体积）

建议： 使用原生替代方案

工作量： M（重构代码以使用原生 API）

4. 通用自定义实用工具／集成替换

模式： 仅 full

检测：

• 在 utils/、lib/、helpers/、common/、shared/、pkg/、internal/ 中查找重要的自定义实用工具／集成文件
• 查找 parser、formatter、validator、converter、encoder、serializer、logger、cache、queue、scheduler、mailer、http、client、wrapper、adapter、connector 等名称
• 阅读代码，先对用途进行分类，再建议替换方案
• 优先考虑平台原生 API、项目现有依赖，然后是维护良好的 OSS 软件包

严重性：

• HIGH： 高置信度地替换超过 200 行代码的通用模块，或使用更安全的成熟替代方案替换自定义加密／序列化实现
• MEDIUM： 高置信度地替换 100-200 行代码，或以中等置信度替换且能明显改善维护性
• LOW： 部分替换机会或清理原生 API

第 2 层：

• 跳过特定领域的业务逻辑
• 功能兼容性低于 80% 时跳过
• 建议使用 OSS 前，使用可用的研究工具检查维护情况、许可证兼容性和已知安全公告

建议： 替换为原生 API、现有依赖的功能或经过审查的 OSS 替代方案

工作量： M（集成库并替换调用）

5. 漏洞扫描（CVE/CVSS）

模式： full 和 vulnerabilities_only

检测：

• 检测生态系统：npm、NuGet、pip、Go、Bundler、Cargo、Composer
• 根据 references/vulnerability_commands.md 运行审计命令
• 根据 references/cvss_severity_mapping.md 的 CVSS 映射解析结果

严重性：

• CRITICAL： CVSS 9.0-10.0（需要立即修复）
• HIGH： CVSS 7.0-8.9（48 小时内修复）
• MEDIUM： CVSS 4.0-6.9（1 周内修复）
• LOW： CVSS 0.1-3.9（方便时修复）

修复分类：

• 补丁更新（x.x.Y）-> 可安全自动修复
• 次版本更新（x.Y.0）-> 通常安全
• 主版本更新（Y.0.0）-> 需要人工审查
• 没有可用修复方案 -> 记录并持续监控

建议： 更新至已修复版本，并验证锁文件完整性

工作量： S-L（取决于是否存在破坏性变更）

---

评分算法

必须阅读： 加载 references/audit_scoring.md。

注意： 当 mode=vulnerabilities_only 时，仅根据漏洞发现进行评分。

输出格式

必须阅读： 加载 references/templates/audit_worker_report_template.md。

根据 references/audit_summary_contract.md 编写 JSON 摘要。在 managed 模式下，调用方会同时传入 runId 和 summaryArtifactPath；在 standalone 模式下，工作进程会根据共享约定生成自己的运行专属工件路径。

将报告写入 {output_dir}/ln-625--global.md，并设置 category: "Dependency & Reuse Risk"，检查项为：outdated_packages、unused_deps、available_natives、custom_utility_replacement、vulnerability_scan。

根据 references/audit_summary_contract.md 返回摘要。

当 summaryArtifactPath 不存在时，将 standalone 运行时摘要写入 .hex-skills/runtime-artifacts/runs/{run_id}/evaluation-worker/{worker}--{identifier}.json，并可选择在结构化输出中回显相同摘要。

Report written: .hex-skills/runtime-artifacts/runs/{run_id}/audit-report/ln-625--global.md
Score: X.X/10 | Issues: N (C:N H:N M:N L:N)

参考文件

文件	用途
references/vulnerability_commands.md	特定生态系统的审计命令
references/ci_integration_guide.md	CI/CD 集成指南
references/cvss_severity_mapping.md	CVSS 到严重性级别的映射
references/audit_output_schema.md	审计输出架构

关键规则

遵循已加载的 references/audit_worker_core_contract.md。

• 不要自动修复： 只报告问题，绝不修改包清单或锁文件
• 按模式执行： 在 vulnerabilities_only 模式下，完全跳过检查 1-4
• 合理评估工作量： S = <1h，M = 1-4h，L = >4h
• 基于 CVSS 的严重性： 严格按照 references/cvss_severity_mapping.md 映射漏洞严重性
• 排除项： 漏洞严重性升级时跳过 devDependencies，跳过 vendored/bundled 依赖
• 独特范围： 仅审计依赖项/包的健康状况和通用复用机会。不要审计应用程序的可利用性、架构现代化或特定领域的业务逻辑。
• 必须执行的操作： 每项发现都必须使用 PATCH_DEPENDENCY、REMOVE_DEPENDENCY 或 REPLACE_CUSTOM_UTILITY

完成定义

遵循已加载的 references/audit_worker_core_contract.md。

• 已解析 contextStore（包括 mode 参数和 output_dir）
• 已完成所有适用的检查（完整模式为 5 项，vulnerabilities_only 模式为 1 项）
• 在提出替换建议前，已对通用自定义工具/集成候选项进行分类
• 已收集包含严重性、位置、工作量、操作、fix_type 和建议的发现
• 已按照 references/audit_scoring.md 计算分数
• 已将报告写入 {output_dir}/ln-625--global.md（通过一次原子 Write 调用完成）
• 已按照合约撰写摘要

---

版本： 4.0.0 最后更新： 2026-02-05