总结过去三年软件供应链安全一些非共识核心问题

写在前面

过去三年，我大概每年平均至少见300个企业的专家和大佬们，这三年下来也快1000人次了吧。虽然有一些人是重复见了很多次的，但每次见也多少会有新的收获。

因为工作的原因，我们聊最多的话题其实是跟软件供应链安全相关的，所以我最近就特别想把过去我们这1000次交流过程中，聊到的最核心的问题都提炼出来，然后在今年的产品迭代、公众号、直播、闭门会议、对外技术交流分享中，把这些内容重点放进去。

也是希望通过这样的方式，给所有准备做，或者正在做企业软件供应链安全的专家和大佬朋友们一些输入。

一方面可以把过去我们交流和讨论这些问题的一些成果分享给大家，让大家可以在思考和实践的过程中少踩坑。

同时我们可以就这些重点问题，结合各个企业的实际场景，进行更多更深入的讨论。让一些其他正在碰到/还没有碰到这些问题的朋友也能受益。

以上，就是今天这篇文章的想法和初衷。

我想这是一个长期的工作，后面我会把它整理成一个系列，这是第一篇。我可能更多的是抛出一些最关键的、被提及最多的问题，这些问题通常是非共识的。

之后我会不定期的通过不同的方式分享，也欢迎企业安全的各位专家和老师一起参加讨论。

软件供应链安全最被关心的20个问题

以下是我和我所有同事们一起总结出来的，被企业问到最多的20个非共识问题，我先把它们列举出来。

出于篇幅的原因，本文我将先聊聊对于前10个问题的简明扼要的看法。关于全部20个问题的解答，之后找时间我会汇总发出。

如果你们企业最近准备/已经开展软件供应链安全治理工作，不妨再好好梳理一下这20个关键问题，我相信对于你们开展这项工作治理一定会有一些帮助。

▸ 1）软件供应链安全太大了，到底什么是软件供应链安全？

▸ 2）软件供应链安全有哪些威胁场景？

▸ 3）如何向企业的管理者说清楚软件供应链安全的价值？

▸ 4）同行业企业软件供应链安全项目是怎么立的？

▸ 5）同行业企业是怎么落地的？效果和价值咋样？

▸ 6）软件成分分析工具识别出来的漏洞太多了？大家怎么处理？

▸ 7）怎么识别漏洞是不是真实存在影响？

▸ 8）软件供应链投毒严重吗，需要治理吗？

▸ 9）各个企业的开源安全治理的组织是怎么样的？

▸ 10）开源许可证合规治理需要做吗？怎么做？

▸ 11）一些开源组件漏洞研发反馈打了补丁修复了，怎么自动化识别有没有真修？

▸ 12）浏览器插件和IDE插件的投毒怎么防？

▸ 13）很多开源组件的漏洞没办法升级怎么办？

▸ 14）c/c++开源组件的漏洞可达性分析怎么做？

▸ 15）开源组件的准入准出应该怎么做？

▸ 16）开源和商业工具在软件供应链安全治理效果上主要的差异在哪？

▸ 17）商业软件供应商没有能力治理自己的软件安全怎么办？

▸ 18）开源组件风险治理的工作成果应该怎么去量化？

▸ 19）间接依赖的风险要不要解决，怎么解决？

▸ 20）二进制的漏洞识别准确率/覆盖率的问题如何解决？

01 到底什么是软件供应链安全？

为什么这个问题被问的很多。

一方面，近些年企业来自各种各样的软件供应链的威胁越来越多，不同企业面临着开源组件、商业软件、外包软件供应商等等不同场景的攻击事件。

另外一方面，是当前行业缺乏一个对于软件供应链安全定义的共识。

但是企业在急切开展软件供应链安全治理时，说清楚软件供应链安全治理项目的边界，又是必答题，所以通常这个问题被问的最多。

我想，我们要说清楚，或者定义清楚软件供应链安全的边界，必须要搞清楚软件供应链资产的分类标准，同时明确每一类软件供应链资产有哪些场景的威胁。

只有搞清楚这件事情，我们才能够清晰的定义企业的软件供应链安全边界在哪里，才能在立项时轻松应对企业管理者的关键问题。

关于这个资产分类和威胁分类标准是什么，我们联合一些企业也输出了我们的一些最佳实践，可以联系我们获取（视频号：白帽子章华鹏）。

02 软件供应链安全有哪些威胁场景？

企业为什么问这个问题这么多，本质上和第一个问题是一样的。

企业首先必须要知道，当他们在开展软件供应链安全治理时，一个治理的威胁场景全集是什么，这样未来才有可能持续的管理，以及衡量治理的进度和效果。

我们在梳理这些威胁场景的时候，我们会充分考虑每一类软件供应链成分已知的风险场景，比如开源组件的投毒、漏洞、许可证合规、仿冒等，又比如商业软件的漏洞、后门、劫持、代码抄袭等等，关于这个威胁场景的全集，我们在第一个问题中已经说明了，大家可以联系我们获取参考（视频号：白帽子章华鹏）。

03 如何向企业的管理者说清楚软件供应链安全的价值？

过去很多企业，在内部推进软件供应链安全立项时，企业基于ROI及降本增效的考虑，一定会反复问到，企业为什么要开展软件供应链安全的治理？价值到底有多大？

而回答这个问题的根本，就要回到企业安全的本质，也就是控制风险，而安全风险的三要素是资产、威胁、脆弱性。

那么我们只需要搞清楚企业（生产及办公业务系统）有多少软件及软件供应链资产，然后识别出来这些资产存在的潜在威胁和脆弱性是什么样的。

一方面，可以通过过去公司内/行业内典型的安全事件，来说清楚存在的潜在安全危害，比如工商银行美国子公司，因为软件供应链安全漏洞攻击被勒索事件。

另外一方面，我们也可以借助监管的一些要求，来明确说清楚，不治理可能潜在的企业违规风险。

而我们可以通过软件资产数 X 潜在威胁场景，来量化企业的潜在风险规模，从而说清楚治理价值。

04 同行业企业软件供应链安全项目是怎么立的？

在我看来，今天有很多企业并没有开展完整的软件供应链安全项目立项，大家很多时候更多的是围绕一个很痛的业务场景来进行立项，优先解决其中一部分问题。

比如金融业，大家更多的是开展开源组件安全治理工作，当然也有一部分企业，已经开始非常重视他们的商业软件供应链治理。

而互联网企业，除了开源组件安全治理之外，他们对于投毒攻击的关注度尤其重要。

而智能制造行业，又尤为关注开源组件许可证合规等相关的风险。

总之，在企业内部开展安全项目立项时，有两个关键点是我们需要思考的。

如果你有信心说服老板，什么是软件供应链安全威胁，那么你可以按照我们第一个问题的思路，说清楚并且成功立项。

另外一点是，如果你没有信心跟企业管理者说清楚软件供应链安全全貌是什么，那么你就先找到当下你最痛的（最好历史出过重大安全事件，或者最近友商出过重大事件的）点，先解决软件供应链场景中的局部问题。

这个时候一定要提前和老板对齐预期，千万不要让他觉得，你现在做的事情就是所有的软件供应链安全。

大家都知道的，如果你错误地引导了老板的预期，那么你的治理成果很难被老板认可，老板的默认预期是很高的。

05 同行业企业是怎么落地的？效果和价值咋样？

关于这个问题，我们可以相对负责任的跟大家说，在开源组件安全治理、软件供应链安全情报预警、开源许可证合规管理等场景，目前在互联网、金融、运营商、能源、智能制造等领域，还是有不少已经成熟落地运营的案例，包括很多运营超过2-3年的案例。

从效果和价值上来说，虽然很多企业没办法说已经把软件供应链安全治理的非常完美了。

但在一些相对聚焦的场景，还是能够说清楚，自己已经管控了哪些高风险的软件资产及威胁场景。

虽然没法说清楚软件供应链安全的全集是什么，但在明确高风险威胁场景下，也还是能说清楚治理的资产对象目标，以及达成很好的治理效果是什么。

06 软件成分分析工具识别出来的漏洞太多了？大家怎么处理？

这是在实际落地的时候，被问到最多的问题。

过去很多企业，一上来就不想开展软件供应链安全治理，核心因素就是在他的印象里，随便一个Java项目，基本上都会被软件成分分析工具，扫描出来上百个，甚至是数百个安全漏洞，那这怎么解决？这发给研发团队不就等着挨骂吗？

所以大家面临的首要问题，就是如何从这里面筛选出来真正有危害的漏洞，并且能够科学的分级。

但大家过去也都知道，这是一件极其困难的事情。因为每一个漏洞，你必须要分析清楚它的真正成因、利用方式、影响范围等等，这往往是需要投入极大成本的。而公开的漏洞库，往往极其缺乏这些准确的描述信息。

所以我们需要做的事情，就是分析清楚每一个漏洞的真正成因、利用方式、影响范围等等，同时这些数据必须要能结构化，并且结合企业代码项目中，对这些开源组件、软件的调用/使用方式来判断，是否会受到这个漏洞的影响，而通常做出这个判断非常非常地难。

但是我们可以换一种思路，如果我们能够过滤掉绝大多数明确的无效漏洞，那么剩下的极少数真正有影响的，或者无法判断是否真正有影响的漏洞，其实研发团队也就已经可以接受去处理它们了，更何况这里还会给出进一步的严重性优先级评估，这实际上非常非常重要。

而今天其实我们的成熟工具和产品，以及可以做到这样的水平，安全团队的工作完全可以得到研发同学的认可。

07 怎么识别漏洞是不是真实存在影响？

其实第6个问题已经回答了这个问题的绝大部分，我想补充说明的是，很多时候我们想要真正去验证，所有漏洞是否真实存在影响，这是极其困难的。

但是研发人员是真的要跟你较劲吗？他们需要知道每一个漏洞的真实影响吗？

其实并不是，他们关心的是如何降低他们的处置成本，如果需要处理的漏洞足够少，且单个漏洞的处置成本足够低。那么他们其实不愿意和安全同事去扯皮，我相信这是绝大多数的情况。

所以问题就简化成了我们如何过滤掉所有的已知不会真实有影响的场景，然后我们用技术去做自动化排除。

然后我们需要想办法尽可能地降低他们的修复成本，包括提供一键修复的工具、包括生成自动修复的代码等等。

08 软件供应链投毒严重吗？需要治理吗？

毫不夸张地说，我认为过去三年，黑灰产和企业都严重低估了针对开源组件、开源软件、商业软件的投毒，所能带来的极大攻击成功率。

所以当你在2024年下半年到2025年第一季度，看到大量关于开源组件、商业软件、开源项目的投毒案例时，你会惊叹于原来成功率这么高。

本质上这件事情理解起来很简单，主要有几个方面的核心因素：

1）今天开源组件/软件发布和管理的安全生态，可以说是没有任何门槛，谁都可以在中央仓库和github等开源平台，上传一个开源项目/组件，而且稍作运营就能够拥有大量的使用者。

更不用说很多攻击者精心设计的使用企业内部包名投毒，设计仿冒的热门项目投毒，甚至一些简单的拼写错误投毒，这些成功率都高的吓人。

2）对于攻击者来说，通过这样的攻击搞网络勒索/挖矿的ROI是非常高的，几乎没有什么成本。

这两者就必然导致开源组件/软件投毒这件事情，对于企业未来几年的安全威胁都是巨大的，因为本质上开源生态的安全治理不太可能一时半会儿解决，而越来越多的黑灰产尝到投毒的甜头后，一定会愈演愈烈。

09 各个企业的开源安全治理的组织是怎么样的？

越来越多的企业安全部门发现，开源软件供应链安全治理的工作，光靠安全部门的努力是行不通的。

因为本质上，这根本就不是一个独立的安全问题，企业的开发人员在选择开源组件时，或者修复开源组件安全漏洞时，他们不可能只考虑安全问题，他们在选择和升级开源组件时，必须要考虑这个开源组件及其版本的生态健康度，包括维护团队、生态活跃度、可扩展性、对于业务场景的适配等等。

所以开源组件的安全治理是需要研发部门、架构部门、工程效率部门、法务部门、安全部门等都参与进来的工作，这种情况下一般企业都会成立开源治理委员会，由前面提到的几个部门的负责人组成一个虚拟组织，通常CTO会是这个组织的主席。

然后安全、架构部门、工程效率部门来一起主导这个事情治理，当然，由哪个部门来主持工作，通常这几个部门来主持的我都见过。然后在这个虚拟组织下面会成立不同的治理小组来开展具体的治理专项。

10 开源许可证合规治理需要做吗？怎么做？

通常会考虑这个问题的公司，一般主要有几类场景：

1）业务出海。比如有软件/硬件产品要交付给海外的大型企业。这些企业通常非常关心你交付给他的软件/硬件中依赖的开源组件是否存在许可证合规风险。

2）企业一些软件项目要在社区开源。这个时候全球的开发者，都会关注你开源项目的所有代码是否满足开源许可证的约束。

3）所有大型的企业。通常他们在行业内有广泛的影响力，一旦被人发现不合规地使用开源组件，可能会面临舆论风险，同时也有可能被开源社区声讨。

如果你们的企业存在这几类的场景，那么你应该重点考虑开展开源许可证合规治理工作。

通常来说，你们的技术（安全/工程效率部门）或者法务部门需要采购专业的软件成分分析工具，对所有的线上业务进行成分分析，并明确代码项目中依赖的所有开源组件/软件。

这个时候需要你们的知识产权法务同事，对这些检测结果进行专业的分析和研判，是否涉及侵权。

法务同事在确认这个事情的时候，通常是需要和业务研发的同学来确定，这个代码项目的具体使用场景，才能确定真正的影响。

确定影响之后，需要根据该开源许可证的约束来调整你的项目如何合理的使用这些开源组件。

写在最后，诚邀各位一起聊聊

文章的篇幅和阅读体验的考虑，本文先简明扼要的聊了聊前10个问题，剩下的问题我们会在后续陆续分享。

同时关于更多我们没有提到的问题，大家可以一起交流（可关注视频号：白帽子章华鹏）。