技能介绍

解决的问题

很多项目在构建时会把私有注册中心和公共注册中心同时暴露给解析器。一旦清单里出现像 @internal/billing、payment-core、acme-worker 这类内部包名，却没有硬性锁定到私有源，解析器可能去公共 registry 找同名包；如果攻击者抢先注册更高 semver 的版本，构建或 CI 安装就可能拉到恶意代码。真正难的不是“有没有锁文件”，而是包名是否已经外泄、锁文件是否在 CI 被强制、版本范围是否允许解析器跨源取“最新”版本。

技能如何工作

这个技能把依赖混淆当作一次可审计的供应链测试来组织，而不是简单跑一遍 npm audit。先看清单和锁文件：找未加 scope 的短包名、组织专属 token、产品代号，以及公共注册中心是否已有同名包或可抢注空间；再核对解析配置，例如 npm scopes、pip --extra-index-url / --index-url、Maven repository 顺序，判断公共源是否会在版本解析中胜出。随后用回调、DNS/HTTP 请求等非破坏性 PoC 验证风险，不把敏感数据导出当目标，而是留下可解释证据：谁请求了哪个包名、哪个源返回了哪个版本、构建链路是否真的消费了它。

适用边界

只用于你已获授权的系统、仓库和构建流水线。它不是漏洞扫描器的替代品，也不能替代资产管理和私有源治理；如果组织尚未区分内部命名空间、公共包命名空间和 CI 缓存信任边界，测试结果需要结合清单、CI 配置和注册表策略一起看。发现命中后，优先收紧源路由、锁文件和签名验证，而不是把 PoC 留在生产环境里反复运行。