给DevOps加点料：融入安全性的DevSecOps
从前，安全防护只是特定团队的责任，在开发的最后阶段才会介入。当开发周期长达数月、甚至数年时，这样做没什么问题；但是现在，这种做法现在已经行不通了。
采用 DevOps 可以有效推进快速频繁的开发周期（有时全程只有数周或数天），但是过时的安全措施则可能会拖累整个流程，即使最高效的 DevOps 计划也可能会放慢速度。
一、DevSecOps是什么
在 DevOps 协作框架下，安全防护是整个 IT 团队的共同责任，需要贯穿至整个生命周期的每一个环节。这个理念非常重要，因此催生出了“DevSecOps”一词，即在开发和运维紧密结合的基础上再强调了Security，强调必须为 DevOps 计划打下扎实的安全基础。
DevSecOps 意味着从一开始就要考虑应用和基础架构的安全性；同时还要让某些安全网关实现自动化，以防止 DevOps 工作流程变慢。
选择合适的工具来持续集成安全防护（比如在集成开发环境（IDE）中集成安全防护功能）有助于实现这些目标。但是高效的 DevOps 安防需要的不仅是新工具。它更需要整个公司实现 DevOps 文化变革，从而尽早集成安全团队的工作。
二、DevSecOps目标及原因
DevSecOps的目的和意图是建立在“每个人都对安全负责”的思想基础上，目标是在不牺牲所需安全性的前提下，将安全决策快速、大规模地分发给拥有最高级别上下流的人员。
如今，也是同样的原因致使传统的安全领导者竭力争取自己在行政会议上的一席之地。虽然这一席之地能够保证安全决策有效性的提高，但由于价值创造过程中缺乏所需安全技能的供应，导致成果在产出过程中摩擦增多、速度减缓。如果没有足够的人手，企业经营者就无法达到业务运营商所期望的速度，也就意味着他们必须改变安全价值的贡献方式，否则风险就会增加。
随着DevOps、敏捷和公共云服务的业务需要，传统的安全流程已成为需要削减的主要目标。但可悲的是，这又是最容易忽略的一点。传统安全性的出发点是，一旦设计了系统，便可以由安全人员确定系统的安全缺陷，并由业务运营商在发布系统之前对其进行纠正。这一原则允许流程将有限的安全技能应用于结果，并且不必在大型系统中额外增加安全环境。
但是，这样设计的流程只有在业务活动的速度是瀑布式的并且得到各方同意的情况下才有效。更糟的是，在迭代中引入认为安全必须以这种方式运行的想法是有缺陷的，也会在系统内增加固有风险。因为业务决策需要内联平衡并以较快的速度解决。因此，这一方式尚未得到实现.
三、DevSecOps优势及实施
在价值创造生命周期的最后阶段，安全团队几乎不可能拥有呈现安全决策所需的所有信息。随着价值创造过程加快提供迭代价值，以便紧密地联系客户的需求，更可能的是，一次性完成整个系统的测试实际上对结果具有破坏性。
实际上，以这种方式做出的大多数安全决策很少有效，经常被业务领导人否决，并且通常会在事件或破坏发生时受到质疑。
因此，随着DevOps的不断变化，传统的安全性不再是一种选择。在通过迭代构建的系统的设计和发布中，协作已经太晚了。
但随着DevSecOps的引入，业务运营商或安全人员都没有必要放弃降低风险的措施；相反，组织内的每个人都应该拥抱并改进它，使其得到那些有能力为系统贡献安全价值的人的支持。
有个很棒的说法是，如果没有刻意的内置安全控制，系统故障是肯定的，因为仅仅是避免安全就会给系统带来更多风险。因此，认为价值创造与安全性不能合作的观点是非常荒谬的。
DevSecOps建立的思维模式包括为业务运营商提供了工具和决策，帮助他们进行安全决策，以及为安全人员提供使用、调整这些工具的支持，这非常适合协作型团队。
在这种情况下，安全工程师与DevSecOps宣言保持一致，该宣言表明了安全从业者必须提供的价值，以及他们必须做出的更改，以使安全价值能够提供给更大的生态系统。
通过这种方式，DevSecOps工程师为系统提供的价值是在非合作的攻击者发现缺陷之前持续监视、攻击并确定缺陷。这需要业务生态系统中的所有人，包括安全人员，为迭代的价值创造做出贡献，并不需要为了团队中安全从业者的缺失而过度焦虑。
DevSecOps作为一种思维方式和安全性转换，有助于流程与其他安全更改合作。换句话说，如果您认为需要将安全性添加到“开发”或“运营”或某些其他业务流程中，那就没关系了！需要将安全性添加到所有业务流程中，并且需要创建一个专门的团队来建立对业务的理解、发现缺陷的工具、持续的测试，以及预测作为业务操作人员如何做出决策的科学。
此外，为了实现全面的转型，DevSecOps需要执行管理层和董事会参与提供相关信息，这些信息是业务如何在当今经济所代表的竞争日益激烈的低信任度环境中运营和保护团队的关键指标。