2025 年的 Java：驾驭迁移、安全和长期风险

执行摘要

2025年，Java仍将是企业系统的支柱，为银行业、政府、医疗保健和电子商务领域的关键任务工作负载提供支持。尽管该语言的语法依然熟悉，但其周边生态系统已发生巨大变化。企业现在必须重新思考如何应对迁移、安全和治理等问题。

‍

甲骨文两年一次的长期支持（LTS）发布周期如今已成为企业规划周期的决定性因素。过去每十年才进行一次的迁移项目，如今已演变为每四到六年重复一次。每次新的LTS版本发布都会带来JDK内部的兼容性变更、模块移除以及架构调整。

‍

Log4Shell 和 Spring4Shell 等安全事件揭示了，一个开源依赖项如何能在数小时内导致数千个应用程序瘫痪。新思科技（Synopsys）2024年的一项研究发现，74%的代码库中存在高风险的开源漏洞，而仅仅两年前这一比例仅为48%。与此同时，Sonatype 报告称，恶意开源软件包的数量同比激增了156%。

对于首席信息官（CIO）、首席信息安全官（CISO）和工程负责人而言，问题已不再是是否继续依赖 Java，而是如何在长期支持（LTS）版本之间安全迁移、降低遗留环境中的风险，以及实施能够经受住监管审查的治理框架。

‍

本白皮书详细分析了迁移的实际情况、实际数据泄露事件的经验教训、供应链风险，以及在2025年影响企业决策的经济、监管和供应商动态。

‍

Java 在企业中的持久作用

尽管Go和Rust等云原生语言日益兴起，Java仍深深植根于企业IT领域。它始终位列全球使用最广泛的编程语言前三名，拥有超过1200万名活跃开发者。

‍

关键任务系统——包括金融清算所、电子健康记录系统、电子商务平台和政府应用程序——都依赖于JVM。其长久的使用寿命既是福也是祸。虽然稳定性让技术领导者感到安心，但也助长了拖延之风。“如果没坏，就别修”这种心态导致无数组织仍在使用已不再受支持的运行时环境，从而扩大了攻击面，并使合规风险不断加剧。

‍

新的 Java 发布与支持模式

自 2018 年以来，甲骨文和 OpenJDK 社区采用了每六个月发布一次新功能的节奏，每两年发布一次长期支持（LTS）版本。当前的 LTS 版本包括 Java 8、11、17 和 21，预计 Java 25 将于 2025 年 9 月发布。

‍

大多数企业采用“跳过两个版本”的做法，计划每四到六年进行一次迁移。这虽然减少了升级的次数，却增加了每次升级的复杂性。例如：

• 从 Java 8 迁移到 Java 11 需要替换 CORBA 和 Java EE 等已弃用的模块。
• 从 11 版本迁移到 17 版本后，内部 API 将实现强封装，并且“安全管理器”将被废弃。
• 从 17 升级到 21 引入了新的垃圾回收策略和虚拟线程，这些变化会影响并发模型。
• 直接迁移到 Java 25 可能需要同时处理长期存在的弃用项，并完全禁用安全管理器。

许可政策的变更带来了进一步的动荡。甲骨文转向按员工人数计费的订阅模式，加之免费支持期限缩短，促使许多组织转而采用 Adoptium、Amazon Corretto 或 Azul 等替代方案。

‍

迁移的现实与陷阱

版本迁移很少能直接替代原有版本。每次 LTS 版本更新都可能导致框架、库和部署模型出现兼容性问题。依赖内部反射、SOAP 绑定或 WAR 部署的遗留系统通常需要进行大规模重写。随着新垃圾回收器的引入，性能特征也会发生变化，因此需要进行全面的基准测试。

‍

推迟迁移的企业将面临更大的风险。如果直接从 Java 8 或 11 跳到 Java 25，很可能需要分阶段升级，这将使成本倍增，并延长项目周期。将迁移计划纳入 IT 路线图的企业，可以避免紧急项目带来的高昂成本。

‍

从现实世界中的漏洞中汲取的教训

过去十年表明，Java 生态系统中的漏洞会迅速演变为灾难性后果。

• Equifax（2017年）：一个未修补的ApacheStruts 导致1.47亿条消费者记录泄露。补丁服务水平协议（SLA）的时限应以天为单位，而非以周为单位。
• Log4Shell（2021）：漏洞披露后数小时内便出现了利用行为，这证明了软件物料清单（SBOM）的可视化与依赖项治理至关重要。
• Spring4Shell（2022）：部署拓扑决定了漏洞暴露程度，其中Tomcat 部署WAR文件的情况Tomcat 容易受到攻击。保障安全既需要打补丁，也需要保持架构的规范性。

这些事件表明，推迟现代化进程已不再是一个可行的选择。安全漏洞会迅速蔓延，攻击行动愈发迅猛，而监管机构则期望企业采取主动治理措施。

‍

日益扩大的供应链威胁

现代 Java 的风险已不仅限于运行时本身。

• 新思科技（Synopsys）2024年OSSRA报告：74%的受审计代码库存在高风险漏洞，这一比例较2022年的48%有所上升。
• Sonatype 2024：仅一年内就记录了超过50万个恶意开源软件包，增幅达156%。
• 2025年第二季度：共发现16,279个恶意软件包，其中许多旨在窃取凭证并窃取数据。
• 定向攻击活动：拉撒路组织利用域名拼写错误劫持的软件包，入侵了超过36,000名开发者。

其含义不言而喻。即使是已安装所有补丁的 JVM，也可能因存在漏洞的框架、HTTP 客户端或日志库而遭到入侵。治理必须延伸至依赖链，通过自动生成的软件物料清单（SBOM）、SCA 扫描以及针对拼写劫持和恶意注入的代码库级防御措施来实现。

‍

安全迁移蓝图

在现代化进程中取得成功的企业将迁移视为一项有条不紊的计划：

1. 库存：生成SBOM并映射依赖关系。
2. 整改措施：替换已弃用的 API 和不再受支持的模块。
3. 测试：验证功能、性能和安全基线。
4. 部署：通过金丝雀发布进行部署，并监控异常情况。
5. 治理：执行补丁服务水平协议（SLA），实现扫描自动化，并淘汰临时运行时变通方案。

当无法立即迁移时，借助商业长期支持以及诸如WAF规则、运行时监控和受限出站策略等补偿性控制措施，组织可以在规划可持续升级的同时保持合规性。

‍

行业案例

• 金融：某家大型银行推迟了从 Java 8 向 Java 11 的迁移，结果在供应商停止支持后被迫启动紧急项目，为此耗资数百万。
• 政府：一家运行 Java 7 的联邦机构在规划分阶段迁移的同时，依靠扩展支持来维持对 FedRAMP 和 NIST 标准的合规性。
• 医疗保健：某医院系统因未打补丁的 Java 应用程序未能通过合规性审计，而遭到 HIPAA 处罚。通过迁移至 Java 17 并结合向后兼容补丁，该问题得以解决。

‍

移民与援助的经济分析

移民的直接成本

每次迁移都会产生巨大的直接成本。必须安排开发人员投入工时来重写代码、更新依赖项以及进行系统测试。通常需要聘请外部顾问，且其收费往往较高，特别是在时间紧迫的情况下进行迁移时。新发行版的许可费用则进一步增加了负担。

‍

隐性成本与机会成本

迁移还会产生隐性成本。对工程师进行新语言功能的再培训、暂停创新项目，以及在分阶段部署期间管理系统停机时间，都会导致生产力下降。这些间接成本通常未被纳入预算，其数额可能与直接成本相当甚至超过直接成本。

‍

长期支持作为一项财务策略

商业级长期支持能带来稳定性。企业无需每四年花费数百万美元进行系统迁移，而是可以将成本分摊到可预测的年度订阅费用中。这种模式对希望稳定预算、避免紧急支出并在不牺牲战略敏捷性的前提下保持合规性的首席财务官（CFO）和首席信息官（CIO）极具吸引力。

‍

监管与合规方面

合规要求

PCI DSS、HIPAA、GDPR 和 FedRAMP 等框架要求及时修复已知的漏洞。不再受支持的 Java 运行时环境违反了这些要求，可能会导致审计发现问题并面临潜在处罚。

‍

SBOM 与供应链法规

美国第14028号行政命令、美国网络安全与基础设施安全局（CISA）的“已知被利用漏洞”目录以及欧盟的《网络弹性法案》均要求提高软件供应链的透明度。软件组件清单（SBOM）现已成为受监管组织必须具备的文件。不受支持的运行时环境会影响对这些规定的合规性。

‍

执法趋势

审计人员要求提供补丁服务水平协议（SLA）、软件物料清单（SBOM）以及整改流程的相关文件。无法提供相关证据的组织将面临审计未通过、声誉受损以及监管处罚的风险。在医疗保健和金融等行业，不合规行为可能导致业务停摆或面临数百万的罚款。

‍

人工智能在Java安全中的作用

人工智能作为攻击工具

威胁行为者利用人工智能扫描依赖关系图、生成漏洞利用概念验证，并实现侦察工作的自动化。国家级的威胁行为者已经将人工智能应用于针对开发者生态系统的攻击行动中。

‍

防御性安全中的人工智能

防御工具利用人工智能加速SCA扫描，识别存在漏洞的传递性依赖关系，并根据被利用的可能性对修复措施进行优先级排序。这有助于提高可视性并缩短响应时间。

‍

以人为本的治理

人工智能无法决定何时进行迁移、何时进行回溯移植，也无法决定如何应用补偿性控制措施。治理仍然是人类的责任，在人工智能提供速度和规模的同时，确保合规性并保持战略一致性。

‍

在 Java 程序中嵌入治理机制

治理必须是一个持续的过程，而不是一次性的举措。

• 将企业路线图与甲骨文的两年期长期支持（LTS）周期保持一致。
• 执行服务水平协议（SLA），确保在数天内修复KEV清单中列出的漏洞。
• 在每次构建和发布时自动生成 SBOM。
• 通过优先使用可执行 JAR 文件而非 WAR 文件来强化部署策略。
• 跟踪并修复临时运行时异常，例如 --add-opens.

将治理机制嵌入 Java 程序本身，既能降低风险敞口，又能增强审计韧性，并确保长期的运行稳定性。

‍

结论

Java 的稳定性既是其最大的优势，也是其最危险的弱点。那些未能按照 LTS 发布周期进行现代化的组织，将面临监管处罚、技术债务以及灾难性的安全漏洞。

‍

未来的发展之路需要在主动的迁移规划、全面的供应链治理以及长期的商业支持之间取得平衡。HeroDevs 认为，企业不应被迫进行不安全或仓促的迁移。通过主动规划和“永不间断的支持”，企业可以确保其 Java 系统保持安全、合规并为未来做好准备。

‍

参考文献

• 新思科技。2024年开源安全与风险分析（OSSRA）会议。
• Sonatype. 《2024年软件供应链现状报告》。
• Sonatype. 2025年第二季度恶意软件包活动报告。
• ITPro. “朝鲜黑客利用开源恶意软件针对开发人员。”2025年。