3.5 供应链安全防线：防投毒与许可证审计

3.5 供应链安全防线：防投毒与许可证审计

本节摘要：依赖供应链的三类主要攻击是抢注（typosquatting）、依赖混淆（dependency confusion）与恶意版本注入，入口分别对应拼写误差、公共仓库优先于私有仓库、被入侵的上游。防线由私服路由、enforcer 白名单、依赖漏扫三层构成。本节给出攻击面地图与可落地的审计工具链。

一次未遂的投毒事件

某日 code review，有人提交了一个新依赖，坐标写的是 commons-lang3——注意，不是团队的常用库 commons-lang3（Apache 官方的 commons-lang3，groupId 是 org.apache.commons），而是一个同名不同门的"李鬼"：groupId 拼了个相似的词，artifactId 一模一样。若不是 reviewer 手滑点开了 POM 详情，这个"功能齐全但夹带了网络外传代码"的包就会进入构建。

这不是虚构的恐吓。公共仓库的准入门槛极低，每年都有仿冒知名库的投毒包被下架，存活期足够咬到几个不小心的团队。作战室必须承认一个前提：你引入的每一个坐标，都是一次对陌生代码的信任授予。防线要先从认清入口开始。

攻击面地图：三类主要威胁

图：依赖供应链攻击面

三类攻击对应三个日常动作，值得逐一对照自查。加依赖时防抢注：新坐标必须核对 groupId 的归属（官方域名或组织名），警惕"功能一样但门牌不对"的包。解析时防混淆：内部构件名若与公共仓库的检索空间重叠，配置不当的路由会让恶意公共包抢先命中——防线是私服上把内网构件圈进独立仓库组，公共仓库只做代理，绝不接收外部的同名构件。升级时防注入：合法上游被盗号后发的毒版本没有任何坐标异常，只能靠扫描与"升级不追首发、观察一两天"的纪律缓冲。

工具链：把防线接进构建

第一层，路由管制在私服配置（第 4 章展开部署细节）。 原则是内部与外部的解析空间物理隔离，这一层在 settings 与私服仓库组里落地。

第二层，enforcer 禁用名单。 对已发现的李鬼坐标直接立法：

<plugin>
  <groupId>org.apache.maven.plugins</groupId>
  <artifactId>maven-enforcer-plugin</artifactId>
  <version>3.3.0</version>
  <executions>
    <execution>
      <id>security-gate</id>
      <goals>
        <goal>enforce</goal>
      </goals>
      <configuration>
        <rules>
          <bannedDependencies>
            <excludes>
              <!-- 禁用已知的仿冒与不安全构件 精确到坐标 -->
              <exclude>仿冒组织:*校验出的李鬼包*</exclude>
              <exclude>已知不安全构件:旧版本范围</exclude>
            </excludes>
          </bannedDependencies>
        </rules>
        <fail>true</fail>
      </configuration>
    </execution>
  </executions>
</plugin>
​

第三层，依赖漏洞扫描。 常用方案之一是 OWASP 系的 dependency-check 插件，它把本地依赖与公开漏洞库比对，产出报告：

mvn org.owasp:dependency-check-maven:check
# 产出的报告片段示意：
# jackson-databind 2.12.7  高危 漏洞编号 CVE 略
#   建议升级到修复版本 2.13.4
#   引入路径 rule-sdk 2.1.0 传递依赖
​

扫描的接入位置建议两处：流水线每次构建做增量快扫（只挡高危），外加每周定时全量扫描出趋势报告。扫描不是一次性动作——今天干净的依赖，明天就可能爆出新漏洞，漏洞面是随时间增长的负债。

许可证审计与漏洞同轨。 依赖战争不只是安全问题，还有法务维度：GPL 系列许可证进入商业闭源产品存在传染风险。审计方法与漏洞扫描类似，按依赖树统计许可证分布，标红需要法务确认的条目。BOM 清单（全部依赖的坐标、版本、来源清单）同时服务两类审计，建议每次发布归档一份。

把"新增依赖"这道日常动作的检查单固化下来，供应链防线就有了岗哨制度：

新依赖引入检查单（copy 进合并请求模板）：
一 坐标归属：groupId 是否为官方或可信组织（对照项目主页而非仓库名）
二 活跃度：近半年有无发布 维护者是谁 issue 响应如何
三 体积与传递面：dependency:tree 数一下它带来多少传递依赖
四 许可证：类型是否与本产品兼容 不确定就交法务
五 替代品：现有依赖里是否已有等价能力（同一功能的第三种日志库就是反例）
六 升级路径：版本是否还在维护线内 避免引入即弃子
​

这份检查单五分钟走完，拦下的是"顺手加包"这个供应链事故的头号入口。作战室的统计口径里，走过检查单的依赖，后续出事故的概率低一个量级——不是因为检查本身多深奥，而是因为它强迫引入者看一眼"自己在信任谁"。

扫描工具的告警处置也需要一条纪律，否则扫描器很快沦为大家集体忽略的噪音源：每条高危告警要么修（升级到修复版本），要么豁免（记录理由与复查期限），禁止第三种状态"放着"。豁免记录是关键——三个月后新人接手，看到一条未处理的红色告警却查不到任何说明，他无法判断这是"已评估可接受"还是"没人管"。作战室的实际做法：豁免统一登记（漏洞编号、豁免理由、到期时间），到期未复查自动升级为待办。扫描器的价值不在于报得多，在于每一条报警都有归宿。

💡 关键直觉：供应链安全的三个低成本高收益动作——私服路由隔离、新依赖必须评审坐标归属、升级不抢首发。它们不依赖任何昂贵平台，依赖的只是把纪律写进流程。多数投毒事故的死因不是缺工具，是"顺手加了个包"。

战报小结

• 三类攻击面：抢注蹭拼写、依赖混淆蹭路由、盗号注入蹭信任，分别对应加依赖、解析、升级三个日常动作；
• 三层防线：私服物理隔离内外解析空间、enforcer 禁用名单立黑名单、漏扫插件接漏洞库持续比对；
• 扫描双位置：流水线增量快扫挡高危，定时全量出趋势，漏洞负债随时间增长必须持续跟踪；
• 许可证同轨审计：GPL 传染风险按依赖树统计，BOM 清单每次发布归档；
• 纪律高于工具：坐标核对、评审通道、不追首发版本，三条零成本动作挡掉大多数事故。

攻防战术与补给防线都已就位。下一节收束本章：把散落的排查经验组织成系统化方法论，让下一次故障处置不再依赖某个人的灵光一现。