技术分享：如何通过三个步骤做好软件供应链的风险治理

2021年5月14日，EISS-2021企业信息安全峰会·北京站举行，在聚焦开发安全的分会场中，来自于悬镜安全的COO——董毅针对“软件供应链的风险与治理”主题进行了分享，重点讲述了企业应如何应对这一风险的关键要点。

董毅介绍到，软件供应链本身就是软件生产的过程，它包括了原始组件、集成组件、软件产品、产品运营共四部分组成。而在这一生产过程中，潜在的风险也会贯穿其中。

众所周知，软件供应链攻击存在着攻破一点、打击一片的高传导性特点，董毅也在演讲中分享了一个施乐打印机因使用美国WindRiver公司的嵌入式实时操作系统——VxWorks，导致爆发了著名的URGENT/11漏洞事件，而由于VxWorks被广泛地应用于汽车、航空、航天以及IoT等领域，因此造成的恶劣影响范围之广可想而知。

但这个案例仅仅只体现了软件供应链攻击的高传播性特征，实际上此类攻击还普遍存在着强隐蔽性的特点。

董毅在这里又拿出了另一个案例——波音787在2019年爆出的漏洞事件。该事件显示，一旦攻击者利用该漏洞控制了机内的集成控制设备，那么最终可以实现接管飞机的操作，具有极大的潜在风险。出现漏洞的这套集成控制平台源自于GreenHill，其产品底层也有VxWorks的“贡献”。在这个案例当中，不仅体现出了前面所说的高传导性，更是体现出了强隐蔽性。

在这些特征之下，董毅也为分享了自己总结出的软件供应链风险的4种基本类型，分别是：

1、 合法供应商引入的漏洞。如VxWork引发的漏洞事件。

2、 伪造的组件。如SolarWinds Orion攻击事件。

3、 开发过程中引入的漏洞。如不安全的开源代码。

4、 未处理的已知漏洞。

那么面对这些风险，应该如何应对呢？董毅也给出了相应的建议。

第一步是通过SCA（Software Composition Analysis，软件成分分析）来提高软件应用的透明度。

董毅谈到，BOM（Bill of Material，物料清单）系统早已广泛地应用在诸多领域之中，通过这个系统，奔驰汽车可以做到在2021年4月30日针对某车型的一个部件有可能产生问题而发出召回通告，而这个车型是早在十几年前所生产的，数量也可以精确到390台，是什么可以让他们快速追溯和定位到某一时间段生产的车辆问题呢？这就是BOM的威力。

而在软件行业，也同样有自己的BOM系统——SBOM（Software Bill of Material，软件物料清单），其内容是代码库中所有开放源代码和第三方组件的列表，可以列出并管理这些组件的许可证，代码库中使用的组件的版本及其补丁程序状态。

SBOM（Software Bill of Material，软件物料清单）示例

结合上面的内容，在这里我们可以很容易地看出应用SBOM的好处，当问题出现时，我们可以根据SBOM中的内容来确认自己是否使用了有风险的供应商及相关产品，如果有那么就第一时间去做出响应，去降低甚至规避风险。

那么如果没有SBOM会如何？董毅在这里还是用上面的VxWorks事件举例，如果漏洞已经发现，但自己又并不知道自己所使用的产品中应用了VxWorks，这意味着在安全的更新包出现之前，会一直处在一个安全无管理的状态，将自己暴露在巨大的潜在风险之中。

在谈到企业的SBOM具体应该做到什么程度这一问题时，董毅给出的建议是至少要做到两层，即“直接供应商”以及“直接供应商的供应商”。

那么如何获得SBOM呢？主要有两个方法，一是向供应商索取；二是采用第三方的SCA工具。

第二步是完善安全开发工具链，强化供应链风险发现能力。

在这里，董毅分享了悬镜安全所发布的DevSecOps全流程应用安全工具链，明确了从开发到运营的整个软件周期中，每一个阶段所需要做的安全工作。

之所以要据此建设一个安全体系，主要原因在于SCA只能帮助企业掌握第三方的部分组件基本信息，而无法解决发现深层漏洞的问题。董毅介绍到，“很多漏洞仅通过一个组件是无法发现的，但如果形成一个整体后，问题才有可能会被发现，在这种场景下，我们就需要有其他的方法来解决这一问题。”

完善DevSecOps或SDL全流程应用安全工具链

同时，在他的演讲中，也分享了DevSecOps工具链中，各个工具分别在设计、开发、构建、测试到运营的周期中，各自所处阶段及自动化程度做了分析。具体可以通过下图了解。

通这张图可以明显看出，结合SAST和DAST两者优点的IAST拥有更高的自动化程度，而在实际应用中，IAST也表现出在高检出率、低误报率方面的显著优势。“IAST在工具链中是非常重要的一环，因为它的能力是其他工具无法补充的。”董毅强调道。

第三步是引入RASP 做好应用内生的保护。

前面的两个步骤主要都是针对于开发阶段，而这个步骤则主要针对于运营阶段。

通过上图可以看出，在这个图中，防火墙、WAF、EDR等主要是从外部来检查应用的风险，无法做到应用内部的状态，所以在一些情况下会存有误报、漏报的情况，这是难以避免的，相比之下，只有RASP 是真正的从应用内部来解决这个问题。

通过RASP可以在风险出现时快速、清晰的了解到问题所在，直接将相应的代码行信息反馈给研发人员，并能够判断到底这一问题是源于自身还是供应商，这可以令企业在解决相关问题时更加的高效。

在演讲的最后，董毅用一张图清晰地描述了如何将安全开发工具链应用于软件供应链风险治理中的不同阶段，对企业如何做好相关风险治理工作有着明确的建议和指引。

文字来源：安全419

图片来源：悬镜安全