阿里巴巴重发软件谁用过？分析阿里安全部杭特

硬件中的固件，控制器的实现，甚至人工智能（AI）芯片中的算法，都可以看成是广义的软件。“软件定义世界，数据驱动未来”，软件成为影响世界发展的重要因素。前美国联邦调查局（FBI）员工号称曾在欧盟通信的系统里置入过算法级后门，这个传言似乎离我们相对遥远。但是，最近几年，软件供应链的安全问题却呈现出迅速增长的趋势。

从XCodeGhost引起大众的注意，到NetSarang公司因入侵导致的XShell软件后门事件，之后又发生了多起开发基础库（PIP/NPM）源码污染导致的后门植入，今年则有Gentoo Linux发行版的GitHub因账号安全导致所有软件包存在威胁，以及账号登录管理库（libssh）后门甚至可以影响F5设备的事件等。软件供应链导致的安全问题越来越向上游发展，也越来越隐蔽。可以预见，在不久的将来，软件供应链安全的影响会更广泛，甚至会涉及工业生产设施、医疗系统、无人机、自动驾驶汽车等对象。

一方面是功能需求的突然爆发，一方面是软件开发人员的相对短缺。面对社会全面互联网化带来的海量需求，有限的开发人员不得不大量复用各种软件模块（包括各种开源软件）来提升开发效率，对软件供应链形成极大依赖，其中的安全风险不容忽视。

既然软件供应链是一个链条，那么，链条上的每一个环节都会对安全造成影响，而这些影响对于末端的用户来说，是很难感知到的。

第一，最上游的操作系统和基础库的程序员。这个对象群体的特点是影响面极广，因此，无论是程序员主动或者被动嵌入后门，都会造成灾难性的后果。以2017年的无线通信WPA2 KRACK劫持漏洞为例，其安卓系统下漏洞引入的对象是基础库wpa_supplicant，全世界所有的安卓系统都依赖这个基础库进行无线接入，但是，实际上该软件的开发者只有一两个人。类似的基础库还有成百上千，然而，这些开发者的安全意识未必更强。对于大型互联网企业来说，表面看起来安全水位不低，但是，如果换一种思维，从这些企业依赖的众多基础软件供应链开发者为目标，难度将大大降低，影响面将涉及几乎每一台主机。

第二，下游的使用基础库、IDE开发系统的程序员。以XCodeGhost为例，由于使用了嵌入恶意功能的非官方XCode 集成软件开发环境（IDE）工具，包括微信在内的数百款IOS App都受到影响。程序员由于个人偏好，会使用多种类型的IDE、代码管理工具、代码编辑工具、编译工具链、集成测试系统等。每种软件都是相对复杂且容易遭受“毒手”的对象，甚至包括各种网上可以下载的插件。

第三，IT运维人员。运维人员常用的软件包括各种登录管理软件、系统监控软件、业务发布系统、日志分析软件等。由于运维的特性，这些软件一般都以最高权限运行，因此，如果依赖的软件包含恶意行为，将直接泄露系统的关键信息（如登录号、业务数据）。这也是为什么XShell、Putty、WinSCP、SecureCRT的无论官方还是非官方版本都出现过后门的原因。

第四，末端用户。虽然他们大多是病毒木马的受害者， 如果这些用户恰巧是办公网的敏感用户，或者某些特定场景的用户，也会受到攻击者的“关爱”。例如，别有用心的人曾在计算炮弹弹道的移动应用上做过手脚，每次使用时都会向外发送信息，进而暴露武器使用者的地理位置。

虽然前面列举了软件供应链安全的种种危害和相关事件，但是，目前国内相关方面还没能“严阵以待”，还有亟待提升的空间。

1. 重视程度不足，“不觉得会是个事儿”

安全本来就是冰山一角，相对于病毒木马和漏洞，软件供应链安全问题的出现概率较低。对于这种影响面巨大，却相对罕见的情况，绝大多数部门和企业都是被“事件驱动”。每当有软件供应链安全事件发生，及时处理就可以了，如果把发现未知威胁作为核心考核指标（KPI），产出是极其不确定的，也鲜有组织和企业愿意投入资源。总归一句话，相关职能部门和企业“不觉得会是个事儿”。

2. 检测难度更高，“自动化检测更困难”

相对于代码质量与漏洞扫描，软件供应链安全相关的自动化检测更为困难，主要原因是：第一，缺乏严格地定义与分类。与漏洞有完善的CWE和OWASP等分类不同，软件供应链安全的相关问题没有标准的定义与分类，通常只是一个笼统的“未定义功能”或者后门，英文中有一个bugdoor与之相近。未定义功能与软件本身的行为有比较强的相关性，一个功能在一个软件里是正常的，在其他的软件里却可能是异常的。第二，缺乏通用的测试集。既然没有定义与分类，与之对应的测试集也处于空白状态。第三，缺乏相关的学术理论与实践。第四，缺乏相应的开源软件与商业产品。第五，软件种类极多，且检测方式差异较大，既包括基于源码的C/Java/Python/NodeJS等多种语言，也包含基于二进制的x86/arm/IR等对象。不同种类的软件，其检测规则会有较大的差异，存在极大的工程量。

3. 国家政策导向空白，“急需完善”

目前，国家在重点项目引导中并没有以软件供应链安全为主题的专题，在产品审查测评过程中，也鲜有供应链安全相关的流程要求及检测手段。面对如此高的风险，，国内基本上的对策就是一片空白，急需完善。

目前，我国应在了解国外先进经验的前提下，通过研究立项、标准制定、测评要求等方式尽快缩小差距，并督促企业进行风险控制。

1. 了解国际先进经验才能“知己知彼”

美国的NIST-800-161标准发表于2015年4月，美国国家标准与技术研究院（NIST）的这个标准其实并不单纯聚焦软件供应链安全技术，而是信息与通信技术（ICT）系统的风险管理指南。更多的是从风险控制的视角，制定流程、规则，识别、评估风险等级，确保信息系统风险可控。

，针对商用信息技术软件及固件进行审查的研究项目。其主要目的就是探索各种检测软硬件存在的隐蔽行为。项目周期4年，项目经费约5000万美元。

工业界的尝试Grafeas项目是由Google、IBM、红帽公司（Red Hat）、杰蛙科技（JFrog）等公司联合开发的开源项目，用于统一设计和管理软件供应链，从而提升其安全性。

2. 开展相关研究项目、流程标准及测评项目

相对美国自2013年开始的研究项目，2015年给出的风险管理指南，我国在这方面仍处于空白。应通过研究项目、流程标准、项目测评准入等方式，对该风险进行有效控制。具体包括：

第一，研究项目引导。对软件供应链安全风险进行定义和分类，积累通用测试集，探索代码和二进制检测能力，完善相关的学术理论和实践，筛选出优秀的研究团队和方法论。

第二，流程标准开路。探索符合国情的软件供应链安全风险管理指南，指定流程规范，对风险进行评估和规范。

第三，测评准入。对重点项目进行测评准入，软件供应链安全管理能力应成为一票否决因素。

3. 督促企业相关投入

重点项目和企业应该具备软件供应链安全风险管理能力，如发现风险应及时上报，持续确保核心系统的安全可靠。

除了前面列举的对策，还需要澄清一个误解，并提出一个建议，供参考。软件设计中超过90%的部分通过“拿来主义”实现的现实，“自主可控”的呼吁，以及采取“平台方式”让大家群策群力的方式等，都是值得思考的问题。

1. “拿来主义”观念的核心软件安全是否靠谱

从软件开发角度，模块化是提效的基本要求，再加上开源软件的极大丰富，网民才能享受众多的应用、物联网设备和新奇酷炫的人工智能科技。据统计，每款软件中自主开发的平均比例不超过10%，超过90%的部分是通过“拿来主义”，复用各种第三方开源/闭源软件实现的。另外，IT从业者还会大量使用IDE开发软件、下载软件、网管软件等。那么，会不会有恶意的开发者，在自研软件中加入恶意功能？90%“拿来主义”的非自研部分，以及工作、生活中使用的核心软件，是不是真的安全可靠无后门呢？这些问题，值得思考。

2.“自主可控”是否能够解决软件供应链安全问题

实现“自主可控”是否不存在软件供应链安全问题？答案显然是否定的。自主可控只是核心系统为自己实现，仍存在以下问题：无法消除恶意开发的风险、代码实现仍有可能存在漏洞、仍有大量外部依赖代码，安全性仍然无法保证。因此，无论是否自主可控，都将面对同样的软件供应链安全风险，不可大意。

3.“平台方式”的群策群力是否可以借鉴

互联时代，所有的大型互联网公司都面临同样的安全风险。实际上，有需求的组织和企业很多，而很多学术机构虽有技术储备，但是，缺乏突破口和衡量能力的尺子，何不采取平台的方式，集合买方和卖方，让大家都参与进来，群策群力？阿里以软件供应链安全的定义和检测能力为比赛目标，吸引了很多对此有兴趣的高校和企业参加。相关参与方的能力已超出举办方的预期，目前积累了各种安全风险的样本和检测方案，阿里也愿意用自己的企业信誉为这些优秀的团队及其能力进行背书。

（本文刊登于《中国信息安全》杂志2018年第11期）