依赖混淆攻击是什么从 npm、PyPI 到 Maven 的软件供应链防御指南专栏代码安全笔记 · 软件供应链安全进阶篇06关键词依赖混淆、Dependency Confusion、开源投毒、私有仓库、软件供应链摘要依赖混淆Dependency Confusion不是传统意义上的代码漏洞而是包管理器从哪里下载依赖这一信任决策出现偏差。当企业内部包名与公共仓库中的包名发生冲突构建系统又允许向公网回退时就可能安装错误来源的依赖。本文从攻击链、场景分析和工程防御三个维度拆解风险给出可执行的排查清单。一、问题不在代码而在“包的来源”假设团队使用内部组件acme-internal-utils。开发人员认为该依赖来自公司私有仓库但构建工具配置了公共仓库和私有仓库且没有严格限定来源。攻击者若能在公共仓库注册同名包就可能影响依赖解析结果。否是开发者提交依赖声明包管理器解析名称和版本是否限定可信源公共仓库同名包可能被选中仅从指定私有源解析恶意代码进入构建环境进入正常审查与构建注意不同生态、不同工具版本、索引配置与锁文件策略下包选择机制并不相同不能简单认为“公共仓库版本号更高就一定被安装”。应验证实际包管理器行为。二、五种常见的攻击入口入口风险表现优先防护公共与私有仓库混用同名依赖来源不确定私有包命名空间及源绑定构建机默认联网非预期回退到公网索引代理仓库及出口策略无锁文件或锁文件未审查解析结果随时间改变固定版本和完整性校验临时脚本直接安装依赖绕过统一构建规范禁止临时公网安装安装生命周期脚本获取依赖后触发脚本执行在可行情况下限制脚本与权限除了依赖混淆同样值得关注的还有维护者账户被接管、包名拼写诱导typosquatting和恶意版本更新。这些都是依赖链滥用但攻击条件不完全相同。三、npm 项目的治理实践1. 配置企业包作用域如果组织使用example-corp作为内部包作用域可在项目.npmrc中设置example-corp:registryhttps://registry.example.com/npm/ registryhttps://registry.npmjs.org/这只是示意地址。生产环境应结合企业制品仓库权限、认证和网络策略作用域配置并不能单独保证所有依赖都可信。2. 固定依赖并使用一致性安装npmcinpmls--allnpm ci基于锁文件进行安装适合 CI 环境。应同时审查package-lock.json中的来源 URL、integrity 信息和异常新增包。不能把锁文件视为不可篡改的安全证明。3. 在低权限构建环境中执行安装使用临时构建容器避免长期驻留密钥依赖安装阶段默认不提供生产环境凭据对外网访问实施白名单或经过受控代理将安装日志、仓库解析记录纳入审计。四、Python 与 Maven 的差异化处理Python 工程应统一维护pip.conf或组织级索引策略避免开发者随意组合多个索引对于敏感项目可以使用受控镜像仓库与哈希锁定机制。--require-hashes需要对所需依赖准备完整哈希清单。Maven 工程应通过settings.xml中的 mirror、repository 和权限配置控制组件来源并配合依赖树审计mvn dependency:tree对于 Java 包还要核对groupId:artifactId:version、仓库来源与制品哈希避免只按组件名称判断。五、一次可执行的排查流程第一步盘点。汇总内部包、组件坐标及实际使用的公共/私有仓库。第二步对账。核查内部包名称是否出现在公共仓库并确认是否存在非预期来源。第三步验证。在隔离环境中观察依赖解析日志确保不会向不可信源回退。第四步加固。对内部包实施命名空间、源绑定、锁定、制品校验与网络限制。第五步运营。新增组件或变更索引时自动触发审查。核心检查点 [ ] 内部依赖是否有明确的可信下载源 [ ] CI 是否允许绕过代理直连公网包仓库 [ ] 锁文件是否纳入代码审查 [ ] 是否记录最终安装组件的来源与摘要 [ ] 安装阶段是否暴露敏感令牌六、企业落地建议优先从三个高价值动作入手建立内部包命名台账、统一依赖下载入口、让构建流水线验证组件来源。当企业已经使用 SBOM 时还可以将组件名称、版本、来源、制品摘要关联到每个发布版本形成持续追溯能力。安全扫描发现不了所有来源替换风险。SCA、锁文件审查、可信构建和最小权限必须配合使用。总结依赖混淆的本质是“名字相同来源不同”。真正有效的防护不是简单禁止开源而是让依赖解析具有确定性让软件组件来源可验证并把这一要求固化在开发与 CI/CD 流程中。
