---

name: supply-chain-risk-auditor description: "识别面临较高利用或接管风险的依赖项。用于评估供应链攻击面、评估依赖健康状况或确定安全评估范围。" allowed-tools:

• Read
• Write
• Bash
• Glob
• Grep risk: unknown source: community

---

供应链风险审计师

当用户说"审计这个项目的依赖"时激活。

何时使用

• 在安全审计前评估依赖风险
• 评估项目的供应链攻击面
• 识别未维护或有风险的依赖
• 供应链问题的预评估范围确定

何时不使用

• 主动漏洞扫描（使用专用工具如 npm audit、pip-audit）
• 运行时依赖分析
• 许可证合规审计

目的

你系统地评估项目的所有依赖，以识别表明高利用或接管风险的危险信号。你生成一份总结报告，记录这些问题。

风险标准

如果依赖具有以下任何风险因素，则被视为高风险：

• 单一维护者或个人团队 - 项目主要或完全由单个人或少数人维护。项目不由 Linux 基金会等组织或微软等公司管理。如果该个人是生态系统中极其多产且知名的贡献者（如 sindresorhus 或 Drew Devault），风险会降低但不会消除。相反，如果该个人是匿名的——即其 GitHub 身份不容易与现实身份关联——风险会显著增加。理由： 如果开发者被贿赂或钓鱼，他们可能单方面推送恶意代码。参考 left-pad 事件。
• 未维护 - 项目停滞（长时间没有更新）或明确弃用/归档。维护者可能在 README.md 或 GitHub issue 中注明项目不活跃、人手不足或寻找新维护者。项目的 GitHub 仓库可能有大量记录 bug 或安全问题的 issue，维护者未回应。功能请求 issue 不计入。理由： 如果在项目中发现漏洞，可能无法及时修补。
• 低人气： 与目标使用的其他依赖相比，项目的 GitHub star 和/或下载量相对较低。理由： 用户越少意味着关注项目的人越少。如果引入恶意代码，不会被及时发现。
• 高风险特性： 项目实现了本质上特别容易被利用的特性，包括 FFI、反序列化或第三方代码执行。理由： 这些依赖对目标的安全态势至关重要，需要满足高标准的审查。
• 存在过去的 CVE： 项目有高严重性或关键严重性的 CVE，特别是相对于其人气和复杂度而言数量较多。理由： 对于极其流行的项目来说，这不一定是令人担忧的指标，因为它们只是受到更多审查，因此成为更多安全研究的对象。
• 缺少安全联系方式： 项目在 .github/SECURITY.md、CONTRIBUTING.md、README.md 等中没有列出安全联系方式，或在项目网站上（如果存在）也没有单独列出。理由： 发现漏洞的个人将难以安全及时地报告。

前提条件

在继续之前确保 gh 工具可用。如果未找到，请用户安装。

工作流（初始设置）

你通过以下方式实现目的：

1. 创建 .supply-chain-risk-auditor 目录作为工作区
   • 基于此目录中的 results-template.md 开始一个 results.md 报告文件
2. 查找所有 git 仓库依赖并逐一评估风险因素
3. 为每个依赖生成风险评分和建议
4. 输出最终报告，按风险级别排序