我所理解的开源软件供应链安全

供应链与断供

隐喻会帮助人,也会误导人。

当我们谈到“供应链”时,会产生哪些联想?环环相扣?缺一不可?掉链子?当我们这样去思考软件供应链,或者开源软件供应链时,同样的“意象”也会出现在我们的脑海里。

一条从不知名的远处延伸到我们面前的链条,这个链条的最后一环,是一款我们看得见、用得上的软件。

这个链条当中,有很多环节都是别人(美国)提供的。也许有一天,美国(人)一旦决定,拿回他的那一环。我们就断供了,延伸到我们面前的链条就断掉了,我们手中正在使用的软件,就消失了。

这就被称为————“断供”。

物质断供

当一个链条是由物质构成的时候,这个“意象”并不是幻想,而是实实在在的现实。比如:芯片断供,手机缺货。GPU断供,显卡涨价。

当我们想要把这个情况,引申到软件、甚至开源软件领域的时候,我们必须重新定义“断供”。

这就带来了各种“乱象”。

开源软件断供:分类

从中国,无法下载到美国(Github)上的开源代码。或者无法及时下载到最新的源代码

一个开源社区,用规则或潜规则,拒绝中国开发者,导致中国开发者被排除在外。我们的开发者被禁止向上游提交代码,无法参与、回馈社区

在某个版本之后,该软件不再提供开源代码

基于某种License(不允许商业使用、不允许邪恶用途、不允许特定国家使用)

开源本身不断供,但是开源所依赖的服务,无法使用

整个Github不允许你使用

具体某一款开源软件的某一个版本,存在安全漏洞,需要修复(或替换)

一款无人维护的开源软件(维护不及时,不到位),比如曾经的OpenSSL,就是一种值得关注的风险

《技术的本质》与其不足之处

首先推荐一本非常了不起的著作《技术的本质》(布莱恩·阿瑟),在这本书中,布莱恩提出了一些极其深刻的洞见。例如:技术的本质是对现象的驾驭。以及:技术是组合与递归的。

我想继续引申这个观点。类似于我们在做软件开发时,通常会定义的一个依赖文件。一款软件,会依赖一组其他软件(包),而这些软件(包)又会进一步的依赖某些其他的软件(包)。但是,随着包依赖描述的不断改进,我们会区分:开发期(Dev)依赖与执行期(Running)依赖。

在更加广泛的技术领域,我们也会发现类似的现象。我们发明一种新技术时(开发期),会依赖一组其他已有的技术。但是,当我们基于这个新技术,生产某一个产品时,会依赖另外一组技术(编译期),当我们的产品被实际使用时,还会依赖其他一些技术(执行期)。

当我们泛泛的分析技术时,可以发现其中的组合与递归结构。而当我们更加深入的分析技术的依赖关系时,会发现不同的依赖与递归结构。

依赖与风险

《技术的本质》告诉我们,依赖一定存在,而且无穷无尽。但是:依赖不能简单的等同于风险,至少不能等于同样大小的风险。

当我们对于开源软件,做供应链风险分析的时候。泛泛的树立一个假想敌,然后一概以风险视之,不但将风险不断放大,也将防范风险手段无限提升。

我认为:这并非一种理性的应对风险的策略。

换一种隐喻

如果我们将“链条”的隐喻,换成“生态圈”的隐喻,来看待软件、以及开源软件所面临问题。也许会更加有利于我们朝向正确的方向前进。

空气、水、土壤与风,是环境的一部分。温度、湿度、海拔也是环境一部分。对于一个生态圈来说,我们虽然也提“食物链”,但是很难想象:一个单一物种的缺失,会导致整个食物链的断裂,以及食物链上端的物种全部灭绝。所以:事实上现在描述生态系统时,常用的概念是“食物网”而非“食物链”。

作为软件行业的从业者,我们应该关注整个生态的健康程度,以及预防可能存在的“污染”和“破坏”。甚至,考虑到生态多样性,我们也的确应该支持更多类似的软件,甚至竞争性的平台。

但是:这并非一场“为了防止我的链条断掉”,而发起的一场“伟大战斗”。这是一场“建设更加丰富、繁荣的软件生态的运动”。

所以,我的提议是:不再提“开源供应链安全”,而是提“开源生态建设”。

与诸君探讨。