NPM 包依赖审计器

要解决的问题

当你的 package.json 里只有几个直接依赖时，看似风平浪静。但 npm install 拉下来的可能是成百上千个传递依赖——这些间接引入的包才是供应链攻击的主要战场。

常见的风险包括：

• Typosquatting 攻击：恶意包注册与知名包近似的名称（如 reqst 代替 request），一旦误装就可能泄露凭证或植入后门。
• 依赖混淆：攻击者劫持已废弃包的命名空间，老项目升级时误引入恶意版本。
• 许可证冲突：传递依赖中混入 GPL 或 SSPL 等传染性许可证，可能在不知不觉中让商业产品面临合规风险。

传统的 npm audit 能发现已知漏洞，但对上述供应链层面的威胁覆盖有限。

技能如何工作

这个技能从两个维度交叉验证依赖树的安全性：

数据源

• npm Registry API：获取包的元数据、版本历史、维护者信息。
• Socket.dev：聚合 npm 生态的威胁情报，包括恶意包行为特征、可疑命名模式和供应链异常信号。

审计流程

1. 依赖树展开：从项目的直接依赖出发，递归解析所有传递依赖及其版本锁定关系。
2. Typosquatting 检测：将每个包名与已知的合法包进行编辑距离计算，标记名称高度相似的可疑条目。
3. 许可证兼容性检查：提取所有依赖的许可证类型，比对项目声明的许可证，标记存在传染性条款的组合。
4. 供应链风险评分：结合 Socket.dev 的威胁情报，对每个依赖项给出风险等级，区分已知恶意包与潜在可疑包。

适用边界

• 该技能依赖公开数据源，私有 registry 或本地 file: 依赖不在审计范围内。
• Socket.dev 的情报更新存在延迟，刚发布的恶意包可能尚未被标记。
• 许可证兼容性判断基于 SPDX 标识符的静态分析，复杂自定义许可证可能需要人工复核。
• 审计结果应作为安全决策的参考，而非自动化拦截的唯一依据。