在软件开辟的过程中，为了提升开辟服从、软件质量和稳固性，并低沉开辟成本，使用开源组件是开辟职员的不二选择（现实上，所有软件开辟技术的演进都是为了可以大概更短时间、更低成本地构建软件）。这里的开源组件指的是以开源许可证发布的软件组件、库、框架和工具等，组件的源代码是公开的，而根据差别的许可协议，版权所有者可以授予用户使用、研究、更改和分发软件及其源代码的权利。软件开辟职员可以根据所开辟程序的差别，选择提供各种功能的开源组件，如Java的SpringBoot框架、Fastjson库、Log4j库，Python中的NumPy库、TensorFlow库，Javascript中的jQuery库等。
对比闭源组件，由于开源组件的源代码公开，使用者能更加轻易发现其中存在的漏洞，部门时候漏洞发现者还会提供修复的手段以加快修复进程。然而，并非所有人发现漏洞都会举行通报，对于攻击者而言，公开的源代码使得发现可利用的漏洞更为简朴，他们大概并不会将其上报给开源组件的维护者，而是对使用该开源组件的应用举行攻击。别的，由于使用开源组件的程序开辟职员大多数对开源组件的源代码并不熟悉，对其的认知仅停顿在函数和功能的使用上，对安全性、正当性并无了解，所以这也造成引入开源组件的同时引入了开源组件自身的漏洞，扩大了软件的攻击面。
Black Duck Audit Services团队2023年分析了1703个代码库，并在其年度审计陈诉中指出，其中96%包含开源组件，其总代码中有76%是开源代码，84%的代码库包含至少一个已知的开源漏洞，48%的代码库包含高危风险漏洞。
根据新思科技（synopsys）2023年的陈诉《开源安全与风险分析陈诉》表现：
1703个代码库中，54%的代码库有开源协议辩论，31%的代码库包含没有协议或自界说协议的开源代码，89%的代码库包含超过4年以上未更新的开源代码，91%的代码库包含已往2年未更新的组件，84%的代码库包含至少一个开源漏洞，5%的代码库包含有漏洞的Log4J版本，11%的Java代码库包含有漏洞的Log4J版本。
Gartner预测：
到2025年，环球将有45%的组织的软件供应链遭受攻击，比2021年增长三倍。
根据Veracode 2022年的陈诉《软件安全状态》表现：
97%的Java应用是由开源组件库构成，77%的第三方组件库漏洞在三个月后依然未被修复。
从上述的陈诉和预测中可以预见，未来软件安全中开源组件的安全题目会成为软件安全的聚焦点。引入第三方组件导致的安全题目大概造成严肃的后果可以参考下面的三个案例：
1992年，Borland InterBase 数据库软件出现隐蔽后门事件，该后门在软件中潜藏了8年之久，是由该软件的开辟职员写入的，答应未经授权的用户通过特定的用户名和密码访问数据库，并实行一些特权操作，如修改、删除数据。开辟职员的用意大概并非主观恶意，但是该后门如若被攻击者提前知晓，便会造成环球范围内的严肃后果。
2014年，Heartbleed（心脏出血）漏洞爆出，造成了加拿大税务局泄露了近900人的社会安全号码（Social Security Number，它被用作个人信用记录、就业配景检查以及金融交易中的身份验证等）以及各大网站的用户敏感信息泄露。
2021年，核弹级Log4j漏洞爆出，该漏洞会让攻击者在受害者主机上实行代码，可造成服务器权限被获取，信息泄露等危害。
这些组件正是由于被广泛使用来提升开辟服从，导致一旦爆出漏洞，其对于应用程序的危害终极会波及到天下各地的企业集行业，并终极损害到用户长处。
开源组件产生漏洞的原因有很多，根据我们对于最常出现漏洞的Top 20开源组件中最多遇到的漏洞分析，根本的原因如下：
- 开辟职员编写的代码存在漏洞；
- 组件引入了其他存在漏洞的组件；
- 攻击者/受信托的开辟职员向该组件源码提交了恶意代码；
- 开源组件所使用的配置文件存在默认安全题目，且用户使用时没有修改。
在开辟软件过程中引入的开源组件漏洞不但会影响到软件的安全性，也会影响到软件的简便、结实和稳固，这些技术债务会进一步影响软件的迭代、交付和运营。
别的，开源组件还存在许可协议的题目，许可协议意味着并非所有的开源组件都可以按照使用者的意愿随意使用，部门接纳严酷的许可协议的开源组件会要求使用该组件的应用程序也必须公开其源码，并限定其商业模式，或是受到开源社区的束缚。如使用以GPL3.0协议开源的组件，自身也必须依照该协议，需要将源代码保持开源和免费。
假如违背使用组件的开源协议大概会造成法律风险和后果：
2017年10月，深圳市中级人民法院某判决表现，使用GPL3.0协议开源组件而未依照其约定公开源代码的某公司罚款50万元。
2021年10月，软件自由保护协会（Software Freedom Conservancy，SFC）对智能电视制造商Vizio提起了诉讼，控告其未服从GNU通用公共许可证（GNU General Public License，GPL）和GNU Lesser General Public License Version 2.1（LGPL v2.1）的规定。SFC声称Vizio在其智能电视中使用了包含Linux内核和其他代码修改的SmartCast代码，并未按照GPL许可证的要求发布修改后的源代码或提供书面要求提供源代码的声明。诉讼要求Vizio提供完整的源代码，并要求法院裁定GPLv2和LGPLv2.1要求Vizio提供源代码或书面声明的条款。
2009年12月，软件自由保护协会（Software Freedom Conservancy，SFC）对西数（Western Digital）提告状讼，控告将 BusyBox集成到他们自己的产品中违背了 GPL 许可。2018年7月27日，颠末裁决，法院克制西数贩卖配备BusyBox的产品，同时，要求西数支付90,000美元的损害赔偿金和法律费用（约合47,000美元）。
Black Duck Audit Services团队的数据表明，在2022年审计的代码库中，54%的代码库包含了许可协议辩论，影响最大的行业是物联网，协议辩论比例高达78%。对比2021年，总体的辩论数目在减少，原因大概与经济下行和对供应链安全的焦急相干。
自20世纪90年代以来，随着开源软件（Open Source Software, OSS）的普及，与OSS相干的风险也被发现和重视，包括：
- OSS版本变更引入的风险；
- 组件漏洞的风险；
- 许可协议带来的法律风险；
- 现有代码以及OSS的兼容性风险；
- OSS文档质量差和逾期的风险。
在1998年发现该题目后，人们最初是使用电子表格和文档来跟踪开辟职员使用的所有开源组件，这是一种SCA（Software Composition Analysis）技术，用于管理开源组件的使用。但是人工的统计服从低下，且没有一个较好的管理尺度，于是2002年，第一个手动开源扫描工具诞生，但是这种技术早期仍旧误报率高，需要人工干预，不符合灵敏开辟情况的需求。到2011年，SCA技术得到进展，可以大概及时主动检测漏洞和许可题目，这使得软件开辟职员能在开辟周期的早期就举行开源组件管理。同时，SCA工具也在发展，如今已经能与存储库、构建工具、包管理、CI/CD等软件开辟工具集成。
除此以外，美国NIST（National Telecommunications and Information Administration，国家电信和信息管理局）提出了SBOM（Software Bill of Materials）概念，并在2021年7月发布了SBOM所包含的最小必需元素。
- 数据字段：存储供应商、组件名、组件版本、组件依赖关系、时间戳、其他唯一标识符、SBOM数据作者。
- 主动化支持：支持主动化，SBOM可通过工具主动生成，并具备机器可读性，以答应在整个软件生态体系中扩展。用于生成和使用SBOM的数据格式包括SPDX，CycloneDX和SWID标签。
- 实践和流程：界说SBOM的哀求、生成、使用操作，包括：频率、深度、已知未知、分发和交付、访问控制、错误调整。
SCA工具的首要功能是举行组件检测，它会分析项目的源代码、配置文件和构建文件，确定项目中使用的外部依赖库版本和组件。这些依赖可以通过各类语言的管理组件以及其版本的包管理文件来举行依赖组件的主动化识别，如package.json，pom.xml，go.mod，.gradle等。这些文件记录了软件开辟过程中使用到的第三方组件，以及第三方组件使用到的一些开源组件。
别的还可通过代码片断、组件哈希值来识别组件，代码匹配重要通过文本比力、代码指纹、代码克隆检测、语义分析、语义分析等方式举行匹配。这几种技术各有优劣：
- 文本比力算法大概无法捕获到代码结构和语义上的相似性；
- 语法分析大概会导致相似代码匹配上同一个组件导致判定禁绝确；
- 语义分析创建准确的模子较难，并且在大型代码库中举行全面的语义分析大概耗时较久；
- 代码指纹的生成算法同样会影响匹配的准确性和全面性，并需要规模庞大的指纹库。
随后，SCA工具会解析项目的依赖关系，包括依赖库之间的版本关系和通报依赖关系，通报依赖关系指的是所引入的开源组件自身也引入了其他组件。
末了，SCA工具将所得的组件依赖关系与已知的组件漏洞库举行比对，检查项目所使用的开源组件是否存在已知漏洞，如若存在则举行漏洞陈诉。别的，SCA工具还会对组件的许可协议信息举行分析和解释，它会确定哪些许可协议是兼容的，哪些是不兼容或有商业使用的潜在风险的，并给出相应的建议和措施。当前的SCA工具往往也可以大概生成SBOM，帮助开辟团队更好地了解和管理软件项目中的组件及其相干许可风险，从而确保合规性和安全性。
SCA工具属于一种静态分析工具，可以帮助开辟团队识别和追踪应用程序中的开源组件信息和漏洞信息，以便及时发现和办理与这些组件相干的潜在安全漏洞和许可证合规性题目。但是其使用中也会存在一些题目：
- 检测的组件大概会出现误报，或者版本不对的情况，这源于包管理文件的识别错误或是代码匹配的匹配错误。
- 漏洞库更新的滞后性以及其办理方案并不符合现实场景，大多数企业并没有精力维护开源组件漏洞库，而SCA漏洞数据通常源于一些公开漏洞库，如CISA (US-CERT)、NIST (NVD)、MITRE (CVE）。不对外联网的情况下，会造成对于新漏洞更新不及时以及办理方法不存在的情况。
- 对于冷门语言的支持性不足，部门语言SCA工具不支持开源组件的识别。
- 扫描的安全漏洞现实大概并不存在，如所引入的组件被包括在了包管理相干文件中，但现实上项目并没有使用组件的漏洞函数，这时的漏洞现实是误报。
- 工具固然提供漏洞的检测和陈诉，但终极的漏洞修复依然需要人工实行。修复过程大概涉及代码修改、组件配置、升级（依赖）组件版本等操作，其中差别的修复方式对开辟项目会带来差别的修复成本（如架构重构），因此会让开辟团队对于漏洞修复望而却步。
为了办理以上的题目，提前规避和低沉软件开辟过程中的风险，需要联合其他的方法。如在开辟过程中引入第三方组件时，提前过滤和筛选较为活跃的开源组件项目，具体可以从项目上一次合并的提交时间、提交频率、维护团队人数、社区活跃度多维度评估该组件的活跃性，活跃的项目被攻击者关注的同时，也会被安全职员关注，因此其修复漏洞的服从也会因此变快。
比方下图中的Gitee指数：
并且经常对漏洞库举行更新，对自身所使用组件的漏洞举行订阅，对出现组件误报的情况举行人工验证，同时搭配诸如WAF、RASP等安全防护工具，配置其防御规则，对尚未提供更新版本的组件漏洞利用举行拦截。对于一些行业，如航空航天，汽车，交通和物流等行业，由于其特殊的运行情况和体系结构，可以通过其他措施来低沉漏洞的风险，而不是仅仅依赖更新组件到未出现漏洞的办法。这些措施大概是网络隔离，访问控制和监测等操作。当然这并非是说在封闭的体系中，漏洞修复不紧张，由于假如封闭情况中漏洞普遍存在，一旦攻击者进入内网，内网大概很快瘫痪。
别的，SCA工具也应当集成到开辟职员工具中，如将其作为Atlassian Bamboo，AWS CodeBuild 等CI/CD工具管道中的主动化任务，以便将识别和修复漏洞成为软件开辟和构建过程中的第一部门活动。这样不但可以让开辟职员适应代码安全，还可以防止后续检测出安全漏洞时做代码重写。
综上，固然SCA工具能帮助企业管理所开辟应用的依赖关系，检测所使用组件的安全题目以及合规性题目，但真正的安全防护以及漏洞治理照旧需要多方面的联合来实现。
作者： hu1y40
2024年3月5日
洞源实验室
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。 |
