协作让我们更强大
内容提要
Databricks通过漏洞赏金计划，与研究员Mehmet合作修复了PostGIS扩展address_standardizer的内存安全漏洞。该漏洞可被普通租户利用，影响Lakebase和Neon平台。团队快速部署补丁保护客户，并推动上游修复，研究员将赏金捐给PostGIS项目。文章强调开源组件安全需平台方主动负责。
延伸解读
开源组件的责任边界
文章强调，托管服务商对开源组件的安全负有直接责任。即使漏洞源于上游PostGIS，但Databricks将其视为自身问题，主动修复并保护客户。这提醒其他平台，不能以“第三方代码”为由推卸责任，而应建立快速响应机制，确保用户安全。
漏洞赏金计划的价值
此次漏洞发现得益于Databricks的漏洞赏金计划。研究员Mehmet在测试中触发警报，被安全团队主动联系，最终促成修复。这展示了赏金计划不仅是发现漏洞的渠道，更是建立信任、促进协作的平台。对于安全团队，主动联系研究人员并快速响应，能有效提升安全防护。
上游修复的挑战
文章指出，上游修复可能不完整，且不一定分配CVE。Mehmet发现PostGIS的修复未覆盖所有情况，并提交了补充修复。这提醒依赖开源组件的企业，不能完全依赖上游更新，需自行验证和加固，同时积极回馈社区，确保修复完整。
Q&A
Databricks 是如何发现并处理 PostGIS 扩展中的内存安全漏洞的？
Databricks 通过其漏洞赏金计划，由外部研究员 Mehmet Ince 发现了一个在 PostGIS 的 address_standardizer 扩展中的内存安全漏洞。Databricks 的安全团队在收到报告后迅速验证并确认漏洞可被普通租户利用，随后立即部署补丁保护客户，并与研究员合作将修复推送到上游 PostGIS 项目。
这个漏洞具体是什么？它有什么潜在影响？
漏洞位于 PostGIS 的 address_standardizer 扩展中，是一个经典的内存安全缺陷：调用者可控的值被用作固定大小内部数组的索引，且没有边界检查，导致越界内存访问。由于该扩展是普通租户可安装和使用的，因此普通用户角色也能触发该漏洞，可能造成权限提升等安全风险。
Databricks 为什么认为开源组件中的漏洞也是自己的责任？
Databricks 认为，虽然漏洞的根因在上游 PostGIS，但因为他们将扩展默认提供给租户使用，所以暴露风险由他们承担。他们强调“你提供的开源组件中的漏洞仍然是你的问题”，因此主动接受报告、驱动响应，并奖励了研究员。
Databricks 如何在不等待上游修复的情况下保护客户？
Databricks 的扩展构建系统允许他们在编译和打包前对上游扩展应用任意补丁，包括回移修复或禁用风险代码路径。因此，他们可以独立于上游发布周期，快速部署补丁保护客户，同时并行推动上游修复。
研究员 Mehmet Ince 是如何处理他获得的赏金的？
Mehmet Ince 将获得的赏金捐赠给了 PostGIS 项目，并自掏腰包匹配了同等金额，以支持维护该开源项目的志愿者工作。
这个漏洞最终是如何在上游修复的？
最初上游发布了一个小修复，但并未覆盖所有情况。Mehmet Ince 验证了修复的不足，并提交了剩余的修复代码，从而为整个社区关闭了漏洞。整个过程中没有分配 CVE，这提醒人们重要的内存安全修复可能被当作“小清理”而忽略。
从这次事件中，Databricks 总结了哪些经验教训？
Databricks 总结的经验包括：开源组件的漏洞是平台方的责任；需要快速响应并保护客户；与研究员合作推动上游修复；以及提醒其他运营托管服务的公司，攻击面包括他们未编写的代码，需要主动负责。
