OSCS 闭门研讨第一期实录：软件供应链安全建设价值

2023 年 7 月 18 日晚 19:30，软件供应链安全技术交流群（OSCS）组织了第一次线上的闭门研讨会，本次研讨会我们收到 71 个来自各个企业关注软件供应链安全的技术专家的报名，根据研讨会参与规则要求，我们对报名人员进行了审核，最终来自互联网、金融、运营商、软件厂商、国央企超过 35 名安全专家参与了当晚的研讨会，由于讨论过于激烈，原定于 21 点结束的研讨会，拖到 21 点 40 才结束，因为我们内部人力的原因，一直拖到现在才把研讨会的核心内容整理发布出来，先给大家道个歉。

《软件供应链安全建设价值》主题分享

研讨会的第一部分是由墨菲安全创始人&OSCS 发起人章华鹏带来的主题分享，章华鹏用三个公式来分享如何思考软件供应链安全的建设价值。

接下来对公式中的各个因子进行逐一的拆解和剖析，首先要管理软件供应链安全的风险，盘点清楚软件供应链安全资产是其中最关键的环节，资产台账是需要管控的风险的对象的总集，也是未来衡量其建设价值的重要分母，分母说不清楚价值就说不清楚。

关于软件供应链资产台账的采集可以从办公软件、自研生成软件、外采生产软件等三个维度来进行采集和统计。

软件供应链攻击可能导致的数据泄露仍然是企业最关心的风险点。

其次是软件知识产权合规的满足，做为软件使用方和软件生产方都有非常重要的代码知识产权合规管理问题。

此外，大家最关注的还是hvv期间，自己不要被攻破，毕竟现在攻防演练最常用的攻击手段就是利用来自软件供应链的漏洞。

除了一年一度的大型攻防演练，日常大家最关心的风险其实就是因为软件供应链的通用漏洞被勒索的风险。

对于企业内部中高阶管理人员来说，软件供应链安全是一个新的技术方向，在新的技术方向有一些前沿的技术探索和实践，并对行业有所输出必然是提升自己在行业内的影响力的很好的一种方式。

关于建设的收益讲完了，再来讲讲建设所需的成本，这个成本大多数时候主要还是运营成本，实际上接入成熟的软件供应链安全能力，运营成本是非常可控的。

首先是部署和使用软件供应链安全能力的成本，这个成本如果是使用成熟的商业产品，那么成本非常可控，如果是自研，那么从工程和漏洞知识库的运营方面来说，都非常高。

此外就是软件供应链安全问题的处置成本，漏洞如何快速修复且规避软件升级带来的兼容性问题，过滤掉不会真实触发的漏洞，将是最核心的挑战。

关于日常的安全技术运营是保障持续运营效果非常重要的手段，持续提升开发人员的安全意识，明确企业软件供应链安全治理要求是必需的。

分享几个企业关于软件供应链安全治理的案例

高性价比的治理方案

体系化的进行整理的案例

会前收集问题的研讨摘录

Q1：如何保证漏洞数据的正确性

很多 CVE 漏洞，有很多数据字段是缺失的，从各个公开的渠道采集的一些漏洞，一些数据信息不一定是准确的。这个问题核心是说怎么保证做供应链工具安全检测的时候，整个漏洞库数据是准确的？包括它的一些字段、修复方案、影响范围等等

| 某互联网企业大佬：过往会收很多漏洞情报，收完之后专门安排一些同学去做加工处理，来校准数据。

| 某软件厂商大佬：我们是实际这方面积累的不多，主要是用集团的能力。我们在漏洞，比如说在 SCA 识别出来，然后和漏洞库碰撞之后的漏洞修复方面是有一些沉淀，我们团队会去做一些漏洞利用条件的提取，尽可能的把这些东西沉淀下来给开发看，转成开发的一些语言，帮助他们更好的去修复漏洞，其实就是减少他们的工作量。

| 某软件厂商大佬：我们会发现外部的漏洞库有几个比较坑的地方，比如说 CVE 的漏洞，前段时间和某金融企业的安全团队在交流，CVE 的很多漏洞它标识的组件影响范围是非常不准确的，还有log4j 漏洞其实是影响的模块是不一样的。比如有 log4j-core，log4j-api 等等，有很多不同的这个模块，漏洞影响模块不一样，但是在 CVE 里面的标识信息就只写了一个 log4j。当你去做漏洞匹配的时候，就有可能导致会把所有 log4j 相关的漏洞都会匹配出来。但是实际上不同的漏洞影响的模块其实不一样的，这是一个比较典型的坑，这个坑就像刚才讲的，可能需要人工去留用每一个漏洞它实际影响的情况去做一些分析。这个分析可以保证后面匹配结果的一些准确性，这是其中一个点。

再比如修复方案，其实很多数据是没有的，甚至说要去校准不同的数据来源采集的数据里面，每一个漏洞的修复方案的准确性。

十多年前，阿里的空虚浪子心做 Java 漏洞研究，他有提过怎么去挖 Java 的 0 day ，Java 的一些 0 day 漏洞是需要做某个配置的情况下才会触发这个 0 day。有些人会在社区里面教别人去做那个错误的配置。很多外面采集的一些数据，给的修复方案其实都是不对的。我其实觉得没有什么特别多的技巧，每个漏洞可能需要去梳理它真正的影响，包括漏洞的修复方案可能要去做一些校验。这样推给研发去修的时候，保证安全的专业性和权威性不受到挑战。

Q2：软件供应链攻击的威胁和防范措施，供应链的透明度和可追溯性，供应链安全与合规。

| 某软件厂商大佬：第一个问题实际是供应链的一些能力建设，第二部分其实更多的是软件供应链资产台账的建设。第三部分更多的其实合规，一个是出海可能更多的是考虑许可证的合规。另外是国内自主可控信创的一些合规。下次可以围绕这个问题专门来做一次研讨会。

Q3：如何减少供应链漏洞的误报情况

| 某软件厂商大佬：减少误报我理解是有两件事情要做。

第一件事情是识别的供应链成分的准确性，这一部分我们过去的一些实践主要是去识别，比如像 Java 的很多项目，它在 pom.xml 里去做配置的时候有标记 scope 为 test 的，有的是 runtime 的等等，它有不同的标签。不同的标签对应组件是会在不同的这个编译环境里面去用到的。这是一个需要注意的地方，比如说测试环境会用到的组件，可能在线上不会受影响，那么再去发漏洞的时候要把这一部分排除掉。

第二块是在做供应链成分分析的时候，要考虑成分分析的准确率。比如说像 Python，做包管理工具，做包管理依赖的时候可能不会识别准确的具体版本，当去泛匹配的话，那可能会导致误报，这是最基础的一些误报，当然还有很多其他情况。

第二个主要情况漏洞可达性的验证，在海外做这件事情是非常多的，但是国内提的非常少。我们统计 95% 以上的漏洞是误报，比如 fastjson 只是匹配到这个版本是有漏洞的，但实际上 fastjson 缺陷类函数方法在代码里面会不会触发？包括说它触发的这个函数类方法在代码里面有调用，但它的污点是不是能够传进来一些被可控的参数，甚至说有一些漏洞，它对于依赖环境，像 JDK 版本有依赖，那它才会被触发的。那这些都是在减少误报检测结果的时候需要考虑的点。在海外有比较成熟的基础叫漏洞可达性的分析，我们目前做的比较多的是函数类方法，这种代码级别的识别，最近也在做依赖环境识别的这种匹配，降低漏洞不可达的情况。

上面的回答中也有提到：研发让演示漏洞是不是真的受影响。有时候研发其实比安全更懂代码中漏洞会触发这个函数类方法，其实是没有调用的，这会导致说研发会质疑安全给的结果是不准确的。

| 某软件厂商大佬：我是比较赞同刚才说的那两种思路，其实还有种方法是把漏洞库串起来，可是我们对于工具改造这方面是没有太多经验，因为我们得用公司的产品。我们维护的其实是漏洞的利用条件。另外一种是针对误报的漏洞，维护误报的漏洞库，反向去优化我们的漏洞库。

| 某互联网企业大佬：有些困惑为什么大家会有误报的问题？除了 fastjson、log4j 这种影响范围比较大的，其他的高危漏洞顶多影响几十个，几百个资产，修复成本也不高。

| 某软件厂商大佬：其实有一些公司，有一些组件依赖比较复杂要做升级，可是系统现在已经没有人维护了，新人刚接手要去维护这个老系统，要做升级，升级完之后可能会出现兼容性问题，所以不太愿意修。

另外有一些公司，研发相对来说比较强势，项目的进度又卡得比较紧，很多时候研发的心理是我不想修漏洞，我也不认可安全天天让我修漏洞这件事情，那研发就会质疑：漏洞是真的会有影响吗？如果研发刚好很懂安全，判断代码逻辑里面确实是不会被这个漏洞触发，如果发生了这样的质疑，安全再找他去修漏洞，他的配合度肯定就不高了。因为只做版本匹配，其实只是一个潜在的隐患。并不意味着说这个漏洞一定会触发，或者说会对线上代码造成影响。很多公司的研发部门会对这件事情质疑比较多的。

但像在某某云这种国企单位或者公司管控要求很高，尤其是国家的基础设施，那公司有制度，那就必须要改，研发的配合度会很高。但是大部分的泛互联网的客户其实很难解决这个问题。

Q4：怎么有效建设推广？建设好之后怎么能充分发挥作用？

| 某软件厂商大佬：今天咱们先不展开，先讨论主要通用的方法。第一运营推广，像某某云的经验基本上会出制度、规范、要求。某某云是提了漏洞清零的要求，所有交付给客户的基础容器的漏洞是要求清零的。出制度、出考核，出奖惩，去做制度的宣贯运营，给研发提供配套的工具。去做考核，某某云的推广是比较强的。问题里提到得不到开发的认可就暂停了。我个人感觉应该是公司管控要求没有那么严。

Q5：主要矛盾和收益如何定义

| 某软件厂商大佬：之前是事件驱动，现在每天不一定有那么多事件，那去做这件事情就相当于原来的驱动力没有了，例行做这件事情的话，长期的收益怎么去评估。

我原来在贝壳的时候和在百度的时候做安全的思路和理念，发生了一个非常大的变化，也有可能是因为在贝壳的老板是建行出来的。互联网公司典型的思路是出大的事件了那我赶紧趁机会把能力建设一下。但是在银行或者在很多关基行业，它的建设是比较倾向于先把整个公司整体的风险降低，比如说要把整个资产识别出来：比如说办公网、生产环境、包括外采的系统的所有的资产梳理出来，梳理出来之后会去分析。尤其 CTO 甚至 CEO 这个层面，关注的是能不能讲清楚整个公司在软件供应链安全这个方向全局的现状是什么样子的？比如有多少资产，这些资产有多少隐患？隐患是否可以通过我们历史发现问题来解决？比如说美团所有的SRC发现了多少类似漏洞，或者出现了多少攻击的事件，护网期间有多少攻击事件，从所有的维度去统计出来全局的资产关联了有多少风险。甚至说从分析结果里面去预测出哪些重点资产，重点业务对应的漏洞是公司最大的潜在风险。接下来今年会根据以上结果，将潜在隐患风险最大的一些系统作为今年治理的目标，明年可能这个要求可能会变得更高，当资源更多了，那就可以做二期的治理。这是从自身去分析公司的主要矛盾是什么。

另外一个维度是横向对比，横向对比的逻辑是在同类行业里，我公的安全建设做的好一点，可能就不来攻击我，从而去攻击别的友商了。比如同行业大家做的怎么样？举个蚂蚁的例子，蚂蚁本身有金融属性和互联网的属性，所以蚂蚁对于持续保证安全能力的领先性和深度，是有很强的能力的。

另外一个方面是把全局风险说清楚。在说清楚前提下，leader认可并确定要把这些重要的风险进行治理，那就会投入资源。如果leader不认可风险需要治理，至少是把负责的方向说清楚，我觉得这是做安全的一个很重要的逻辑。要给leader讲清楚公司现在有多少潜在的风险，需要投多少资源，能够治理到什么程度。至于需要治理到什么程度，交给公司来做决策。但是如果说不清楚，作为员工责任就比较大了。

| 某互联网企业大佬：你的前提是先建设资产的视野。资产是肯定要做建设的，但后续的漏洞管控可能未必算成一个风险，从case来看，实际利用漏洞的case是比较少的，包括实际有用 log4j 来产生攻击的。目前偶尔有漏洞扫描的诉求，平心而论风险没有那么高。

| 某软件厂商大佬：需要看每个公司具体的情况，美团其实在这块投入还是非常多的，基础安全做得相对来说很不错。所以我觉得这个地方需要评估有无存量的全局风险。如果没有，那重点可能是在新出 0 day或者新出漏洞的时候，保证治理好就可以了。

| 某互联网企业大佬：分享一个视野，我发现内部找不到漏洞之后，其实有很多自己研发的组件是有升级诉求的。

| 某软件厂商大佬：这个我了解到有一家互联网公司目前正在做。他们的案例是做源安全网关。在私有源卡所有的内部二方组件，内部开发的通用组件要传到私有源的仓库里面去，必须保证所有二方组件上传的时候是没有安全问题的。

| 某互联网企业大佬：我这个视野不是从安全角度出发的。我发现的痛点是对二方组件，研发有低版本的困扰，低版本可能不稳定，有一些功能不兼容，所以需要升级的，但是自己推起来又非常困难。其实我们可以帮公司的组件做统一版本管控，这可能是安全之外收益。

Q6：AI 如何帮助企业预测和防止那个供应链中的安全威胁？

| 某软件厂商大佬：分享一下我们最近和 AI 结合做的一些探索。小范围分享一下我们的一些想法。结合 AI ,我们不是做预测，主要是解决软件供应链安全的问题。

第一是在做开源组件选型相关的事情。我们发现软件供应链安全的问题，不能简单的把它理解成一个安全的问题。比如在选用某一个组件，或者升级某一个组件的时候，不仅要考虑解决安全问题，还要考虑这个组件的可扩展性；社区维护的健康度、成熟度；场景的适配（比如说在金融行业的场景是不是能够适配？交易支付这种场景能不能适配？）。所以在组件选型方面，我们用 AI 来做做开源组件选型的智能分析。对内容提炼和总结，做场景的分析（在什么场景下适合用什么样的开源组件）。

另外一点是生成修复代码，或者说是做软件升级的兼容性评估。我们发现升级一个软件的时候，大家会考虑升级完之后会不会有兼容性的问题。就要分析大量这个组件的不同版本之间的差异和它的一些 issues 、release notes 的信息。我们在这方面用 AI 大模型的总结提炼的能力来做一些探索。

Q7：分析依赖状态和威胁程度

| 某软件厂商大佬：前面ppt里有提到，我们可以把所有代码仓库中所有软件的依赖成分全部分析一遍，然后去关联出来漏洞的严重程度，做漏洞的影响分析和数据统计。我们在这方面做了一件事情：把 CVE 威胁重新建模，把威胁分了三类（强烈建议修复、建议修复和可选修复）。强烈建议修复是把有POC、EXP 的，风险等级高危严重以上的漏洞单独梳理出来，作为真正有影响的。做威胁程度的分析还可以关联单个漏洞影响多少资产，或者业务的重要程度是什么，以此做分级的处置，产出报表。我觉得这个是去做价值分析很重要的一点。

Q8：如何加强开发者对于软件供应链安全建设的价值的认同

| 某软件厂商大佬：我觉得企业去做软件供应链安全建设，很重要的一点是深度依赖开发者来参与这项工作，比如开发者修复安全漏洞，所以需要开发者对于安全建设的价值认同。这个过程中我认为有两个点是非常重要的。

第一点是要通过一些事件，甚至是通过企业内部的一些事件，案例，做企业内的真实案例分享，这是比较有效的一种方式。比如说 log4j 、fastjson 出现漏洞导致公司出现安全事件，或者通过蓝军攻防模拟做攻防演练，发现代码是可以被攻击导致公司数据泄露，或者导致服务被入侵的风险。

第二点是在治理完安全风险后，不仅仅需要给安全的老板汇报，还需要做面向企业内部的正向宣传。通过正向的宣传可以让开发人员了解安全的真实影响和风险。比如说定期开展内部案例分享：哪些开发者，哪些部门在开发环节，在做开源组件选型准入的时候，已经把项目的安全性提升得很好。甚至哪些业务部门在每周、每个月解决了哪些安全问题，解决的时效性，解决效果怎么样。还有一个做法是可以每周，每个月可以把建设的成果给所有参与到这项工作里面的开发者做分享培训，像是风险数据的公示、内部访谈标杆案例。这样也可以比较好的建立开发者对于整个软件供应链安全建设价值的认同。

Q9：如何量化和体现供应链安全治理效果？

| 某软件厂商大佬：有一些关键的指标，比如：漏洞处置的时效性，平均每个漏洞修复的数量，资产台账相关的风险下降的数量，突发 0 day 漏洞或者供应链漏洞处置的时效性，单事件的处置效率提升度等。

如果是作为偏关基行业来说，流程制度的完善度，行业的最佳实践，论文专利优秀课题的评选，都是可以从直接、间接的说明价值的。

自由讨论

| 某物流企业安全大佬：我从比较老的传统企业转到比较互联网化的公司，现在的主要问题是 SCA 流程建设起来后，老板的中心思想是降本增效为主，尽量企业内部自己做，节省资源。做 SCA 这个事情的时候，我们这边的研发会比较配合来修复漏洞，但是一定要有比较精确的修复手法。比如说高危漏洞或者是 fastjson 类型的约定好必须做修复。我们也调研了很多产品，Murphysec 产品有一个功能是代码真实调用，这也是可以作为精确修复的一个条件。

第二个问题就是在低资源的情况下该怎么投入。现在流程是跑起来了，高、中危漏洞基本可以被解决掉，研发和安全也形成了一些比较好的互动和规范。但是在老板不愿意投入资源的情况下，作为安全应该怎样去衡量和对应。比如业务增长到了什么体量，供应链安全应该做到什么程度，或者人员上应该投入到什么程度，才达到一个比较好的效果。好像业界没有衡量的比例或者标准。所以说这一起讨论一下大家是怎么做的？

| 某软件厂商大佬：这个问题我感觉和美团的问题有点像，治理到一定程度，驱动力可能已经没有了，那还要不要再投入呢？

我先抛个砖，我以前尝试过一些比较有效的方法：

第一点是同行业、同规模企业的对比。比如说美团和百度、腾讯进行对比，这个方向同行业公司投入了多少人，做到什么了程度。举个例子：蚂蚁的很多漏洞可以做到自动化修复，而且蚂蚁要求全部修复等等。

第二点是回归企业内部实际风险的角度，从攻防的视角去暴露风险。检测出来漏洞之后，通过类似红蓝对抗的做法，找一些真实的漏洞做渗透，或者内部找一个重要业务系统的重要漏洞做内部的攻防，做实际的演示发现漏洞会导致多少数据泄露。

在08年左右，百度在安全方面不是很重视也没有很多资源，当时剑心在百度做的第一件事情是去攻击内部最核心的系统，给老板汇报风险情况，这是很直观地让老板看到风险的重要方式。

| 某物流企业安全大佬：这样确实比较合理，攻防角度我们也在应用，但是基本没有什么供应链安全的漏洞了。同行业的对比下，我们投入确实是不太够的。

| 某运营商安全大佬：简单补充一下，在我们软件供应链刚起步的阶段，促使我们给软件供应链安全的投入最大的原因是和整个阶段有关系的。首先传统的做法是一直在做防护，在做检测。比如前面美团大佬提出来的 log4j，一个企业里面是避免不了会有非标应用存在的，我在这个方面去投入识别，但也做不到 100%。那就要去模拟攻击，然后做这方面的检测等等把缺失的弥补起来，最终达到一个标准。

我们发现这一块的投入很高。当一个漏洞出现的时候，比如说 log4j ，我们去分析成因以及从攻击者视角分析利用链的时候，没有办法很快的确认影响面的时候，特别是当时受 log4j 影响的资产有 2500 多个，没有办法很快的让业务完成修复和分优先级。

所以我们当时的做法是拆解攻击链和利用链，大概拆解了六步，六步的利用链里面涉及到 DNS ，涉及到执行的具体代码。总归是在这六步里一步一步的拆解，在网络层，代码运行时，在其他的环节层层设限设卡，在内网里去投入一些能力，让这些反向连接出不去等等这些操作。再从事件响应的角度上去投入这件事情，成本是非常高的，而且业务影响也会比较大。那几年有很多核弹级的漏洞爆出来，业务本身也经受不住这种折磨，他们也会主动的去提出安全是不是有更好的方法来前置解决，所以我们可以适当性的给业务找一些麻烦。

在这个过程中，我们发现投入一些精力在安全左移上面，包括三同步，从采购对非标类的应用纳入管控，新产品的上线要列入检测等。在这一套逻辑上，如果加入了供应链安全方面的检测能力和手段，或者知识库的储备，那实际上对于事件响应的成本而言是有极大降低的，对效率是有极大提升的。从这个角度来看 ROI 投资回报比肯定是正向的。

| 某银行安全大佬：当供应链建设到一定阶段，包括黑白灰、SCA 都建设起来之后，下一步的建设方向是什么？想请教下大家。除了持续优化建设工具的漏洞发现能力、漏洞修复能力、漏洞准确性。其他的建设方向是什么？

我有几点想法，各位可以看一下可行性。一方面是 AI ，AI 我觉得未来可以体现安全价值。第二方面是应用安全数据的审计，我今年做了一些应用数据安全审计方面的建设。调研了很多头部厂商，都有一个问题是大家都是基于流量层的产品，把流量镜像过去，然后看流量里面有没有关于 API 的敏感数据传输。但是我们这边的数据加密是比较严格的，没有办法解密，这种设备就失效了。在实践中发现 IAST 对解密流量的支持是非常好的，不知道这两方面能不能结合。

第三方面不可达漏洞的验证。我们在漏洞修复的时候，我们的场景基本是拍脑袋。一方面是看业内修了哪些漏洞，第二方面是看漏洞能不能利用，是不是有威胁。所以不可达漏洞分析也是我们未来考虑建设的一个方向，看大家有没有有其他好的想法，可以参考一下。

| 某出海企业安全大佬：我们现在流程都建起来了，最近刚好在定下半年目标。我们的业务场景比较复杂，包含比较多：IoT，云端、APP、嵌入式等，还包括各种智能家居的硬件，可以建设的方向很多。我们接下来的方向是找一些过去覆盖度不够的业务，去重点做威胁建模。比如我们对外的一些业务是要开发者来接入我们的平台，包括 SDK 这类的东西，会站在开发者的角度发现 SDK 里面有没有问题。对接云平台和 APP 嵌入硬件开发的过程中，我们会对外提供一些 IDE 插件，但是这些东西可能过去覆盖度不够深入，这个会是我们后面重点的方向。

| 某互联网公司安全大佬：我们最近也在做 AI 方向的建设，比如我们在做 SDL 的时候，会涉及到流程推动或者工具的 QA 问题。通用的 QA 问题，或者是修复建议，比如安全SDK。我们会把一部分类似于客服的工作，转交给AIGC。

关于我对软件供应链安全、职场的更多思考，点击关注【航行笔记】查看