【DevSecOps系列文章八】安全专业人员需要知道的DevOps术语

翻译：360代码卫士

投稿方式：发送邮件至linwei#360.cn，或登陆网页版在线投稿

传送门：【DevSecOps系列文章七】DevOps和安全：改变文化凝聚开发、安全和运营

在这个软件快速部署成为创新核心的时代，除非采用DevOps的方法，否则安全团队无法与时俱进。

选择目前正在发展的一个IT领域，并将其跟急剧骤升的需求结合起来，得到的结果非DevOps莫属。安全团队越早抓住DevOps方法论越好。安全团队采用DevOps实践并将其嵌入到进程中的方法很多，但有一点是肯定的：即老旧的安全方法和工具从长远来看无法奏效，它们中的一些会进行微小调整，而另外一些需要被完全替换。

我在最近的博客文章中提到了一些关于DevOps应该熟悉的重要安全概念的入门知识。现在我也想为安全人员提供同样的内容。希望有助于你们的组织机构在安全和DevOps的结合过程中迈出第一步，并最终了解确保容器安全有效的同时维护开发环境快速发展的意义。换句话说，践行有效DevSecOps的意义。

1.持续集成 (CI) 

该技术持续地将某团队所有开发人员的源代码更新合并到一条共享主线中，通过尽快整合不同开发人员代码的方式防止出现合并冲突。CI能实时查看软件系统和质量测量的真实状态，所有DevOps团队成员都可立即且不断参与。CI还为安全团队在SDLC中尽早执行安全编码实践和漏洞评估创造了机会。

2.持续交付 (CD)

有很多实践方法能将代码快速推进到QA/测试阶段有时甚至是生产环境中。持续交付意味着将每种变化都传送到生产类型的环境中，这样应用程序和服务就会一直处于部署好的状态。得益于这个可验证的自动化环境，DevOps知道应用程序和服务在需要的时候被秘密交付。一般来讲，内置到CI进程中的同样的自动化安全测试也能被内置到CD进程中。二者的不同之处当然是，CD是一款应用程序进入生产阶段的“最后的边界”，因此应该清楚地定义执行。

3.构建自动化

自动化构建能让DevOps编译源文件、将编译好的文件打包成压缩格式并生成安装程序：所有的这些事情都无需人工参与。当构建步骤是可重复的而且仅涉及存储的源代码时，它就是自动化的。为了能够整合安全服务，控制构建自动化服务的已实现功能必须能防御未经授权的访问和恶意干扰。

4.功能团队

功能团队由来自处理功能开发的所有部门构成；开发人员、QA、生产工程师、以及程序或产品经理。在理想情况下他们在一间大屋子里一起工作或者彼此离得很近，以此来缩短沟通路径并加快信息交换。从概念阶段到运营，每个团队都要完全负责所负责的功能。由某个功能所引发的所有挑战都由团队解决。成为功能团队的一部分对于安全专业人士来说是个确保不会制造下游安全风险的好方法。

5.网站可靠性工程师 (SRE)

SRE团队将软件开发、网络和系统工程专业结合在一起。这些团队通常负责构建和运行大规模分布式软件系统和基础设施。通常来讲，SRE团队是自动化系统开发的一部分，旨在为企业提供必要的规模和速度。由于SRE团队会做出很多影响安全的架构决策，因此这些团队中出现安全是有道理的，否则会面临“事后安全”场景的风险。

6.金丝雀发布

金丝雀发布，也称“金丝雀部署”或“金丝雀发行”，它旨在减少将新软件版本引入生产中的风险。历史上煤矿使用金丝雀来检测毒瓦斯，这个名称本质上是说将新版本发布给一小撮用户，在公布给大众之前让他们评估整个系统。它对于网络应用程序 (SaaS) 来说尤为有用。金丝雀发布是实施持续性交付以快速移动的敏捷开发组织机构的一种最佳实践。安全团队也可使用这种技术在低风险环境中现行监控应用程序，随后再在更广范围发布。

7.螺旋式前进

如在新发布中出现问题，自然的做法是回到前一个没问题的版本，但有时候这种做法是不可能实现的或者不明智的。在“螺旋式前进（译者注：字面意思是：向前失败）”模式中，会在现有的生产系统中设置一个新的生产环境。使用金丝雀进程，流量就会逐渐被发送给新系统。如果存在问题，会推出新环境而原始的环境会保持正常状态。这种“不回头”的方法鼓励团队快速修复问题而非退回到阻挠改进的旧版本。

8.ChatOps

ChatOps即使用自动化聊天“机器人”将运营自动化。这个经配置的聊天机器人能通过由DevOps团队成员发布的自定义脚本和插件执行命令。这些命令包括代码部署、安全事件响应和团队通知。安全专业人士本身会使用聊天机器人转向自动化实践。Demisto公司的产品就是这种聊天机器人的一个例子，它能帮助安全团队以DevOps速度移动。

9.应用程序发布自动化 (ARA)

ARA是从开发到生产过程中包装并部署应用程序的一致、可重复和可审计的进程。当正确行事时，ARA会为应用程序部署去掉构建和维护自定义脚本的需要。它还会减少配置错误和停机次数。从安全角度来讲，ARA可用于执行应用程序安全策略，否则会要求进行手动审查所允许的服务器配置、数据保护等。

10.最小可行产品 (MVP)

它的意思是通过最低投入来创造出目标产品的原型，以判断某个想法是否是好想法。因此，如果需要做出重大改变，那么所消耗的时间和投入会更少。有时候它意味着砍掉一些功能或者高级设置以便集中在核心概念上，或者集中在功能上而不是集中在设计或性能上。MVP允许组织机构在缩减成本减少浪费的情况下快速改进。安全团队可通过MVP来审查新系统以判断结构性安全风险，然而，当MVP被充实起来时，早期的测试结果需要进行重新验证。

是时候从安全转向DevSecOps了

这10个术语只是其中的一部分内容，而在当前快速融合的环境中，安全团队更好地理解DevOps的思想和精神是很重要的。安全并不能被当作“事后想法”或在没有理解如何开发和交付应用程序的情况下就得以应用。也不能用过时的安全工具来部署DevOps。学着用彼此的行话术语来交流是个不错的开始。

原文地址：https://dzone.com/articles/devops-terms-security-pros-need-to-know

传送门：【DevSecOps系列文章七】DevOps和安全：改变文化凝聚开发、安全和运营