勒索软件命名与供应链安全

概述

在开源和云原生生态中，知名的工具和项目名称往往具有很高的辨识度。然而，这种声誉也可能被恶意行为者利用，例如，一个勒索软件组织近期开始使用“Prometheus”和“Thanos”作为其恶意软件家族的名称。此类行为虽然不直接影响现有软件，但提醒我们软件供应链安全是 Site Reliability Engineering (SRE) 确保系统可靠性和安全性的基石。本页面旨在总结从该事件中提炼的SRE最佳实践。

核心概念

供应链攻击

供应链攻击是一种针对软件开发、分发和部署流程的安全威胁。攻击者并非直接攻击目标系统，而是渗透到上游的依赖库、构建工具、软件仓库或分发渠道，在其中植入恶意代码或篡改软件包。当用户从受污染的源头下载并部署这些软件时，就会在无意识中引入风险。

软件供应链安全

这是SRE和DevSecOps领域的一个核心实践，旨在确保从代码编写、构建、存储到最终部署的软件交付流水线的完整性和真实性。它包括验证软件来源、校验软件完整性以及维护一个可信赖的软件依赖关系。software-supply-chain-security

实践

为了应对品牌冒用和潜在的供应链风险，SRE团队必须建立并执行严格的软件获取与验证流程。以下是在部署第三方软件（如 Prometheus 和 Thanos）时应遵循的实践路径，按优先级排序：

从官方源获取并校验：始终从项目官方发布的页面下载二进制文件，并严格验证提供的校验和（如 SHA256）。这是最基础也最关键的一步。
- Prometheus 官方发布页：https://github.com/prometheus/prometheus/releases
- Thanos 官方发布页：https://github.com/thanos-io/thanos/releases
使用官方容器镜像：从项目方控制的官方容器镜像仓库拉取镜像。
- Prometheus: quay.io/repository/prometheus/prometheus 或 docker.io/prom/prometheus
- Thanos: quay.io/repository/thanos/thanos 或 docker.io/thanosio/thanos
通过可信的分发渠道：使用操作系统发行版的官方软件源（如通过 apt、yum 安装）或公司内部经过安全审核的镜像仓库。
依赖内部构建与验证：在企业内部，由专门的构建与验证团队（如通过 GitOps 流水线）统一构建、扫描、签名并分发软件制品。SRE团队应消费这些内部可信制品。
从源代码自行构建：对于安全要求极高的环境，可以从官方源代码仓库获取代码，并按照官方文档进行构建，以完全控制构建环境。

核心原则是：除非你能合理信任软件的具体来源和整个供应链，否则不应使用该软件。

SRE 要点

与可靠性、可观测性、事件响应的关联

可靠性：供应链安全直接关系到生产环境的稳定。引入被篡改或恶意的软件组件可能导致数据泄露、服务中断或被勒索。
可观测性：监控流水线本身（如使用 prometheus 监控构建系统）和运行时软件行为（如异常网络连接、高资源占用）是检测潜在供应链攻击的重要手段。
事件响应：当发生安全事件时（如发现使用了被标记为恶意的软件组件），清晰的软件物料清单（SBOM）和部署记录能极大加速 incident-response 过程，帮助快速定位受影响的范围和组件。

最佳实践与常见反模式

最佳实践：
- 自动化验证：将软件包的校验和验证、镜像签名（如 Cosign）集成到自动化部署流水线中。
- 实施最小权限：只安装和运行必要的组件，减少攻击面。
- 定期审计依赖：使用工具定期扫描生产环境中的软件依赖，识别已知漏洞或可疑来源。
- 建立内部知识库：记录经过验证的软件来源和版本，作为团队的标准配置参考。
常见反模式：
- 信任不明来源：从非官方渠道（如个人博客、搜索引擎推荐的第三方站点）下载软件。
- 忽略更新：因担心兼容性而长期不更新已知存在漏洞的软件版本。
- 缺乏验证：在部署前不验证软件包的完整性或签名。