信创企业如何落地软件开发安全？

信创企业如何落地软件开发安全？

　　向日葵软件下载,小聪软件,网上赚钱的软件现如今，是“软件定义一切”的时代，软件已然成为人类社会基础设施的一部分，与个人生活、社会民生、国家发展高度融合。而大力发展信创是我国目前重要的一项国家战略，为当今形势下国家经济发展注入了新动能。

　　发展信创是为了解决本质安全的问题。本质安全也就是将以前依赖国外的产品和技术变成自己可掌控、可研究、可发展、可生产的产品与技术，通过发展信创产业构建自己的IT产业标准和生态，使得IT产品和技术安全可控。国产操作系统、数据库、中间件、应用软件快速发展，持续构建完善且丰富的行业生态。

　　当下因软件存在的缺陷而导致的网络安全问题越来越严重，CNVD 已收录各类安全漏洞信息超16.6万条，其中：超过95%的安全漏洞都发生在各类软件本身，而当中又因为软件开发相关问题造成的安全漏洞占96% 以上。由此可判断，在开发阶段产生的软件缺陷会成为阻碍信创发展的一道技术难关。

　　如果我们把软件开发类比建筑工程，一栋建筑从设计到建设再到落成的过程中：设计决定了建筑的品质，基础决定了建筑的高度，材料结构决定了建筑的安全程度。同理，构造软件的每一行代码、每一个组件都将影响整个软件的可用性和安全性。我们需要像修建高楼一样构造软件，从规划图纸到着手建设的每个环节都要做好相应的安全措施，才能保证最终交付良好的产品。

　　由于软件本身存在的安全隐患会被人有意或无意的攻击后造成的数据泄漏、系统崩溃，需要我们对软件本身的安全性额外加以重视。可以举个更形象的例子，就像胎儿要进行产检一样，在整个胎儿发育过程中，我们需要持续地对胎儿进行观察检测，包括B超、基因筛查、唐氏筛查等等，通过各种指标来确定胎儿在发育过程中是否是健康的状态。如果发现问题，就能赶在胎儿出生之前做好防护工作，如果等胎儿出生后再发现问题就为时已晚了。

　　我们的开发安全理念就类似于胎儿产检，我们通过在开发过程中的各个阶段做好相应的安全设计或安全检测等，来解决软件的“先天缺陷”，如此一来软件的交付就会像胎儿健康出生一样有保障。

　　从更实际的角度看，开发安全不仅仅是为了降低安全风险。一方面， 我们都希望将软件维护成本控制在合理范围内。但如果忽视软件开发安全，往往需要在软件交付后花费大量资金填补安全漏洞，导致维护成本远超预期。

　　早在多年前，国外调研机构就做过一项数据分析，分析表明：如果一个软件在发布后进行漏洞修复的成本，约是漏洞在研发阶段被解决时投入的成本的上百倍，约是在设计阶段被解决时投入的成本的上千倍，而这还不包括上线后漏洞所带来的额外损失。

　　所以，我们希望在软件开发中，安全是从设计源头开始，通过开发安全的赋能引入自动化的安全工具并且为相应的开发人员进行安全技能的培训，来消除安全风险，为未来降低安全维护的成本。

　　但从目前的企业情况来看，安全开发的能力普遍欠缺，缺失的方面有很多，包括架构上的缺失、人员上的缺失、资金上的缺失等等。

　　另一方面，很多开发人员不具备软件开发安全的意识和技能，同时安全人员对开发又不熟悉，两种人员在职责上有分歧，所以在此情况下也就造成了开发团队和安全团队专业知识的不对称，无法在开发阶段做好安全防护。

　　软件工程发展过程就是管理和技术并行，共同迎接挑战的历史。软件工程的发展历史分为了三个阶段：

　　第一个阶段：上世纪五十年代开始，软件属于高精尖的技术，主要客户以航天航空业和金融业为主。由于软件复杂度上升，软件质量出现了问题，造成工程进度不断延期，在此阶段，人们借鉴硬件制造业的管理方法，初步解决了软件开发中质量差、不可控、无序等问题，项目从“混乱”逐渐走向“稳定可靠”。

　　第二个阶段，上世纪八十年代开始，软件行业爆发增长，各行业对软件的需求开始增加，软件行业开始注重人与技术的思维问题，创造出面向对象的方法。开发效率和交付速度成了该阶段最大的问题，而软件工程的发展出敏捷、精益、DevOps 等概念来解决研发效率问题，项目从“稳定+可靠”走向“速度+可靠”。

　　第三阶段，正是现在我们处于的“软件定义一切”的时代，在上个阶段保障了开发效率和交付速度的开发方式下，解决软件产品可信的问题成了重点任务，我们需要从“速度+可靠”开始向“可信+速度”演进， DevSecOps、S-SDLC、内生安全等理念也随之而诞生。

　　根据国家标准《GB/T 11457-2006 软件工程术语》“软件开发过程（2.1491）”是把用户要求转化为软件产品的过程，此过程包括：把用户要求转换为软件需求，把软件需求转化为设计，用代码来实现设计，对代码进行测试，包括安装和验收。

　　我们通常把软件开发生命周期（SDLC）定义为：需求、设计、实现、验证、发布、运维6个生命周期阶段。随之产生的是我们典型的两种开发模式，就是瀑布式开发、敏捷式开发，这两种开发模式都有自己的适用场景和优势，针对软件开发安全，两种模式也都有各自的方法。

　　首先我们来看瀑布式开发，由于瀑布式是随着这个整个开发生命周期开展，所以在每一个阶段融入相应的安全过程和安全实践，就形成了我们的 S-SDLC 模型和方法论便得以形成。

　　作为软件开发安全的开山鼻祖，微软在前几年更新了之前早期的 SDL 模型，包括适用于瀑布开发和敏捷开发的实践。在新的方法论中适用于瀑布式开发的 SDL 中不在强调流程，而是强调实践，这就对应上了 S-SDLC 模型。在 S-SDLC 中我们强调对开发过程中自动化检测（包括：SAST、DAST、IAST 等），同时也强调对开发过程中人员、工具、组件的管理。

　　第二个是面向敏捷开发的软件开发安全方法。由于敏捷开发是针对需求频繁变更和细化的一种开发模式，同时伴随着互联网的快速发展，用户需求快速变化，企业业务也相应的快速变化，再加上 DevOps 开发运营一体化的理念，推动敏捷开发下开发安全方法向 DevSecOps 这种快速交付保障安全的方式来实现。

　　针对软件开发安全，国家在政策上、安全标准上都有相应的文件，也有行业标准来针对开发源代码缺陷的规范。以下摘选了一些与软件开发安全密切相关的标准与政策，可以在各软件企业在执行开发安全落地时提供参考。

　　“夯实网络安全基础”。坚持创新驱动发展，尽快在核心技术上取得突破。重视软件安全，加快安全可信产品推广应用。

　　鼓励软件企业执行软件质量、信息安全、开发管理等国家标准。加强集成电路标准化组织建设，完善标准体系，加强标准验证，提升研发能力。提高集成电路和软件质量，增强行业竞争力。

　　《网络安全产业高质量发展三年行动计划（2021-2023年）（征求意见稿）》

　　6. 加强共性基础支撑。持续建设高质量威胁信息、漏洞、恶意代码、恶意地址、攻击行为特征等网络安全基础知识库，强化网络安全知识支撑能力。加快发展恶意代码检测、高级威胁监测分析、信息处理、逆向分析、漏洞分析、密码安全性分析等底层引擎和工具，提升网络安全知识使用水平。加快发展源代码分析、组件成分分析等软件供应链安全工具，提升网络安全产品安全开发水平。积极推进网络靶场技术研究，建设结合虚拟环境和真实设备的安全孪生试验床，提升网络安全技术产品测试验证能力。

　　b)应在软件开发过程中对安全性进行测试，在软件安装前可能存在的恶意代码进行检测。

　　b) 应制定软件开发管理制度，明确说明开发过程的控制方法和人员行为准则；

　　e)应保证在软件开发过程中对安全性进行测试，在软件安装前可能存在的恶意代码进行检测；

　　f) 应对程序资源库的修改、更新、发布进行授权和批准，并严格进行版本控制；

　　g) 应保证开发人员为专职人员，开发人员的开发活动受到控制、监视和审查。

　　c)应保证开发单位提供软件源代码，并审查软件中可能存在的后门和隐藏信道。

　　该标准提出了应用软件安全编程的通用框架，从提升软件安全性的角度对应用软件编程过程进行指导。

　　该标准适用于客户端/服务器架构的应用软件开发，其他架构的应用软件也可参照使用。

　　该标准规定了代码安全的审计过程以及安全功能缺陷、代码实现安全缺陷、资源使用安全缺陷、环境安全缺陷等典型审计指标及对应的证实方法。

　　? 规定了各语言程序中典型类型源代码缺陷的表象说明、控制活动和测试方法。

　　信创软件企业如何落地软件开发安全？这里从组织管理层面和技术层面分别提出4点建议：

　　信创企业在软件开发安全落地的时候，仅依赖传统的信息安全部门或者网络安全部门的规划是远远不够的，必须要有公司领导层自上而下的推动。其中一个非常重要的原因，是软件开发安全需要和开发各个环节深度地结合，需要得到研发部门所有人全力的支持，还需要在各个开发环节给出相应的开发规范、相应的开发安全技能和工具——这些我们都需要去大力地做融合调整工作。因此，企业需要领导自上而下的推动，来引导开发安全的落地。

　　另一方面看，开发安全的成本投入是比较大的，但产生的收益却是隐性的。开发安全所创造的价值主要体现在软件的质量层面，一是减少了漏洞的存在，使得这个软件的质量更加可信；二是降低了运维的成本，使软件公司不必为补救漏洞而疲于奔命但这项价值并不能给软件销售额带来直观增长，无法创造近在眼前的利益、难以直接刺激员工积极性，必须使用眼界更开阔、目光更长远的战略加以支持。

　　除了自上而下的要求，企业还需要有相应的组织结构来做支撑，因为软件开发安全在实施过程中，会产生大量的新工作内容和工作流程，如果在工作职责上混乱不清的话，会直接影响软件开发安全的执行效率和实施效果。

　　大部分企业都设有质量管理部门，并有相应的质量管理人员。但是，质量管理部门通常不关心产品的安全问题，却忽略了安全在本质上也是产品的一项质量指标。

　　在质量管理领域里好的质量应该是设计出来的，同样软件安全也应该是在前期就应该做好的。业界已有成熟的方法和流程，如：ISO 9001、CMM等级，这些都用来保障产品的质量的方法。

　　在软件开发安全落地的过程中，需要将一些具体的软件安全指标作为质量管理的标准，比如说普通缺陷和高危漏洞的数量、漏洞修复情况等，质量管理部门可以根据这些指标来决定产品是否可以上线或交付。

　　一套成型的度量体系，能够将软件开发安全实施的效果形象化地呈现出来。为何要做效果可视化，原因可见于第1点管理建议，软件开发安全需要通过自上而下的推动。若要普及安全意识，就必须让其他公司员工亲眼“看见”安全的重要性。只有将安全的效果可视化，才能更容易地获得管理层和团队其他人的持续性支持。

　　在做这个度量体系之前，我们还需要达成一个共识，就是“世界上没有百分之百的安全，因为安全本身就是动态变化的。”我们不能保证实施了开发安全就不会有漏洞存在，但可以给出一个相对合理的预期，通过软件开发安全实施后，我们尽可能减少了缺陷的存在，把风险控制在一个可控范围以内，在这种情况下建立一套度量体系，通过度量方法把软件开发安全成果呈现出来。

　　一般而言，成果呈现有两种方式。一种是通过软件开发安全能力成熟度来体现，能力成熟度的提升可以证明团队的软件开发安全能力得到了提高，能够开发出更加安全可信的软件产品。

　　另一种，是通过一些结果性的数据来判断我们开发安全是有效的。比如说我们能够在软件上线前做了相应的测试和修复工作，来表明软件上线时是不带有严重高危漏洞，这种情况下也是一个非常好的这么一种结果的一种展示。

　　在开发安全业界中，比较成熟的度量体系有两种，一个是 OWASP SAMM 模型，另一个是 BSIMM 模型，这两个模型在行业里面有很高的知名度，也是很多团队在做软件开发安全能力评估的时候常用的方法。

　　软件开发安全不仅仅是偏重于方法和实践， “人”也是其中非常重要的一个因素。想让开发人员了解并且关注软件开发安全，就需要建立起一套合适的安全人员培训体系。与信息安全培训不同，安全人员培训更聚焦在软件开发安全的意识理念和技术能力方面，其中的意识培训板块包括了软件开发安全的基本知识，开发流程与典型的实践，还有一些国家法律法规以及行业标准层面的信息。

　　除了软件安全意识培训外，还有相应的技术能力培训，其中包括安全编码的能力、代码审计能力、威胁建模能力等。在整个培训体系下，我们需要把培训分成不同等级，再去面向不同类型的开发人员和安全人员来提供培训内容。

　　在信创软件开发过程中，增加一些威胁建模的设计工作。它能建立起产品的威胁模型，通过模型化的方法来管理软件的安全威胁，能有效侦察风险与推进缓解措施的实施。

　　STRIDE 威胁建模方法可以将大颗粒度的威胁结构化，避免威胁模型遗漏大颗粒度的威胁，保证威胁的完整性；

　　一套威胁模型的最核心价值，就在于能发现软件的设计漏洞，即发现某个具体的威胁没有相应的缓解措施或缓解措施不足。

　　安全功能的组件化，能帮助我们有效规避编码漏洞。固然，安全扫描工具能够识别一些已经存在的编码漏洞，却无法从防治编码漏洞的产生。安全功能的组件化的意义，就在于从根源上遏制漏洞的产生。

　　虽然之前提到了通过培训提高安全编码能力，但我们还是不能保证所有开发人员编写的代码都不含漏洞。而如果我们能把一些安全功能组件化，尽可能简化开发人员自主编写的流程，就能降低代码出错的风险、提高代码编写的规范性。因为这些组件在成为开发团队的公共组件时，本身就获得了安全团队的重点保障。

　　第三点是管理好开发过程中应用的第三方组件的风险。这里的“第三方组件”不仅仅包括开源组件，还包括商业性的组件，这些组件不仅多见于信创行业，在其他行业所应用的占比也是非常大的。

　　尤其是现在对软件供应链安全的高度重视，大家对组件自带安全漏洞而造成的破坏力也是有目共睹。所以，我们有必要做好第三方组件和软件的资产管理，通过相应的资产清单，来确定团队研发的软件哪些使用了第三方，一旦软件发生漏洞事件，可以根据清单迅速排查处理。

　　无论是瀑布式开发场景下的 S-SDLC 还是敏捷开发场景下的 DevSecOps，软件开发安全的落地始终离不开流程体系和高度自动化的工具链的融合，常见的应用检测工具包括 SAST、DAST、IAST、SCA 、FUZZ 等，都是有助于软件开发安全落地工作的自动化工具，我们可以通过使用这些工具来提升真正软件安全测试的效率和软件开发安全的工作效率。