【编者按】作者 Aaron Volkmann 是 CERT Division 高级研究员，通过提出了一种集成安全系统到 CI/CD 的方法，让机构保持快速部署到生产环境能力的同时，也大幅度降低安全隐患，本文系 OneAPM 工程师整理。
DevOps 理念规定软件开发和运维团队之间需要加强沟通和协作，从而在软件开发和交付过程中实现更好的结果。而在这之后，信息安全团队同样应该集成到 DevOps 实践团队中。虽然在持续集成（CI）和持续交付（CD）过程中还未实现完整的自动化软件安全评估，本文主要介绍应如何将 DevOps 理念应用于安全评估，并集成 CI / CD。
及时和可持续
在一个新的软件项目的开发阶段，信息安全团队应该衡量新软件的安全风险，并在整个开发过程中进行安全评估。为确保快速开发和新功能部署，企业必须确保安全评估的频率，既要保证安全风险最小化，同时也要考虑安全团队有限资源的可持续性。
众所周知，自动化是 DevOps 的主要理念之一，但很多在指定应用上进行软件安全性评估的任务仍然是手动执行。出于这个原因，适当的应用安全性评估仍然是持续集成/持续交付开发管道界外。如果一个企业正在进行持续交付，那怎样才能保证部署到生产环境的软件没有安全风险？
虽然，程序中某些代码的变动，如程序接口（API）终端或更改验证，在迁移到生产之前，需要对此类变动进行手动安全评估。但其他类型的变化则不一定需要，如视觉风格改变。例如，如果在之前评估的基础上，只是修改了一些视觉样式，或者添加了一些不影响安全性的小功能，此时，再对应用安全性进行全面评估则意义不大。
所以，是否需要手动安全评估也取决于应用程序和所处理的数据类型。例如，一个内部应用完全不涉及任何敏感数据，如客户信息、商业秘密、PCI 或 HIPAA 敏感数据等，并且只能通过公司内部访问，这种应用不同于可能接触敏感数据的 Web 应用。由于需安全评估的应用数量和工作量巨大，应用安全团队并没有能力来手动评估每一个被部署到生产的变化。在应用负责人的帮助下，安全团队应该评估和编目企业的应用程序。该目录应包含每个应用程序的威胁模型、所接触数据的相对风险以及应用会如何被用户访问等信息。
软件的新功能在部署之前，相关部门必须进行安全评估。在最初的评估后，下一次全面安全评估只有在安全性配置文件更改后才可以进行。比如，改变身份验证或授权机制，或者添加一个新的外部系统集成。
开发持续集成管道应配备一种检测机制，可以在应用一旦发生变动且需要安全评估时及时做出响应。该机制是图1所示的安全控制器，它会在出现安全性敏感变动时通知信息安全团队，并进一步规划手动安全评估。在评估完成之前，自动部署到生产环境会被叫停。
图1：一个新的软件通知发送到安全控制器后，安全控制器会触发阻塞暂停应用生产部署，并通知安全部门需要手动安全评估。
评估完成后，信息安全系统会通知持续集成/持续交付系统可以继续部署当前应用程序，如图2所示。
图2：一旦安全团队完成了安全评估，安全控制器则释放对应用生产部署的控制。
如果应用中出现了一个不影响安全性的变化，则无需手动安全评估，生产部署不会被阻止，如图3所示。
图3：一个影响安全性的小变动不会改变应用程序的部署能力。
如果对应用程序产生了较大改动，则需要执行下一个安全扫描，生产部署会被阻塞，控制器通知安全团队进行安全评估，如图4所示。
图4：应用程序如有大的更改，则需要安全评估触发阻塞暂停生产部署，并通知安全团队需要手动安全评估。
评估完成后，控制器会释放阻塞。
集成一个安全控制器到开发持续集成和持续交付系统中，可以帮助企业自动存储上一个评估之后所有的代码变动。评估完成之后，所有的代码变动都会被跟踪。在安全事故中，可靠的日志会显示事件发生的顺序，能够帮助你更快更容易地调查和缓解安全性问题。在评估之后，所有部署的更改可以通过持续集成、部署和安全控制器系统可见。定位并解决应用程序中的安全漏洞可谓是「大海捞针」。但通过了解相应的变动，可以大大地缩小问题范围。
目前，完整的应用程序安全评估自动化尚未实现，所以人工评估仍然必要。通过集成安全系统到 DevOps 的 CI / CD 中进行跟踪安全评估，不仅可以提高软件发布过程中的安全性，还能简化安全事件响应，从而提高部署或交付过程中定位并解决问题的能力。
本文系国内 ITOM 行业领军企业 OneAPM 工程师编译整理。我们致力于帮助企业用户提供全栈式的性能管理以及 IT 运维管理服务，通过一个探针就能够完成日志分析、安全防护、APM 基础组件监控、集成报警以及大数据分析等功能。想阅读更多技术文章，请访问 OneAPM 官方技术博客。
本文转自 OneAPM 官方博客