本文整理自 OSCS 软件供应链安全技术论坛- 章华鹏老师开场致辞的分享内容。
章华鹏,十二年的企业安全建设、安全社区白帽子、开发者,先后在百度、贝壳负责过企业安全建设 ,也在乌云负责过安全产品,业余时间活跃于安全技术社区,帮助企业、开源项目、软件公司解决过数百个严重安全问题,现在负责墨菲安全和 OSCS 社区,专注于软件供应链安全方向。
今天讲一讲我对于整个软件供应链安全的理解。100 多年前 1905 年的时候,独立报第一次提出关于供应链概念,过去 100 多年,大家聊得更多是关于整个供应链安全的管理。供应链的管理本质上是产品从原材料到形成最终产品的整个过程的管理,目的是要提升它的效率,包括整个过程的保障。
从上述角度来讲,我们去定义整个软件供应链的安全,可以把它理解为一个软件的产品,从原材料包括组件代码,经过分发包括二次的开发,最终形成软件产品的整个过程中的安全保障。在保障的过程中,最终希望软件的消费者能够在使用软件的过程中保障它的数据和使用过程的安全。其最终的目的其实还是为了去提升最终客户的价值。
把这件事拆解开来去看,软件供应链从原材料到分发和生产应用的过程中,我们可以把它拆解成几部分:
从源头上来看,它会包含的我们常见的一些开源组件。这些构成了软件供应链中原材料的一部分。通过软件源、软件市场的分发,代码托管平台和镜像的分发,最终它会应用到企业开发的全流程场景中。企业的开发者可以通过建立自己的私有源,做一些代码编码的引入,包括整个代码的构建到最终发布成品的过程。在这个过程里面实际上我们可以看到它的每一步都涉及到一些代码、软件技术。
软件供应链存在以下几种风险:
产权合规
漏洞攻击
供应中断
第一个风险是会有一些漏洞的攻击。比如一些开源组件:Log4j、fastjson、Spring Cloud 的一些漏洞。第二个风险是每一个软件诞生都会带有自己的知识产权信息,比如开源的软件的开源许可证的信息、闭源商业软件的知识产权信息,这些信息在每一步供应链的分发、传导过程中会涉及到产权合规的一些风险。第三供应中断,因为供应链整个链条其实是一个持续性的过程,一旦软件的源头被攻击,会导致整个供应中断。
软件需求方会面临以下几种风险:
合规处罚
声誉损失
业务中断
数据泄露
这四大块风险对于企业/组织来讲都是非常严重的影响。下图为近几年软件供应链安全事件的发展的趋势:
可以看到过去十年软件供应链安全事件的上升量是非常明显的,与这个上升量非常明显相似的是关于背后的开源代码的应用指数据的上升增长,这两者是有非常明显的这么一个关联的。
软件供应链生态分为三方:
软件供应方:开源作者、软件供应商;
软件分发方:镜像源、代码托管平台;
软件需求方:开发者、企业。
试想一下,大家能否说能够说清楚自己的公司今天到底用了多少开源的软件/公司使用的商用软件,以及这些开源的软件到底用依赖了哪些三方软件?相信很难完整的阐述,为什么会非常难呢?因为从本质上来讲,今天我们所有的开源项目,包括 github 里面的所有的开源项目,包括这些官方语言的开源项目,没有清晰地告诉下游分发方以及使用方,到底引用了哪些三方的组件,也就是 SBOM 软件物料清单是没有的。
所以在整个过程中大家不知道此软件依赖了哪些成分?这个不清晰就会导致一个非常严重的问题——风险不透明。具体比如今天发生 fastjson 或 Log4j 漏洞后,你甚至可能花一个月两个月甚至半年都不一定能够真正找出来企业里面到底哪一个应用/哪个线上的服务,会受到这个漏洞的真实影响。
由于上方两个问题自然而然会带出第三个问题——缺乏有效协同。比如日常整个生态中任何一方出现了问题,实际上关联方都没有办法跟它有效地协同处置这个风险。
2022 年 murphysec 对 5000 个知名的软件代码做了分析报告,可以看出:
代码库中 81% 代码是开源代码;
78% 的代码库至少有一个漏洞;
60% 的代码库存在许可证冲突;
30% 的代码库包含了不清晰的许可证标识;
代码库中 86% 被调用的组件不是最新版本;
73% 的代码库包含超过3年前的开源组件版本。
上述数据反映出所有的开源、闭源、商业、甚至包括信创软件,其实有大量的未知缺陷和风险。甚至说整个生态里面的每一方都不知道这个风险到底在哪什么时候会出现,出现之后应该找谁去解决。
既然要去做软件规定安全这件事情,那我们肯定不是简单地去做一个工具或者是做一个产品,我们更希望在生态里面能够去协同,去推进整个生态的健康发展,因此我们调研了传统汽车行业关于供应链的召回机制。
从 1966 年开始,这个美国创建了关于汽车的召回制度。到 2004 年的时候国内国家质检总局包括联合几个部门也发布了关于缺陷汽车的召回管理规定。这个规定出来之后过去 17 年过程中大概实施了 2423 次召回,涉及了 9130 万辆汽车。
下图与软件供应链的事件和风险趋势图像有点像,这个过程中随着汽车的使用量越来越多,召回的风险也是越来越大的。就像如今软件用的越来越多,自然而然会产生很多安全的问题需要去治理。
右图为汽车召回机制的三方关系图,我们可以很清晰的看出它每一个环节传递的信息——也就是哪里出了问题,如何去协同。
我们把上述逻辑尝试去推衍如何推动软件供应链生态治理,作为一个提供技术、服务的厂商,我们能够做到什么?
把供应链生态风险拆解开具体如上图,首先第一点是整个生态链协作的过程中 SBOM 清单要足够的透明,需要在软件分发的过程中透明的去传递的信息。第二 SBOM 附带的风险信息,一个透明传递的信息。第三是缺陷情报共享,出现问题及时通知到使用了我软件或者产品的厂商。第四作为消费者或者软件使用方需要持续去做风险监测。第五做一些可信验证,主要是解决是否使用假冒伪劣组件或会被投毒的组件。
以上需要持续的检测,通过整套能力能够保证动态管理和动态持续的安全。因此底层就会依赖到一些能力,比如 SBOM 的清单信息的维护。一旦说 SBOM 都识别错了,后面整个风险包括情报的共享都会出很大问题。就像去医院看病化验,一开始你花钱的指标错了那后面整个看病包括说给你开药的过程都会出现非常大的问题。
所以在此环节需要有精准的软件成分分析及许可证合规的检查。上述能力其实最终都会依赖于我们缺陷知识库,包括组件知识库和许可证知识库。那这些信息本身是不是足够准的?对于整个知识库能力建设并不是一件非常简单的事情,所以其实我们做的所有的事情是作为一个社区、产品、技术解决掉上述问题,个人力量还是比较微薄的,所以我们要在国家的法律法规包括标准的牵引和引导下去做这件事情。
OSCS 社区包括墨菲安全的产品在整个过程中处于一个什么样位置?最核心的,我们做的这一套工具和产品包括开源社区,最终的目的是为了让上述的那些问题能落地,通过一款产品、工具不破坏现有的开发者的开发习惯和开发流程的情况下,能够非常低成本地嵌入到它整个软件、整个应用分发的每一个环节中去,这是我们希望做的事情。
OSCS 社区第一版是在今年 7 月份上线的,9 月底我们更新上线了一个正式版本。OSCS 社区的愿景很简单——让每一个开源项目更安全。社区通过 murphysec 开源监测工具帮助开源项目去做检测,检测之后可能会发现一些漏洞,然后会通过 github 社区的提 PR 机制去给他一键提交提一个 PR 修复建议。修复漏洞之后社区会把这个漏洞通过我们 murphysec 的漏洞情报订阅功能把这个情报通知给订阅的开发者。开发者可以再利用这个 murphysec 的漏洞检测工具快速修复。
整个过程中流程特别简单,过去为什么开源社区的项目中还会存在这些漏洞的?其实本质上来讲还是它的成本太高,或者说信息不对称导致大家没去做这件事情。我们希望把这件事情做得更简单更易用,通过极低的上手门槛,能够把检测结果做得全准快,帮助开发者一键去修复它。
社区上线后的几个月内已经帮助一些主流的开源项目,包括像 dubbo、apollo、rocketmq、onedev、dataease 等 500+ 开源项目提交了安全漏洞修复的建议,社区成员超过 1w 开发者,为超过 5w 个开源项目,执行超过 30w 次开源安全检测,发现安全漏洞超 70w 。
这个过程中,我们引入开发者加入到社区,通过他们的 Review 来检验工具检测出来的信息是否准确。大家都知道工具自动检测出来的结果是没办法自动推送给开发人员去修复的,还是需要去做一些简单校验。当然校验成本有高有低,但我们尽量会把这件事情的成本做得足够低。
社区开发者包括一些白帽子的角色就是帮我们去校准这些信息,可以非常低成本的成为社区中顶级开源项目的贡献者,与社区安全专家共同交流和学习,同时可以拿到最新开源项目的漏洞情报。
OSCS 社区会为大家分享一手的漏洞情报,当然此情报会经过官方授权包括官方公开一些信息或者说上报之后,我们还会去做的分享订阅。
最后,社区的整套逻辑背后,是基于 murphysec 开源检测工具提供的闭环支撑,包括从开始的化验(精准分析输出 SBOM)到问诊(专业漏洞缺陷检测、许可证合规分析)再到治疗(快速自动化漏洞修复),整个全流程闭环能力的打通来支撑上述各种各样的应用场景。
murphysec 项目地址:https://github.com/murphysecurity/murphysec
墨菲安全是一家为您提供专业的软件供应链安全管理的科技公司,能力包括代码安全检测、开源组件许可证合规管理、云原生容器安全检测、软件成分分析(SCA)等,丰富的安全工具助您打造完备的软件开发安全能力(DevSecOps)。
旗下的安全研究团队墨菲安全实验室,专注于软件供应链安全相关领域的技术研究,关注的方向包括:开源软件安全、程序分析、威胁情报分析、企业安全治理等。公司核心团队来自百度、华为等企业,拥有超过十年的企业安全建设、安全产品研发及安全攻防经验。