许多人认为应用安全仅仅应该是安全团队的责任。然而，虽然安全专家可以对此做出贡献，开发人员通常是唯一具备修复软件安全漏洞的技术能力的人。软件合规性也是如此。归根结底，只有开发人员才能构建符合特定软件标准的应用程序。
考虑到开发团队的紧迫期限，给他们额外的职责可能会带来挑战。为了帮助开发人员在不降低速度的情况下交付安全的应用程序，许多团队采用了devsecops，鼓励将自动安全测试集成到每个版本的devops工作流程中。
devsecops帮助团队更快地交付更安全的软件，但是否是更加符合合规性的软件呢?许多尝试实现软件合规性的团队遇到了与试图实现软件安全性的团队相似的挑战。幸运的是，他们可以采用相似的策略。
devsecops的作用是什么?
devops工作流程支持快速迭代的软件发布周期，这给软件安全带来了一定障碍。
在保护软件安全的传统方法中，测试是在应用程序构建之后，软件开发生命周期结束之后才进行的。结果，大多数(如果不是全部的话)应用程序同时测试，并且将一长串、令人生畏的安全问题清单发回给开发人员。
然而，许多团队发现这种方法与devops不兼容。开发团队没有时间，更不用说预算，来停止他们正在做的事情去处理一大堆表格中的问题。
为了解决这个问题，企业可以通过将安全测试集成到devops发布周期更短的、更高频率的反馈循环中，以实现devsecops。devsecops要求在早期经常执行自动安全测试，而不是在开发人员完成构建应用程序之后运行大型的测试。通过帮助开发人员编入更安全的代码，devsecops有助于减少质量保证(qa)必须识别以及发回来的问题数量。
如果开发团队可以将安全测试集成到devops工作流程中，为什么不将合规性测试也集成到devops工作流程中呢?
如何将devsecops实践应用到软件合规性中?
虽然安全测试通常与合规性测试要求不一样的分析方法，但是尝试devsecops的开发团队可以使用类似的方法来进行合规性测试。
正如传统的应用安全测试一样，合规性测试通常发生在qa环境中。大致的应用开发和测试流程如下所示：
1. 开发人员编写应用程序的代码
2. qa在开发人员转移到另一个项目时测试代码
3. qa向开发人员发送一份违反合规性的列表，要求他们暂停当前的工作，先解决这些问题
这种合规性测试策略在技术上并没有什么问题。然而，这种方法并不受开发人员欢迎，如果问题列表特别长，对于开发团队来说可谓代价高昂。为了在应用程序完成之前解决更多的合规性问题，团队可以实施受devsecops启发的实践，来帮助开发人员在软件开发生命周期(sdlc)早期提交合规性代码。
策略之一是将自动合规性测试集成到devops发布周期中。通过定期测试而不是一次性测试应用程序，团队可以减少每个测试周期违规的数量。显然它需要在整个sdlc中进行更高频率的测试，事实证明这种方法比在qa中找到问题更快。
另一种方法是在集成开发环境(ide)中创建沙箱环境，开发人员可以自己在其中运行测试。在编写代码时测试他们自己写的代码，使开发人员能够编入更清晰、更合规的代码，
因此违规就不太可能出现在qa中或者更糟出现在生产中。这种方法另一个好处是帮助开发人员熟悉可能导致违规行为的代码。
这些识别和解决违规问题的策略并不意味着要取代qa测试。然而，通过将合规性测试集成到sdlc的多个阶段，团队将在qa和开发的反馈循环中看到更少的问题，这将会更好地支持devops工作流程。
在现实中又是怎样的情况呢?
就像安全测试一样，将合规性测试集成到devops发布周期需要新的技术和工作流程，它们都有不同的学习曲线。
关于技术，静态分析正成为帮助开发团队构建合规应用程序的流行的选择方式。静态分析工具之间的覆盖范围各不相同，但是总体而言，该技术可以在代码质量标准中发现问题，比如misra 和cert c/c ，以及安全标准，比如owasp top 10和 pci dss。
团队选择的用来解决合规性问题的静态分析工具或者其他的任何技术在他们采用的工作流程中发挥着重要作用。如前所述，那些希望将问题排除在qa之外的人希望找到凯发在线的解决方案从而能够：
1. 将快速反馈循环集成到测试和开发中
2. 在开发人员编写代码时在ide中扫描代码
在测试和开发之间构建一个持续的反馈循环可能代表了开发人员日常工作的重大转变。
虽然“devsecops”并不完全相同，但是受管制行业的开发团队可以通过将合规性测试集成到devops发布周期中来获得降低成本的益处。