许多组织都面临着新的网络安全问题，因为它们希望加快自身和客户的数字化转型。与此同时，信息技术（IT）和运营部门正面临着联合和创新以实现其企业数字化目标的挑战。

通常情况下，公司希望加快速度，安全团队需要保护组织，这会导致摩擦，减缓进展。许多企业以流程、决策和经验的形式提供网络安全的方式并没有以其自身变革的速度、速度和速度发生。

CISO困境

首席信息安全官（CISO）有责任保护其企业。通常，他们通过建立经过战斗考验的策略、标准和服务来实现这一点，这些策略、标准和服务将成为治理模型。这就产生了一种运营模型，这种模型试图在优先考虑风险和安全性的情况下来平衡推向市场的趋势。网络安全团队希望成为创新的推动者，而不是被视为障碍。但是，为了促进转换，除了帮助其他人采用安全意识的文化外，它们本身还必须进行转换。

云计算中的安全软件交付

过去的旧版应用程序看起来与现代的云原生应用程序不同。由虚拟机管理程序管理的裸机或虚拟机已组织成三层应用程序（Web服务器、Web应用程序和数据库），这已成为数十年来的惯例。今天，我们仍然可以在客户中看到这种模式，但是这个据点正在让位于云原生应用程序。

云原生应用程序是商品化和开源争夺解决方案堆栈（包括操作系统（Linux）、云计算、软件定义的网络以及最近的容器）不断发展的结果。甚至接口方法也已经商品化（请考虑应用程序编程接口）。“应用”一词的定义正在不断发展。现在，过去的巨石被分解为一系列微服务，这些微服务由Kubernetes（k8s）进行容器化和管理。

随着体系结构的根本变化和当前应用程序的结构，安全问题也在不断发展：

· 在云原生模型中，威慑，预防，侦探和纠正措施的应用方式有所不同。

· 攻击面是不同的（图像，名称空间和服务帐户在过去的遗产计算模型中不存在）。

· 攻击面的数量更大（微服务固有地比整体服务具有更多的服务间通信）。

· 攻击面是短暂的（从零缩放和动态缩放功能可以暴露在定期扫描和审核之前可能已经消失的漏洞）。

扩展DevOps以包括安全性

在DevOps流行之前，安全团队通常在项目后期参与评审，在应用程序投入生产之前提供指导。安全性只在开发过程的最后才被考虑，如果发现问题就会导致延迟。这导致了更大的补救成本。

DevOps的初衷是在生命周期的早期将两个不同的交付利益相关者聚集在一起：开发和运营。为什么停在那里？

尽早将IT安全作为第三大利益相关者，不仅可以防止生产延迟，还可以改变对安全团队是“无人之队”的看法。它可以将与安全的关系转变为强大的盟友。

显然，在安全性方面，包容性具有积极的影响。这引起了诸如DevSecOps之类的引领潮流的术语，这些术语着重于解决交付过程中的安全性。通过这种方法，安全不仅仅是一种趋势，它还是负责任的企业交付的基础。

安全是软件交付的基础

Andrea C. Crawford和IBM Garage 撰写的Modern DevOps宣言列出了一些适用于端到端安全软件交付的关键概念。第一个主题是“一切皆有代码”，这为在企业内部更深入地实施安全性和安全实践（图像、k8集群配置、应用程序配置甚至管道本身）提供了机会。

编码资产将需要建立为“受信任”资源。好的候选者是在整个企业中共享的那些构造。 一个示例就是将容器映像，应用程序模板，基于角色的访问控制策略和群集配置视为保证其自身治理和管道的“可信”资源，以及管理这些资源的明确定义的角色。较大的企业可能会考虑为新角色（例如图像工程师、集群工程师、管道工程师等）使用徽章和内部认证。

组织可以使用零信任和最小特权原则加强职责分离。定义新角色和角色后，他们应该获得对受信任资源的足够访问权以完成其工作，从而降低风险并限制暴露。取决于行业和区域合规性环境，这可能意味着一个角色的访问权限和职责不同。由于对应用程序堆栈影响太大的风险，受到严格监管的企业可能不允许应用程序开发人员兼任图像工程师。