快手安全 X 墨菲安全 | 软件供应链安全解决方案完整分享

84 阅读 0 评论 56 点赞

我是靠谱客的博主火星上衬衫，最近开发中收集的这篇文章主要介绍快手安全 X 墨菲安全 | 软件供应链安全解决方案完整分享，觉得挺不错的，现在分享给大家，希望可以做个参考。

概述

前言

本次分享由墨菲安全联合创始人&研发负责人宇佰超于 9 月 26 日快手安全沙龙中分享，本次主题《软件供应链安全体系、方法与落地》，文末附本次分享视频链接，欢迎大家查阅分享，如有任何欢迎联系我们一起交流讨论～

完整视频地址：https://www.bilibili.com/video/BV1x24y1o7sE/?spm_id_from=333.999.0.0

随着国家 IT 及信息化的推广与普及、IT 行业的快速发展，软件供应链体系愈发的成熟。企业软件开发与信息化建设过程中，涉及与使用到的供应链比重越来越高。然而高占比的供应链软件的使用，再提升工程效率的同时，势必带来更多的软件供应链安全风险。本议题将结合墨菲安全软件供应链安全领域的研究及互联网、金融头部标杆客户的落地实践经验，着重介绍软件供应链安全治理解决方案，给出治理相关的技术点与实现方法，落地建议与方法案例。

Part 1：软件供应链所面临的风险

什么是软件供应链？举个例子：

房地产：钢筋水泥是供应链；
纺织行业：棉布丝绸都是供应链。

软件供应链近一两年慢慢走进大家的视野。通俗来讲，软件供应链是一个可以直接被拿来使用的轮子。开发者可以自己造一个轮子，把它放在 Github 上或者放在代码管理器上等等…这种情况下被其他开发者、项目使用，我们称之为软件供应链。

企业使用其建设自己的服务，比如 App 、商业软件，他们所做的商业软件也会作为软件供应链的一环流入到市场中会被其他的企业所使用，这也成为了软件供应链中的一部分。简单说，软件供应链安全就是指我们在从事企业生产过程中所用到的一些物料的安全。

新思 2021 年的统计报告中，基于 2400 个项目数据得出了以下结论：

开源代码占整个项目的比例达78%；
开源代码里有 81% 的开源代码至少存在一个漏洞；
项目里有 88% 的组件在两年内是没有更新的；
项目里有 85% 的开源代码在四年内是没有经过任何更改。

当下这几个数据仍呈现快速上升的趋势。这说明了做开源社区、供应链的整个生态的过程中，有很大一部分供应链或者是项目是没有得到完善的维护的，这存在问题的相当于售后的缺失。

软件供应链的风险主要分为四部分：

开源组件安全漏洞：这是安全同学最关心的三方组件的漏洞问题；
上游软件供应商风险：举个例子，前几天某友的一款产品爆发了 0 day 漏洞，这就是软件供应商带来的风险；
开源组件许可证合规：法务同学更关心开源组件许可证的合规问题；
软件供应链投毒事件：攻击者在开源软件供应链的链条中，利用软件供应链来传播挖矿或者勒索病毒，该类事件是这几年非常常见的。

Part 2：软件供应链的治理体系

软件供应链安全的治理体系是围绕着代码开发流程来做的，安全左移是如何做到的呢？

在做软件计划、需求、设计的时候，可以把研发所使用的源管理起来，这是从源头进行风险管理。
在代码开发和代码入仓的时候，把更多的安全能力赋能给研发同学，让他们更多地参与到整个的代码安全规范的过程中。
在项目构建的时候做卡位、在入库入仓的时候做卡位，甚至在对外发布服务、产品的时候做卡位。

Part 3：软件供应链的治理方法

根据以上介绍的体系，接下来拆解出各个部分，介绍一下它的实现方法。

一、制定需求阶段引入源的管理

我们先来看一下在项目需求和计划阶段可以做哪些内容呢？

黑白名单管理：很多企业对源进行管理，然后构建一个私有源。也有一些企业会对这个源标记黑名单或者白名单，明确哪些是不能用的，哪些是可以用的。

漏洞风险动态管理：打个比方，我现在使用的这个组件昨天它还没有爆出洞，那么大家都可以用，今天这个漏洞爆发出来了，从今往后大家都不要再用它了，这是一个动态的管理。大家在构建、编译、调试的时候，我们能动态来提醒现在引用的这个组件是有风险的，你引用了有风险的组件之后，代码是不允许被编译通过的。

源安全还有另外的一个问题，对源的投毒，这一部分偏向于云端的数据能力建设。这里共介绍三个简单的识别方式

元数据：例如是否伪造包的名称；
静态代码：分析代码里是不是有敏感函数的调用、诡异的数据、动态行为；
动态分析：这种更像是沙盒的玩法，真正的引用组件然后把代码真正的调用起来，看是不是有一些异常的这种文件行为。

二、开发过程中的建设方法

接下来看一下在代码开发过程中软件供应链安全建设应该如何去做呢？

近十年来，依赖管理发生了很大的变化。这种包管理器的出现极大的方便了识别软件里使用了哪些供应链的软件。

以上罗列了各个语言的识别的方式：第一个 github 地址就是我们开源的一个项目地址，通过各种各样语言的一个包管理器的识别方式，来识别出说我的这个项目里面到底用了哪些开源组件，或者说非开源的组件。

上边讲了如何识别项目中的风险组件，而安全左移的问题就是需要从项目开发的源头把安全能力建设好，研发如何能够更好的参与到代码安全的建设中呢？

安全需要给研发安全能力的赋能，有可以使用的工具，同时还需要一个丰富的知识库，怎么检测、知识库如何使用、怎么修复风险等等。比如我们要考虑三方组件的漏洞风险，该组件的维护能力、兼容性、流行度、许可证等等都是安全同学需要给到研发同学的解决方案的能力，同时该能力要使用起来非常便捷。最直观的一个工具就是 IDE 插件，能让研发在开发阶段尽早的识别风险，从源头把问题解决。

三、代码入仓节点的卡位

研发同学写完了代码，在推到仓库的这个过程中，安全运营最好能够做到一个比较理想化的卡位。举个例子，很多代码管理平台都很 open ，例如 Gitlab 提供了很多的 API，能够很灵活的集成其他的能力，这时候企业就能够轻松的把安全能力集成在 Gitlab 里。

在代码入仓的过程中可以做两件事。第一部分是摸底，大家能够知道仓库里代码的安全情况，企业能够更全面的掌握自身所使用的一些资产，进而能够更全面地掌握目前代码里面临的风险。第二部分是门禁，研发同学在提交代码的时候符合要求才可以提交成功。这块 Gitlab 提供了一个很好的机制，配置好 webhook ，在研发提交了代码之后就能够触发提交状态的消息提醒。同样的，一个完善的软件供应链安全系统，可以做到检测、通知一系列的事情，同时在研发提交的代码入库前，先进行一次检测，检测完之后再入库。