supply-chain-risk-auditor

供应链风险审计器

当用户说“审计此项目的依赖项”时激活。

适用场景

• 在安全审计前评估依赖项风险
• 评估项目的供应链攻击面
• 识别未维护或有风险的依赖项
• 针对供应链问题进行合作前范围界定

不适用场景

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

用途

系统地评估项目的所有依赖项，识别表明存在较高遭攻击或被接管风险的警示因素，并生成一份注明这些问题的摘要报告。

风险标准

如果依赖项存在以下任一风险因素，则视为高风险：

• 维护者或维护团队人数少 - 项目主要或完全由一位个人或少数几人维护。项目并非由 Linux Foundation 这样的组织或 Microsoft 这样的公司管理。如果该个人是生态系统中极其活跃且知名的贡献者，例如 sindresorhus 或 Drew Devault，风险会降低，但不会消失。相反，如果该个人身份不明——也就是说，其 GitHub 身份无法轻易与现实身份关联——风险会显著增大。**理由：**如果开发者遭到贿赂或钓鱼攻击，他们可能会单方面推送恶意代码。可参考 left-pad 事件。
• 未维护 - 项目已停滞很长时间没有更新，或已明确弃用／归档。维护者可能在 README.md 或 GitHub issue 中说明项目已停止维护、人手不足或正在寻找新的维护者。项目的 GitHub 仓库中可能存在大量指出 bug 或安全问题、但维护者未予回应的 issue。功能请求 issue 不计入。**理由：**如果发现项目存在漏洞，可能无法及时修复。
• **受欢迎程度低：**与目标项目使用的其他依赖项相比，该项目的 GitHub 星标数和／或下载量相对较低。**理由：**用户越少，关注项目的人就越少。如果引入恶意代码，就无法及时发现。
• **高风险功能：**该项目实现了天生特别容易遭利用的功能，包括 FFI、反序列化或执行第三方代码。**理由：**这些依赖项是目标安全态势的关键部分，需要接受严格审查。
• **曾出现 CVE：**该项目存在高危或严重级别的 CVE，尤其是相对于其受欢迎程度和复杂度而言，数量较多时。**理由：**对于极受欢迎、仅仅因为受到更多审查而成为更多安全研究对象的项目，这未必意味着存在问题。
• **缺少安全联系渠道：**项目未在 .github/SECURITY.md、CONTRIBUTING.md、README.md 等文件中列出安全联系渠道，也未在项目网站（如有）单独列出。**理由：**发现漏洞的人将难以安全、及时地报告问题。

先决条件

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

工作流（初始设置）

1. 为工作区创建 .supply-chain-risk-auditor 目录。
   • 根据此技能目录中的 resources/results-template.md 创建 results.md 报告文件。
2. 查找所有直接依赖项对应的 Git 仓库。
3. 将 Git 仓库条目规范化为 URL——如果条目只有 name/project 格式，则在前面加上 GitHub URL。

工作流（依赖项审计）

1. 对于在初始设置中确认仓库的每个依赖项，请根据上述风险标准评估其风险。
   • 对于需要执行操作的标准（例如统计 GitHub 未处理议题数量），请使用 gh 工具查询确切数据。引用的任何数字（例如星标数、未处理议题数等）都必须准确，这一点至关重要。议题数和星标数可使用 ~ 符号取整，例如「~4000 星标」。
2. 如果某个依赖项符合上述任何风险标准，请将其添加到 results.md 中的高风险依赖项表，并清楚说明将其标记为高风险的原因。为保持简洁，请跳过低风险依赖项；只列出至少存在一个风险因素的依赖项。不要列出风险因素的「反面」，例如添加一列标注「有组织支持（风险较低）」的依赖项。报告中未提及某个依赖项，即表示其风险较低或无风险。

工作流（审计后）

1. 对于高风险依赖项表中的每个依赖项，请在建议替代方案字段中填写一个功能相同或相似、但更受欢迎、维护更完善等的替代依赖项。如有直接后继项目或可直接替换的方案，请优先选择。简要说明推荐理由。
2. 在按风险因素统计表中填写各类风险因素的总数，并在执行摘要部分概述整体安全态势。
3. 在建议部分概述你的建议。

**注意：**不要添加 resources/results-template.md 中未列出的章节。