目录
随着软件系统研发速度的日益敏捷，世界上出现了大量可复用的开源软件。对于个人来说，使用开源软件构建一个非商业的软件系统是没有太多限制的，但对于一个企业或公司来说，软件系统是对外售卖或者对外提供服务的，是具有商业行为的，在这种情况下，不了解开源软件的使用要求，就贸然使用会给企业带来巨大的风险。
笔者从事开源软件使用合规工作已经第3个年头了，今天就来总结下企业在使用开源软件时存在的风险和问题，以及如何解决或规避这些问题。（注：后续文章中提到的“软件”、“软件系统”和“产品”都是指可对外售卖的软件产品，后文不再对这三个名词作详细区分。后文中的“服务”是指有web页面的网站服务，或者是有对外公共接口的后台软件服务。）
一、开源软件的漏洞
众所周知，如果软件系统中的漏洞被黑客利用，轻则会导致系统不可用，不能再继续向用户提供服务，用户进而对企业更失去信心和安全感。重则导致用户的隐私数据泄露，造成直接的经济损失。比如耳熟能详的2014年的心脏出血漏洞，再比如2017年的大规模隐私数据泄露。而开源软件的漏洞则是开源软件永远的痛，因为开源软件本身的源代码是公开的，任何人都可以看得见，这样就给懂行的黑客们发现更多漏洞的机会。可以肯定的说，开源软件的漏洞是无法避免的，我们能够做的事情是尽量避免使用质量较差的开源软件，并及时的发现并修复掉严重的漏洞。
1.1 发现漏洞并评估影响范围
世界上每一天都有黑客在发现漏洞，在披露漏洞。我们最需要关心的问题是，这些漏洞有没有影响我们的产品，如果有的话影响了我们哪些客户？
为了搞清楚这个问题，我们首先要有一个客户使用产品或服务的记录，即我们的产品或服务卖给了哪些客户。然后，我们还需要知道，这些产品和服务到底使用了哪些开源软件。最终通过漏洞所影响的开软软件的信息，反向找出产品被售买给哪些客户的信息，这些数据联合在一起之后，能够知道漏洞影响了哪些产品以及哪些客户。请见以下数据关系。
最左侧，客户与产品的对应关系是产品在被售卖、下载、注册时记录的客户与产品的关系。中间产品与软件平台、组件、开源软件的依赖关系则是在软件的构建和集成过程中自然产生的关系。其中某一个产品（如产品1）与其依赖的平台、组件、开源软件之间的包含关系的数据记录在业界被叫做《软件成分清单SBOM》，参考维基百科对SBOM定义（国内需要代理才能打开），而美国白宫在2021年的5月12日也将软件的SBOM上升到了这个国家网络安全的高度参考《Executive Order on Improving the Nation’s Cybersecurity》一文中针对软件供应链安全章节的论述。所以，按照软件安全和可信的基本要求，这个SBOM清单每一款软件产品都有一份，这里的软件系统是指一个完整的产品，或者是指一个独立的服务，这个清单中描述了一个软件系统有哪些软件组件构成，其中包含了第三方软件和开源软件。这里我们主要关注的是SBOM清单中关于开源软件部分的清单。
1.1.1 开源软件清单和SBOM
一个庞大的软件系统是由各个粒度小的软件程序构成的，每一个软件程序又可能由不同语言编写，每种编程语言都有自己独特的管理依赖的方法，所以要生成和管理一款产品完整的软件成分清单并不简单。我们先看看某一个特定语言的组件如何获取所有的软件依赖（含所有的开源软件）。
1.1.1.1 c/c++的依赖清单
参考：https://docs.conan.io/en/latest/getting_started.html#inspecting-dependencies
1.1.1.2 java的依赖清单
参考：https://blog.csdn.net/u014703039/article/details/84680826
1.1.1.3 Python的依赖清单
参考：https://www.cnblogs.com/xingxia/p/python_depends_package_manager.html
1.1.1.4 javascript的依赖清单
参考：https://www.axihe.com/api/npm/cli/npm-ls.html
1.1.1.5 Golang的依赖清单
参考：https://studygolang.com/articles/32518?fr=sidebar
这里仅列出了5种主流语言的包管理器是如何获取当前项目使用的依赖软件信息，当然还有其他语言以及其他管理方法，这里不再展开，具体的依赖管理器都有自身相应的以依赖软件的管理方法。这里的方法仅仅解决了单个语言编写的组件级别的依赖关系（即下图绿色虚框部分的信息），而一个产品则可能是由成百上千个组件或者组件合成的软件平台集成起来的（即还需要拿到下图红色虚框部分的信息）。
只有将绿色框中的信息和红色框中的信息都获取完整才能够得到完整的产品SBOM，通过这个完整的SBOM才能找到某款开源软件被那些产品和客户使用。
1.1.2 如何得到软件产品完整的SBOM
有两种方法可以得到产品的SBOM
1.1.2.1 方式一：人工维护SBOM
最简单也最容易想到的就是人工维护一份产品和组件的对应关系的excel表，而单一组件（单语言）内的依赖则可以通过对应语言的包管理器获得，参见上述1.1.1.1-1.1.1.5。
优点是：不需要额外的软件就能支持，对于初创的小微企业，产品就那么一两款，维护起来开销也不大。
缺点是：一旦产品上了一定规模，或者说大企业是有大产品族的，这种人工维护的工作量和数据的准确度都是无法想象和保证的。
1.1.2.2 方式二：通过构建系统自动生成
所有软件的构建都要经过两个阶段，第一个阶段是将单个组的代码编译成组件二进制包；第二个阶段是将这些组件包集成为平台，并最终集成为产品。
在阶段1中，构建组件的时候，我们可以得到组件和开源软件的依赖列表。在阶段2中，集成各组件二进制包，我们可以得到平台与组件的集成关系，以及产品与平台的集成关系。
将这些关系信息通过自动化工具保存到数据库中，形成完整的SBOM信息。
优点是：构建过程当中通过自动化工具生成SBOM，无需人工维护每次的依赖变更。
缺点是：当前业界并没有这么一套现成的工具，需要自行投入开发以及维护。
1.1.3 通过SBOM识别漏洞影响范围
无论是使用哪种方式得到了产品的SBOM，最终在进行漏洞影响识别时，都可以轻松找到受影响的产品以及受影响的客户，如下图所示：
通过图中SBOM中的完整依赖关系，从最右侧红圈向左侧反向查找，能够识别出影响哪些产品和客户收到了该漏洞的影响。该结果可用于决策如何升级和如何进行现网修复策略的制定。
参考：一个当前业界正在形成的BOM标准Cyclonedx，注意该标准仅仅定义了SBOM的完整格式，但并未提供一个工具生成完整的SBOM。
最低0.47元/天 解锁文章
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
