软件供应链安全的核心到底在哪？

软件供应链安全的挑战大头是来自维护者，大部分开源组件的维护者都依赖某一两个人，无论看上去这个组件有多少个 commit，总会是某几个人贡献度排在前列，但是这些维护者一方面没啥钱可赚，另一方面也没有足够的资源、时间来做维护，这一定会导致软件更容易变脆弱...

不管企业用到了多强大的 SBOM 工具、供应链分析、依赖分析 blabla 各种听起来很天花乱坠的东西，没解决根上的问题，供应链安全也无从谈起。

确实，国内外有很多供应链安全工具厂商，但它们在解决问题上都存在很大的滞后性，也就是说这一类工具关注的重点是事后检测和缓解，例如识别已知的漏洞、生成软件物料清单等，但是这些工具都没法在漏洞被利用之前预判风险。

软件签名是通过验证软件的来源和完整性，来防止恶意软件通过供应链传播，降低供应链攻击的风险。但是吧，软件签名方案只能保证这个包来自可信的开发者，也能保证这个包发布后没有被篡改，并没法对供应链安全有更多的保护，也没法解决根上的问题。

一般大家喜欢用 SCA 来识别、分析自己代码里用到的开源和第三方组件，SCA 工具可以通过依赖扫描确定一个应用的直接和间接依赖项，也能识别出这些依赖的已知漏洞，还可以做一些许可证合规。不过 SCA 能做到关于供应链安全的一切，都要依赖已知漏洞库，因此还是一样的滞后，么得办法。

广义的安全网关实际包含一切防火墙、API 网关之类的，我们在供应链安全中使用的安全网关功能也比较有限，无非是做一些第三方组件的入口检查、仓库访问控制、Pipeline 上做扫描之类，不过劣势和上面的解决方案都差不多，那就是滞后性。

威胁情报也是滞后，而且误报、漏报有点多，大家经常面临的情况就是情报千千万，运营三五条，信噪比太低了，安全运营如果过分依赖低质量威胁情报源，很容易做大量的无用功。

确实，几乎所有安全解决方案都存在滞后性，但难道就不做了吗？不是的，还是要看性价比，小公司我觉得可以做做尝试，用开源工具免费工具来简单做做供应链基础，至少控制一下仓库组件版本之类；大厂再好好做探索就行。

有些人会说，砸钱呗！给开源组件维护者发钱，某种程度上确实能解决这个问题，对于小型项目或者组件，砸钱能几乎解决99%的问题。再大再复杂一点的项目，就像 Linux 内核、Open SSL、K8s、Node.js 之类，给再多钱，维护者都不一定有时间，也可能由于技术限制眼界限制等等很难解决安全问题。

V社（Valve）试图砸过钱，他们找了超过100位开源开发者，让他们帮忙开发 Proton 兼容层、Mesa 图形驱动程序和 Vulkan，同时也在推进 Steam for Linux 和 Chromebook 等项目，效果有但有限，因为这世上还有很多开源组件的维护者是靠自己的热爱驱动项目推进...

不过我认为另一种砸钱方式是好的，如果你的项目依赖于某个开源软件，那么就你们公司的一部分人加入社区，真真正正的给项目添砖加瓦（而不是像某些公司刷 KPI 改 log），把投入开源项目的工时计算给参与者，只有这样做才能减轻开源项目维护者的负担。

 

原文始发于微信公众号（imBobby的自留地）：[周末闲聊]软件供应链安全的核心到底在哪？