企业安全建设中的第三方组件问题

简述：

我们知道常见第三方组件分为开源组件和闭源组件。开源组件Open-Source Software实际上就是各个公司、软件开发者基于各种协议公布的源代码开源让所有人使用的软件依赖，只要遵守对应的协议就可以使用。闭源组件一般都是三方的商业公司开发提供，方便研发人员实现业务功能而进行统一定制化的，包括依赖库、SDK等等，大多数是需要付费购买并且没有源代码。

三方组件在项目开发中扮演着很重要的角色，也是软件供应链的重要组成部分，研发在项目开发过程中引入使用三方组件，可以提高研发效率、缩短项目上线的时间并且有效的降低了开发的成本。如果使用的三方组件依赖库、SDK本身存在安全风险漏洞，就会严重威胁到业务安全。也是OWASP TOP 10列表中反复强调的“使用含有已知漏洞的组件”逐步成为供应链安全的显著问题。想一想养活了安全人员的Apache Struts、Fastjson和Weblogic。

所以为全面把控第三方组件依赖库安全威胁情况，降低外部依赖库带来的安全风险，提高业务系统整体安全防护能力，在企业安全建设中应建立相应的第三方组件全生命周期管理体系，对第三方组件进行漏洞检测、修复、报告、跟踪，及时根据官方漏洞修复方案进行漏洞修复。

由各个业务组和安全运营人员对漏洞检测结果、修复方案、修复结果、未修复原因等信息进行汇总整理，方便后续对第三方组件进行全生命周期管理。对第三方组件在引入前、上线前进行安全评估，在系统发版后对第三方组件进行追踪，定期进行安全评估工作。这是一个持续迭代并且优化的过程。

准备：

1、安全团队要有项目中引用的三方组件清单列表，记录哪些项目使用了哪些开源组件。一旦某个开源组件出现漏洞，可以通过清单列表迅速排查。该清单列表也正是Gartner提到的材料清单，将在开源组件管控过程中发挥重要的作用。

2、安全团队要有维护一个清单列表记录禁用的开源组件，即，开源组件黑名单。对于那些安全问题比较多、风险较大的第三软件，应加入到这个禁用清单列表中禁止使用。

3、安全团队对于使用较多的开源组件，建议执行静态代码扫描或其他必要的安全测试，提早识别安全漏洞。对于发现的漏洞，提交开源社区，并促使开源社区修复。

4、对于开源组件的使用要有安全性指导（主要是规避一些因配置不当引入的安全问题）。

5、慎用对安全问题处理态度消极的厂商所开发的开源组件。

要点：

组件的安全风险

近年来，针对软件供应链的安全攻击事件一直呈快速增长态势，造成的危害越来越严重，防范软件供应链安全风险，已经迫在眉睫；
开源软件漏洞频现：截至2020年底，CVE/NVD、CNNVD、CNVD等公开漏洞库中共收录开源软件相关漏洞41342个，其中高达13%（5366个）为2020年度新增漏洞；
研究发现：近9成软件项目存在已知开源软件漏洞；平均每个软件项目存在66个已知开源软件漏洞；影响最广的开源软件漏洞存在于44.3%的软件项目中；15年前开源软件漏洞仍存在于多个软件项目中。
2020年 “奇安信开源项目检测计划”对1364个开源软件项目的源代码安全检测显示：开源软件项目整体缺陷密度为14.96个/千行，高危缺陷密度为0.95个/千行；

组件的合规风险

合规风险主要来源于两方面，一方面是开源协议滥用导致的安全风险，另一方面是来至监管合规的风险。

• 《中华人民共和国网络安全法》第三十三条规定，建设关键信息基础设施应当确保其具有支持业务稳定、持续运行的性能，并保证安全技术措施同步规划、同步建设、同步使用。该条规定，明确了关键信息基础设施的安全工作应该前移，在信息系统的规划阶段就应该保证安全技术措施的介入。

• 信息安全技术网络安全等级保护基本要求【GBT22239-2019】中要求企业自行软件开发应制定代码编写安全规范，要求开发人员参照规范编写代码，在软件开发过程中对安全性进行测试，在软件安装前对可能存在的恶意代码进行检测；对外包软件开发应在软件交付前检测其中可能存在的恶意代码。

• 2019年，中国银保监会办公厅文件【银保监办发（2019）129号】文《中国银保监会办公厅关于开展银行业和保险业网络安全专项治理工作的通知》中提出建立新技术引入、开源技术应用安全评估与准入机制，加强科技创新、新技术应用的风险监测与处置。

• 2020年，中国人民银行办公厅文件【银办发（2020）45号】文《中国人民银行办公厅关于开展金融科技应用风险专项摸排工作的通知》中提出应不定期组织针对开源系统或组件的安全测评，及时进行漏洞修复和加固处理。

组件的稳定性

开源社区维护者和贡献者为我们所有人构建工具，为我们日常的开发提供了很大的帮助，但开源社区的贡献者自身却面临诸多问题，这些问题一定程度上影响了开源软件的可持续发展，开源项目的可持续性也一直存在矛盾。这一矛盾导致很多开源软件在最初更新迭代比较快速，文档书写也比较及时，后面却可能出现一些人员离职等问题，导致该开源产品后续的更新不及时，甚至直接中断，这时使用该开源产品的的同学在反馈问题时往往需要很长时间才会得到答复，甚至得不到答复。

• 除非是非常成熟的开源项目，否则其稳定性是未经考验的，这也是使用开源项目在真正进入持续商业化时所遇到的最大挑战！关于一个项目是否“成熟”，这是个非常主观的问题，如果用Github的star数量来衡量，要充分考虑中国式开源通过运营人头来点赞的模式，即便有1-2万颗星，也并不意味着项目已经成熟了。另外，要看Top-100的贡献者，很多所谓的开源项目几乎所有的贡献者都是项目所在公司的内部员工，这种开源项目的成熟度能有多少呢？

• 像MySQL，Redis之类这么稳定的项目并不常见，即便是像MongoDB这么宏大的开源项目，一旦进入大规模部署后对于任何中小公司而言都是巨大的挑战，一旦无法克服，会深陷泥潭难以自拔。

• 国内市场上一度火爆的TFS(Taobao File System=淘宝文件系统)，曾经受到很多程序员的追捧，但是很少有人仔细的分析过淘宝的应用场景和对该项目的支持力度，现在该项目已经寿终正寝（淘宝团队不再维护该项目），而且淘宝当时设计的目的是支持海量小文件，而有多少创业项目是一样的业务需求呢？很多人盲目的上马了TFS，到头来发现系统稳定性很差而且有无数的问题，这些是小团队、二次开发能力并不强悍的团队可以承受得了的吗？
  https://zhuanlan.zhihu.com/p/361101335

解决：

接入

梳理目前业务中开发的项目，项目里面使用了哪些组件，要对目前使用的三方组件有一个全面、准确和可实现自动更新维护的资产清单列表。关注引入情况和组件的版本及安全漏洞

发现

漏洞

开源组件的漏洞和风险主要是通过邮件列表，github issues，nvd漏洞库进行的标注，我们可以根据组件资产清单，发现项目中的依赖->找到对应的cve漏洞，将漏洞信息填充到我们组件依赖检测的平台。

软件许可协议

除了安全问题外，license问题也需要关注。未按照开源许可证约定使用开源组件会引发潜在的法律纠纷，其中最常见的是 GPL（GNU 通用公共许可证）许可证违规。懵懵懂懂的用户使用了不合规的license，会导致产品下降或被传染被迫开放自有商业产品的源代码。

防护

商业工具：

jfrog的产品是xray，snyk势头不错，和github集成推广力度大

开源工具：

dependency check && dependency track。

自主研发 ：

自己动手，丰衣足食。更贴合实际业务。

管理

1. 自上而下，与管理层沟通达成一致。建立更好的安全流程，给出专业的修复建议。
2. 成立开源治理团队，包括管理者、法务、安全专家、研发负责人，梳理重点组件，推动大面积的升级版本
3. 建立第三方软件引入制度，审核组件的历史漏洞、预估业务解耦风险，选型备用组件
4. 面向研发工程师进行政策、法规、案例的培训宣传。
5. 聘请知识产权律师处理软件法律冲突，审核并购公司的合规性。

参考：

企业安全建设 - 软件供应链 | 岚光

第三方组件安全评估指南_黑客技术