Bitnami到底怎么了?揭开关于你最喜欢的预打包开源软件目录的种种误解

发布: (2025年12月23日 GMT+8 01:38)
9 min read

Source: VMware Blog

Source:

Bitnami 的丰收之年:真实情况

这是 Bitnami 的丰收之年。除了在今年春季 迎来 18 周岁链接),开源目录已经进行了精简,并推出了全新的商业产品。正如预期的那样,这一连串的活动引发了一些混淆,甚至有少数竞争对手试图散布恐惧、不确定性和怀疑。

下面是一份清晰、客观的概述,帮助 Bitnami 的用户和客户了解 唯一的开源目录 以及其相关商业产品的真实情况。

“关于我倒闭的传闻被大大夸大了!” –(向马克·吐温致敬)

现实情况

  • Bitnami 仍然是开源且免费。
    目录仍然公开可用,所有资产的源代码托管在 GitHub 上。

  • 商业供应商仍然依赖 Bitnami 的开源工作。
    许多公司将 Bitnami 的开源镜像和 Helm Chart 打包进自己的解决方案中。

  • 强大的工程遗产。
    在其 18 年的历史中,Bitnami 工程团队已经创建了 110 多个业界领先的 Helm Chart

  • 所有源代码仍然可访问。

    • 基于 Debian 的 容器镜像
    • Helm Chart
  • 你仍然可以从公开的源代码自行构建镜像和 Chart

保持信息灵通,保持信心,继续使用 Bitnami 构建。

Source:

Bitnami 的 Docker Hub 注册表仍然可用

  • 全新加固镜像 – 我们新增了 40 个此前社区从未提供的加固 OCI 镜像。
  • 降低 CVE 数量 – 过去平均出现 > 100 个 CVE 的社区,现在因这些加固构建而几乎为

有哪些变化?

旧镜像新镜像好处
基于 Debian 的镜像基于 PhotonOS 的镜像• 直接替换
• 与相同的 Helm‑chart 兼容
• 不需要 CI/CD 或 Helm‑chart 的任何更改
有限的安全元数据完整的安全元数据(SBOM、VEX 等)• 可通过公共目录界面查看

可用性

  • 40 个加固镜像 可免费在 Docker Hub 上获取。

    • 注意: 这些镜像会在每次更新时被覆盖,我们仅支持最新的标签。它们适用于开发和测试,但 不建议在没有订阅的情况下用于生产 环境。
  • 企业订阅 – 对于需要超过 40 个镜像的团队,商业 Bitnami 订阅 提供 > 280 个加固应用的访问权限。

结论: 切换到基于 PhotonOS 的镜像即可立即提升安全性——无需更改 Helm chart 或 CI/CD 流水线。

Bitnami的 Helm Charts 无可匹敌

Bitnami 多年来一直致力于编写第一方 Helm Charts,已成为该领域的领军者。因此,“替代” Bitnami Charts 的快速出现令人怀疑——这些所谓的替代品实际上就是 Bitnami 的 Charts。要从零构建超过 110 个 Helm Charts,并在设计时遵循安全原则、在多个 Kubernetes 发行版上进行持续测试,需要大量的时间和专业知识。

多年来,Bitnami 收到了无数 GitHub issue 和 pull request,这些贡献不断改进 Charts,使其形成了今天的模样。这也是为什么一些厂商不得不承认他们 “soft‑forked” 了 Bitnami 的工作(参见Chainguard 公告)。如果 Bitnami 的 Charts 不是免费提供的,这种复制根本不可能。

真正的误区在于其他厂商能够提供与 Bitnami 同等的生产级支持。实际上,Bitnami 长期坚持的质量、安全和社区合作,使其 Helm Charts 具备了独特的可靠性。

Source:

并非所有补丁都相同

Bitnami 自动化能力的威力在于能够快速发布补丁——通常在修复可用后仅数小时内完成。

示例

Bitnami 对 Python CVE 的响应(2025 年夏季) 展示了这种速度。当 Bitnami 检测到上游新版本时,它会自动:

  1. 触发构建和验证流水线。
  2. 更新 Helm chart、容器镜像以及所有相关依赖。
  3. 确保一切按预期工作。

由于 Bitnami 从不对上游进行分叉,你获得的是真正由原项目维护者审查的原始构建。

为什么不采用“快速修复”分叉?

有些团队在官方补丁发布前就会发布修改过的代码(例如替换 JAR 文件)。虽然看起来更快,但会牺牲:

  • 质量 – 代码未经过上游的正常审查流程。
  • 持久性 – 将来的更新可能会破坏自定义的改动。
  • 安全性 – 绕过了同行评审和既定的开源控制。

在规定的上游路径之外进行补丁会产生分叉,违背了开源开发的最佳实践。

Bitnami 的做法

  • 从源码构建,使用官方发布的版本,确保依赖保持不变并维持操作的一致性。
  • VEX 评估数据,针对尚未在上游解决的 CVE。该数据说明漏洞如何影响应用,帮助客户快速评估风险概况。参见VEX 评估文档

综合 SBOM

Bitnami 自动直接获取应用的源代码——包括源代码 URL、版本和许可证信息——这些信息仅通过扫描镜像是无法发现的。这使得 Bitnami 能够更深入、更透明地识别软件中的内容,简化审计、降低风险并提升供应链安全(参见 SLSA 对供应链威胁的定义)。

许多供应商使用扫描工具从镜像生成软件材料清单(SBOM)文档。虽然扫描器可以提供一定程度的可见性,但它们往往无法识别正确的许可证或不属于任何软件包的二进制文件,因为缺乏可依赖的元数据。因此,您无法获得对所摄取软件的全面覆盖。

Bitnami 的做法:

  • 在流水线的最初构建步骤就生成 SBOM。
  • 直接从源代码捕获源代码 URL、版本和许可证信息。
  • 提供所有组件的完整、准确可见性,包括那些没有软件包元数据的组件。

Bitnami的持久企业吸引力

对于在开源上开展业务的组织,Bitnami 提供最高水平的透明度,使其能够快速响应安全漏洞和漏洞。Bitnami 继续开创企业使用开源的方式,快速发布 CVE 修补程序——有时在发现后数小时内即可完成。

我们的透明方法确保组织能够在充分了解选项及每个决策影响的前提下采取行动。

Back to Blog

相关文章

阅读更多 »