kscz0000 供应链风险审计员
当用户说"审计这个项目的依赖"时激活。
适用场景
- 安全审计前评估依赖风险
- 评估项目的供应链攻击面
- 识别无人维护或高风险的依赖
- 供应链问题的事前范围界定
不适用场景
- 漏洞主动扫描（使用专用工具如 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 工具可用。若未找到，请用户安装。
工作流程（初始化）
- 创建
.supply-chain-risk-auditor工作目录- 基于
results-template.md在此目录下创建results.md报告文件
- 基于
- 找出所有直接依赖的 git 仓库
- 规范化 git 仓库条目为 URL 格式，如仅为 name/project 格式则需补全 github URL 前缀
工作流程（依赖审计）
- 对初始化阶段识别的每个依赖，按上述风险判定标准评估其风险
- 对于需要统计 GitHub issue 数量等操作的指标，使用
gh工具查询精确数据。引用的任何数字（如 star 数、open issue 数等）必须准确，可使用 ~ 符号约数表示，如"~4000 stars"。
- 对于需要统计 GitHub issue 数量等操作的指标，使用
- 若依赖符合上述任一风险标准，将其加入
results.md的高风险依赖表，注明标记原因。为简洁起见，跳过低风险依赖；仅记录至少有一个风险因素的依赖。不记录风险因素的"反面"（如"组织支持（低风险）"列）。报告中未出现的依赖即表示低风险或无风险。
工作流程（审计后）
- 对高风险依赖表中的每个依赖，在"建议替代"字段填写功能相同或相似但更流行、维护更好的替代方案。优先选择直接继任者和即插即用替代品（如有）。提供简短的推荐理由。
- 在"按风险因素统计"表中记录各风险因素类别的总数，并在"执行摘要"部分总结整体安全态势。
- 在"建议"部分汇总改进建议
注意： 不要添加 results-template.md 之外的章节。
局限性
- 仅在任务明确匹配上述范围时使用此技能
- 不要将输出作为特定环境验证、测试或专家审查的替代品
- 若缺少必要输入、权限、安全边界或成功标准，请停止并请求澄清