# Supply Chain Risk Auditor

> 识别易被利用或接管的高风险依赖项。用于评估供应链攻击面、审查依赖健康状况或界定安全评估范围。触发词：审计依赖、供应链风险、依赖审查

- Skill: `kscz0000/supply-chain-risk-auditor` (Agent Skill)
- Install (CLI): `npx skillmds@latest add kscz0000/supply-chain-risk-auditor`
- Raw SKILL.md: https://api.skillmd.com/api/skills/kscz0000/supply-chain-risk-auditor/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: kscz0000 (https://skillmd.com/u/kscz0000)
- Updated: 2026-09-21
- Page: https://skillmd.com/skills/kscz0000/supply-chain-risk-auditor

---


# 供应链风险审计员

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

## 适用场景
- 安全审计前评估依赖风险
- 评估项目的供应链攻击面
- 识别无人维护或高风险的依赖
- 供应链问题的事前范围界定

## 不适用场景

- 漏洞主动扫描（使用专用工具如 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. 规范化 git 仓库条目为 URL 格式，如仅为 name/project 格式则需补全 github URL 前缀

## 工作流程（依赖审计）
1. 对初始化阶段识别的每个依赖，按上述风险判定标准评估其风险
	* 对于需要统计 GitHub issue 数量等操作的指标，使用 `gh` 工具查询精确数据。引用的任何数字（如 star 数、open issue 数等）必须准确，可使用 ~ 符号约数表示，如"~4000 stars"。
2. 若依赖符合上述任一风险标准，将其加入 `results.md` 的高风险依赖表，注明标记原因。为简洁起见，跳过低风险依赖；仅记录至少有一个风险因素的依赖。不记录风险因素的"反面"（如"组织支持（低风险）"列）。报告中未出现的依赖即表示低风险或无风险。

## 工作流程（审计后）
1. 对高风险依赖表中的每个依赖，在"建议替代"字段填写功能相同或相似但更流行、维护更好的替代方案。优先选择直接继任者和即插即用替代品（如有）。提供简短的推荐理由。
2. 在"按风险因素统计"表中记录各风险因素类别的总数，并在"执行摘要"部分总结整体安全态势。
3. 在"建议"部分汇总改进建议

**注意：** 不要添加 `results-template.md` 之外的章节。

## 局限性
- 仅在任务明确匹配上述范围时使用此技能
- 不要将输出作为特定环境验证、测试或专家审查的替代品
- 若缺少必要输入、权限、安全边界或成功标准，请停止并请求澄清