如何利用CMMI和ISO27001建设软件安全开发流程提升软件工程能力

近期，某出行服务巨头事件引发了各方热议。该企业于2021年7月1日凌晨在美国低调上市，上市第二天，国家网信办网络安全审查办公室发布公告，对其出行App实施网络安全审查，审查期间停止新用户注册。两日后，因存在严重违法违规收集使用个人信息问题，其出行App又在应用商店被下架。随后一周内，依据《中华人民共和国网络安全法》，公司旗下共计25款App也相继被下架。

让我们把时间线稍微拉长点看就不难发现，最近几年，随着《中华人民共和国网络安全法》、《中华人民共和国个人信息保护法》、《中华人民共和国数据安全法》、《网络安全等级保护基本要求》等系列法律法规的相继出台，网络安全已上升到了国家安全的角度，这也对现有的软件企业交付（含出海交付）带来了更多的要求和挑战。

比如，一些公司最近几年都要参加国家级的网络安全攻防演练(代号HVV行动)。除了这种针对内部系统的安全整改和攻防对抗要求，国内外的用户对于软件安全交付也有着越来越高的要求，如：“系统安全等级需要达到国家等保二级/三级要求”，“上线前要有第三方的渗透测试报告”，“按照ISO27001信息安全管理体系要求进行建设”等等。

今天擎标从质量流程的视角和大家探讨下：针对国内和国际上对于网络信息安全方面的要求，如何结合CMMI和ISO27001的要求，来建设软件安全开发流程，并提升相应的软件工程能力？

首先，我们需要先了解下CMMI和ISO27001对于软件安全开发的要求。

最近发布的CMMI2.2里，最重要的security内容是两个实践域：Enabling Security（ESEC）、Managing Security Threats & Vulnerabilities（MST）, 它们都属于ManagingSecurity and Safety能力域。而ISO/IEC 27001:2013，则从组织的整体业务风险的角度，基于PDCA持续改进的框架，为建立、实施、运行、监视、评审、保持和改进文件化的ISMS规定了要求。与软件系统安全开发相关的主要涉及A14信息系统获取、开发和维护，A10 密码学，A9 访问控制，A16 信息安全事件管理，A17等多个控制域，同时，如果存在系统外包开发，还会涉及A15供应商管理。

了解了两大体系要求后，我们再看看如何搭建流程框架并开展工作。
如果一个组织已经通过CMMI认证，现在要过ISO27001，一定重建一份体系制度文档吗？答案是否定的。
质量体系建设要围绕业务价值，更多投入有价值的活动，起到切实改进的作用， 而不是单纯的套体系套框架拿证书。
基于这个共识，根据内外部客户对于信息安全的需求以及企业的安全方针，结合公司的实际情况，完全可以将其对软件开发要求自然融入到现有的CMMI体系框架中。
“安全是质量属性的一部分”，将安全融入到质量管理是构建软件安全开发流程的基本条件。需要Security Built In的整体解决方案：通过在软件开发生命周期各阶段采取必要的、相适应的安全措施来避免绝大多数的安全漏洞，以交付符合安全要求的系统。

要求目标和方向框架确定，并取得高层领导支持，就该开始撸起袖子加油干了。通过现状调查和差距分析，并针对性选用安全专项活动和对应的工具方法，逐步融入并优化已有开发流程。

在研发开发流程中嵌入Security、Safety以及隐私保护的要求时，网络安全、功能安全、隐私保护，应该纳入到OEM、Tier1的研发流程中去，具体包括：
产品定义阶段：系统性规划安全、隐私、韧性等相关的需求与特性，并导入到设计环节进行落地；
产品实现阶段：分别在编码、构建、测试、发布环节采取针对性的策略与措施，将安全能力进行固化，确保来源可信、编码可信、构建可信、测试安全；
使用阶段：在部署与运维环节，通过软件完整性保护、漏洞管理、隐私保护等措施确保使用部署与运维的安全；

以下是擎标给企业的几点建议：
1. 流程制定不要做成两张皮：说到做到，知行合一。
2. 注重对全员的安全意识培训。
3. 流程和先进工具的有机集合，能有效提升工程能力。
4. 在整个软件开发生命周期中要确保将安全作为软件的一个有机组成部分，贯穿产品定义、需求、设计、开发、测试、发布、运维全过程。
5. 软件安全是以风险管理为基础：安全不必是完美无缺，但风险必须是能够管理的。
6. 最适宜的软件安全策略就是最优的风险管理对策。这是一个在有限资源前提下的最优选择问题。