为什么 Shift Left 的梦想已成为安全和开发者的噩梦

Source: Bleeping Computer

作者：Ivan Milenkovic，Qualys 欧洲、中东和非洲地区风险技术副总裁

介绍

在过去的十年里，我们一直沉浸在关于安全和开发的舒适幻想中。如果我们能够 “shift left” 并让开发者在编码、测试和基础设施部署的同时，承担更多的安全责任，数字世界将会变得更安全、更快速、更廉价。

然而，速度与安全之间的根本冲突却变得更加严重。

为什么会失败？

开发人员承受着巨大的压力。项目管理的经典三角——快速、优质、低价；选其二——已经被打得粉碎。

企业现在要求 快速、优质、低价且安全 的解决方案。关键时刻，“快速” 总是占上风。同时，我们给已经捉襟见肘的开发人员施加了过多的认知负荷。

当他们选择使用公共容器镜像来加速开发时，虽然是为了实现目标，但也让自己面临潜在风险。

那么，我们该如何理解真正的问题并着手解决呢？

业务需求与安全建议

业界普遍流传一种说法，认为开发者懒惰或粗心。这并不真实。
开发者工作负荷沉重，是在既定激励下做出务实选择的专业人士。如果他们的奖金取决于周五前交付功能，而一次安全扫描需要四个小时并且会阻塞构建，他们就会想办法绕过该扫描。

为什么安全被视为障碍

• 速度压力： 企业要求结果越来越快。
• 噪声工具： 产生大量误报或运行缓慢的安全工具会打断工作流。
• 流程割裂： 当安全检查未集成到 CI/CD 流水线时，它们就会成为事后考虑，而不是工程的内在部分。

后果

• 组织失去对实际运行环境的可视性。
• 流水线自动部署代码，基础设施在无人干预下弹性伸缩，AI 代理现在甚至可以自行编写并执行脚本。
• 在这种高速、自动化的混乱中，我们把公共注册表当作精挑细选的库来使用，默认 Docker Hub 上的镜像一定安全。

信任公共注册表是有风险的

Docker、Amazon、Google 和 Microsoft 等公司都运营公共容器注册表，因此自然会假设它们是安全的。这种信任是错误的。

当容器镜像进入部署流水线时，它已经成为一个受信任的制品——被烘焙进应用中——但它仍可能包含漏洞或恶意代码。

要点： 为了弥合业务速度与安全之间的鸿沟，我们需要既快速、噪声低，又能紧密集成到开发者工作流中的工具和流程，而不是把安全当作外部的障碍。

34,000 张镜像的现实检验

Qualys 威胁研究部（TRU）最近对从公共仓库中提取的 34,000 多个容器镜像 进行了一次详尽分析，以了解清单背后到底发生了什么。

• **恶意镜像：**约 2,500 个（≈ 7.3 % 的样本）
  • 其中 70 % 包含加密挖矿软件。
• **机密泄露：**42 % 的所有镜像包含 超过五个 可用于访问其他资源或账户的机密信息（例如，直接写入镜像层的 AWS 访问密钥、GitHub API 令牌、数据库凭证等）。

关键要点

1. 错拼域名（Typosquatting）仍是主要威胁——攻击者常利用拼写错误的镜像名称，使其恶意容器被下载。
2. 像“检查拼写”这样的简单建议是必要的，但不足以应对高风险问题；这只是低成本的应对方式。
3. 告诉开发者“要更小心”并不是安全策略。

推荐做法

• 在成熟的环境中 绝不要直接从公共注册表拉取 镜像。
• 通过内部制品库对所有外部镜像进行代理，将其作为隔离区。
• 通过为开发者提供快速、已审查的供应链，同时将繁重工作转移给基础设施团队，来平衡速度与安全。

这种转变意味着基础设施团队的工作量会增加，但回报是开发者能够 更快 工作且 风险更低。

Shift Down

为什么 “向左移动” 仍然不够

• 早期修复漏洞成本更低，但把安全性 提前 到 SDLC 只会把负担转嫁给开发者。

• 现在开发者被期望要：

  1. 扫描自己的代码。
  2. 审核第三方依赖。
  3. 加固配置。
  4. 检测密钥。
  5. 执行合规审计。

• 与此同时，他们的绩效主要以功能交付速度来衡量。

结果如何？安全性成为每个开发者待办事项清单上的另一项，而不是协作性的工作。

“向下移动” 方法

与其把安全性强行嵌入每个 IDE，不如 让安全的基础设施成为默认，让开发者沿着已经审查过的 黄金路径 工作。

如果你走在黄金路径上，安全是自动完成的；如果走偏离路线，则必须自行处理额外的安全步骤。

如何落地

1. 平台工程默认配置

   • Terraform 模块 / Crossplane 组合 / OPA 策略 强制执行必需的设置（例如，S3 桶必须启用版本控制）。
   • 开发者无法创建不合规的资源；平台会拒绝该请求。

2. 自动化扫描与强制执行

   • CI 流水线自动运行容器镜像扫描。
   • 准入控制器在镜像进入集群前阻止不合规的镜像。
   • 开发者只需知道 有漏洞的镜像会被拒绝，而不必了解扫描的内部细节。

3. 自愈修复

   • 当发现基础镜像漏洞时，平台会创建 PR 来升级镜像。
   • 运行时安全工具会自动终止或隔离违规的 pod/节点，而不是仅仅发送警报。

4. 明确的业务信号

   • 从一开始，安全和开发就围绕成本、风险和工作量形成统一阵线。
   • “安全成本”已经内嵌在平台中，而不是事后作为附加考虑。

好处

• 最小阻力路径：安全部署成为最简便的选项。
• 降低认知负荷：开发者专注于功能，而不是安全细节。
• 更快的修复：自动化 PR 和运行时动作消除人工延迟。
• 共享责任：平台工程师和开发者都以业务需求的速度协同工作。

继续 “向左移动” 的风险

• 开发者倦怠 – 在功能工作之上堆叠安全任务。
• 控制绕过 – 团队压力过大时可能会忽视或规避安全防护。
• 事件增多 – 手动步骤易出错且修复更慢。

结论

向下移动 意味着把安全从开发者的 IDE 移到 基础设施层，由专门的 平台工程 团队管理。通过提供安全默认值、自动化强制和自愈机制，我们让安全成为最小阻力的路径，确保业务安全前行。

Sponsored and written by Qualys.