依赖混淆供应链攻击风险检查器
勾选项目在包命名、Registry配置、版本管理、CI/CD完整性校验等方面的暴露面,按权重计算依赖混淆(Dependency Confusion)攻击风险评分与等级。
免费在线工具
Loading…
使用说明
勾选当前项目符合的风险项(如内部包名未加scope前缀、私有Registry未限定作用域、未锁定包来源等),点击「计算风险评分」查看总分(0-100)与风险等级(低/中/高),以及命中的具体风险项列表。
点击「加载示例数据」可快速体验勾选两项高危因素后的评分效果。
功能介绍
本工具是一个纯前端加权清单打分器,覆盖5类常见暴露面(权重合计100分):
- 内部包名未加组织专属scope前缀(30分)
- 私有Registry未按scope限定来源,会向公共源fallback(25分)
- 项目配置未显式锁定内部包来源Registry(20分)
- 内部包版本号低于可能被抢注的公共同名包版本(15分)
- CI/CD构建允许跳过或修改lockfile完整性校验(10分)
总分≥60「高」需立即整改,25-59「中」应尽快排期,<25「低」建议持续关注。依赖混淆攻击利用包管理器默认优先解析公共Registry上版本更高的同名包这一机制,攻击者抢注与企业内部包同名的恶意包即可被自动拉取执行,2021年由安全研究员Alex Birsan首次公开披露并影响了多家大型科技公司。
使用场景
供应链安全自查
在安全审计或渗透测试前自查依赖混淆攻击的暴露面。
新项目上线前检查
新项目接入内部私有包管理体系前,确认命名与Registry配置符合安全规范。
向安全团队汇报整改进度
用评分变化量化展示依赖混淆风险的整改效果。
常见问题
怎么给内部包加scope前缀?
npm可用@company/package-name的scoped package命名;Python可用company-internal-前缀或独立的私有索引命名空间;核心是让包名在公共Registry上不会与常见命名规则冲突。
为什么Registry fallback风险权重最高?
即使包名已加scope前缀,如果包管理器/私有Registry配置未正确限定该scope只从私有源解析,仍可能在私有源不可用或配置错误时意外回退到公共源,是最容易被忽视的高危配置项。