Spring Boot迁移与CRA：当“足够好”已不再足够
目录
今年四月我写过一篇文章，探讨当 Spring Boot 3.5 跨越终止支持（EOL）线时，你的安全态势会发生什么变化。
简而言之：CVE 管道枯竭，扫描器变得安静，而恶意行为者会持续关注上游的任何漏洞，以便在下游针对无人修补的废弃代码进行利用。
我称它们为“僵尸依赖”。
6 月 30 日即将到来。几周后，Spring Boot 3.5 将结束开源支持。你要么已经制定了计划，要么还没有。
如果你已经升级到 4.0
僵尸问题依然与你同在
很好。我猜这次迁移并没有你想象的那么容易。不过有件事值得一说：迁移到 4.0 并不意味着你已经摆脱了僵尸问题。你的新依赖树中，传递层里仍然潜伏着自身的 EOL 包。
现在，使用 HeroDevs EOL CLI 对你的新构建进行扫描，是明智的第一步。
如果你仍然停留在 3.5
技术风险在增长，法律风险即将改变
技术风险是什么？就是我在四月描述的僵尸问题：漏洞在上游披露、在下游可被利用，但在你的扫描器中不可见（因为没有人为一个压根不打算修补的代码库提交 CVE）。
这种情况已经存在。
而 6 月 30 日改变的是法律背景。
迁移成本高昂，所以你才需要时间。
从 3.5 迁移到 4.0 不是简单的版本号变更。超过 50 个破坏性变更，36 个废弃类被移除，8 个主要依赖同时发生变化。我写了一篇详细指南，说明迁移的实际成本。
根据 HeroDevs 自身对类似 Spring 主版本迁移的分析，小型代码库大约需要六周；中型代码库（5 个微服务、3 万到 8 万行代码）需要 12 到 14 周；大型代码库所需时间更长。
Spring 社区自身的建议是在 EOL 之前九到十二个月开始迁移。对于 Spring Boot 3.5，这个窗口在 2025 年 7 月就已经打开了。
“无不当延误”现在究竟意味着什么
第 14 条与 24 小时倒计时
欧盟《网络弹性法案》（CRA）将于 9 月 11 日开始逐步生效。
第 14 条第 1 款规定：如果你发布的产品包含一个正在被野外利用的漏洞，并且你得知了该漏洞，你必须在 24 小时内向 ENISA 和本国的 CSIRT 提交预警。
完整的漏洞通报需在 72 小时内提交。在有纠正措施可用后的 14 天内，必须提交最终报告。
触发条件是实际被利用，而不是 CVE 分配，也不是特定的严重性评分。
CISA 已知漏洞利用目录是了解哪些漏洞正在被积极利用的有用代理，但 CRA 的义务范围更广：它适用于你得知产品中存在漏洞正在被利用的任何情况，无论该漏洞是否列在某个特定清单上。
此外，你还有一项更广泛的义务：无不当延误地解决该漏洞。
这个短语是关键。它具有实际的法律分量。
在欧盟监管框架中，“无不当延误”通常按比例解释：相对于组织在当时合理可用的资源而言。
衡量标准是情境性的，而非绝对性的。
6 月 30 日起计算方式改变
6 月 30 日之前，如果在 Spring Boot 3.5 中出现一个被积极利用的漏洞，监管机构若问你是否做到了“无不当延误”，本质上是在问：为什么你没有采用上游补丁？这个问题很容易回答。上游支持存在。你可以升级。修复措施就在那里。
6 月 30 日之后，上游补丁不再存在。但商业支持存在。这完全改变了监管问题。
监管机构不再问为什么你没有采用上游修复。他们问的是：为什么你没有利用诸如 HeroDevs 之类的可用方案来获取补丁？
“无不当延误”是根据你合理可用的情况来判断的。一旦商业支持存在，“我们无能为力”这个答案就不再成立。
为何商业支持改变你的法律地位
商业支持选项是存在的。HeroDevs 提供 Spring Boot 3.5 的永续支持（Never-Ending Support），将安全补丁移植回 EOL 版本。
其他供应商则提供 Spring Boot 4.x 的扩展商业支持直到 2032 年。不过公平地说，作为一个活跃的开源项目，你本可以从活跃支持的线路中获得安全补丁。在这些服务中，你购买的也包括错误修复。
现在，如果出现一个新的僵尸漏洞，并且被积极利用，而商业支持供应商已经有了可用补丁，“我们计划在六个月内迁移”这个理由将更难辩护。
监管机构隐含的问题是：为什么你在建桥的时候没有使用渡轮？
我在 HeroDevs 工作，所以我显然有利益关系说清楚这一点。但无论如何我还是要说，因为无论谁受益，这都是事实，也是我加入 HeroDevs 的主要原因之一。
现在规划，否则日后手忙脚乱
商业 EOL 支持只是支持。它不会改变你的应用程序，也不会改变其他依赖中出现僵尸漏洞的风险。
无论是现在迁移还是以后迁移，迁移工作是相同的。
区别在于：你是按自己的时间表来做，还是按监管机构的时间表来做。或者，如果你幸运的话，利用支持选项让应用保持安全，直到它退役。
僵尸问题有了新的紧迫性
从待办事项到合规事件
目前延期似乎还可以应付。出现僵尸 CVE 的几率有多大？记住，那是一个在上游披露、下游可被利用，但在你的扫描器中不可见的 CVE。
你是等它发生了再担心，还是现在就采取行动？它必然会发生，但也许你只需在需要时获取支持？如果那是你的计划，那么请立刻确保你堆栈中的每个依赖都能获得支持。
为什么？因为并非所有东西都可能得到覆盖，而 CVE 可能出现在任何地方。不仅仅是 Spring Boot 3.5。如果这种情况发生在 9 月 11 日之后，CRA 很可能会对如何以及多快地修复有发言权。
计划依赖并不存在的支持，可能会有点尴尬。
时钟在滴答作响
当 CRA 报告要求生效时，你 EOL 的 Spring Boot 3.5 部署中任何被积极利用的漏洞，都会在你得知的那一刻启动一个 24 小时的倒计时。
由于只有最高严重性的 CVE 才可能在 EOL 软件上被标记，难点在于你只会看到那些糟糕的——那些 CRA 真正要求你报告的漏洞。但来自开源项目的上游补丁并不存在。
这并不改变义务。CRA 不会为 EOL 软件网开一面。事实上，它正是为此而制定的。
CRA 的报告要求是欧盟收紧规则、使商业软件更加安全的第一步。义务只会越来越广泛。
迁移不是可选项
试图通过迁移来摆脱安全危机，除非这真的是万不得已的最后手段，否则不会得到认可。
确保在发生这种情况之前，你清楚自己的所有选择。
下周该做什么
如果你仍在使用 3.5，请本周开始迁移讨论。阅读迁移指南。针对你的依赖树运行 EOL 扫描。
现在就做
事实上，无论你使用什么软件栈——无论是 Java 还是其他——现在就是时候全面了解你的资产在 CVE 和 EOL 方面的情况了。你需要尽可能多的时间来对你的供应链中的每项技术做出明智的决策。
下次再聊
下次我会更详细地介绍 HeroDevs 的 EOL 数据以及如何使用。
实践中“实际被利用”是什么意思，你怎么知道？
CRA 并没有精确定义。这是一个事实问题：漏洞是否在现实世界中被用于真正的攻击。有几个信号可以帮助判断：
- CISA KEV 是最权威的公开列表。列入 KEV 意味着 CISA 已确认利用且有证据。它并不全面——利用可能先于列入——但它是最清晰的公开信号，几乎肯定能满足 CRA 的触发条件。
- EPSS（漏洞利用预测评分系统，由 FIRST 维护） 评估 30 天内被利用的概率。每天更新，广泛集成于工具中。高 EPSS 是指标；KEV 列入是滞后的确认。
- Snyk 会将有证据证明被野外利用的漏洞标记为“Attacked”。如果你的项目中某个依赖被标记为 Attacked，则将其视为潜在的 CRA 触发。
- Sonatype Lifecycle 整合了 EPSS 及其自身通过监控公共仓库和威胁情报源获得的利用数据，在显示严重性同时展示利用概率。
- OSV Scanner 不直接显示利用状态，但将其输出与 CISA KEV 目录交叉引用可以得到组合信息。
Steve Poole 是 HeroDevs 的开发者倡导者，也是 Java Champion。HeroDevs 为 EOL 开源软件（包括 Spring Boot 3.5）提供永续支持。本文是《跨越冥河：Spring Boot 3.5 与僵尸依赖问题》的续篇。
本文最初发表在 foojay。