敏捷开发大大提高了开发团队的工作效率和版本更新的速度，但不利于运维工作。为了让开发人员和运维人员更好的沟通协作，缩短系统开发生命周期，实现高质量的持续交付，开发团队逐渐转向DevOps模式。DevOps可以有效促进快速和频繁的开发周期，但过时的安全措施可能会拖累整个过程，从而催生了DevSecOps的概念。DevSecOps强调在软件开发生命周期（SDLC）的早期引入安全保护，在软件开发之初就必须考虑应用程序和基础设施的安全，为DevOps打下坚实的安全基础。在DevSecOps的建设中，为了大大降低安全风险，核心是构建和利用应用安全工具（AST）进行自动漏洞发现，从而保证缺陷检测的时机准确及时，不会影响研发效率。目前市场上的应用安全工具主要有静态AST（SAST）、动态AST（DAST）、交互式AST（IAST）和MobileAST。其中，静态代码分析工具SAST采用白盒测试的方法，直接从代码中查找和搜索。提问是目前使用比较广泛的工具。本文将介绍SAST在DevSecOps中的常见使用场景。SAST集成Devsecops的不同场景1.IDE研发阶段检测使用场景：将SAST集成到开发者的IDE中，检测开发者何时敲代码并保存。最常见的安全问题，帮助代码开发者在研发阶段发现缺陷耗时检测：二级规则集：误报率低的检测项，偏向性规则，检测前期主要采用函数内分析技术，为了将安全工作对生产效率的影响降到最低，开发人员要求检测工具能够快速响应并尽可能少的误报。因此，在这个阶段，检测引擎是开发者本地的，检测器通常只检测编码风格和API使用错误等低级错误。对于一些检测器无法确定的问题，SAST工具在提交前检测时会选择暂时不报告漏洞，以免给开发者增加额外的负担。场景二、提交时检测场景：代码提交到代码仓库后自动触发目的：每次提交结果快速返回给提交代码的开发者开发者提交代码到版本管理时自动触发工具，每次提交都会触发一次。开发者提交代码后，检测器检测单次提交的代码及其影响的几个文件，收集本次提交需要关注的重要缺陷和漏洞。与IDE检测不同的是，这个阶段会关注跨功能、跨文件的缺陷类型。对代码质量要求高，或者临近发布的团队，往往会选择这种方式进行代码检查。场景三、构建时检测使用场景：代码提交编译成功后，进行定时检测目的：每天定时反馈问题检测耗时：小时级规则集：允许配置更全面的检测项，如作为现阶段OWASPTop10检测由开发者向版本管理工具提交代码时自动触发，每次提交都会触发一次。开发者提交代码后，检测器检测单次提交的代码及其影响的几个文件，收集本次提交需要关注的重要缺陷和漏洞。与IDE检测不同的是，这个阶段会关注跨功能、跨文件的缺陷类型。对代码质量要求高，或者临近发布的团队，往往会选择这种方式进行代码检查。场景4.测试时检测使用场景：构建成功后在环境中进行全量检测目的：将构建好的软件部署到模拟环境中进行全量测试检测耗时：几小时规则集：所有的SAST检测结果检测项目将由QA进行分析和评估。QA期望找到尽可能多的可能的软件问题。因此，不同于前三种场景对低误报率的要求，这个阶段需要SAST工具报告所有可能存在的漏洞或缺陷，以保证低误报率和高覆盖率。.这个阶段往往是测试部门使用该工具，使用SAST工具对所有文件进行全量测试。应用现状及发展在实际使用中，由于一些技术不成熟，代码分析工具的一些问题导致开发者抱怨频频，这使得SAST工具在DevOps中的集成仍然是一个比较大的阻力。一些企业用户测试人员花了很多时间去误报，但二次检测后仍然报出类似问题，受到开发团队的批评。此外，高误报率也不容忽视。研究人员使用国外三种主流代码分析工具共检测出100个CVE缓冲区溢出错误，性能最好的工具仅检测出32个，漏报率接近70%。但是，在了解了以上SAST工具的使用场景后，我们可以看到，SAST工具已经在尽力去适应开发者的工作习惯。为了满足不同阶段开发者对代码分析工具的需求，SAST工具的规则集和检测时间在不同时期进行了调整。例如，开发者认为在编写代码时进行安全测试会影响生产效率，所以先科在前期只允许配置有限的一组规则，以便能够进行快速扫描，及时反馈，尽量减少开发和安全测试之间脱节的影响。即使是同一个检测项目，不同阶段SAST工具的检测范围也不同。以SQL注入为例，SAST工具可能只在提交前检测单个函数内的问题，在提交时检测单个文件内的问题，在最后阶段进行跨文件检测。通过这种方式调整误报、漏报和检测时间，最大限度地提高开发人员对SAST工具的接受度。我们相信未来SAST工具的能力会不断提升，同时开发团队也应该根据自身需求在工作流中选择合适的节点使用合适的SAST工具进行代码安全审查，并采取向真正融合安全保护的DevSecOps迈进一步。【本文为专栏作者“安安牛”原创文章，转载请通过安安牛（微信公众号id：gooann-sectv）获得授权】点此查看作者更多好文
