凌晨两点，拦截n漏CI服务器突然爆红。洞包日志翻到最后，拦截n漏一行刺眼的洞包提示：log4j-core-2.14.1.jar 正在被远程代码执行利用。那周我们刚把log4j升级到2.14.1，拦截n漏以为躲过了CVE-2021-44228，洞包结果第二天官方又披露2.15.0的拦截n漏绕过漏洞。项目组三个人轮流盯着Nexus仓库，洞包手动删掉所有带漏洞的拦截n漏包，再逐个模块重新构建——折腾到天亮，洞包还有两个微服务因为依赖传递没清干净，拦截n漏照样带着旧包上线。洞包

后来我学乖了。拦截n漏直接在Nexus里配了规则：log4j-core 版本号低于2.17.0的洞包，一律拦截，拦截n漏连下载都不允许。这招比在代码里写检查靠谱得多——因为没人能保证每个开发者的本地仓库都干净。你改了pom.xml，但同事的 ~/.m2 里可能还躺着那个旧包，构建时直接拿去用了，CI根本察觉不到。

更隐蔽的是传递依赖。你明明只引了 spring-boot-starter-web，结果它背后拉进来一个老版本的 commons-collections，里面有个反序列化漏洞，攻击者只要构造一个特殊请求就能执行任意命令。这种包不会出现在你直接管理的依赖列表里，但你得对它们负责。Nexus的“违规版本”规则能拦住这种间接引入——只要仓库里出现匹配条件的组件，无论从哪个依赖路径进来，直接拒绝下载。

规则要写细。别只拦版本号，还得看仓库类型。有些团队把第三方包和内部包放在同一个仓库，结果内部包用了相同的groupId，一升级就把外部版本覆盖了。我见过最离谱的一次，某个同事把 org.apache.commons 的包误传到了release仓库，还加了 -SNAPSHOT 后缀，导致所有人构建时都拉到那个坏包，编译直接报错。所以拦截规则里要限定 repository 匹配，只对proxy类型的远程仓库生效，别误伤内部制品。

还有种情况容易被忽视：时间戳版本。有些仓库允许 1.0-20241201.123456-1 这样的动态版本，每次构建都可能拉到不同的包，漏洞修复后你根本不知道哪个版本被缓存了。对付这个，最好在Nexus里开启“定期清理未使用快照”策略，同时设置规则禁止这种带时间戳的版本号出现在release仓库里。

配置好之后别忘了测试。我见过有人配了规则，但忘了勾选“阻止下载”的选项，结果Nexus只是弹个警告，包照样被拉走。那跟没配一样。得在规则里明确指定动作是 BLOCK，并且返回给客户端的错误信息要写清楚——比如“该版本存在CVE-2021-44228，请升级到2.17.0及以上”，这样开发者看到报错就知道怎么改，不用翻文档。

最后说个反直觉的事：拦截规则不是越多越好。你每加一条限制，都可能误伤合法场景。比如有些老项目依赖旧版 httpclient，新版本API不兼容，你硬要拦，人家编译都过不了。所以规则要分优先级：高危漏洞的包必须拦，但中间件版本升级的提示可以只发警告，让团队自己权衡。我现在的做法是维护一个漏洞清单，每周更新一次，把新披露的CVE对应到具体groupId和版本范围，再批量导入Nexus。平时不用管它，等它真正拦住一个包的时候，你就知道这功夫没白费。