全文共3234字，阅读大约需6分钟。
本文为安全知识图谱技术技术白皮书《践行安全知识图谱，携手迈进认知智能》精华解读系列第七篇，介绍了知识图谱相关技术如何在软件供应链安全领域应用。
01软件供应链安全的兴起与挑战
随着软件技术的飞速发展和软件开发技术的不断进步，软件开发和集成过程中常会应用第三方软件产品或开源组件，其供应链中软件的安全性和可靠性逐步成为软件产业面临的重要安全问题。近年来大量涌现的软件供应链安全事件则具有不同的特点，攻击软件供应链相较于攻击软件本身，难度和成本显著降低，影响范围一般显著扩大，并且由于攻击发生后被供应链上的多次传递所掩盖，难以被现有的计算机系统安全防范措施识别和处理。如Xcode非官方版本恶意代码污染事件、远程终端管理工具Xshell后门事件、开源组件Fastjson反序列化漏洞等，主要体现在针对开发工具的污染、源代码污染、预留后门、捆绑下载、软件漏洞等方面。
我们对软件供应链安全的关注由来已久，2020年爆发的SolarWinds供应链遭受APT攻击事件，是典型的软件供应链攻击案例。2021年2月美国总统拜登签署行政令，为包括信息技术在内的商品构建更安全的供应链，将软件供应链安全推进公众视野。我国对于软件供应链安全的法规和标准也在日趋完善中，《信息安全技术 信息技术产品供应方行为安全准则》（GB/T 32921-2016）约束了供方的安全要求，由中国信息安全测评中心牵头的《信息安全技术 软件供应链安全要求》也在编制阶段，对供需双方的安全要求进行约束。由此可见软件供应链安全的重要性。
与传统软件安全相比，软件供应链面临的安全风险不断加大，因其遭受破坏而引发的网络安全事件愈演愈烈。第一，软件供应链攻击面由软件产品本身的漏洞扩大为上游供应商的软件、组件和服务漏洞，任何一个上游阶段的漏洞都将影响下游所有软件，导致整个软件供应链遭受的攻击面不断扩大；第二，攻击面的扩大显著降低了攻击者的攻击难度，软件供应链中的任意环节一旦被攻击或篡改，都将会引起安全风险的连锁反应，产生巨大的安全危害；另外，软件开源化趋势增强，据Forrester Research 研究表明，应用软件的80%~90%代码来自开源组件，开源组件的安全性直接关系到信息系统基础设施安全，已成为软件供应链安全问题增长的重要因素。
软件供应链的安全治理可以从以下角度进行：
1、清晰供应链关系：需要全面梳理软件供应链中涉及到的供应商、软件、信息、工具、服务、上下游交付环节，保证供应链流程不会存在遗漏。
2、系统和组件引用关系：需要识别软件源代码、工具存在的安全问题，重点明确系统和组件、组件与组件间的引用关系。
3、供应链上下游软件漏洞风险管理：上游软件漏洞如被引入当前环节，需追踪当前环节的产出会被哪些下游所使用，跟踪信息流，确保问题发生时影响范围的可知、可控、可追溯。
4、制定有效的安全防护方案：针对已知安全风险需要制定决策或解决方案，通过替换、升级、修复解决，也可采用安全防护、封堵等方式规避风险。
在实际的企业安全运营中，仅从以上几个方面考虑软件供应链安全远远不够，我们还需要从软件的全生命周期考虑更细粒度的安全性，如SDL 软件安全开发生命周期、DevSecOps、安全编码、软件供应商评估与风险管理、成熟的应急响应机制等。
02基于知识图谱的应用方案
传统软件供应链安全体系
狭义的软件供应链安全解决方案一般以开源软件为切入点，跟踪开源软件在系统和项目中的应用情况，以此作为软件供应链安全的主体内容。在这种情况下，检查、管理开源组件，并识别开源组件的已知漏洞，成为软件供应链安全的主要技术手段。
但软件供应链安全绝不等于开源组件及漏洞管理。传统软件供应链安全体系一般以SDL软件安全开发生命周期来整体构建，在每个阶段都有属于软件供应链安全的体系内容和技术要素。如图1所示，是一个简化版的基于SDL的软件供应链技术实践方案。
图1 SDL软件供应链安全体系
可以看到，在SDL流程中，从软件供应商评估到产品安全检测与防护，都是软件供应链安全解决方案中的重要环节。在每个阶段，都有专门的技术、产品或方法来保障过程的全面性和安全性。
传统的软件供应链安全体系缺乏统一的度量标准或规范对供应链中的供需关系、软件质量进行风险评估。在目前安全运营场景中虽然可以通过SOC（Security Operation Center）或者安管平台反映每个阶段的执行结果，但这种结果过于分散，未形成连接关系，不足以反映整体结果。其次，采用SDL解决方案，无法发现供应链安全中特有的关联风险，只能提前预设可能的风险点进一步安全评估。
考虑到以上传统技术体系的不足，我们结合软件供应链的关联特性，基于知识图谱方式，对软件供应链安全进行风险分析。
软件供应链知识图谱构建
以当前组织为切入点，收集软件供应链上下游的依赖关系。这种依赖关系可以是组件引用、购买产品、使用服务、安装软件、下载应用等，还可以包括地理位置、开源社区、供应商的可信能力等。
如图2所示，是一个典型软件供应链知识图谱中不同软件对象和对象之间的依赖关系。可见其中有很多节点和过程存在潜在安全风险并容易受到攻击。
图2 软件供应链知识图谱
风险识别
结合软件供应链安全知识图谱，采用不一致性进行判断。可以通过设定查询模式，找出在知识图谱中本应相同却不同、本应不同却相同的实体。如图 3 所示，开源组件A和B本应是两个不同的开源组件，但他们却指向同一md5哈希值，则A和B可能存在冒用的风险。假如图谱中开源组件A，存在两个不同的md5属性，则可能存在组件A被篡改或其他恶意软件伪装的风险。
图3 开源组件风险识别
高风险软件推荐
软件供应链有一个明显特征，即引用关系链较长。假如某个软件实体被公布或暴露存在安全隐患，我们可根据知识图谱多步关联搜索，快速梳理出受影响的用户和供应商实体，进一步进行风险管理和应急处置。如图4所示，用户 A安装了APP-I，而APP-I引用了开源组件A和开源组件B。若开源组件A（fastjson 1.2.67）存在CVE-2020-8840注入导致远程代码执行漏洞，则能间接分析出影响用户A。知识图谱中节点之间的边，可以很好的表示软件与组件之间的引用、存在、依赖等关系，完全适用于软件供应链安全中的多级依赖和分析场景。通过深度搜索，提取相应特征，可作为风险评估模型的输入。
图4 高风险软件推荐
基于图模式可以识别高风险开源软件节点，对节点被引用数或更新周期等计算对应节点的风险值。图4中开源组件B被多个APP引用，因此一旦开源组件B被暴露存在安全漏洞，受影响的范围将会扩大，所以开源组件B被定为高风险节点。同时从开源社区角度考虑，活跃社区的开源组件更新及时且质量较高，版本迭代、更新维护不及时的社区组件则相对安全风险较高。
影响范围分析
基于安全知识图谱中的所有存储历史信息，对潜在威胁进行建模，包括开发工具污染、预留后门、源代码污染、捆绑下载、升级劫持等。通过图谱可直接对可识别威胁进行影响范围分析，如图5所示，Microsoft office2007、2013 和 2016 均存在 CVE-2017-11882 远程执行漏洞，被 SideWinder 组织在某次APT攻击战役中使用。通过知识图谱中软件的引用关系，可以分析得到环境中受到影响的终端PC。
图5 CVE漏洞利用影响范围分析
缓解措施决策
将攻击和风险结合起来，形成 < 风险值，影响 > 对，构建该软件供应链的安全知识图谱风险图。基于风险图和业内收集的漏洞解决办法和防护策略，制定相应的安全管理措施，缓解针对软件供应链的攻击影响。在实际操作时，可以对缓解措施进行约束，以便只执行在约束范围内的缓解措施（例如在规定的成本内、在规定的持续时间内等），任何不满足约束的缓解措施不会被预先提出来进一步考虑。
03总结
知识图谱能够很好地表现出软件供应链安全中的依赖和使用关系，且能够利用自身特性发现其中的风险。在软件供应链安全范围广度和深度兼具的复杂场景下，使用知识图谱来保障软件供应链安全，极具先进性和创造性。但在当前的应用与研究中，软件供应链的相关实体，包括供应商、组件、代码、工具、社区、应用开发平台等，都是软件供应链安全中的关键风险节点。而全面收集关键节点并进行语义准确表达，是目前面临的重要挑战，值得我们继续深入研究。
