依赖漏洞扫描

要解决什么问题

现代应用依赖树往往跨 npm、PyPI、Maven 等多个生态，CVE 与许可证风险不会只出现在直接依赖里。团队在合规审计、发布前检查或供应链可见性项目里，需要一份可核对的结果：哪些包有已知漏洞、版本是否过时、SBOM 能否导出给采购或安全部门。

本技能把角色设定为依赖与供应链安全方向的安全专家，围绕你提供的项目上下文（$ARGUMENTS）给出可执行的扫描与评估思路，而不是泛泛的安全口号。

技能如何工作

• 多生态扫描：在存在依赖清单或锁文件的前提下，统一讨论如何识别漏洞与过时依赖。
• 风险与合规：结合漏洞数据库与许可证维度，帮助区分「必须修」与「可接受风险」。
• SBOM：说明为合规或供应链可见性生成软件物料清单时应覆盖的字段与验证方式。
• 修复规划：给出升级、替换或缓解策略的步骤，并强调未经批准不要执行自动修复；依赖变更应按发布级改动做测试。

操作上会先澄清目标、约束与输入，再应用最佳实践并给出可验证的检查步骤；更细的模式与示例见技能内 resources/implementation-playbook.md。

适用边界与注意点

• 仅需要运行时渗透或动态测试、或仓库里没有 package-lock.json / poetry.lock 等可扫描清单时，不适合作为主力方案。
• 若环境禁止安装或运行第三方安全扫描器，应先解决策略与工具白名单，再谈扫描流程。
• 自动升级脚本可能改变构建与行为；默认应停留在分析与方案层，修复落地需人工审批与回归验证。