保障 DevOps 安全的挑战与机遇

关键要点

1. DevOps 团队整合软件开发、部署与运营流程，但基础设施的复杂性也增加了安全风险。
2. 平均组织使用 4 至 9 种编程语言，每年处理数百万个新包和镜像。
3. 安全事件频繁发生，尤其与 Kubernetes 和容器安全相关。
4. 需要更全面的视角来监控开发和部署中的所有环节。
5. 企业在云原生应用迁移时，往往忽视了安全隐患。

在 DevOps团队将软件开发、部署与运营流程结合的过程中，提升了效率、简化了更新流程，并提高了应用程序的质量。然而，基础设施的复杂性同样导致了一个日益扩大的攻击面，这使得监控和维护变得困难。

根据 ，在开发方面，平均组织使用四到九种不同的编程语言，每年需要处理数百万个新包和镜像，并修复数千个常见开源组件中的漏洞。而根据 ，三分之二的公司由于 Kubernetes安全问题延迟了应用程序的部署，近一半（46%）的公司实际发生过安全事件。

为了确保应用程序管道的安全，网络安全专业人士必须关注开发人员编写的软件、开发者引入的开源组件、用于部署软件的容器和云基础设施，以及用于构建软件的工具，ContrastSecurity 的首席技术官兼联合创始人 Jeff Williams 说道。

“问题在于这是一个庞大的攻击面，”他说。“这不仅仅是你的管道，还有其他用于开发软件的代码——包括集成开发环境（IDE）、测试工具和性能套件……这些都可能破坏你开发者构建和生产的代码。”

获得整个 DevOps 管道从开发到应用程序部署的综合视图变得越来越重要。软件组件——不仅是开源库，还有 和 ——经常含有脆弱代码，增加了风险。第三方工具可能会被攻击——例如，考虑到 ，恶意代码可以被注入到开发中的项目中。云基础设施和存储可能配置不当或保护不力，例如 。

努力保护四个关键领域

Josh Lemos，DevOps 提供商 GitLab 的首席信息安全官（与本文作者无关），表示，良好的 DevOps软件管道和部署基础设施的可见性至关重要。

“有两个重要的部分需要同步进行，”他说。“一个是你需要在其中一个流程中确保开发、打包的安全，合规性和所有构建工件的验证。另一个是对这些内容在生产环境中的监控和编排。”

总体来说，DevOps 安全团队需要保护四个开放的攻击区域。前两个区域对开发人员来说是最明显的：他们编写的代码和使用的软件组件，ContrastSecurity 的 Williams 指出。

“我们从 OWASP 的早期开始就关注这些代码……如果你写的代码存在漏洞，别人会利用这些漏洞，导致安全 breaches，这可不妙。”

公司还需要关注他们购买或通过服务间接使用的代码。最后，他们需要对用于构建和部署软件的应用程序和服务进行保护——即 IDE、测试工具、性能套件和仪器。

“其中任何一个都有能力颠覆最终代码，”Williams 说，并补充大多数 DevOps 团队并没有关注他们管道和软件供应链带来的全面攻击面。“在真正的供应链安全方面，我认为我们仍处于石器时代。”

尽管绝大多数公司（87%）正在构建或迁移应用程序到云原生，但大多数（59%）并未理解这样做的安全隐患，因此遭受了安全问题。根据一项 ，常见的安全事件来自网络入侵、API 漏洞、证书配置错误、集群配置错误和容器漏洞。

即使是那些监控其 DevOps 管道部分的公司，覆盖范围也有限，Williams 说。

“它并不是无处不在，几乎没有任何东西覆盖 DevOps 的一部分，比如开发工作站、IDE、测试框架和插件。”他说。“我指的是，那里有一个没人监控的代码宇宙，而大多数组织并没有真正关注这个问题。”

关注 DevOps 基础设施

对于大多数公司来说，确保他们对整个管道的可见性至关重要。监控可以在未受信任的一方突然在代码库中复活已退役的包时发出警报，或者在代码中包含可能会被推送到代码库的机密信息时发出警报，或当 Docker 镜像中包含大量未使用的软件时发出警报。

根据软件供应链提供商 JFrog 的现场 CISO Paul Davis 的说法，公司需要对管道中的每一步进行持续监控。

“知道发生了什么……看到一个包在生产中出问题，或者需要回滚一个包，因为有人因为新的漏洞而提出了问题——这样的易用性和可见性进入攻防面，这种洞察和可追溯性，对我来说是至关重要的。”他说。

根据 GitLab 的 Lemos 的说法，公司还应在 DevOps基础设施的四个特定领域采取行动。首先，应记录参与管道的任何开发人员、运维专家、设备或服务的身份。公司还应维护一个软件工件列表，包括它们使用的和可能存在漏洞的工件，并在可能的情况下维护一个私有库。构建系统应经常测试，任何自动触发——如第三方软件的更改触发构建——应分析潜在的安全隐患。最后，应为整个管道的架构设计确保尽量减少妥协时的影响——“爆炸半径”。

“我见过的公司作为第一步所做的最好的事情，就是采用一些已知的良好设计模式，”Lemos 说。“你能从不良安全实践中抽象出越多，安全计划就越成功，你的代码将变得更易于重用，负担和混乱会减少。”

AI 的承诺与风险

DevOps 的攻击面广度同时也为自动化和 AI一体化提供了机会。由于通过自动化获得操作的敏捷性和速度，配置和基础设施即代码的使用日益普遍，因为将架构表达为文件允许运营的重复性，而分析指令也能提高基础设施的安全性。

然而，当谈到安全问题时，大多数公司对采用这些技术持谨慎态度，Kubernetes 自动化平台 Cast AI 的首席产品官 Laurent Gil 说道。

“几乎每个安全公司以某种形式都提供自动化，然而几乎没有人使用它。”他说。“安全团队应当知道，使用自动化来阻止应阻止的事情，或在发现包含漏洞的内容时进行自动修复是可以的。”

AI 开发也带来了处理代码和数据的新方式——一个尚未完全被理解的攻击面，DevOps 团队对此还没有准备，GitLab 的 Lemos 表示。

“确实存在结合数据和内容形成模型的老旧攻击方式的可能性。”他说。“如果模型中含有 pickle 文件，该文件被引入数据科学家的工作站，如果他们对其进行反序列化并包含恶意代码，他们就将一些恶意代码引入了他们的环境。”

通过采取必要的措施，企业可以在确保安全的同时提高 DevOps 流程的效率，从而在不断变化的数字环境中保持竞争力。