从源头上来看，它会包含的我们常见的一些开源组件。这些构成了软件供应链中原材料的一部分。通过软件源、软件市场的分发，代码托管平台和镜像的分发，最终它会应用到企业开发的全流程场景中。企业的开发者可以通过建立自己的私有源，做一些代码编码的引入，包括整个代码的构建到最终发布成品的过程。在这个过程里面实际上我们可以看到它的每一步都涉及到一些代码、软件技术。

软件供应链的三大风险

软件供应链存在以下几种风险：

产权合规
漏洞攻击
供应中断

第一个风险是会有一些漏洞的攻击。比如一些开源组件：Log4j、fastjson、Spring Cloud 的一些漏洞。第二个风险是每一个软件诞生都会带有自己的知识产权信息，比如开源的软件的开源许可证的信息、闭源商业软件的知识产权信息，这些信息在每一步供应链的分发、传导过程中会涉及到产权合规的一些风险。第三供应中断，因为供应链整个链条其实是一个持续性的过程，一旦软件的源头被攻击，会导致整个供应中断。

软件需求开发所面临的风险

软件需求方会面临以下几种风险：

合规处罚
声誉损失
业务中断
数据泄露

这四大块风险对于企业/组织来讲都是非常严重的影响。下图为近几年软件供应链安全事件的发展的趋势：

可以看到过去十年软件供应链安全事件的上升量是非常明显的，与这个上升量非常明显相似的是关于背后的开源代码的应用指数据的上升增长，这两者是有非常明显的这么一个关联的。

软件供应链生态风险分析

软件供应链生态分为三方：

软件供应方：开源作者、软件供应商；
软件分发方：镜像源、代码托管平台；
软件需求方：开发者、企业。

## SBOM 不透明

试想一下，大家能否说能够说清楚自己的公司今天到底用了多少开源的软件/公司使用的商用软件，以及这些开源的软件到底用依赖了哪些三方软件？相信很难完整的阐述，为什么会非常难呢？因为从本质上来讲，今天我们所有的开源项目，包括 github 里面的所有的开源项目，包括这些官方语言的开源项目，没有清晰地告诉下游分发方以及使用方，到底引用了哪些三方的组件，也就是 SBOM 软件物料清单是没有的。

风险不透明

所以在整个过程中大家不知道此软件依赖了哪些成分？这个不清晰就会导致一个非常严重的问题——风险不透明。具体比如今天发生 fastjson 或 Log4j 漏洞后，你甚至可能花一个月两个月甚至半年都不一定能够真正找出来企业里面到底哪一个应用/哪个线上的服务，会受到这个漏洞的真实影响。

缺乏有效协同

由于上方两个问题自然而然会带出第三个问题——缺乏有效协同。比如日常整个生态中任何一方出现了问题，实际上关联方都没有办法跟它有效地协同处置这个风险。

通过 murphysec 对软件代码生成风险报告

2022 年 murphysec 对 5000 个知名的软件代码做了分析报告，可以看出：

代码库中 81% 代码是开源代码；
78% 的代码库至少有一个漏洞；
60% 的代码库存在许可证冲突；
30% 的代码库包含了不清晰的许可证标识；
代码库中 86% 被调用的组件不是最新版本；
73% 的代码库包含超过3年前的开源组件版本。

上述数据反映出所有的开源、闭源、商业、甚至包括信创软件，其实有大量的未知缺陷和风险。甚至说整个生态里面的每一方都不知道这个风险到底在哪什么时候会出现，出现之后应该找谁去解决。

协同治理模型——汽车召回机制

既然要去做软件规定安全这件事情，那我们肯定不是简单地去做一个工具或者是做一个产品，我们更希望在生态里面能够去协同，去推进整个生态的健康发展，因此我们调研了传统汽车行业关于供应链的召回机制。

从 1966 年开始，这个美国创建了关于汽车的召回制度。到 2004 年的时候国内国家质检总局包括联合几个部门也发布了关于缺陷汽车的召回管理规定。这个规定出来之后过去 17 年过程中大概实施了 2423 次召回，涉及了 9130 万辆汽车。

下图与软件供应链的事件和风险趋势图像有点像，这个过程中随着汽车的使用量越来越多，召回的风险也是越来越大的。就像如今软件用的越来越多，自然而然会产生很多安全的问题需要去治理。

右图为汽车召回机制的三方关系图，我们可以很清晰的看出它每一个环节传递的信息——也就是哪里出了问题，如何去协同。

推动软件供应链生态治理

我们把上述逻辑尝试去推衍如何推动软件供应链生态治理，作为一个提供技术、服务的厂商，我们能够做到什么？

把供应链生态风险拆解开具体如上图，首先第一点是整个生态链协作的过程中 SBOM 清单要足够的透明，需要在软件分发的过程中透明的去传递的信息。第二 SBOM 附带的风险信息，一个透明传递的信息。第三是缺陷情报共享，出现问题及时通知到使用了我软件或者产品的厂商。第四作为消费者或者软件使用方需要持续去做风险监测。第五做一些可信验证，主要是解决是否使用假冒伪劣组件或会被投毒的组件。

以上需要持续的检测，通过整套能力能够保证动态管理和动态持续的安全。因此底层就会依赖到一些能力，比如 SBOM 的清单信息的维护。一旦说 SBOM 都识别错了，后面整个风险包括情报的共享都会出很大问题。就像去医院看病化验，一开始你花钱的指标错了那后面整个看病包括说给你开药的过程都会出现非常大的问题。

所以在此环节需要有精准的软件成分分析及许可证合规的检查。上述能力其实最终都会依赖于我们缺陷知识库，包括组件知识库和许可证知识库。那这些信息本身是不是足够准的？对于整个知识库能力建设并不是一件非常简单的事情，所以其实我们做的所有的事情是作为一个社区、产品、技术解决掉上述问题，个人力量还是比较微薄的，所以我们要在国家的法律法规包括标准的牵引和引导下去做这件事情。

关于 OSCS 社区

OSCS 社区包括墨菲安全的产品在整个过程中处于一个什么样位置？最核心的，我们做的这一套工具和产品包括开源社区，最终的目的是为了让上述的那些问题能落地，通过一款产品、工具不破坏现有的开发者的开发习惯和开发流程的情况下，能够非常低成本地嵌入到它整个软件、整个应用分发的每一个环节中去，这是我们希望做的事情。

OSCS 社区第一版是在今年 7 月份上线的，9 月底我们更新上线了一个正式版本。OSCS 社区的愿景很简单——让每一个开源项目更安全。社区通过 murphysec 开源监测工具帮助开源项目去做检测，检测之后可能会发现一些漏洞，然后会通过 github 社区的提 PR 机制去给他一键提交提一个 PR 修复建议。修复漏洞之后社区会把这个漏洞通过我们 murphysec 的漏洞情报订阅功能把这个情报通知给订阅的开发者。开发者可以再利用这个 murphysec 的漏洞检测工具快速修复。

整个过程中流程特别简单，过去为什么开源社区的项目中还会存在这些漏洞的？其实本质上来讲还是它的成本太高，或者说信息不对称导致大家没去做这件事情。我们希望把这件事情做得更简单更易用，通过极低的上手门槛，能够把检测结果做得全准快，帮助开发者一键去修复它。

社区上线后的几个月内已经帮助一些主流的开源项目，包括像 dubbo、apollo、rocketmq、onedev、dataease 等 500+ 开源项目提交了安全漏洞修复的建议，社区成员超过 1w 开发者，为超过 5w 个开源项目，执行超过 30w 次开源安全检测，发现安全漏洞超 70w 。