构建SecDevOps体系

近十年来，随着数字化转型的加速，软件开发战略经历了自软件开发商业化以来最大的变革。DevOps的出现是为了更快地满足市场需求，但随后DevOps团队发现安全性进展太慢，无法集成到他们的现代开发管道中。然而，数字化也使网络安全比以往任何时候都更加重要（也更加复杂），这使得安全和开发团队在试图合作时产生了分歧。
开发团队和网络安全团队之间的不一致导致了商业机会的错失，因为新的能力迟迟不能进入市场。在某些情况下，缩小差距的压力导致了脆弱性的增加，因为开发团队扭曲规则，围绕安全策略和标准工作。“（麦肯锡，《网络安全：数字企业的关键》，2019)
传统上，安全检查站位于生产和释放成品的过程中的每个点之间。虽然在瀑布环境中，有时间在不打乱工作流程的情况下完成这些工作，但在现代DevOps管道中–67%的公司每周或更频繁地发布–团队现在被要求在速度和安全性之间做出权衡。

为了平衡这一点，公司现在转向SecDevOps，将安全从阻碍开发速度的主要手动的网关保持和合规复选框转移到考虑整体的应用程序安全过程，并利用自动化将其集成到SDLC中。当他们采用由工具支持的基于过程的方法时–而不是由工具及其限制驱动–他们不仅通过生产更安全的工具，而且通过降低与安全性相关的成本来获得艰难的ROI，而安全性通常盲目地最终导致非功能性需求桶。
然而，将应用程序安全流程集成到DevOps并不是一蹴而就的。需要时间和意愿来彻底改变公司文化以支持必要的变革。人们必须兴奋，训练有素，并得到适当的管理，这样他们才能在新的系统中有效地工作，流程必须适应，工具包必须建立。冰冻三尺非一日之寒。SecDevOps也不是。

SecDevOps：不仅仅是一种工具，一种操作方式

虽然关于与SecDevOps、DevSecOps和DevOpsSec相关的不同术语存在争议，但现实是，它们只是向SecDevOps进化的一步，从90%的公司的现状开始，即DevOps+安全，在那里，直到代码已经投入生产，安全才会出现，这导致公司玩“AppSec轮盘赌”，永远不知道修复问题需要多少成本或多长时间。
通过在过程的早期转移安全实践的实现，使它们从开发的最开始阶段就出现，甚至在编写第一行代码之前。这不仅仅是早期测试–而是在每一步提供信息，以通知、教育和管理。这意味着消除可以防止的错误（如错误配置）的低垂果实，以了解在单个项目、版本和环境基础上哪些漏洞是最关键的，并为漏洞的解决设定最后期限。它必须是在开发生命周期的每一步中嵌入安全性的整体方法。正如Gartner所指出的，“IDE插件不是替代品。但是，本着DevSecOps的精神，它们可以在早期捕获简单的错误。”

需要注意的是，大多数开发团队都希望在安全性方面发挥更积极的作用。他们已经看到了对工作流中的操作进行主动管理的好处–因此DevOps诞生了–应用程序安全性的集成也没有什么不同。在开发过程中防止或弥补安全漏洞比最终取消大量代码或事后修复更容易、更实用、成本更低–尤其是当您添加了频繁发布代码所产生的额外复杂性层时。
向DevOps的过渡并不是一个漫长的过程；Dev和Ops基本上使用相同的语言。这就像美国英语和英国英语一样：不同，但说两种语言的人都能听懂对方在说什么。向SecDevOps的过渡更加复杂。开发团队说的是美式英语，安全团队说的是没有联系的哨兵部落的语言。所以，首先也是最重要的，SecDevOps是一个文化转型。每个部门都必须学习一种共同语言，这样才能进行有效的交流。

移动到SecDevOps

当组织评估他们在SecDevOps成熟度曲线上的位置时，他们应该评估三个参数：人员、过程和工具。你会注意到人是第一位的；这是因为如果没有一个有效的团队，将安全性编织到DevOps中的过程和工具是无关紧要的。重要的是要记住，您可能在成熟度模型的一个阶段中处于一个领域，而在另一个领域中处于完全不同的阶段。
无论您是个人团队还是大型企业，您都可以沿着曲线开始执行步骤。

DevOps + Security

成员

• 确保团队成员理解安全性和遵从性是不一样的，这一点很重要。遵守是最低限度的；安全性是关于产品的性能。
• 训练并不等同于意识。教授团队成员安全最佳实践是很重要的，每个开发人员都应该知道它们；创造一种问责文化更好。
• 当扫描在早期和经常实施时，它可能会对团队精神和个人信心造成损害。扫描的结果应该用于教学，而不是责骂。

过程

• 制定控制和指导方针之间的区别。在“必须”和“可能应该”之间划分界限，这样团队成员就可以在需求中拥有自主权。
• 确保策略适用于项目的每个部分。在项目开始前执行此操作，以防止由于团队成员试图遵循不适用的策略而浪费时间和产生挫折感。

工具

• 列出工具箱–这可以通过您的组织或免费工具，如OWASP或NIST计算器。安全策略的透明性、优先级和集中化是目标。
• 了解如何使用SevDevOps工具包补充流程。您如何使用工具来自动化，跟踪项目，改善部门之间的沟通？
• 从Excel、Word和PDF格式获取信息。集中式工具提高了整个公司的可见度和参与度。

DevOpsSec

成员

• 创建一种文化，鼓励团队成员以开发安全代码为荣。考虑某种奖励制度，甚至不惜一切代价来优先考虑安全。
• 选择一个热情的布道者，帮助他们成为安全的捍卫者。对他们进行广泛的培训，使他们能够自始至终领导和捍卫安全的重要性。
• 确保问责制是一项核心价值。如果你写了代码，你就修复了代码。这确保了正确的人从错误中学习，错误不会成为未来的风险。

过程

• 集成自我证明。为团队提供对政策的洞察力。请他们提供反馈意见，并在制定新政策时考虑到这些反馈意见。
• 将工具集成到当前的工作流中，这样团队成员就不必走出他们的路。给开发人员带来安全提升工具，不要让他们去寻找它们。

工具

• 如果你现在没有扫描，开始。当我们拥有这么多工具来加快过程并改善结果时，手动扫描效率或效率不够，不足以成为答案。
• 扫描应该超越基本的遵从性扫描，但不应该做得太频繁，以至于它们变得累赘。找到正确的平衡点。这种平衡会因团队而异。
• 学习对扫描中发现的漏洞进行优先级排序。进行有意义的修复，并了解漏洞何时是可接受的风险。完美是不可能的，所以完美主义必须消失。

DevSecOps

成员

• 设计协作。不要让它发生；为它做计划。每个部门应该如何以及何时向其他部门寻求建议和合作？把一切都摆在那里。
• 收集来自小组的反馈并坚持透明。透明度并不总是容易实现的；这是一种文化价值，必须通过时间、重复和证明来灌输。

过程

• 将安全性集成到您的拉请求中。询问潜在变化的反馈，并促进围绕将安全集成到开发过程的对话。
• 确定可以减少安全债务的地方。学会优先考虑安全债务的哪些方面是可接受的，哪些是不可接受的。

工具

• 为开发的每个阶段制定特定的安全标准，但避免在每个阶段内创建新的处理安全的筒仓。
• 通过已经在做这项工作的人将安全集成到每个阶段。这在整个项目中创建了问责制，并每次都将安全的产品发送到下一个步骤。
• 找到集成适合您的工具的方法。不要试图把一个方形的钉子插在一个圆孔里，而是寻找适合你目前每个部门工作流程的工具。

SecDevOps

成员

• 利用人工智能和ML，让人们专注于做他们最擅长的事情，让计算机做咕噜咕噜的工作。在可行的地方释放时间和大脑空间。
• 提供智能剧本，帮助指导团队成员完成这些过程。这可以帮助团队成员解决问题，并确保他们了解最新的协议更改。
• 根据需要提供有针对性的培训，以确保每个团队成员都是最新的。利用错误作为可教的时刻，作为指导，知道什么时候需要更多或不同的训练。

过程

• 自动化治理用于指导流程。确保产品的完整性是必要的，但没有必要把所有美味的数据都晾在外面。用吧！
• 质量门的设置是为了确保产品满足需要，而不是作为限制因素。使用它们将项目参数与当前产品进行比较，以确定要进行哪些修复。
• 改进政策建议，因为整个团队都是最新的安全问题。确定策略是否适用于当前项目并处理景观。
  安全分析可以在每个阶段使用，以确保产品的安全，先发制人地减少在游戏后期的安全问题。

工具

• 使用工作流平台帮助简化操作。当SecDevOps有效地避开工作流工具时，需要管理的数据太多了

实现SecDevOps：它看起来像什么？

SecDevOps的目标最终是让人们更有效地工作。改进流程和添加集成工具的全部目的是帮助团队更聪明地工作，而不是更辛苦地工作，允许创造力和创新在开发过程中而不是事后解决安全和遵从性问题的同时绽放。
当DevOps的整个目标是尽可能快地完成生产过程时，任何阻碍齿轮的安全网关似乎都是违反直觉的。这有点像乌龟和兔子：一个稳定的、执行良好的工作流，从一开始就包括安全性，通常证明比一个更快的孤立过程更有效，该过程产生了一个必须重建的安全性不足的产品。

总结

• SecDevOps中不存在完美
  完美的代码是不存在的。完美的安全是一个神话。在商业、开发或安全方面，没有什么是无风险的。完美不仅不切实际，而且是不可能的。相反，我们必须专注于解决大问题，尽最大努力降低风险，并继续前进。

• 使安全适应发展，而不是相反
  至关重要的是，开发团队应该遵守的安全措施被集成到他们的过程中，而不是要求他们在当前的工作流之外使用安全工具。确保工具在当前平台和工作流中易于访问和部署。

• 安全与发展相似多于不同
  虽然他们可能会说不同的语言，但驱动其过程的基本租户是相同的：

  • 策略只是安全编码标准
  • 漏洞只是bug
  • 需要补救的项目只是技术债务的安全部分

  SecDevOps是将它们放在同一个页面上，这样它们就可以在安全方面采取策略，而不是因为信息不及时而被动应对。