【文/观察者网专栏作者 熊节】 ，今天小编就来聊一聊关于智能防疫报告发布?接下来我们就一起去研究一下吧!
智能防疫报告发布
【文/观察者网专栏作者 熊节】
与新冠疫情防控相关的软件系统在关键时刻出现技术故障的问题，一直以来备受关注。这样的重要系统屡屡出现重大技术故障，暴露出我国当前数字化建设过程中的若干短板，尤其是整个信息产业普遍缺乏交付可信软件系统的能力。
“可信”的门槛
按照英国可信软件基金会（Trustworthy Software Foundation）的定义，可信的软件系统应当具备以下5个方面的特质：
无害性（Safety）：软件运行时不会对任何东西或任何人造成伤害。
可靠性（Reliability）：软件正确运行不发生错误的能力。
可用性（Availability）：软件在需要时正常运行并提供服务的能力。
坚韧性（Resilience）：软件从错误中快速和完全恢复的能力。
安全性（Security）：软件防护恶意软件、黑客或意外误用造成危险的能力。
所有人都会赞同，良好的软件系统应当具备上述这些特质，服务于大众重要应用场景的软件系统应当是可信的。然而事实证明，获得可信的软件系统并非易事。即便是当前最受重视的疫情防控相关系统，由“已在国内17个省120多个地市部署应用”的行业领先企业来实施，仍然会在关键时刻不可用、且无法从错误中快速恢复。
更值得关注的是，在我国大张旗鼓开展数字化新基建的大背景下，采购软件系统的甲方单位普遍缺乏对软件项目实质性的监管治理能力。大部分甲方单位、尤其是信息化程度较低的传统行业和中西部地区甲方单位，基本不具备实质管控软件项目的能力。
曾经，某西部地区知名国企采购一个软件系统后，不确定乙方是否按合同要求交付了源代码，请笔者帮忙鉴定。笔者打开甲方传来的一个压缩包一看，只有若干光秃秃的.java源文件，前端网页源码、构建脚本、配置文件、数据库脚本、部署脚本等必要工作件（artefacts）全部付之阙如。
拿着这样一堆“源代码”，甲方根本不可能重新构建出线上运行的软件系统，甚至无法知道自己拿到的究竟是不是线上系统的源码，更遑论对其质量和可信性进行任何有效的管控。
在极度简化的场景下，软件开发商使用人类可读的编程语言来开发软件，产出的成果就是源代码。源代码和图片、文本等各种资源文件一起，再加上众多依赖软件，通过一个叫做构建的过程，被打包成为可执行的软件包，其中的内容通常是人类不可读、但是计算机可以执行的二进制文件。这个软件包再与各种配置文件相结合，通过叫做部署的过程，被安装到真实使用的生产环境上，成为线上运行的软件系统。
典型的（过度简化的）软件交付过程
在这个过程中，所有工作件的质量、所有操作的质量，都会影响最终线上系统的质量。
然而在当前我国数字化项目建设中，很多甲方只获得乙方构建部署完成后的线上系统，对构建过程、部署过程及涉及的工作件无法触及，也没有专业技术能力评判这些过程和工作件的质量。毫不夸张地说，很多数字化项目中，甲方实际上只获得了软件系统的使用权，根本没有获得系统的所有权。
甲方对软件系统所有权和管控权的缺失，会带来两个直接的恶果。首先是形成对厂商的严重依赖甚至绑定。因为甲方没有掌握软件交付过程和工作件，未来任何修补和增强都只能依赖原厂商，客观上形成原厂商的反竞争壁垒。另外，软件系统质量是否过关、是否可信，因为甲方不掌握软件交付过程和工作件，基本只能依赖厂商“又当球员又当裁判”。
笔者在之前接受观察者网采访时打了一个比方：
我国现在很多软件系统的验收，甲方既没有能力检验软件的无害性、可靠性、可用性、坚韧性、安全性等非功能指标，也没有能力深入软件交付过程审核其架构质量、代码质量、供应链质量等质量指标，常常只是以最终用户视角把软件功能跑一遍就完成了验收。这就好比修建一座大桥，甲方既不检查桥梁结构是斜拉式还是拱式，也不监督桥墩的施工质量，到竣工那天开一辆小轿车从桥面上顺利通过就算完工验收。至于大桥是否安全可靠，就全凭乙方自己提供的一堆文档来论证了。
这听起来可能荒诞，却是当前行业的真实现状。
英国政府如何落实可信要求
英国政府和业界几年前已经开始重视软件可信能力。英国标准协会（BSI）于2014年发布了《软件可信：治理和管理》规范，2018年又代之以《信息技术系统可信：治理和管理》规范。
不过，英国政府对可信的重视为中国业界同行所知，大约是从他们以“软件可信能力欠缺”为由限制华为产品开始的。
英国政府对华为实施审查的机构“华为网络安全评估中心”（HCSEC）从2015年起开始发布监督委员会年度报告（可在英国政府网站下载），迄今已发布7期。透过这7期年度报告，可以部分还原英国政府落实软件可信要求的治理结构和审查内容。
治理结构
HCSEC成立于2010年，其目的是“根据华为与英国政府之间的一系列安排，为英国电信市场上使用的一系列华为产品提供安全评估，以规避因华为参与英国部分关键国家基础设施而带来的任何风险”。2013年，该机构共有21名员工，到2020年已增加到42名员工。
HCSEC是华为下属的一家全资子公司。但这只表示华为要承担审查相关的费用，却不表示华为能“又当球员又当裁判”。该中心监督委员会的主席由英国国家安全顾问指派，主席再邀请其他委员会成员，也就是说，该中心的人事安排完全在英国国家安全委员会的控制下。
实践上，HCSEC监督委员会的主席一直由政府通信总部（GCHQ）的主席兼任，前几年是夏兰·马丁（Ciaran Martin），2020年由琳迪·卡梅伦（Lindy Cameron）取代——GCHQ是向英国外交大臣汇报的情报和国家安全机构与国家安全局（MI5）、秘密情报局（MI6）一同接受联合情报委员会（JIC）的领导，其主要职责是向英国政府和英军提供情报和信息保障。
华为现任监事会副主席、运营商BG总裁丁耘一直在HCSEC监督委员会担任副主席，监督委员会的其他成员还包括华为英国区管理董事、英国内阁办公厅国家安全秘书处网络安全主任、英国国家网络安全中心（NCSC）技术主任、以及白厅各部的代表。从监督委员会的人员构成就能看出，这个委员会确保了HCSEC服务于英国的国家安全利益。
另外，HCSEC还每年聘请知名审计事务所安永（Ernst and Young）对自身运作的独立性进行审计——这里所说的“独立性”特指“独立于华为总部”。安永基于国际鉴证业务准则（ISAE）3000的规范，从财务预算、人事、采购、评估计划、与华为的协作关系、评估汇报机制等角度审计HCSEC的活动。
在2015年的审计报告中，安永指出：HCSEC雇员的奖金是由华为英国公司根据华为公司的标准计算的，HCSEC管理层无法审查或批准员工的奖金，并建议未来改为由HCSEC管理层负责审查其雇员的奖金分配。
安永还指出，部分HCSEC雇员尚未取得“高度审查”（DevelopedVetting）级别的安全许可，并建议未来强化对员工安全许可级别的管理制度。在外部专业审计公司的帮助下，HCSEC雇佣了一批通过英国政府安全审查的专业人士，给他们设置了不受华为影响的激励制度，从而确保了对华为产品评估审查的独立性。
HCSEC的组织架构
审查内容
虽然对华为产品的评估是基于BSI的可信规范，但纵观7年的报告可以发现，HCSEC关注的重点并不是某个具体的软件缺陷或漏洞，而是华为持续交付可信软件的能力。从2015年发布的第一期报告到2020年发布的第六期报告，HCSEC一直在跟华为强调同样的几个问题：
首先是软件构建流程一致性。HCSEC在2016年报告中指出，华为的多款运营商产品缺乏二进制等价性（binary equivalence）——即，HCSEC拿着华为提供的源代码，无法构建出与线上运行的可执行软件包等价的软件包。HCSEC提出了一个非常合理的置疑：我们对源代码做再多的审查，如果不能验证这份源码正是线上系统的源码，又如何能说这些审查是有效的呢？
2018年的报告中，HCSEC声称：在经过“大量努力”后，他们终于成功地从源代码构建出一个与正式发布的可执行软件包等价的软件包，然而这个产品尚未被任何英国运营商正式使用。其他已经投产使用的产品，HCSEC仍然无法自主构建出来。因此HCSEC认为，华为的软件构建流程缺乏端到端的可靠性，不能保障持续一致地交付可信的软件。
合理的置疑：缺乏二进制一致性，如何保障审查的有效性？
然后受到强调的是软件供应链可信性。在2018年的报告中，HCSEC记录了在华为上海研究所举行监督委员会会议期间，在华为软件研发现场获得的一手信息：在华为的一个产品中，就存在70多份OpenSSL——这是一个常用的开源组件——的完整拷贝，涉及4个不同的OpenSSL版本。在整个华为产品体系中存在“无数个”OpenSSL版本，其中一些甚至不是该组件的正式发行版本。HCSEC认为，这表明华为缺乏良好的配置管理和软件组件生命周期管理实践，会增加软件供应链风险发生的概率和管控的难度。
HCSEC对软件供应链可信的要求并非空穴来风。现代软件开发高度依赖于第三方组件、尤其是开源软件组件。虽然软件厂商往往会声称“100%自主研发”，但软件产品中绝大部分、经常多达99%的代码是以依赖的形式引入的，厂商自主编写的代码通常只占整个软件的1%左右。一个典型的现代商用软件通常会依赖几千、上万个开源组件，其中任何一个组件被发现安全漏洞，都可能给整个系统造成损害。
去年12月，一个用于记录服务器日志的开源组件Log4j被爆出安全漏洞，据估计互联网上70%以上的企业系统都因此暴露在安全风险下。如果软件研发组织不能有效地管理软件供应链，对开源软件的依赖管理混乱而无章法，软件产品的可信程度必然大打折扣。
HCSEC还一直强调软件代码编写质量。同样在2018年的报告中，HCSEC指出：“华为的软件开发人员大量地违背基本的安全编码实践，包括华为2013年推行的内部编码标准也没有得到有效执行；尽管有一些自动检测违反编码规范的工具存在，工程师却常常对工具检出的告警视而不见、甚至直接关闭某些类型的告警”。
HCSEC认为，尽管华为强制推行安全编码标准，但管理要求并没有落到实处，客观上体现为代码质量不稳定、不一致，从而削弱了华为持续地、一致地交付可信软件系统的能力。
综观HCSEC的报告，可以看到英国政府作为甲方看待可信问题的思路：软件系统的长期可信，不在于能否解决某一个两个缺陷或漏洞，而是需要建立一套持续地、一致地交付可信软件的流程和机制；而流程和机制的运行，最终要落实到乙方的组织能力和人员能力上。如果能力不足、缺乏有效的流程和机制，那么不管应对某一个具体问题多么积极主动，这个乙方供应的软件系统长期来看仍然是不可信的。
尽管HCSEC最近的报告表现出受政治影响、钻牛角尖的趋势，但这个思路、以及他们落实这个思路的治理结构和审查方式是值得我国甲方单位学习借鉴的。
被甲方倒逼出来的可信能力
华为以积极正面的态度接纳了HCSEC的批评意见，并投入了大量资源着手强化软件可信能力。
就在HCSEC措辞尖锐的2018年度报告发布后不久，任正非在2019年致全体华为员工的第一封信中就提出要“全面提升软件工程能力与实践，打造可信的高质量产品”，要求全体员工、特别是软件工程师“从最基础的编码质量做起”、“深刻理解架构的核心要素”、“重构腐化的架构及不符合软件工程规范和质量要求的历史代码”、“深入钻研软件技术”、“遵守过程的一致性”，并特别强调“全面强化以Committer角色为核心的代码审核和提交机制，代码经过更加严格和系统的审核才能合入版本”。
这可能是我国IT行业历史上首次有一家重要企业将代码层面的能力建设提到如此高的地位。同年，丁耘承诺华为将在未来3-5年投入超过20亿美元资金，用于在包括软件和硬件工程、第三方组件管理、公司文化等八个关键领域实现可信。
华为全面强化软件可信能力的具体举措大多不为外人所知，但透过零星的公开信息，仍能一窥这些举措。尤其针对HCSEC多年强调的三方面问题，华为的应对取得了明显的成效。从华为的案例，能看到在具备高度专业能力的甲方驱动倒逼下，乙方如何提升自身交付可信软件的能力。
针对软件构建流程一致性问题，华为建设了内部的研发云平台，把原来分散在开发人员各自工作环境中的构建流程集中管理，统一代码管理规范、统一构建过程、统一质量标准。到2022年，据称华为内部研发云平台搭建了超过40万个CPU的计算资源池，支撑华为超过10万开发人员每天100万次以上软件构建，彻底解决了软件构建流程不一致、源码与二进制软件包无法证明等价性的问题。
针对软件供应链可信性问题，华为一方面投入大量成本和精力清理过时的、不规范的依赖软件，同时在内部研发云上建设了受控的开源制品库和开源软件审查机制，从而尽量降低被开源供应链投毒的风险。
针对软件代码编写质量问题，华为内部开发了可信认证考试体系，并要求所有技术人员通过考试。考试内容涵盖编程知识、安全编程、质量、隐私、开发者测试、设计模式、重构等基础技术能力。
从2021年HCSEC发布的年度报告中，可以明显看到华为建设可信能力取得的进展。在这份报告中，HCSEC多少有点不情不愿地承认：“2020年期间，华为在补救英国网络中产品的非主流支持组件方面取得了很大进展，在二进制等价性、固网产品质量问题和漏洞管理方面也取得了与预期一致的进展”，但又马上话锋一转，说：“在2020年的过程中，在满足NCSC所期望的产品软件工程和网络安全质量方面没有整体改善”——笔者竟然从这份一本正经的报告中读出了“虽然我提的所有问题都得到了解决而且我也提不出什么新的问题了，但是我就是对你没有信心”这样无奈的傲娇感。
华为（新华社资料图）
我国信息产业应如何建设软件可信能力
抛开带有政治偏见的傲娇姿态，英国政府作为甲方对软件系统供应商的监管治理方式，有很多值得学习的地方。我国政府和国企作为数字化新基建的大甲方，可以参考借鉴英国在软件可信方面的治理结构和审查内容，建立一套更完善的软件可信准入机制，进而牵引倒逼乙方企业提升自身能力，从而促进整个行业基础能力的提升。
首先应当设置独立于供应商、服务于甲方利益的第三方专业机构，代表甲方负责对重要软件系统的技术评估、审计、验收工作。这类专业机构应当充分利用市场机制吸引具备专业技能的人才，同时又应当为其设置预防腐败的围栏机制。
受命于英国政府的HCSEC雇佣的专业人士有能力评估软件从源码到二进制包的构建过程、有能力评价产品源码是否遵循编程最佳实践，同时该机构又外聘安永对其独立性进行审计，整个机构的运行费用还是由乙方来承担的。这个巧妙又平衡的治理结构，值得我国政府和国企借鉴。
同时，政府作为国家数字化战略的引领者，应当考虑牵头建设一套标准的软件研发云平台，将代码库、依赖库、构建流程、质量保障流程、产品发布流程等绝大多数软件项目和产品共通的流程、机制和基础设施固化、标准化到研发工具中，并推动牵引其成为行业标准实践。
即便短时间内无法实现软件质量和可信性的显著提升，至少能确保甲方能获得源代码、能从源代码构建出二进制软件包、能保障源码与二进制软件包等价，这就已经对提高软件可维护性、降低厂商绑定有很大的意义。对可信软件交付提供支撑的研发工具，也是我国工业软件装备体系上的一块短板，目前仍严重依赖国外软件。软件研发工具的自主国产化，也应当受到国家重视。
最后，标准制订机构和高校应当重视软件开发工程师的基础能力、尤其是基本的编程和设计能力建设。具体而言，诸如开发者测试、代码重构等已经被欧美业界证明对软件质量价值巨大的实践，在我国IT业界一直没有得到广泛接受，这与过去二十年间标准制订机构和高校对基础编程能力的忽视是直接相关的。尽管多年来业界一直有一种幻想，认为靠“软件工程”、靠“社会化大生产”，就能降低对一线程序员的能力要求，然而事实是绝大多数的技术决策仍然是在编码的阶段由程序员做出的。
正所谓“魔鬼藏在细节里”，靠流程和文档解决不了软件质量差、缺陷多、可信性低的问题。长期来说，整个行业可信能力的提升最终还是要落实到全行业从业者能力的普遍提升上来。
本文系观察者网独家稿件，文章内容纯属作者个人观点，不代表平台观点，未经授权，不得转载，否则将追究法律责任。关注观察者网微信guanchacn，每日阅读趣味文章。
