近年来，在DevOps模型的指导下，将开发和运维团队结合在一起的公司在以更快的速度发布代码方面取得了普遍的成功。但这一趋势加剧了将安全集成到流程中的必要性，因为发布代码越快，漏洞也就越容易产生。而越来越多的企业和组织已经认识到，信息安全是企业存续发展的基石之一，因此希望将安全融合在DevOps之中，也就是我们所说的DevSecOps。      

简单来说，若想要将安全集成到DevOps之中，需要采用工具和方法，将应用开发、IT运维和安全团队结合在一个通用的DevSecOps规则下，其目标是使安全成为软件开发工作流的一部分，而不是像瀑布开发模型那样，在软件开发周期的后期再将安全引入。这一转变颠覆了安全控制应在何时、何处及如何引入到软件中的传统观念，并对相互孤立的团队提出了挑战，他们需要找到合作的方法来高效且安全地发布代码。

但究竟如何将安全集成到DevOps当中，对很多企业和组织来说是现实的疑问。对希望实践DevSecOps的组织和企业，我们有以下5条建议：

一自动化

速度是DevOps的主目标之一。在一个持续集成和持续部署（CI/CD）环境中，能够以多快的速度将代码发布并投入生产，几乎成为最重要的事情。因此，要使安全成为这一工作流程的一部分，它就需要实现自动化。安全控制和安全测试需要在开发生命周期的早期嵌入，而且它们需要以自动化的方式进行，因为对于一个应用程序，企业或组织每天可能会将新版本的代码推送到生产环境50次以上。

自动化已经成为具有高度成熟的DevSecOps实践的组织中的一个关键特性。在欧美国家，DevSecOps的实践已经有了相当的成熟度。在Sonatype的一项对2300名IT专业人员调查中，大约40%的受访者正在进行全生命周期的自动化安全测试。而在传统的瀑布开发模型中，自动化安全测试只在产品发布之前才可能被引入。

从源码分析到软件集成再到运维监控，越来越多具有一系列功能的工具可针对整个软件开发生命周期进行安全分析和测试，如Checkmarx、Sonatype、悬镜灵脉和默安雳鉴等。

若要进行自动化的安全测试，需要注意一些事情。例如，如果要每日进行静态应用程序安全测试（SAST），需要确保只检测当天改变的代码内容。因为每天尝试在整个应用程序源代码上运行自动扫描会耗费大量时间，这会大大拖累你的进度。可以将自动化动态应用程序安全测试（DAST）和交互式应用程序安全测试（IAST）嵌入到软件开发生命周期中。与侧重于在代码本身中查找潜在安全问题的静态分析不同，DAST会在应用程序运行时实时查找漏洞。自动化DAST扫描，可以捕获OWASP中列出的常见漏洞（如SQL注入错误），这些漏洞在应用程序的静态分析中可能无法被检测出来。而IAST融合了SAST和DAST的优点。如果条件允许，SAST、DAST和IAST都需要作为例行检测方式，因为你永远不知道只使用一种测试方法，会遗漏什么漏洞。

在CI平台中添加自动化的安全分析可以减小在软件开发生命周期的早期引入威胁代码的可能性。自动化可以与轻量级嵌入式代理相结合，以提供从自动化安全分析中检测到的问题的相关运行时分析数据，这使开发人员更容易解决代码问题。 

二检查代码依赖包

尽管人们越来越担心使用第三方软件组件的风险，但根据国外机构进行的一项调查，企业在应用程序中使用的开源软件正在变得更多，而不是更少。该机构对1000多个商业应用程序进行的独立调查显示，96%的应用程序包括开源组件。超过6成的应用在这些组件中包含已知的安全漏洞，其中一些已经存在了4年之久。只有27%的受访者表示，他们对开源软件的已知缺陷进行了识别和修复跟踪。

了解开源组件的使用情况是更好地实践DevSecOps的关键之一。云服务以前所未有的方式推动了创新，使公司和组织能够更快速地满足客户需求。这种创新的步伐也带来了越来越多的开源软件的使用。开发人员没有时间审查他们所使用的开源库代码，因此以自动化方式管理开源和第三方组件是DevSecOps的基本要求。你需要清楚地知道开源程序是否会在代码中造成漏洞，以及这些漏洞对应用程序的影响。代码依赖性检查是DevSecOps的基础，企业或组织需要使用开源审查工具扫描代码并识别相关的开源组件库，查看它们是否包含严重的OWASP漏洞。

三不要贪多

一些AST工具可以让开发人员在编写代码时扫描代码，这样他们就可以收到可能导致安全问题的即时反馈。这些工具帮助开发人员识别和修复潜在的安全漏洞，是DevSecOps实践的重要组成部分。

通常，当一个安全团队在CI/CD链中使用安全测试工具时，该团队倾向于打开对所有安全问题的检查规则，这会使得暴露出来的问题过于庞杂，最终只会给开发人员带来困扰。相反，最好一次打开一到两类漏洞的检查开关，逐渐让开发人员习惯将解决安全问题融合到他们的工作当中。例如，刚开始使用一个AST工具时，可以只打开SQL注入漏洞的检测规则。一旦开发人员看到该工具如何帮助他们在编码过程中识别并解决漏洞，他们就更有可能习惯使用它。在启用越来越多的规则之前，需要先在工具和人员之间建立信任。

实践DevSecOps需要循序渐进，将事情分解成可以独立管理的部分，逐步解决。一步到位是不切实际的想法。安全产品、安全制度和安全人员的短期大量引入，只会降低工作效率，并引起开发人员的不满，这最终可能会让DevSecOps的实践无法长久下去。

四选择合适的工具

集成至关重要。安全产品需要能够集成到开发流程中，并使开发团队和安全团队能够一起工作。如果开发人员必须费时费力地启动扫描，他们很有可能会放弃扫描工具。一个优秀的安全产品应该可以让开发人员能够很容易地快速启动扫描并获得结果，而不必离开他们现有的工具集。

工具的速度和准确性也需要关注。安全工具应该工作得很快，不能影响流程的敏捷性。同时，要关注工具的误报率，需要开发人员或安全工程师抽出时间来验证扫描结果的工具对企业没有什么帮助。

五开发人员的安全编码培训

获得开发团队安全编码培训所需的时间和资金投入的预算是一大挑战，但绝对划算。开发人员通常不知道他们的编码方式不安全。多数情况下，安全不经常被提及，也不是开发团队的优先事项，企业和组织必须主动地对开发人员进行安全培训。如果人员没有安全意识，再多的工具也难有成效。

许多DevSecOps的实践方式和工具仍在出现，目前对DevSecOps的最佳实践还没有一个普遍且共识性的认知。但很明显，在一个大数据、云计算、持续集成和快速发布的世界中，安全已成为IT相关行业中的一个共同主题。