【翻译】英国HCSEC对华为产品安全方面的调查报告【翻译】英国HCSEC对华为产品安

译者的话
目前越来越多的企业推出国际化的产品和服务，而国际市场已经被发达国家用专利、法律法规、准入制度所占领，中国企业家是国际市场的 “后来者”，“走出去” 要承受更多、更大的风险。这就要求企业作更多的努力，尽量根据市场的规则来行事，以减少风险。但互联网公司对这个客观环境认识不清或者没有足够的认识，从而把自己推向“风险地带”，所部署的产品和软件更需要“打铁自身硬”。
从译文中我们可以从技术层面了解国际商业环境上对以服务为中心的软件安全方面的 “苛求”。当然各家业务不同，对标华为这样的商业模式未必适用，但从业者依然可以管中窥豹发现除了符合 GDPR 对数据安全方面的要求，企业应当具备什么样的应用安全交付能力？业界领先的标准是什么？我们自己做得差距在哪？
背景新闻

[英国的NCSC监督员表示，华为尚未修复其安全漏洞](https://www.theregister.co.uk/2019/02/20/ncsc_huawei_security/)
[英国再爆华为安全漏洞？华为已回应](https://www.eet-china.com/news/201903291048.html)
[华为网络安全调查报告发布：存在严重软件安全问题](https://www.expreview.com/67589.html)
下文的链接解释了任正非19年一号总裁令提到的《关于启动彻底变革，提升软件工程能力，打造可信的高质量产品》的来龙去脉，以及华为方面对csec认证这件事的解释说明。
[华为轮值董事长徐直军：华为5G绝对安全美国禁用或为其他目的](https://tech.qq.com/a/20190215/007916.htm)
5年20 亿美金投入的重点：

本质上，我们将采用未来的标准、未来的需求来重建我们的软件开发过程，并且在我们重构遗留代码的过程中，我们将遵循这些未来的标准。

为了获得客户或政府部门的信任，我们不仅要确保结果的高质量和可信性，而且还要确保生产这些软件的过程的高质量和可信性。我们认为这是华为实现我们长远目标的基础或基石。

参考阅读文章

[华为是网络安全的威胁者还是捍卫者？](http://3g.forbeschina.com/review/201012/0005918.shtml)

[CSEC咨询，求大神讲解 ](http://xinsheng.huawei.com/cn/index.php?app=forum&mod=Detail&act=index&id=3511681)
[华为在布鲁塞尔成立网络安全透明中心](http://xinsheng.huawei.com/cn/index.php?app=forum&mod=Detail&act=index&id=4204723&p=1#p38049955)
【【翻译】英国HCSEC对华为产品安全方面的调查报告】[松山湖ICSL是个神马部门？不产粮，为毛还这么屌 ](http://xinsheng.huawei.com/cn/index.php?app=forum&mod=Detail&act=index&id=3489163&p=1#p28053039)
[【研发】“头痛医头，脚痛医脚”式的源码扫描工具何时休止 ](http://xinsheng.huawei.com/cn/index.php?app=forum&mod=Detail&act=index&id=3845121&search_result=20)
[https://cn.linkedin.com/in/qiuhua-xie-b6aa8710a](https://cn.linkedin.com/in/qiuhua-xie-b6aa8710a)
正文
华为网络安全评估中心监督委员会年度报告
第一部分：简介
略
5. 监督委员会第五年工作的主要结论是：

2018 年，作为管理华为参与英国核心网络对国家安全风险战略的一部分，HCSEC 履行了向 NCSC 和英国运营商提供软件工程和网络安全保障的义务;
然而，正如 2018 年报告的那样，HCSEC 的工作继续证实了华为软件开发环节中存在问题给英国运营商带来了显著增加的风险，这需要持续管理和采取缓解措施；
在上一份 2018 年报告中所提出的问题没有取得实质性进展；
监督委员会继续只能提供有限度的保证，即可以对目前在英国部署的华为设备中管理长期安全风险;
监督委员会建议，在英国现网部署的场景下，很难对未来产品进行适当的风险管理，直到华为软件工程和网络安全流程的根本缺陷得到纠正为止;
目前，监督委员会还没有看到任何让华为成功完成其转型计划要素的能力，而华为提出的转型计划就是解决这些潜在缺陷的核心方式。理事会将要求持续证明 HCSEC 和 NCSC 验证的更好的软件工程和网络安全质量;
总体而言，监督委员会只能提供有限度的保证，即华为参与英国关键网络对国家安全的所有风险可以在长期内得到充分缓解。

第二部分：技术和运营报告
这是华为网络安全评估中心（HCSEC）监督委员会的第五份年度报告。该报告可能包含一些更广泛的华为公司战略和非英国方面利益的参考。重要的是要注意，监督委员对于这些事项上没有直接的根据，只有确保与 HCSEC 的英国业务有直接结论有关联的情况下才将其考量在内。英国政府对这些非英国方面的关注仅限于确保 HCSEC 有足够的能力履行其对英国的约定义务。除此之外，无论是英国政府，还是整个董事会，都没有在这一过程中施加任何影响。
介绍

这是华为网络安全评估中心（HCSEC）监督委员会的第五份年度报告。HCSEC 是牛津郡班伯里的一家机构，隶属于华为技术（UK）有限公司（Huawei UK），其母公司是一家总部位于中国的公司，华为技术有限公司，现在是全球最大的电信供应商商之一。
HCSEC 已经运作了八年。2010 年 11 月，根据华为与 HMG 达成的一系列协议，该合资公司成立，旨在减轻华为参与英国关键国家基础设施部分项目所带来的任何潜在风险。HCSEC 为英国市场使用的一系列产品提供安全评估。通过 HCSEC，英国政府可以了解华为在英国的战略和产品范围。英国国家网络安全中心 (NCSC，前身为 GCHQ) 是国家信息保障技术主管部门，也是政府网络安全方面的主要运营机构，负责政府处理 HCSEC 和华为更广泛的技术安全事务。
HCSEC 监督委员会成立于 2014 年，由 NCSC（国家网络安全中心）首席执行官 Ciaran Martin 担任主席，他也是 GCHQ（应该政府通讯总部）负责网络安全的执行董事。监督委员会继续包括华为的一名高管担任副主席，以及来自政府和英国电信行业的高级代表。监督委员会的组成没有发生重大变化，但成员在 2017-18 年发生了变化。这主要是由于 HMG 和华为的员工轮岗造成的。
这是监督委员会成员一致通过的第五份年度报告。同去年的报告一样，审计委员会同意不需要一个保密的附件，因此，本报告的内容是全面的分析和评价。
报告如下：

第一节规定了监督委员会的职权范围和成员资格;
第二节描述了 HCSEC 的人员配置，技能，招聘和住宿;
第三节涉及 HCSEC 技术保障，优先排序和研发;
第四节总结了 2018 年独立审计的结果;
第五节汇总了一些结论。

第二部分
第一节：HCSEC 监督委员会：职权范围和成员资格
略
第二节 HCSEC 雇员
略
第三节（a）HCSEC 技术保证
略
第三节（b）支持性技术证据

HCSEC 评估流程
略
HCSEC 计划建立和优先级划分
略
HCSEC 技术工作和高层次结果概述
3.7HCSEC 和 NCSC 在 2018 年开展了重要的技术工作，NCSC 承担了职责范围第 3.3 段所设想的监督委员会的审计工作。本节的下半部分提供了这项工作的详细信息，但为了方便起见，这里提供了高级别的结论和结果。

华为提供了四种产品来测试二进制溯源一致性。HCSEC 对其进行验证的工作仍在进行中，但已经暴露了底层构建过程中更广泛的缺陷，这些缺陷需要在大规模演示二进制一致之前加以纠正。NCSC 已向监管委员会建议，作为华为转型计划的一部分当务之急应该是纠正这些潜在缺陷。除非做到这一点，否则不可能确信 HCSEC 检查的源代码正是用于构建在英国网络中运行的二进制文件。（译者：英国政府 NCSC（国家网络安全中心）要求部署的所有产品都有可复现的构建过程，在由华为提供稳定具备编译环境的镜像的中，保证提供的源代码和二进制组件可以编译出同现网部署完全一致的产品安装包文件）
由于各种与构建相关的问题，很难相信类似华为设备的不同部署大体上是同等安全的。例如，很难确信通过持续集成流程的正常运行，在一个构建中发现的漏洞在另一次构建中得到修复。这种能力以及对特定源代码集精确用于构建特定二进制的端到端能力保证通常会被视为现代软件工程所带来的附加影响。
华为的配置管理改进自 2010 年以来一直受到英国社区的推动，但并没有在产品和平台开发组或配置项类型 (源代码、构建工具、构建脚本等) 之间得到普遍应用。如果没有良好的配置管理，华为交付的产品就不可能有端到端的完整性，对华为能够理解 “任何给定的全部编译内容” 含义或者具备识别产生问题的根本原因进行分析的能力缺乏信心。
华为仍在使用一个即将退出主流支持版本的老版本，该版本是由第三方提供的一个知名且广泛使用的实时操作系统。（译者：WindRiver 家的 VxWorks，一家美国公司的操作系统）华为已经单独从供应商处购买了一项的长期支持协议，以便在未来以商业上可行的方式解决漏洞，但单内存空间、单用户上下文安全模型带来的潜在网络安全风险依然存在。NCSC 认为，目前还没有可靠的计划来降低在英国使用这种实时操作系统的风险。华为自己的等效操作系统与其他组件一样，也有许多相同的开发过程，而 NCSC 目前没有足够的证据来判断该组件的软件工程质量和网络安全影响。此外，它采用了更现代的内存和安全模型，因此与运行在操作系统上的现有产品集成会带来风险。这意味着，转向这种实时操作系统可能不会长期改善这种情况，同时会给英国运营商带来集成风险。华为、HCSEC、英国运营商和 NCSC 之间的工作仍在继续，以制定一个切实可行的计划，降低英国网络使用这种老式的第三方实时操作系统的长期风险。但是 NCSC 仍然关注自发现这个问题以来没有提出可靠计划的时间。
对华为更广泛的软件组件生命周期管理的分析揭示了导致重大网络安全和可用性风险的缺陷。这是一个重要的发现，在本节的第二部分中提供了更多的细节。对存在这一问题的现有代码库以及允许其系统性发生的有缺陷的过程进行补救，需要进行重大的纠正。

HCSEC 对 LTE eNodeB 软件的后续主要版本进行了软件工程和网络安全趋势分析。后来的版本旨在整合华为的所有改进，因此平均而言应该比以前的版本客观上更好。虽然有所改进，但产品的一般软件工程和网络安全质量仍然显示出大量主要缺陷。因此，NCSC 仍然担心华为的软件工程和网络安全能力以及相关流程未能得到充分改进。

监督委员会要求华为提供计划，以修复 LTE eNodeB 产品开发和持续工程中的软件工程和网络安全问题，并由 NCSC 在英国运营商的支持下进行审核。NCSC 和英国运营商无法接受提交的计划。NCSC 目前不相信华为能够解决它所面临的重大问题。
针对其工程流程中发现的缺陷，华为向监督委员会提出了通过五年内 20 亿美元投资改变其软件工程流程的计划。然而，这项拟议的投资虽然受到欢迎，但目前仅仅是针对尚未指明的活动的拟议初步预算。虽然对华为全球转型计划的正式监督不属于监督委员会活动的范围，但董事会希望看到转型计划的细节及其对英国网络中使用的产品的影响的证据，然后才能确信它将会推动更改。除非提供并审查了详细的计划，否则无法对华为能够解决的问题具备任何程度的信心。
HCSEC 持续发现华为产品的严重漏洞。2018 年，数百个漏洞和问题被报告给英国运营商，告知他们的风险管理和补救措施。在以前版本的产品中发现的一些漏洞仍然存在。

结论：HCSEC 能力
3.8 NCSC 仍然认为，英国的缓解战略 (包括 HCSEC 开展技术工作和监督委员会作为两个组成部分提供保证) 是管理华为参与英国电信部门风险的最佳方式。本报告中暴露的问题的发现表明该模型工作正常。华为目前继续参与这一进程。
3.9 HCSEC 在 2018 年的工作继续在必要的基础工具方面发展能力，为英国运营商和 NCSC 提供理解和技术安全产品。到 2018 年，HCSEC 继续在华为产品中发现问题，展示了他们持续发现华为产品缺陷的能力。此外，2018 年 HCSEC 花费了大量精力分析华为研发人员的所声明的，并有效地从一个异常复杂和难以控制的开发和构建过程中逆向工程发现根本原因。这需要卓越的技术技能和洞察力。
3.10 HCSEC 继续拥有世界一流的安全研究人员，他们正在开发新的工具和技术，以使英国社会了解华为在复杂电信领域独特的软件工程和网络安全流程对软件工程和网络安全的影响。
3.11 在核心网络安全工作方面，向英国运营商报告的漏洞和问题数量已增至数百个。鉴于 2018 年进行的产品评估数量有所增加（2017 年为 39 次，超过 27 次），这一数字大致与往年持平。在以前的评估中报告的一些严重漏洞在较新版本中继续存在。
3.12 这些年来，漏洞的特征没有显著变化，许多漏洞具有很高的影响（相当于高的基础 CVSS 分数和相关的运作场景），包括公共可访问协议中未受保护的堆栈溢出、导致拒绝服务的协议稳健性错误、逻辑错误，加密弱点、默认凭据和许多其他基本漏洞类型。尽管华为要求在研发过程中应用其安全编码标准，广泛使用商用静态分析工具，并且华为坚持对有风险代码进行重构，在目标软件工程和网络安全质量方面，HCSEC 交付给英国运营商进行评估的代码几乎没有改进。
3.13 华为设备带来的英国电信基础设施重大风险将继续需要由英国运营商进行管理，同时需要所有相关方进行大量的工作以降低现有设备的风险。NCSC 和英国运营商将继续与华为合作，为英国的设备制定可靠和可运营的修复计划。华为已同意在英国对设备的修复独立于华为可能做的任何其他工作，并将及时进行。作为正常业务的一部分，监督委员会将判断 HCSEC 在这方面的有效性。如本报告所述，目前尚不清楚英国可能会对新设备制定类似的计划。
3.14 这些风险并不是因为 HCSEC 的人员配置和能力存在任何问题，而 HCSEC 的人员配置和能力仍然是世界级的。监督委员会将希望 HCSEC 就华为选择对其开发过程进行的任何更改提供独立的意见，并确定软件工程和网络安全提升对最终部署产品的有效性。
3.15 NCSC 认为，HCSEC 仍有能力在必要的技术安全领域向运营商、NCSC 和监督委员会提供有关在英国电信基础设施中使用华为产品所承认的产品和解决方案风险的建议。NCSC 向监督委员会提交的报告指出，HCSEC 将继续提供独特的、世界一流的网络安全专业知识，以协助政府在英国运营商使用华为设备的过程中进行的风险管理计划。
结论：对英国国家安全风险的影响
3.16 上述 HCSEC 的工作揭示了华为软件工程和网络安全能力的严重和系统性缺陷。因此，NCSC 继续向监督委员会提出建议，因为 NCSC 尚未看到可靠的补救计划，因此仅对目前在英国部署的设备进行安全风险管理提供有限的技术保证是恰当的。即使这种有限的保证也只有在很大程度上归功于 HCSEC 的工作，才能在英国很好地理解华为设备的缺陷。鉴于这种知识，在极端情况下，NCSC 可以指导华为对目前在英国的设备进行补救。我们不应将这一做法视为将困难最小化，或暗示这将是一种可持续的做法。在某些情况下，补救还需要替换硬件 (由于 CPU 和内存的限制)，这可能是也可能不是常规操作员资产管理和升级周期的一部分。
3.17 鉴于良好的软件工程和网络安全实践的不足，以及华为通过其宣布的转型计划和目前未知的研发过程。很有可能对英国新产品或英国新产品的主要软件版本进行安全风险管理会更困难。根据 HCSEC 已经开展的工作，NCSC 认为很可能 HCSEC 尚未检查的产品中会出现新的软件工程和网络安全问题。
3.18 差劲的软件工程和网络安全流程会导致安全和质量问题，包括漏洞。HCSEC 中相对较小的团队发现的漏洞的数量和严重性，以及体系结构和构建问题，是一个特别值得关注的问题。如果攻击者知道这些漏洞并有足够的访问权限来利用它们，它们可能会影响网络的运行，在某些情况下导致网络停止正常运行。其他影响可能包括能够访问用户流量或重新配置网络节点。然而，大多数英国运营商实施的架构控制限制了攻击者与任何未明确向公众公开的网络元素进行通信的能力，而其他措施的实施加大了利用漏洞的难度。这些体系结构控制以及英国运营商对网络的运营和安全管理在未来几年中仍然至关重要。这些发现是关于基本的工程能力和网络安全问题会导致一些漏洞，这些漏洞可能被一系列攻击者利用。NCSC 不认为这些缺陷是中国政府干预的结果。
第三节（b）：支持性技术证据
二进制溯源与软件一致性
3.19 确保 HCSEC 检查的源代码恰好是编译到英国网络设备中执行的二进制文件的源代码一直是缓解策略的一部分。如果没有一个过程显示 HCSEC 检查的源代码和构建环境惟一地生成部署在英国网络中的二进制文件，就不可能在使用的产品的安全性和完整性方面提供端到端的保证。在华为极其复杂的构建过程中，二进制一致性被视为获得这种保证的一个中间步骤。值得注意的是，源代码到二进制链接的保证绝不能保证工程质量或安全性。之前的监督委员会报告了实现二进制一致性的新过程的详细进展，即能够构建一个产品，从 HCSEC 的源代码到一个与华为在中国研发的通用可用性 (GA)（译者：General Availability, 正式发布的版本，在国外都是用 GA 来说明 release 版本的）版本等效 (不一定相同) 的二进制版本。在上一份报告中，记录了单个产品——宽带顶端器——已经成功地创建了可重复的构建，并且该版本的部署迫在眉睫。不幸的是，由于特定于版本的依赖关系，目前英国的部署无法满足这些依赖关系，所以没有一家英国运营商能够部署这个版本。
3.20 上一份报告中设定的预期是，LTE、EPC 和光传输产品线的其余三个试点产品将在 2018 年上半年成为商用、可重复的 GA 构建。虽然二进制文件由华为研发部在一年中交付，并由华为标记为 GA，但 HCSEC 的单独验证工作尚未完成。EPC 产品的验证工作在 2018 年底才刚刚开始，光传输产品已重新安排在 2019 年开始。与所有 HCSEC 方案变更一样，这些变更代表监督委员会与 NCSC 达成一致。
3.21 HCSEC 的任务是了解华为在创建可重复构建方面面临的问题。在任何情况下，问题都与华为的基本构建过程有关，该过程没有提供端到端的完整性，不提供良好的配置管理，不提供跨版本软件组件的生命周期管理，使用不推荐的和不支持的工具链（其中一些是不确定的），以及构建环境中的不干净，其中许多 HCSEC 无法轻松重新创建。考虑到基础构建过程和驱动它的客户管理和工程过程中的基本问题，不清楚在继续二进制一致性方案时是否有任何实用性。HCSEC 和 NCSC 一致认为，作为更广泛的软件工程和网络安全转型的一部分，从头开始重新设计构建过程的努力将得到更好的投入。NCSC 的意图仍然是，在英国部署的所有产品都将具有可重复的版本，并且 HCSEC 将能够定期显示安装在英国网络中的二进制文件与可以根据 HCSEC 持有的源代码构建的二进制文件之间的等效性，这与管理良好的软件工程过程通常是一样的。最近对这四个试点产品的研究表明，鉴于华为目前的构建过程，目前这在任何有用的规模上都是不切实际的。 NCSC 已告知监督委员会，除非并且直到构建过程发生根本性变化，否则只能对目前在英国部署的设备提供有限保证。
3.22 英国运营商界仍对华为提供的类似版本软件的一致性表示担忧。在某些情况下，构建是在华为发布之前由运营商提供的运营商预期的最终配置中进行测试的。虽然这提高了预期配置的可靠性，但它可能掩盖了本报告中详述的严重问题，当配置受到干扰或漏洞被利用时，这些问题将影响网络性能，从而对网络造成安全或可用性影响。通过操作的真正一致性要求纠正此报告中的问题。
配置管理
3.23 正如 2018 年报告中所详述的，监督委员会和 NCSC 要求华为研发部门开展更多的二进制溯源方案所需的工作，HCSEC 将提供验证的。随着这项工作的进展，研发团队提供越来越多的预期之外的组件。要求 HCSEC 进行分析，以揭示导致所遇到问题的潜在系统性问题。他们发现了以下缺陷：

构建过程中使用的虚拟机的配置管理较差。具体来说，虚拟机在构建开始时并不干净，有许多包含（有时不相关）源代码、以前构建的组件和其他杂项。
构建环境（包括工具链）的配置管理较差，有时甚至不存在。工具在构建环境或不需要的环境中安装多次。许多工具明显不受支持，并且具有不受欢迎的属性，例如基于环境变量值的非确定性编译或优化。
源代码的配置管理较差。这体现在两个广泛的领域。首先，配置管理在开发团队之间的应用并不一致。产品代码与平台代码的管理方式不同，二者与第三方组件的管理方式也不同。其次，集成到整个产品体系结构中非常差，组件有多个副本和版本，显然版本相同的组件包含显著差异，组件之间的循环依赖性和某些组件在整个产品增量之间的版本中回退。

3.24 NCSC(当时的 CESG) 在 2010 年首次要求华为进行适当的配置管理，此后华为一直在投资该流程，此前监管委员会的报告详细介绍了华为在这一领域的工作。然而，由于在此期间所进行的各种技术工作，已经发现了额外组件，这表明在整个公司范围内这种推动并不一致，而且在工作期间配置项也没有得到合理化。2016 年，HCSEC 应 NCSC 的要求撰写了一份报告，概述了其中的许多问题，但华为当时拒绝了这些问题。从 HCSEC 和 NCSC 在监督委员会主持下所做的后续工作来看，现在很明显 2016 年报告中所发现的问题仍然存在，而且是贯穿公司产品线的系统性问题。于这些问题，NCSC 已经告知监督委员会，目前华为提供的产品没有端到端的完整性，对华为理解任何给定构建内容的能力缺乏信心。或者能够对已发现的问题进行真正的根本原因分析。
第三方组件支持问题
3.25 各方已投入大量精力，充分理解先前报告中提出的关于支持特定第三方软件组件的问题。这一问题与广泛使用的第三方实时操作系统的各种旧版本和即将过时的主流支持版本有关，华为选择继续在使用寿命明显更长的产品中使用第三方实时操作系统。继续使用依赖旧软件组件（包括但不限于操作系统）的产品会给运营商带来风险。此外，所讨论的操作系统基于单个内存空间、单用户模型（在设计时很普遍），这进一步增加了风险，因为在此操作系统下运行的任何进程中的单个漏洞足以危害在同一操作系统实例中运行的任何组件。华为已从供应商处购买了一份单独的长期支持协议，以在未来以商业上可行的方式解决漏洞，但单一内存空间、单一用户上下文安全模式带来的潜在网络安全风险仍然存在。保持组件最新并根据供应商版本升级版本是行业最佳实现。监督委员会和英国运营商已明确表示，长期依赖英国的这一操作系统是不可接受的，必须创建一条升级路径。在撰写本文时，NCSC 还没有看到华为为缓解这一问题而制定的可信计划，也没有看到一条升级到可支持的操作系统的途径，该操作系统具有适合现代电信运营商级通信系统的安全模式。在制定可靠的计划之前，运营商将继续进行特殊工作以降低持续风险。
更广泛的组件和生命周期管理问题
3.26 在华为上海工厂举行的 2018 年 6 月监督委员会会议上，会议结束后增加了技术跟进日程，以更好地了解更广泛的组件和生命周期管理战略，包括上文详述的操作系统问题。
3.27 第一项工作是围绕华为的意图，将即将脱离主流支持的操作系统转移到他们自己的基于开源 Linux 内核的实时操作系统上。在上海进行审查后，NCSC 得出结论，它没有足够的证据对华为自己的实时操作系统的长期持续工程充满信心。现有应用程序代码移植到更现代的操作系统内存和安全模型中存在集成风险。这会导致跨平台的风险，需要谨慎注意修复，特别是在某些情况下可能需要新硬件。需要做一些工作来权衡一个过时的操作系统的已知风险与更改到另一个操作系统的风险以及所有这些风险。对于操作者来说，这是一个非常困难的点。稍后将详细介绍。
3.28 第二项工作是确定更广泛的组件和生命周期管理是否显示出类似的问题。自从监督委员会会议在上海召开以来，工程师们有可能在现场对实时开发系统进行操作，以显示实时证据。。华为提供了预期的流程和一些高级别的证据，表明它正在被遵循。然后，NCSC 选择了一个常用的组件 OpenSSL 库，并在华为开发数据库上执行了特定的查询。这表明，允许在产品中使用的 OpenSSL 版本数量无法管理，包括不在主分支上、具有已知漏洞和不受支持的版本。（译者：为组件和产品建立并维护有效的可追溯系统十分重要）向监督委员会报告的结论是，华为的基本工程流程没有正确管理组件使用或生命周期维持问题，导致产品总体上无法支持。
3.29 监督委员会在 9 月份的会议上明确表示这是无法接受的，并重申了过去 12 个月内华为要求从根本上改造其软件工程和网络安全流程的要求。
LTE-eNodeB 的改进试验
3.30 在华为上海举行的 2018 年 6 月监督委员会会议上，HCSEC 负责分析 LTE eNodeB 两个版本之间的软件工程和网络安全质量变化。在华为计划的实施过程中，正在执行的改进过程通常是在后期版本代码完成时嵌入的。为给华为提供改进计划的时间，推迟了向 NCSC 提交本报告，但 NCSC 在 9 月份的董事会会议上提出要求，因为在确定根本原因或改变开发过程的行动举措方面缺乏进展。
3.31 期望软件的后期版本完美无缺是不现实的，但 NCSC 希望看到广泛和一致的改进。审查显示，两个版本之间的代码重复已经显著减少，一个开源组件的副本数量也显著减少。不幸的是，产品的一般软件工程和网络安全质量仍然显示出大量的主要缺陷：

广泛不遵守基本的安全编码实践，包括华为自 2013 年起强制执行的内部标准，这使得漏洞的可能性更大。这一点在不同版本之间有所降低，但仍然引起关注；
大量错误使用安全内存操作功能，显著增加了内存安全漏洞的可能性。这一点在不同版本之间有所降低，但仍然引起关注；
在执行算术运算（包括边界计算）时，大量滥用有符号 / 无符号类型并强制转换为不同的变量大小，显著增加整数溢出和下溢漏洞以及相关缓冲区大小漏洞的可能性；
软件组件导入管理不善，使得支持性和生命周期安全非常困难；
不适当地抑制静态分析工具发出的警告，潜在地隐藏漏洞；
广泛使用固有的不安全和禁止的内存操作功能，进一步增加了内存安全漏洞的可能性。这一点在不同版本之间有所降低，但仍然引起关注；
不可管理的构建过程，包括过期的工具链。

3.32 从广泛的报告中选取两个具体的例子，说明所发现问题的规模。
3.33 报告分析了常用和维护良好的开源组件 OpenSSL 的使用情况。OpenSSL 通常是在安全方面是相关重要的，它处理来自网络的不可信的数据，因此保持组件的最新版本非常重要。在该软件的第一个版本中，有 4 个不同 OpenSSL 版本的 70 个完整副本，从 0.9.8 到 1.0.2k(包括来自供应商 SDK 的一个版本)，其中 14 个版本的部分副本，从 0.9.7d 到 1.0.2k，这些部分副本编号 304。10 个版本的片段 (范围从 0.9.6 到 1.0.2k) 也可以在整个代码库中找到，它们通常是为导入某些特定功能而复制的小文件集。也有大量的文件, 再蔓延到整个代码库, 开始生活在 OpenSSL 库 3.34, 华为已经修改。在以后的版本中, 只有 6 份 2 不同 OpenSSL 版本, 5 是 1.0.2k 从一个供应商和一个叉 SDK。还有 17 个版本的部分拷贝，从 0.9.7d 到 1.0.2k 不等。来自 10 个不同版本的 OpenSSL 的片段和经过华为修改的 OpenSSL 派生文件都保留在代码库中。更令人担忧的是，较晚的版本似乎包含易受 10 个公开披露的 OpenSSL 漏洞攻击的代码，其中一些漏洞可以追溯到 2006 年。这表明由于配置管理、产品体系结构和组件生命周期管理不善，导致缺乏可维护性和安全性。
3.35 报告还分析了产品是否符合华为自己的部分安全编码准则，即安全内存处理功能。分析了 eNodeB 中一个面向公共的处理板上的二进制图像，以便在它们的安全和不安全变体中直接调用 memcpy（）-like、strcpy（）-like 和 sprintf（）like 函数。该板处理与不受信任的接口的通信，预计将以一种健壮和防御性的方式对其进行编码。在这种情况下尤其如此，因为缺乏操作系统的缓解措施。
3.36 总结：

直接调用 17 个不同的 safe memcpy（）类函数超过 5000 次，直接调用 12 个不同的 safe memcpy（）类函数超过 600 次。大约 11% 的 memcpy（）类函数直接调用是不安全的变量。
直接调用 22 个不同的 safe strcpy（）类函数超过 1400 次，直接调用 9 个不同的不安全 strcpy（）类函数超过 400 次。大约 22% 的 strcpy（）类函数直接调用是不安全的变量。
有超过 2000 个直接调用 17 个不同的 safe sprintf（）类函数，近 200 个直接调用 12 个不同的 safe sprintf（）类函数。大约 9% 的 sprintf（）类函数的直接调用是针对不安全变量的。

3.37 这些数字不包括任何间接调用，如通过函数指针等。值得注意的是，这些不安全的函数存在于二进制文件中，因此会带来真正的风险。
3.38 对相关源代码的分析令人担忧地确定了 “定义安全库”（dest，destmax，src，count）memcpy（dest，src，count）形式的许多预处理器指令，这些指令将安全函数重新定义为不安全函数，有效地消除了为删除源代码中的不安全函数而进行的工作带来的任何好处。还有一些指令强制潜在安全功能的不安全使用，例如 “定义另一个”memcpy（dest，src，size）memcpy_s（（dest），（size），（src），（size））。
3.39 这种重新定义使得开发人员很难做出好的安全选择，任何代码审计人员的工作都异常困难。这些只是示例，但表明华为自己的内部安全编码准则在本产品中并没有得到常规遵循，而且在某些情况下，开发人员可能会积极努力隐藏糟糕的编码实践，而不是修复它。
3.40 该分析表明，华为的软件工程和网络安全开发仍有重大问题需要解决。
LTE 改进计划
3.41 在 2018 年 9 月的监督委员会会议上，董事会成员越来越担心华为在纠正 HCSEC 和 NCSC 发现的基本问题方面缺乏进展。特别是，在过去的 12 个月中，在制定可靠的计划以减轻英国不受支持的软件的重要安装基础方面缺乏进展已变得至关重要。为了集中精力，监督委员会要求制定一项计划来修复单一产品，最终选择成为 LTE eNodeB。华为一直到 2018 年 10 月 19 日 - 随后延长到 10 月 26 日 - 为 eNodeB 的整治提供可靠的计划。其目的是确保华为，HCSEC，英国运营商和 NCSC 之间能够进行讨论，并确保在 12 月监督委员会会议之前进行改进，以便讨论该计划。
3.42 所提交文件的大部分内容是对 eNodeB 功能的安全性分析，主要来自 NIST SP800-187。已经确认了 HCSEC 和 NCSC 发现的问题以及一些描述基本修复的尝试，但该文件主要描述了华为目前的流程及其预期结果，而不是实际发现的产品和根本原因。报告的一小部分涉及对华为发展过程进行变更的计划。遗憾的是，交付的计划没有解决所遇到的问题的规模，也没有从根本上解决潜在的软件工程能力问题。华为还有四周时间在与 NCSC 和英国运营商的会议上提出计划。华为在那次会议上的发言表明，没有取得实质性进展。在撰写本文时，NCSC 没有看到华为在英国使用 eNodeB 或任何其他华为产品进行补救的可靠计划。
华为转型
3.43 在会议讨论 LTE eNodeB 改进计划后，NCSC 再次代表监督委员会致函华为，寻求一个可靠的计划，对已部署在英国的产品进行范围性的整改，并寻求更广泛的转型计划。将使这些问题不太可能在未来再次发生。NCSC 明确表示，如果没有这样的计划，就不可能长期对华为的技术有信心，也不可能长期支持运营商安全使用华为的技术。
3.44 华为接受了对其软件工程和网络安全流程的批评，并承诺在五年内投资 20 亿美元进行公司范围的转型，以遏制和缓解监督委员会提出的担忧。显然，任何这样的投资都必须得到包括可衡量结果的计划的支持。虽然华为全球转型计划的正式监督不属于监督委员会的活动范围，也不希望报告与英国网络安全风险无关的更广泛的事项，但董事会希望看到华为软件工程和网络安全转型的充分细节。使 IT 部门能够评估其有效控制和缓解已识别风险的程度的流程。在董事会重新评估其保证水平之前，特别是考虑到威胁环境和所涉及技术的日益复杂，将需要持续证据证明其对在英国使用的产品的影响。与此同时，NCSC 将建议监督委员会继续为目前在英国部署的设备提供有限的安全保障。NCSC 和英国运营商将继续与华为合作，为英国的设备制定一个可靠和可持续的修复计划，而不受华为任何更广泛的改造的影响。在极端情况下，NCSC 可以指导华为如何在华为的正常开发和支持流程之外修复已经在英国基础设施中的特定产品，从而将英国目前的风险降低到更合理的水平。这不是一种可持续的办法，只有一个良好的实践软件工程和网络安全开发过程才能为未来提供保证的基础。
3.45 重要的是，NCSC 目前无法预测华为未来产品在转型期间和转型后可能的技术结构和特点。此外，考虑到华为的开发过程在不同的产品组之间是不一致的，NCSC 不能假定在英国使用的产品组合的发现可以转化为其他产品。英国对华为设备在英国电信领域使用的缓解战略 (HCSEC 和监督委员会是其中之一) 预计，行业良好实践软件工程和网络安全开发及支持流程将作为基础。华为目前没有达到这一基本预期。由于 HCSEC 的运营，英国运营商和 NCSC 对当前部署的华为设备产生的风险有着重要而详细的了解。如果没有相同详细程度的重要新设备和基于现有知识的假设无法重复使用（由于不一致的开发实践），将使风险管理更加困难。
3.46 考虑到这些问题的规模，要开始在华为的软件工程和网络安全质量及开发过程中树立信心就必须有证据表明多个版本和多个产品都在不断改进。在现实世界中，一个单一的 “良好” 构建将无法为产品的长期安全性和可持续性提供信心。华为在有关转型计划的公开声明中表示，这将需要 5 年时间。NCSC 的技术总监认为这与最佳情况估计大致相符。监督委员会承认，在未来年度报告中，当涉及报告与英国网络安全风险相关事项的进展时它将继续考虑华为关于特定事项具有商业敏感性和 / 或与英国网络安全风险无关的任何陈述。其将继续适当考虑任何此类陈述，前提是其始终能够按照附录 A 所包含的职权范围的要求，适当履行其报告英国网络安全风险的义务。
第四节：董事会的工作：独立性保证
略
任命安永会计师事务所为审计师
略
第五部分：结论
略
附录 A：华为网络安全评估中心监督委员会的职权范围
略
附录 B 2017-2018 审计中提出的问题和现状
全文完