开源软件以其转换思维、破除壁垒、充分共享等特点，颠覆了传统软件开发模式，越来越多的企业或个人开发者选择拥抱开源代码。然而，开源软件在实现开放协同、互利共生的同时，也向网络犯罪分子敞开了大门，给开源软件使用者带来了诸多风险。近日，安全牛采访了深圳海云安网络安全技术有限公司（简称“海云安”）首席科学家齐大伟博士，就开源软件安全治理相关话题进行了探讨。

开源组件给软件开发带来了红利，但同时也引入了安全风险。您认为目前开源组件应用的典型风险有哪些？

齐大伟：

使用开源软件或组件带来的风险主要体现在两个方面：

首先，组件自身存在安全漏洞，有些漏洞甚至是高危的，可以被攻击者直接利用，这些漏洞是由程序中的Bug导致。组件漏洞会导致使用该组件的系统暴露在安全风险之下；

其次，每个组件开源时都会有许可声明，规定使用者可以用开源代码做什么事情，不能做什么事情，有些会要求不能商用或者在商用时有一定限制等，使用了这类组件的软件制品会受许可声明的限制，如果没有注意，在使用时违反许可合规要求就需要承担法律风险。

我们看到，国家监管机构也越来越关注开源软件使用带来的风险，比如，去年中国人民银行、网信办等五部门联合发布《关于规范金融业开源技术应用与发展的意见》，指出金融机构应当把保障信息系统安全作为使用开源技术的底线，要认真开展事前技术和安全评估，堵塞开源组件中的安全漏洞，切实保证技术可持续和供应链安全，提升信息系统业务连续性水平。

企业在进行开源软件治理时面临的主要挑战有哪些？

齐大伟：

使用开源软件或组件带来的风险主要体现在两个方面：

首先，组件自身存在安全漏洞，有些漏洞甚至是高危的，可以被攻击者直接利用，这些漏洞是由程序中的Bug导致。组件漏洞会导致使用该组件的系统暴露在安全风险之下；

其次，每个组件开源时都会有许可声明，规定使用者可以用开源代码做什么事情，不能做什么事情，有些会要求不能商用或者在商用时有一定限制等，使用了这类组件的软件制品会受许可声明的限制，如果没有注意，在使用时违反许可合规要求就需要承担法律风险。

我们看到，国家监管机构也越来越关注开源软件使用带来的风险，比如，去年中国人民银行、网信办等五部门联合发布《关于规范金融业开源技术应用与发展的意见》，指出金融机构应当把保障信息系统安全作为使用开源技术的底线，要认真开展事前技术和安全评估，堵塞开源组件中的安全漏洞，切实保证技术可持续和供应链安全，提升信息系统业务连续性水平。

企业在进行开源软件治理时面临的主要挑战有哪些？

齐大伟：

目前，企业在开展开源软件治理工作时，面临的挑战主要有三个方面：

第一，企业该如何判断软件制品中是否存在漏洞，以及如何及早、准确、全面地把漏洞检测出来。尽管目前公开的漏洞库有很多，国外有NVD，国内有CNVD、CNNVD等，但仅依赖公开漏洞库也不能发现所有的漏洞，因为很多漏洞在加入到公开漏洞库时可能已经在外边暴露了很长时间；

第二，企业内部会有正常的开发流程，安全团队需要在尽量不影响正常开发流程的情况下进行漏洞检测和许可合规管理，如何与企业内部开发流程高效衔接成为一个不可回避的问题；

第三，企业在大范围使用开源组件时，安全团队进行漏洞检测和许可管理的工作量也是一个不小的挑战。

基于以上开源软件治理的挑战，企业有什么有效应对的方法？这些方法的具体优势体现在哪些方面？

齐大伟：

目前，行业普遍认为SCA是解决开源软件治理问题的有效方案，相对于黑盒、白盒以及交互式检测技术来说，SCA主要是为了检测第三方组件，特别是开源组件的漏洞风险和许可合规问题。SCA即软件成分分析，它是一种对软件的组成部分进行识别、分析和追踪的技术。专门用于分析软件中使用的各种第三方组件，以识别和清点开源组件及其构成和依赖关系，并识别已知的安全漏洞或者潜在的许可证授权问题，把这些风险排查在应用系统投产之前。

对于软件开发来说，安全介入越早，安全成本就会越小，SCA可以在第三方开源组件引入阶段，对开源组件进行漏洞风险和合规检测，使安全尽可能“左移”，我们也推荐在应用程序开发早期阶段使用SCA产品。此外，SCA的工作原理是基于漏洞库进行检测，只要漏洞库够全，SCA产品的检测结果就会非常精准。

目前SCA技术的成熟度怎么样，在国内市场的实际应用情况如何？

齐大伟：

我们对目前主流的SCA工具进行过调研分析，通过研究发现，目前国内SCA技术发展跟国外相比还存在一定差距，产品能力参差不齐，产品功能方面差别也很大。有些厂商的产品功能相对比较完善，检测出的漏洞和许可合规问题比较全，准确率也比较高，同时，对企业开发流程的支持也很到位，支持的开发语言也比较全面。有些厂商的产品功能相对来说就没有那么完整。以对漏洞阻断策略的支持为例，有的产品仅支持根据漏洞的高、中、低危来阻断。但实际上，开发团队还要结合组件的名字及其他各种条件综合判断漏洞的风险分数，再决定是不是去阻断组件的使用。

在开源组件治理中，除了SCA等工具的使用，还有哪些方面是企业需要引起重视的？

齐大伟：

开源组件治理是一个系统性的工程，SCA工具在开源组件治理中可以提供关键的风险与合规检测，并提供修复建议。除了SCA工具之外，企业也应当关注以下几个方面。

首先，企业应当建立开源组件的引入机制，形成企业内部的开源组件库，避免任由程序员随意从互联网引入组件。如果需要引入不在企业内部的开源组件，则需要通过相关负责人的审核；

其次，企业应当依据自身的开发流程，对SCA工具检测的结果设置卡点，制定合理的开源组件使用规范，比如，禁止引入长期无人维护的组件、禁止引入频繁出现的高危漏洞组件等，对于不符合使用规范的组件禁止引入；

最后，在把控好组件准入机制的基础上，企业还应当有完善的应急机制来处理随时可能曝出来的高危漏洞。通常情况下，当一个组件的高危漏洞被曝出来后，企业需要在短时间内排查有哪些应用系统使用了该组件，这些应用系统被部署到了哪里，并在此基础上做应急响应。事先制定应急响应机制是有效处理组件突发高危漏洞的重要前提。

企业如何选择适合的SCA产品或服务供应商？

齐大伟：

评估SCA产品或服务有两个主要指标：一是准确率，也就是判定检测出来的漏洞和合规问题是否准确，主要体现在漏洞库的匹配准确度上；二是召回率（覆盖率），是判定检测出来的漏洞和合规问题是否全面，主要体现在对漏洞和合规问题的覆盖度和及时性上。做得比较好的厂商，不仅可以覆盖NVD、CNVD、CNNVD等常见漏洞库，而且还可以自己额外梳理一部分漏洞。除了这两个主要指标，平台的易用性、对漏洞修复的推荐、以及对DevOps平台对接的支持等也是比较重要的评估因素。

建议用户选择SCA产品时，尽量在试用阶段比较不同厂商产品的实际功能。比如，对比一下厂商的SCA产品是否提供漏洞修复建议，因为在漏洞被纳入漏洞库时，可能已经有对这些漏洞修复的升级版本了。还可以比较不同产品对Docker、标准SBOM(Software Bill of Material)和DevOps的支持程度，以及对漏洞的闭环管理能力和易用性等。

随着开发技术的发展，您认为未来SCA技术会有哪些发展趋势？

齐大伟：

SCA的检测模式主要依据漏洞库进行漏洞和许可合规匹配，产品成熟度更多依赖于产业的力量补全补齐这个漏洞库，检测模式上应该不会有很大的变化。在检测模式不变的情况下，SCA产品会持续优化以帮助用户解决实际问题。

比如，现在大多数SCA产品都是对一个项目引入的组件进行匹配，一旦有漏洞的组件被引入项目，不管漏洞能否触发，都会被SCA工具检测出来。但实际上，很多漏洞有一些复杂的触发条件，只有在特定条件满足的情况下才能触发，如果SCA产品能够帮助用户判断哪些组件中的漏洞可能会被触发，哪些不会被触发，就能让用户优先聚焦处理那些可能触发的高危漏洞。

再比如，对二进制或者代码片段的检测，需要利用从二进制或者代码片段中提取的特征（feature）进行检测，市面上的SCA产品在这方面还有较大的提升空间。

谈一谈您对软件供应链安全发展的看法？

齐大伟：

提到软件供应链安全的发展，我们先回顾一下软件供应链的发展，从最开始汇编基本没有组件可用，到早期C++语言时代的标准库可用，再到现在Java等语言的标准组件仓库。从无到有，从简单到复杂，各种软件在构建时通过第三方组件来实现功能的占比越来越高。对于软件供应链的安全问题，不可能所有安全方面的检测和把控都在最终的制成品上完成，一定是在供应链的每一个环节都有安全把控。

供应链上的每一环都有原材料，也就是使用的组件，还有这一环上开发团队编写的代码，最终完成制成品。这一环的制成品又是下一环的原材料。在这个链条中，对于自身编写的代码，可以使用源代码检测工具，对于出口的制成品可以使用交互式安全检测或者黑盒检测工具。如果企业对于使用的每个开源组件都进行一次源代码扫描，将需要投入非常多的资源，这时候可以借助于一个共建共享的漏洞库来进行检测和分析。当然也会有专业的SCA厂商在公共漏洞库基础之上扩展自己的漏洞库。

目前来看，采用完善的安全技术和工具进行检测的开发项目还是集中在大型公司和重点行业。以后的发展趋势一定是会有更多的公司使用这些技术和工具，在供应链每一环节的入口、出口和内部进行安全管控。而实际上这也是一个相互促进的过程，当工具被越来越多地使用时，也会促进工具的完善。

国内知名媒体评：

努力消除和减少源代码中潜在的漏洞，是软件供应链安全治理的终极目标。SCA作为开源软件安全治理的基础性手段，可以提供较关键的风险与合规检测，并提供修复建议，从而帮助用户前移了漏洞修复时间，同时也有效控制了漏洞泛滥。但是，我们需要认识到，软件供应链安全治理是一个系统性的工程，要将安全工具和规范的管理制度相结合，才能切实保证技术可持续和安全可靠，实现企业数字化业务的稳定开展。

如若转载，请注明原文地址