Kotlin官方宣布标准库安全支持政策

Kotlin 用户群体的升级节奏差异很大。有些团队在新版本发布后从不犹豫，立即更新。而另一些团队，比如受监管组织内部的团队，则遵循多季度升级周期，将每个依赖项视为需要经过审核、批准并冻结在生产环境一段时间才能使用。

在这些不同受众中，Kotlin 在 JVM 上的采用率持续增长。如今约有半数 Kotlin 开发者编写服务端应用，涵盖支付基础设施和银行业务等领域，其中一些团队已在生产环境中运行 Kotlin 多年。在这些领域的大量团队中，每个生产依赖项都需要经过正式的安全审查。

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

日益增长的采用率意味着更强的兼容性和安全保障

随着越来越多代码依赖 Kotlin，这门语言变得更有用——也受到更多约束。基于 Kotlin 构建的人们期望昨天写的代码明天仍能正常工作，变更可预测，并且 Kotlin 团队将兼容性视为有意为之的选择，而非事后补丁。

Kotlin 在某些方面已经实现了这一点。源代码级别的语言稳定性意味着今天编写的代码能在新版本上继续编译。有文档记录的弃用周期取代了静默破坏性变更，因此我们移除的任何内容都会提前公告，并给开发者留出时间适应。语言委员会是负责批准语言重大变更的正式机构。标准库也为其跨版本的公共 API 提供了向后兼容性合约。

这些承诺自然而然地随着 Kotlin 成为大型代码库的承重部分而不断扩展。每一项都是在清楚我们需要为用户提供这种保障时添加的。

但有一项关键内容一直缺失，即对“Kotlin 版本的安全修复支持周期有多长？”这一问题的回答。对于大多数团队，这个缺口并不明显。但有些组织在依赖项审核时必须依赖此答案——对他们而言，这个缺口几乎决定一切。

缺乏支持政策为何会成问题

Kotlin 的发布模型基于稳定的发布节奏。最新稳定版本（无论是语言还是工具链发布）是推荐的基准版本。Bug 修复和语言特性向前流动到下一个版本，而非通过补丁向后回溯。对于大多数团队而言，这完全可行——升级很简单，几乎无需将“支持”作为独立概念来考虑。

但对于那些需要明确支持信号的组织而言，后果是实实在在的：

合规团队无法将 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 为例说明（时间线为近似值；具体日期对本例不重要）。

2.4.0 发布。2.4 发布线进入其 18 个月的安全支持窗口。
发布后不久收到一份安全报告。安全修复被添加到该发布线，并以 2.4.10 的形式发布。（注意：x.x.10 号段沿用 Kotlin 在 x.x.0 上首次错误修复的既定惯例。）
数月后，2.4.20 作为 2.4 发布线的下一个常规版本发布。它包含所有先前的安全修复。
在 2.4.20 之后收到新的安全报告。安全修复以 2.4.21 的形式发布。2.4 发布线的最新补丁现在为 2.4.21——受支持团队应使用的版本。
2.5.0 发布，开启其自身的 18 个月窗口。2.4 发布线仍处于支持中；两条发布线现在均接收安全回溯。
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——三个版本在同一天发布。
2.4 发布线在 2.4.0 发布 18 个月后达到支持终止。该发布线停止接收安全修复。

两个实际要点：首先，您可以停留在已经鉴定用于生产环境的发布线上，并仍然接收安全修复——您无需跳转版本。其次，当修复发布时，所有受支持的发布线会同时获得更新。不存在“最新线已打补丁而您的旧线最终会得到修复”的滞后。

哪些方面没有变化

Kotlin 的发布流程保持不变。Bug 修复、语言和库特性以及性能改进仍然像往常一样通过新版本发布。较早的仍在支持中的发布线仅接收安全回溯。
每个新的 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