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

Tips：本文为业内企业干货投稿，本期先放出20个问题中的上半部分。3月26日晚19:00的线上闭门会，会有京东、小米、理想、字节、某股份制银行、某头部券商、某头部运营商等企业安全大佬，一起专场讨论这些软件供应链安全的核心问题，会议结束后将会继续放出本文的下半部分，敬请期待。（可根据文末报名方式进行报名，联系安全419官方账号“anquan_419”享受优先参会权利。）
 

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

▸1）软件供应链安全太大了，到底什么是软件供应链安全？
▸2）软件供应链安全有哪些威胁场景？
▸ 3）如何向企业的管理者说清楚软件供应链安全的价值？
▸ 4）同行业企业软件供应链安全项目是怎么立的？
▸ 5）同行业企业是怎么落地的？效果和价值咋样？
▸ 6）软件成分分析工具识别出来的漏洞太多了？大家怎么处理？
▸ 7）怎么识别漏洞是不是真实存在影响？
▸ 8）软件供应链投毒严重吗，需要治理吗？
▸ 9）各个企业的开源安全治理的组织是怎么样的？
▸ 10）开源许可证合规治理需要做吗？怎么做？
▸ 11）一些开源组件漏洞研发反馈打了补丁修复了，怎么自动化识别有没有真修？
▸ 12）浏览器插件和IDE插件的投毒怎么防？
▸ 13）很多开源组件的漏洞没办法升级怎么办？
▸ 14）c/c++开源组件的漏洞可达性分析怎么做？
▸ 15）开源组件的准入准出应该怎么做？
▸ 16）开源和商业工具在软件供应链安全治理效果上主要的差异在哪？
▸ 17）商业软件供应商没有能力治理自己的软件安全怎么办？
▸ 18）开源组件风险治理的工作成果应该怎么去量化？
▸ 19）间接依赖的风险要不要解决，怎么解决？
▸ 20）二进制的漏洞识别准确率/覆盖率的问题如何解决？

 

 

为什么这个问题被问的很多？一方面，近些年企业来自各种各样的软件供应链的威胁越来越多，不同企业面临着开源组件、商业软件、外包软件供应商等等不同场景的攻击事件；另外一方面，是当前行业缺乏一个对于软件供应链全定义的共识。但是企业在急切开展软件供应链安全治理时，说清楚软件供应链安全治理项目的边界，又是必答题，所以通常这个问题被问的最多。
 

我们要说清楚或者定义清楚软件供应链安全的边界，必须要搞清楚软件供应链资产的分类标准，同时明确每一类软件供应链资产有哪些场景的威胁。只有搞清楚这件事情，我们才能够清晰的定义企业的软件供应链安全边界在哪里，才能在立项时轻松应对企业管理者的关键问题。关于这个资产分类和威胁分类标准是什么，我们联合一些企业也输出了我们的一些最佳实践，可以联系我们获取，当然也会在3月26日的闭门会上分享。

 

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

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

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

 

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

过去很多企业，在内部推进软件供应链安全立项时，企业基于ROI及降本增效的考虑，一定会反复问到，企业为什么要开展软件供应链安全的治理？价值到底有多大？而回答这个问题的根本，就要回到企业安全的本质，也就是控制风险，而安全风险的三要素是资产、威胁、脆弱性。

 

那么我们只需要搞清楚企业（生产及办公业务系统）有多少软件及软件供应链资产，然后识别出来这些资产存在的潜在威胁和脆弱性是什么样的。一方面，可以通过过去公司内/行业内典型的安全事件，来说清楚存在的潜在安全危害，比如工商银行美国子公司，因为软件供应链安全漏洞攻击被勒索事件。另外一方面，我们也可以借助监管的一些要求，来明确说清楚，不治理可能潜在的企业违规风险。
 

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

 

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

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

比如金融业，大家更多的是开展开源组件安全治理工作，当然也有一部分企业，已经开始非常重视他们的商业软件供应链治理。而互联网企业，除了开源组件安全治理之外，他们对于投毒攻击的关注度尤其重要。而智能制造行业，又尤为关注开源组件许可证合规等相关的风险。
 

总之，在企业内部开展安全项目立项时，有两个关键点是我们需要思考的：如果你有信心说服老板，什么是软件供应链安全威胁，那么你可以按照我们第一个问题的思路，说清楚并且成功立项。另外一点是，如果你没有信心跟企业管理者说清楚软件供应链安全全貌是什么，那么你就先找到当下你最痛的（最好历史出过重大安全事件，或者最近友商出过重大事件的）点，先解决软件供应链场景中的局部问题。
 

这个时候一定要提前和老板对齐预期，千万不要让他觉得，你现在做的事情就是所有的软件供应链安全。大家都知道的，如果你错误地引导了老板的预期，那么你的治理成果很难被老板认可，老板的默认预期是很高的。

 

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

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

限于篇幅，我在这里没法说非常细的逻辑，在3月26号的闭门会上我也会邀请这些企业的大佬展开详细聊聊。从效果和价值上来说，虽然很多企业没办法说已经把软件供应链安全治理的非常完美了，但在一些相对聚焦的场景，还是能够说清楚，自己已经管控了哪些高风险的软件资产及威胁场景。虽然没法说清楚软件供应链安全的全集是什么，但在明确高风险威胁场景下，也还是能说清楚治理的资产对象目标，以及达成很好的治理效果是什么。

 

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

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

过去很多企业，一上来就不想开展软件供应链安全治理，核心因素就是在他的印象里，随便一个Java项目，基本上都会被软件成分分析工具，扫描出来上百个，甚至是数百个安全漏洞，那这怎么解决？这发给研发团队不就等着挨骂吗？所以大家面临的首要问题，就是如何从这里面筛选出来真正有危害的漏洞，并且能够科学的分级。
 

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

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

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

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

 

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

其实第6个问题已经回答了这个问题的绝大部分，我想补充说明的是，很多时候我们想要真正去验证，所有漏洞是否真实存在影响，这是极其困难的。但是研发人员是真的要跟你较劲吗？他们需要知道每一个漏洞的真实影响吗？
 

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

所以问题就简化成了我们如何过滤掉所有的已知不会真实有影响的场景，然后我们用技术去做自动化排除。然后我们需要想办法尽可能地降低他们的修复成本，包括提供一键修复的工具、包括生成自动修复的代码等等。

 

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

毫不夸张地说，我认为过去三年，黑灰产和企业都严重低估了针对开源组件、开源软件、商业软件的投毒，所能带来的极大攻击成功率。所以当你在2024年下半年到2025年第一季度，看到大量关于开源组件、商业软件、开源项目的投毒案例时，你会惊叹于原来成功率这么高。

 

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

1）今天开源组件/软件发布和管理的安全生态，可以说是没有任何门槛，谁都可以在中央仓库和github等开源平台，上传一个开源项目/组件，而且稍作运营就能够拥有大量的使用者。更不用说很多攻击者精心设计的使用企业内部包名投毒，设计仿冒的热门项目投毒，甚至一些简单的拼写错误投毒，这些成功率都高的吓人。
 

2）对于攻击者来说，通过这样的攻击搞网络勒索/挖矿的ROI是非常高的，几乎没有什么成本。这两者就必然导致开源组件/软件投毒这件事情，对于企业未来几年的安全威胁都是巨大的，因为本质上开源生态的安全治理不太可能一时半会儿解决，而越来越多的黑灰产尝到投毒的甜头后，一定会愈演愈烈。

 

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

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

 

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

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

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

 

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

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

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

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

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

如果你们的企业存在这几类的场景，那么你应该重点考虑开展开源许可证合规治理工作。通常来说，你们的技术（安全/工程效率部门）或者法务部门需要采购专业的软件成分分析工具，对所有的线上业务进行成分分析，并明确代码项目中依赖的所有开源组件/软件。
 

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

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

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

 

更多精彩分享，请关注以下闭门会议报名信息：