用社区和开发者工具驱动软件供应链安全治理

本文整理自 OSCS 软件供应链安全技术论坛- 章华鹏老师开场致辞的分享内容。

章华鹏,十二年的企业安全建设、安全社区白帽子、开发者,先后在百度、贝壳负责过企业安全建设 ,也在乌云负责过安全产品,业余时间活跃于安全技术社区,帮助企业、开源项目、软件公司解决过数百个严重安全问题,现在负责墨菲安全和 OSCS 社区,专注于软件供应链安全方向。

软件供应链安全的概念

今天讲一讲我对于整个软件供应链安全的理解。100 多年前 1905 年的时候,独立报第一次提出关于供应链概念,过去 100 多年,大家聊得更多是关于整个供应链安全的管理。供应链的管理本质上是产品从原材料到形成最终产品的整个过程的管理,目的是要提升它的效率,包括整个过程的保障。

从上述角度来讲,我们去定义整个软件供应链的安全,可以把它理解为一个软件的产品,从原材料包括组件代码,经过分发包括二次的开发,最终形成软件产品的整个过程中的安全保障。在保障的过程中,最终希望软件的消费者能够在使用软件的过程中保障它的数据和使用过程的安全。其最终的目的其实还是为了去提升最终客户的价值。

把这件事拆解开来去看,软件供应链从原材料到分发和生产应用的过程中,我们可以把它拆解成几部分:

用社区和开发者工具驱动软件供应链安全治理

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

软件供应链的三大风险

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

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

第一个风险是会有一些漏洞的攻击。比如一些开源组件: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、dataease500+ 开源项目提交了安全漏洞修复的建议,社区成员超过 1w 开发者,为超过 5w 个开源项目,执行超过 30w 次开源安全检测,发现安全漏洞超 70w

已有数千名开发者加入 OSCS 社区

这个过程中,我们引入开发者加入到社区,通过他们的 Review 来检验工具检测出来的信息是否准确。大家都知道工具自动检测出来的结果是没办法自动推送给开发人员去修复的,还是需要去做一些简单校验。当然校验成本有高有低,但我们尽量会把这件事情的成本做得足够低。

社区开发者包括一些白帽子的角色就是帮我们去校准这些信息,可以非常低成本的成为社区中顶级开源项目的贡献者,与社区安全专家共同交流和学习,同时可以拿到最新开源项目的漏洞情报。

/
(0)
上一篇 2023年8月9日 下午9:18
下一篇 2023年8月9日 下午9:32

相关推荐

  • 企业开展开源安全治理必要性及可行性详细分析

    背景 开源软件安全威胁是近几年企业安全面临的主要威胁,也是企业应用安全方向讨论的热门话题,但是由于是新的需求新的方向,很多企业在观望,当前开展这项工作是否已经成熟,项目成功率如何? 当新鲜事物产生时,首先我们应该积极的态度去拥抱它,但是它是不是真的值得我们投入(包括当下工作和未来个人技术成长),就需要客观的分析其必要性,同时结合自身情况了解它的可行性。 开源…

    2024年3月18日
    0
  • 14 条策略助力企业构建更安全的软件供应链

    每个软件都存在供应链,然而现代软件大部分代码都是开源的,这意味着任何人都可以访问和编辑。但是软件平台的安全取决于其最薄弱的环节,安全漏洞可能随时出现,因此技术领导者必须建立监控和保护供应链中每个环节方案和动作。福布斯技术委员会给出应对软件供应链安全的14条明智的策略,为开发者、企业的安全建设带来思考和建议。 承包商在建造建筑物的时候,会按照计划和流程去采购使…

    2023年8月9日
    0
  • 剖析美国政府视角下的ICT供应链安全

    2018 年 11 月 15 日,美国国土安全部(DHS)宣布成立了信息和通信技术 (ICT) 供应链风险管理(SCRM)工作组,这个工作组是由美国多个政府部门、IT行业企业代表及通信行业企业代表联合成立的。该组织对外宣传的目标是识别和管理全球 ICT 供应链的风险。 之后该组织非常活跃,2024 年 2 月 6 日,该组织刚刚宣布将工作组延长两年。我们翻阅…

    2024年3月25日
    0
  • 《信息安全技术 软件供应链安全要求》征求意见稿

    2022年9月30日,全国信息安全标准化技术委员会归口的国家标准《信息安全技术 软件供应链安全要求》现已形成标准征求意见稿。 本文件给出了软件供应链安全保护目标,规定了软件供应链组织管理和供应活动管理的安全要求。 标准文本下载:https://pan.baidu.com/s/1NvAjVmrUMUjOyu-YOCTVSA 提取码: 324a

    2023年8月16日
    0
  • 《信息安全技术 ICT供应链安全风险管理指南》(GB/T 36637-2018)

    《信息安全技术—ICT供应链安全风险管理指南》(GB/T 36637-2018)是2019年5月1日实施的一项中国国家标准,归口于全国信息安全标准化技术委员会。 《信息安全技术—ICT供应链安全风险管理指南》(GB/T 36637-2018)规定了ICT供应链的安全风险管理过程和控制措施,适用于重要信息系统和关键信息基础设施的ICT供方和运营者对ICT供应链…

    2023年8月22日
    0