01 数字化转型的安全原生诉求

2020年，新冠肺炎疫情席卷全球，随着多国疫情得到有效抑制，企业复工复产被提上日程，在这样特殊的时期，各行各业加速转型升级、降低人力密度、提升生产效率的必要性愈加凸显。事实上，企业对于转型的需求并非仅仅在特殊时期，数字化、网络化、智能化的转型早已体现在近些年的国家政策和企业行动中，包括从产品开发到供应链管理，从市场营销到客户体验。

在这个数字化转型和万物互联的时代，随着云计算技术、大数据技术、5G技术、人工智能和区块链技术的快速发展和落地实践，人、数据、机器、网络紧密结合在一起，推动企业数字化转型的脚步不断加快。与此同时，新的业务和运营模式伴随着互联网应用、移动互联应用、物联感知应用、企业办公应用等一系列应用系统的快速开发与迭代，系统和软件作为重要的载体，其安全性、可靠性面临着比以往任何时候都更严峻的挑战。

在系统和软件开发过程中，企业根据用户的需求和系统产品的特性，选择采用不同的开发模型，如瀑布式或是DevOps（Development和Operations开发运营一体化），但不论采用哪种模型，均需面对系统自身的安全漏洞风险（产品风险）以及系统开发项目中的各类技术和管理风险（项目风险），应用开发的安全问题逐渐成为企业迫切需要解决的问题。

在上一篇文章《企业该如何应对新时代下的网络安全挑战》中，我们介绍了企业应以 “Security by Design” 的思路应对网络安全的调整。安永在2020年全球GISS报告（Global Information Security Survey）中提出了“安全原生”的概念，将网络安全置于企业转型的核心过程，即在业务系统设计初期就嵌入网络安全，建立信任，而不是将其作为问题出现后的补救措施，从而形成贯穿整个业务生命周期的安全管理。“安全原生”具有战略性和务实性，有助于持续管理，降低企业安全风险，减少事后处理问题的精力和费用，增强业务韧性。

02 基于业界洞察的安全原生实践

传统瀑布式的安全原生

数字化转型对开发活动提出了一系列安全需求，对于传统的瀑布式软件开发流程，业界有着一套较为成熟的最佳实践，将安全管理流程和安全技术措施嵌入到整个开发生命周期过程中，有效减少开发代码的安全漏洞，降低系统上线后的风险和业务整改成本，有力地保证输出可信合规的产品。这些实践包括：

1、在需求阶段，为系统项目定义网络安全要求。

需求阶段是网络安全要求定义的黄金时机。定义工作涉及：确定在计划运行环境中运行的应用程序的最低网络安全要求、确立和部署安全漏洞/工作项跟踪系统等；

2、在设计阶段，应仔细考虑网络安全问题，进行威胁建模及攻击面分析。

如果在项目的开始阶段执行缓解措施，则会大大降低后期缓解安全问题的成本。项目团队应避免在项目开发收尾阶段再“插入”网络安全功能及缓解措施；

3、在开发阶段，将软件设计的结果转换成计算机可运行的程序代码。

应在程序编码中制定统一、符合标准的编写规范，维护程序的可读性和易维护性，提高程序的运行效率；

4、测试阶段包括调试过程，确保安全设计都完整地实现。

开发过程中遗漏的系统缺陷会在测试阶段被检测发现，这些缺陷会记录下来并回传至开发人员进行修复，通过回归测试，直到清除所有关键问题；

5、新软件版本发布后，系统运维团队加入。

运维部门提供用户反馈，并负责咨询和解决用户的问题。此外，该阶段工作任务还包括所选组件的更新，以确保软件保持最新状态，不会受到安全漏洞带来的网络安全影响。

敏捷开发的安全原生

如今，DevOps使得大量的应用和业务需求的快速迭代，它的流行和融入，为越来越多企业的数字化转型按下了加速键。DevOps通过“一切皆为代码”使基础架构更加容易获取，这将使软件交付更加迅速且更具韧性，但同时也带来了新的安全难题，例如，应用程序组件之间的内部调用通常是在公共网络通过API调用来实现，而API调用容易受到网络攻击，微服务的快速部署大大扩展了系统暴露的攻击面。这些变化正在使得基础架构、代码开发和IT角色之间的界限模糊。同时，DevOps中使用大量的开源架构和开源代码，如何控制开源代码的风险，也是开发过程中需要及时进行评估的。

使用DevOps的企业应当建立一套良好的安全措施来应对相应开发模式的风险，比如：建立风险的集体所有权和问责制，使用开源组件的风险责任评估，重新定义安全职责，使用自动化安全工具管理风险等，将DevOps进化到DevSecOps。基于安永的最佳实践框架，我们将就企业在DevOps中应考虑的核心安全活动进行阐述。

图1 DevSecOps框架示意图

01 软件分类分级

软件分类分级是对企业各个业务场景中使用的应用，根据安全管理和信息保护、IT合规管理和数据保护等维度，确定待办事项中安全功能的优先级顺序和重要程度。对软件开发和维护进行有效的分类分级管理，能够使企业管理更科学化、标准化，帮助企业更好地实现商业目标。企业在开展软件分类分级时的主要考量包括：

►IT安全管理和业务影响：

  • 当系统数据的保密性、完整性、可用性受到威胁时，是否有巨额的损失？

  • 项目是否考虑了项目上线时间的紧迫性、业务对应用的依赖程度、应用系统影响的范围、项目开发的成本？

  • 系统是否部署在安全的环境？

  • 是否提供标准化的IT解决方案？

  • 是否对业务有重要交付？

  • 是否与外部合作伙伴长期合作？

► IT合规管理和数据保护：

  • 项目是否符合属地合规要求？

  • 系统是否包含了大量的个人敏感信息？

  • 系统是否包含了商业机密？

  • 处理的数据是否包含财务报表或审计记录？

  • 是否存在不合理的流程设计或实施问题？

  • 是否涵盖了隐私影响的评估？

02 安全需求定义

准确识别和定义内外部安全需求，对企业控制和应对风险至关重要，应在每一个迭代循环的早期阶段进行安全需求的快速制定。首先我们需要一份安全需求库，即包括了企业内部不同的管理要求（例如，身份验证、角色管理、密钥管理、审核/日志、密码、协议等等），同时也包括了软件应用场景相关的监管、合规、数据隐私要求。通过一套快速推导筛选的方法能够将安全需求库中适用的部分映射为User Story的安全需求说明。在过程中嵌入合规性控制的DevOps方法越来越多地出现在软件定义基础架构和网络中。

图2 软件安全合规需求框架示例

安全团队应定期审查已发布的安全需求、跟踪进度记录和其他必要的信息，以维护安全需求库的时效性，避免新技术、新风险出现时的混乱。

03 开源组件评审

DevOps对开发效率的追求，串连了多重的应用服务，因此对第三方开源组件愈发依赖。如今很多软件在开发过程中由于长期大量使用第三方开源组件，且在整个设计开发、安全测试阶段，开发者或测试者又经常忽略针对第三方开源组件的漏洞安全审查，从根本上导致了持续、隐形的安全问题。如Java中的反序列化漏洞（Deserialization）、GNU Bash出现的破壳漏洞（Shellshock）和OpenSSL中出现的心脏滴血漏洞（Heartbleed），这些都是第三方开源组件漏洞的典型案例。

安全团队应对第三方组件的安全风险进行调查、评估、监控（如参考权威漏洞平台披露的漏洞信息），并会同法务部门，对开源控制策略进行了审核和法务风险评估，形成相关报告，此外，还需会同开发团队建立第三方组件（包括开源组件）管理视图，包括组件的来源、用途、安全审批流程、安全评估结果、漏洞修复等信息，保证信息清晰、可追溯。

04 安全编码审计

DevOps强调开发（应用程序/软件工程）、技术运营和质量保障（QA）部门之间的沟通、协作与整合。通常，企业的安全防护只是特定团队的责任，团队一般在开发的最后阶段才会介入。随着现在项目迭代周期的加快，过时的安全措施可能会拖累整个流程，即使最高效的DevOps计划也可能会放慢速度。

一个关键的DevOps原则是“自动化你尽可能想到的一切”。安全团队应当以适当方式对高风险应用开展特别代码审查，把静态分析整合到代码审查流程中，使代码审查更高效、更一致。同时，添加自定义规则可以帮助发现特定于企业编码标准或基于框架/中间件的安全缺陷，从而避免在企业代码库中经常遇到的错误。为了增强工作效率，许多企业还创建了规则以消除重复的误报并关闭不相关的检查。

原则上所有项目都必须接受代码审查，但不同类型的项目审查过程可能会有所不同。例如，低风险项目的审查可以更多地依赖自动化工具，而高风险项目可能会消耗审查人员很多时间。设置最低可接受标准会强制要求对未通过审查的项目进行修正重审。

05 系统安全测试

在DevOps的测试阶段，可采用静态安全控制测试，包括静态结构分析、代码质量度量，对局部或全部代码的正确性、合法性、功能性、合理性、可靠性进行统一、规范地把控。在实践中，应该首先根据当前项目使用语言、框架及组件等信息及对应的需求选择合适的静态安全扫描工具及版本对应用产品进行审查；随后根据企业现状，结合研发团队技术方案，分析、调整和优化静态扫描工具规则，调整相应的优先级，以确定最终的扫描规则，并根据产品发布需求情况确定扫描阈值；对不同角色（例如开发人员与审计人员）使用的工具规则进行调优，形成自定义的工具红线以及配置基线。

在发布之前的安全测试阶段，需采取动态安全控制测试将安全性整合到标准的质量保证流程中。可对应用程序进行安全性功能与接口测试、性能分析、覆盖率分析等。大多数情况下，安全功能可以像其他软件功能那样进行测试；同时，也可以使用正常输入和异常输入对基于要求的安全性机制进行测试，这样的安全性机制包括账户锁定、交易限制、访问权限等等。针对对于企业至关重要的API应量身定制模糊测试，测试人员需要让模糊测试框架能够涵盖其所调用的所有应用接口。

我们建议将安全和合规测试无缝地整合到DevOps中，使开发者专注工作在持续集成和持续部署工具链环境中。

06 上线风险签核

企业需制定一套正式的风险验收和问责流程来处理所有的软件开发项目，在应用最终上线前企业安全管理团队应确保签发与合规性相关的安全性证明书。该证明书必须是明确的、可被采集的，以备将来可供查阅。任何例外或异常情况都必须得到跟踪，即便在速度最快的敏捷方法下也不例外。

在工程师具有发布软件技术能力的DevOps组织中，即使标准被嵌入在自动化流程中，也仍然需要非常严谨的风险验收步骤。如果风险验收者签署了一套特定的合规性验收标准，然后自动实施它们，则必须持续验证该标准是否准确和自动执行这些标准是否可行。

安全团队还应当以易于理解的语言向企业管理层解释企业的合规性和隐私义务以及如果不履行这些义务时可能产生的后果，并将项目的剩余风险告知管理层，由其做出相应的风险确认。对某些企业而言，解释违反合规性要求以及数据泄露所造成的直接成本和潜在后果可能是着手处理这方面问题行之有效的办法。而对于另一些企业而言，邀请外部专家对董事会做演讲可能会更有效，因为某些高管人员更加重视外部专家的观点。获得了高层充分支持可使得安全团队能够分配到足够的资源来履行合规和隐私义务。

07 运维环境配置

DevOps强调软件部署和运维管理的关系，运维环境是软件安全的基础保障。

企业应当监控生产软件，寻找不当行为和攻击迹象，包括应用与操作系统（通过系统调用）之间的交互，或者应用与其所使用的、发起的和操作的数据类型之间的交互。

企业可使用应用容器来支持其软件的安全目标，包括易于部署、应用与其依赖内容之间的更紧密耦合、集成。容器能为一致的应用和更新安全控制手段提供了一个便利场所。

同时，应采用自动化功能以规范的方式来扩展服务、容器和虚拟机部署。编排流程可以利用内置的和附加安全控制手段来确保每个已部署的容器和虚拟机都满足预先规定的安全要求。集中设置安全属性有助于在需求出现时进行快速更改。

DevSecOps的理念根植于安全与业务的融合，在企业数字化转型的战略目标中亦应确保包含以下关键考量：

文化：每个人都朝着一个共同的目标努力，并怀着不断改进的愿望进行合作。

分享：为每个应用程序的安全性分担责任，坚持将安全作为原则的理念。

度量：通过比对一切数据生成智能分析与指标，以帮助提供安全决策。

精益：通过缩短反馈循环和利用标准化来实现规模化，从而减少或消除瓶颈，并关注小批量。

自动：利用工具来自动化耗时和容易出错的任务，最大限度地减少人工交互。

03 总结

在前两篇乘风破浪的网络安全系列文章中，我们看到数字化转型中的新兴技术，例如，云计算技术、大数据技术、5G技术、人工智能和区块链技术对商业环境和企业发展带来双面性影响，同时我们对于网络安全在新环境中面临的多因素影响进行了重新定位，并根据 “Security by Design” 的思路，从数字化及网络安全同时兼顾的角度提出企业的解题思路和应对措施，在本篇文章中做了具体阐述。

在数字化转型的浪潮中，软件作为万物互联的重要载体，如何识别、应对其安全需求是企业无法回避的问题。构建安全原生，一方面能够帮助企业在混沌中抓住机遇，从多个维度监控和考察风险，并积极采取应对措施，集成风险管控策略，并且在全面的风险管理策略下采取有效而敏捷的风险处置措施；另一方面，能够以风险应对为机会点，加速产品的市场化，数字化的风险智能，带有预判性的实时风险监控机制，助力快速决策，高速发展，增加商业价值和持续信任。

软件的开发和迭代过程，如同前赴后继的浪头，推动着企业在数字化转型中不断突破，我们将帮助企业创造信任的数字化观念和企业文化，以客户为中心和客户关系为驱动的战略主动性，从传统的“流程、风险、控制”框架，实现到连接业务的安全原生，助力企业在数字化转型的浪潮中乘风破浪！

本文是为提供一般信息的用途所撰写，并非旨在成为可依赖的会计、税务、法律或其他专业意见。请向您的顾问获取具体意见。

声明：本文来自安永EY，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。