用途
vuln-research 用于对某个具体 CVE 或漏洞披露做端到端研究。当依赖审计工具已经指出某个包存在漏洞时，真正需要回答的问题不是“我们有没有这个包”，而是：受影响的代码路径是否真的被调用、是否存在公开 PoC、是否有补丁及补丁时间、无法在 24 小时内部署时的暴露窗口有多大、无法打补丁时有什么缓解措施、CISA 是否将其列为在野利用。该技能把这一工作流完整串起来，并与 dependency-audit（负责发现 CVE）和 finding-triage（负责关闭处置闭环）配合使用。
主要能力
该技能覆盖从信息收集到决策记录的完整流程，包括：
- 拉取权威来源：NVD 记录、厂商安全公告、GitHub Security Advisory、CISA 已知被利用漏洞目录、EPSS 评分。
- 确认受影响版本：核对厂商发布说明与修复提交历史；对开源项目用
git tag --contains <commit>判断哪些版本包含修复；对闭源项目仅依赖公告并谨慎比较版本；对 monorepo 或再发布方确认修复是否同步落地。 - 映射到自身环境：用
npm ls、yarn why、pnpm why、pip show、bundle info、go list -m all等命令确认包是否安装、确切版本、是直接依赖还是传递依赖、是否仅开发依赖；直接检查锁文件，因为实际运行的是解析后的版本而非版本范围。 - 可达性分析：阅读补丁提交，确定具体哪个函数、文件或 API 存在漏洞，再用 grep 检查自身代码或依赖内部是否调用该代码路径，得出“可达（直接）”“可达（间接）”“不可达”“未知”的结论。
- 检查公开 PoC 与在野利用：在 GitHub 搜索 CVE 编号、查询 CISA KEV、Exploit-DB、厂商安全邮件列表、GreyNoise 扫描遥测，并参考 EPSS 评分判断紧迫程度。
- 决策与闭环：在补丁、缓解、接受风险之间选择；对传递依赖可用 overrides（npm）/ resolutions（yarn）/ pin 强制使用已修复版本；无法打补丁时可禁用受影响功能、增加请求级过滤（WAF 规则、代理过滤）、网络分段、增加检测；接受风险需记录原因、补偿控制与重新评估触发条件。
使用方式
该技能以工作流步骤形式组织，使用者按步骤执行：先拉取权威来源，再确认受影响版本，然后映射到本地环境，进行可达性分析，检查公开 PoC 与在野利用，最后做出补丁/缓解/接受风险的决策并记录。技能给出了具体的命令示例（如 npm ls <package> --omit=dev、grep -A1 '"<package>"' package-lock.json、grep -rn "vulnerableFunction" . 等）和 EPSS 评分解释区间（大于 0.7 视为紧急，0.1 至 0.7 按常规节奏修补，小于 0.1 可择机修补）。
适用场景
适用于安全工程师、开发者在收到 CVE 告警后评估其是否真正影响自身代码、依赖或系统；适用于需要判断补丁优先级、制定缓解措施、记录接受风险决策的场景；也适用于需要向团队或管理层说明漏洞暴露窗口与处置依据的情况。
限制与边界
该技能仅用于研究用户已获授权范围内的代码、依赖或系统漏洞。不得开发、武器化或分发漏洞利用程序，阅读现有 PoC 仅用于评估适用性。对于仅内部可见的漏洞或披露前情报，未经授权不得再分发。若研究过程中发现他人代码中未报告的漏洞，应遵循负责任披露原则，不得公开、不得利用。拒绝将 CVE 研究结果用于攻击系统的请求。
输出格式
技能提供结构化评估模板，包含摘要（标题、CVSS/EPSS、CISA KEV、受影响版本、自身版本）、可达性（直接调用、间接调用、结论）、利用可用性（公开 PoC、在野利用）、决策（补丁/缓解/接受风险）、行动项表格与参考链接。
常见研究陷阱
技能还列出若干常见陷阱，例如：公告称“在 vX 修复”但该版本从未发布；厂商静默修复导致公告描述的是静默修复前的版本；CVE 同样适用于同代码不同名的兄弟包；CVSS 高但 EPSS 低通常意味着利用前置条件复杂；CVSS 中但 EPSS 高通常意味着已被大规模扫描利用；PoC 需要难以获得的认证，但自身应用使该认证容易获得。