Introducing a Security Support Policy for the Kotlin Standard Library

由 JetBrains 开发的简洁多平台语言

新闻

为 Kotlin 标准库引入安全支持政策

2026 年 5 月 21 日

Kotlin 用户群体中的升级节奏差异很大。一些团队会在新版本发布时毫不犹豫地立即更新。另一方面，受监管组织内部的团队则按季度周期运作，将每个依赖项都视为需要审查、批准并在生产环境中冻结一段时间的东西。

在所有这些用户群体中，Kotlin 在 JVM 上的应用持续增长。如今约有一半的 Kotlin 开发人员编写服务端应用程序，包括支付基础设施和银行业等领域，其中一些团队已在生产环境中运行 Kotlin 数年。这些领域的大部分团队工作在这样的环境中：每个生产依赖项都要经过正式的安全审查。

在这样的环境中，平台团队面临一个看似简单的问题：_"哪些 Kotlin 版本受到支持？"_ 直到今天，我们都没有一个明确的答案。本文将介绍一个答案。

**不断增长的应用意味着更强的兼容性和安全性保证**

随着越来越多的代码依赖于 Kotlin，这门语言变得更有用——同时也更加受限。在其基础上构建的人们期望昨天编写的内容明天仍能正常工作，变化将是可预测的，并且 Kotlin 团队会将兼容性视为有意的选择而非事后的考虑。

Kotlin 的某些方面已经以这种方式运作。源码级语言稳定性意味着今天编写的代码在新版本中仍能继续编译。有文档记录的弃用周期取代了静默的破坏性变更，因此我们移除的任何内容都会被公告，开发人员有时间进行适应。语言委员会是批准语言重大变更的正式机构。标准库在不同版本间为其公共 API 承担自己的向后兼容性合同。

随着 Kotlin 成为大型代码库的重要组成部分，这些承诺自然而然地发展起来。当明确我们需要向用户提供该保证时，每一项都会被添加进来。

但列表中一直缺少一个关键要素，即对问题 "_Kotlin 版本的安全修复支持多长时间？_" 的回答。对于大多数团队来说，这个差距是不可见的。但有些组织的依赖审查依赖于这个问题的答案——对他们而言，这个差距就是一切。

**缺乏支持政策为何是个问题**

Kotlin 的发布模型建立在稳定发布节奏的基础上。最新的稳定版本，无论是语言还是工具发布，都是推荐的基线。错误修复和语言开发向前流向下一个版本，而不是通过补丁向后传递。对大多数团队来说，这完美地运作着——升级很简单，几乎不需要将"支持"作为一个独立概念来考虑。

对于需要有文档记录的支持信号的组织，后果是具体的：

• 合规团队无法在其标准流程中将 Kotlin 列为受支持的依赖项，因为没有正式的支持终止日期可供记录。
• 生产环境中的每个新 Kotlin 版本都会触发单独的安全审查，而不是继承有文档记录的支持状态。
• 采购和供应商评估框架要求供应商提供不存在于此形式的文档。
• 在平台冻结事件中，缺乏政策意味着"立即升级或失去支持"。这种方法不适合这类组织实际管理依赖的方式。

Kotlin 的用户群持续增长，这种增长包括那些缺乏文档化答案会带来实际成本的环境。解决这一缺失是下一步。

**为 Kotlin 引入安全支持政策**

• 每个 Kotlin 发布系列（例如 2.4.x）从其 .0 版本发布日期起，将获得 18 个月的安全修复支持。
• 安全修复将反向移植到所有处于活跃支持窗口内的发布系列，并作为每个系列的最新补丁发布。
• 范围：JVM kotlin-stdlib 运行时构件。

_为什么特别关注 JVM 标准库？_ 该政策主要解决的是在 JVM 上生产环境中运行的代码——每个 JVM Kotlin 应用程序链接并部署到其服务器的运行时组件。这是合规和安全审查流程在评估依赖新鲜度时关注的层面，也是文档化支持真正能够解锁决策的地方。编译时工具——编译器、Gradle 和 Maven 插件——位于构建基础设施中，不在生产运行时中，因此采用不同的管理模式。该政策精准针对需要支持的地方。

_补丁如何发布。_ 当发现并修复安全问题时，修复首先会添加到基于最新 Kotlin 发布线的版本中，然后向后移植到所有其他仍在支持的发布线。补丁以每个受影响发布线中的下一个补丁版本形式发布——例如，如果 2.4.20 是 2.4 发布线中的当前稳定版本，那么下一个补丁版本就是 2.4.21。每个发布线都保持自己的版本编号，因此已经为生产环境验证过 2.4 的团队可以继续使用 2.4 来接收修复，而无需跨越到新的发布线。

_发布同步进行。_ 每个安全补丁都是一个完整的 Kotlin 版本——它会通过标准发布流程，并发布完整的构件集。你在构建中更新一个 Kotlin 版本即可获得已修补的标准库。所有受影响的支持版本线的补丁会同时发布。

_CVE 和安全公告。_ 安全问题在适用的情况下会被分配 CVE 标识符，并通过 JetBrains 安全公告流程发布在 JetBrains 已修复安全问题页面上。

该政策适用于从发布开始的所有 Kotlin 版本线（2.4 及以后）。早期版本线仍采用之前的模式，不会追溯覆盖。

受支持的发布线当前列表、它们的支持结束日期以及每条线的最新补丁版本维护在一个专门的 kotlinlang.org 支持页面 上。该页面是当前受支持版本的权威参考。

**发布线如何演进**

如果你观察一条发布线从首次发布（.0）到支持结束的演进过程，该政策更容易理解。以下是 2.4 的示例（时间线近似；确切日期对这个示例并不重要）。

1. 2.4.0 发布。2.4 线进入其 18 个月的安全支持窗口。
2. 发布后不久收到一个安全报告。安全修复被添加到发布线并作为 2.4.10 发布。（注意：x.x.10 位置遵循了 Kotlin 在 x.x.0 上首次错误修复的既定约定。）
3. 几个月后，2.4.20 作为 2.4 线中的下一个常规版本发布。它包含了所有之前的安全修复。
4. 2.4.20 之后出现一个新的安全报告。安全修复作为 2.4.21 发布。2.4 线中的最新补丁现在是 2.4.21——这是受支持团队应该使用的版本。
5. 2.5.0 发布，开启自己的 18 个月窗口。2.4 线仍在支持中；两条线现在都会接收安全向后移植。
6. 2.6.0 发布，开启 2.6 线。此时，2.5 已经有了自己的常规周期并处于 2.5.20；2.4 仍在 2.4.21 支持中。报告并确认了一个新的安全问题。修复作为 2.6.10 添加到最新的稳定版本中，并同时向后移植到仍在支持的 2.5 和 2.4 线作为 2.5.21 和 2.4.22——三个版本在同一天发布。
7. 2.4 线在 2.4.0 之后 18 个月达到支持结束。该线的安全修复停止。

两个实用要点：首先，你可以留在为生产环境验证过的发布线并仍然接收安全修复——你不需要跳过版本。其次，当修复发布时，它会在所有受支持的版本线上同时可用。不存在"最新版本线已修复，你的旧版本线最终会得到修复"的时间差。

**什么没有改变**

• Kotlin 的发布流程保持不变。错误修复、语言和库功能以及性能改进仍以与以往相同的方式在新版本中发布。较旧但仍受支持的版本线仅接收安全向后移植。
• 每个新的 Kotlin 版本仍然是新项目的推荐基线。安全支持窗口适用于因合规原因需要停留在特定次要版本线的组织——我们仍然不建议延迟升级。

**常见问题解答及后续步骤**

问：根据此政策，什么是安全修复？ 答：具有确认安全影响的问题——由 CVE 跟踪的漏洞类型，其中 API 的文档化和正确使用导致安全影响。应用程序级误用和由于将未经验证的用户输入传递给 stdlib API 导致的问题不在覆盖范围内。

问：我需要升级才能获得安全修复吗？ 答：仅限在您的发布线内。修复以该线中的下一个补丁形式发布——例如，2.4.20 → 2.4.21。您无需跳转到更新的版本来接收它。

问：我在哪里可以看到当前受支持的版本线？ 答：kotlinlang.org 上的专用支持页面。您可以在下面找到链接。

问：我的团队使用依赖于不同标准库版本的库。这有关系吗？ 答：是的。依赖解析后类路径上只会有一个 kotlin-stdlib 版本，具体是哪个版本取决于您的构建工具。Gradle 的默认解析会选择所有直接和传递依赖中请求的最高版本——所以如果传递依赖引入了更新的标准库，那么运行的是那个更新的版本，而不是您在构建中设置的已修补版本。Maven 默认使用"最近获胜"。无论哪种情况，都应明确固定解析的标准库（通过 BOM、版本约束或严格版本规则），以确保运行的是您想要的已修补版本。

• * *

_后续步骤：_

• 支持页面（当前受支持的版本线、支持结束日期、最新补丁）：kotl.in/stdlib-security
• 安全政策：kotlinlang.org/docs/security.html

[](https://blog.jetbrains.com/kotlin/2026/05/security-support-policy-for-the-kotlin-standard-library/#)

1. 日益增长的采用率意味着更强的兼容性和安全保证
2. 缺乏支持政策为何是个问题
3. 为 Kotlin 引入安全支持政策
4. 发布线路如何演进
5. 哪些内容不会改变
6. 常见问题解答及后续步骤

了解更多