企业官网建设流程全解析

name: supply-chain-risk-auditor
description: “Identifies dependencies at heightened risk of exploitation or takeover. Use when assessing supply chain attack surface, evaluating dependency health, or scoping security engagements.”
allowed-tools:

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

供应链风险审计器

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

何时使用

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

何时不使用

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

目的

你系统性地评估项目的所有依赖，以识别表明存在较高被利用或被接管风险的警示信号。你会生成一份总结报告，指出这些问题。

风险标准

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

• 单一维护者或个体团队—— 项目主要由单个个人或少数个人维护。项目不由 Linux 基金会等组织或微软等公司管理。如果该个人是该生态系统中极其多产且知名的贡献者，例如sindresorhus或 Drew Devault，风险会降低但不会消除。相反，如果该个人是匿名的——也就是说，其 GitHub 身份不容易与现实身份关联——风险会显著增加。理由：如果开发者被贿赂或钓鱼，他们可以单方面推送恶意代码。想想 left-pad 事件。
• 未维护—— 项目已停滞（长时间没有更新）或被明确弃用/归档。维护者可能在 README.md 或 GitHub issue 中说明项目不活跃、人手不足或正在寻找新维护者。项目的 GitHub 仓库可能有大量指出错误或安全问题的 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. 将 git 仓库条目规范化为 URL，即，如果它们只是 name/project 格式，确保在前面加上 github URL。

工作流（依赖审计）

1. 对于你在初始设置中识别出仓库的每个依赖，根据上述风险标准评估其风险。
   • 对于任何需要执行操作（如统计未解决的 GitHub issue 数量）的标准，使用gh工具查询确切数据。你引用的任何数字（如 star 数、未解决 issue 数等）必须准确，这一点至关重要。你可以使用 ~ 符号对 issue 和 star 数取整，例如 “~4000 stars”。
2. 如果依赖满足上述任何风险标准，将其添加到results.md的高风险依赖表中，并清楚说明你将其标记为高风险的原因。为简洁起见，跳过低风险依赖；只记录至少有一个风险因素的依赖。不要记录风险因素的"反面"，例如为"组织支持（风险较低）"依赖设置一列。报告中没有某个依赖，就应该表示它是低风险或无风险的。

工作流（审计后）

1. 对于高风险依赖表中的每个依赖，填写"建议替代品"字段，给出执行相同或类似功能但更受欢迎、维护更好等的替代依赖。如果可用，优先选择直接继任者和即插即用替代品。为你的建议提供简短理由。
2. 在"按风险因素统计"表中记录每个风险因素类别的总数，并在"执行摘要"部分总结整体安全态势。
3. 在"建议"部分总结你的建议

注意：不要添加results-template.md中列出的章节之外的章节。

局限性

• 仅当任务明确符合上述范围时使用此技能。
• 不要将输出视为特定环境验证、测试或专家审查的替代品。
• 如果缺少必要的输入、权限、安全边界或成功标准，请停下来询问澄清。