过去几年以来，DevSecOps已经成为DevOps生态当中的一波热潮，它结合了DevOps的效率优势，同时提高软件安全性。但当我们静心下来实际推行DevSecOps时，情况往往变得颇为棘手。DevSecOps并不能”一键启动“，它的落地需要一系列工具与实践的协同支持。

　　下面，我们来聊聊DevSecOps实现过程中必须考虑的主要因素，了解其中到底存在哪些障碍。

　　DevSecOps是什么?

　　从本质上讲，DevSecOps就是在根源上内置有安全因素的DevOps。这要求我们将安全性融入需求、设计、编码与部署阶段——换句话说，纳入整个DevOps管道。

　　旧有安全实践往往会拖慢开发团队的行动速度。而面对产品上市周期每年都在缩短的现实要求，软件开发团队必须找到一种新方法以加快自己的软件开发速度，同时又不对安全性造成影响。DevSecOps的意义也在于此。

　　DevSecOps的终极目标是在安全团队与开发人员之间架起桥梁，保证既快速、又安全地完成代码交付。以往的孤岛思维，也将由此被替代为在不同团队之间实现应用安全责任分摊。

　　DevSecOps实践与工具

　　那我们要如何把这些目标转化为实践？我们可以对哪些特定安全环节进行自动化，再将其集成至CI/CD管道当中？让我们结合DevSecOps工具与实践的现实情况，共同为这些问题找寻答案。

　　第一，漏洞扫描

　　扫描代码内的漏洞无疑是保护产品的第一步。而将漏洞扫描机制集成到CI/CD流程中，自然成为实现DevSecOps的绝佳起点。这意味着我们需要保证在交付管道中从代码编写到生产部署的各个主要阶段，全面检查代码中是否存在漏洞。大家需要保证负责管道各个环节的不同团队都拥有检测代码漏洞所需要的专业知识及技术工具。

　　这类技术工具主要包括检测专有代码内漏洞的SAST工具，以及检测包含已知漏洞的开源组件的SCA工具。不少SAST与SCA供应商也都提供面向CI服务器、构建工具、存储库以及IDE的集成方案，能够帮助开发人员更快发现问题。

　　第二，运行时保护

　　安全流程中的另一大关键在于运行时保护，同样需要以DevSecOps策略的形式被集成至CI/CD管道当中。

　　运行时保护的本质，在于保护软件免受应用程序开始运行之后可能遭遇的威胁影响。尽管在传统上，关于运行时安全性的讨论主要集中在软件生产流程，但事实证明交付管道中的早期阶段同样可能存在运行时威胁因素。即使并不存在，我们也同样有必要及早考虑到这一安全问题，从源头抓起减轻运行时威胁。出于这两大基本原因，我们才应该将运行时安全纳入CI/CD管道，而不再仅限于生产环境。

　　用于运行时检测的特定工具与策略，具体取决于企业的当前业务需求。但大家至少要保证能够监控当前应用程序中是否存在可能与违规相关的异常行为。更重要的是，企业需要了解哪些环境变量或配置设定可能会在运行时内产生安全漏洞，并制定出相应流程及时识别出此类风险。

　　第三，云服务供应商

　　向应用程序交付流程中引入安全集成的另一大重要策略，在于充分利用云服务供应商提供的安全功能。其中不少工具位于DevOps链的部署及部署后端，因此更多类似于传统意义上的事后安全服务。但其仍然能够在应用程序的外部防御体系中发挥重要作用——而且由于其属于云基础设施的固有组成部分，因此更易于实现自动化与系统化。

　　请注意，云服务供应商可能会默认禁用某些安全功能，或者需要进行相应配置才能起效，因此大家可能需要主动操作才能享受由此带来的便利。

　　第四，标准与政策

　　安全标准与政策的制定在很大程度上仍然只能以手动方式完成。企业可以自动扫描源代码及基础设施中的漏洞，但在决定安全优先级以及具体实施方式时还是少不了人类知识的加持。同样的，我们在设计及代码层级上建立安全标准时同样无法完全依赖自动化技术。

　　欧盟推行的《通用数据保护条例》（GDPR）也开始明确要求在设计层面制定并实施安全标准。

　　另一方面，使用RBAC等编排工具/服务网格功能建立起的细粒度策略，则能够在运营层面上实现一定程度的标准自动化。而且与应用程序源代码内的安全标准设计类似，我们也有必要将基于角色的访问策略设计全面推广，并将其视为一项高优先级任务。

　　第五，容器与服务管理

　　在部署基于容器的大型应用程序时，以Kubernetes为代表的容器编排工具已经成为不可或缺的元素。服务网格能够与编排工具协同工作，并管理服务发现、访问活动等常见行为，同时快速厘清用户、基于容器的应用程序以及各外部服务之间的关系，帮助我们清晰明确地认识当前运营体系的总体情况。

　　而此类工具已经成为DevSecOps中的关键元素，它们能够充分容器与外部世界之间的高可扩展性隔离层（借此保证用户或者潜在攻击者只能访问隐藏在代理之后的服务，却无法触及任何单一容器），并借此实现身份验证、授权及加密等功能。更重要的是，这些工具在设计之初就充分考虑到了自动化需求，因此更易于匹配现代开发及运营环境。

　　但与云服务供应商提供的安全工具相比，编排工具及服务网格要求我们对其中的安全功能进行深入研究，并在必要时主动配置并加以启用。例如，Kubernetes中基于角色的访问配置（RBAC）虽然已经成为DevSecOps领域的一大重要元素，但默认情况下并未直接启用。

　　小结

　　要实现DevSecOps，大家必须对现有IT资源及DevOps流程开展全面评估，而后建立起整体战略以确保将高水平安全机制集成至流程之内。除了前文提到的内容之外，DevSecOps还包含众多其他应被纳入实施策略的重要元素，例如监控、日志分析与警报等。但其中不少已经成为软件及互联网安全领域的标准元素，因此本文不再另作赘述。

　　当安全性与CI/CD管道实现全面集成时，DevOps也将与DevSecOps彼此相融，共同成为“次世代软件开发”的新范式、新标准。
 

（至顶网）