开源埋雷?一文带你看清安全风险!

导读

当前,国际形势中不稳定、不确定和不安全因素日益突出,各个行业中都存在没有硝烟的战争。在信息技术领域,由于去年俄乌冲突爆发,Oracle、SAP公司宣布暂停俄罗斯所有业务,Github考虑限制俄开发人员访问开源代码存储库的可能性。这也让我们意识到国外开源项目的地缘政治性,因此有关信息技术安全可控与开放创新的问题得到了国家的空前重视。

聚焦图数据库领域,国内大部分厂商均采用基于国外开源代码+自研的方式,由于搭建过程存在开源组件,因此研发的图数据库产品在商用过程中容易违反开源许可协议,产生知识产权侵权风险。 同时,安全管理企业Endor Labs发布报告指出“几乎所有(95%)开源漏洞都存在于可传递或间接依赖关系中”,我们也能了解到开源软件可能存在bug,易产生安全性或功能性漏洞,造成企业大量敏感信息与数据随着代码的共享而泄露。 此外,在软件部署后,一旦开源组件出现问题,则会牵一发而动全身,产生高昂的维护成本。

在此背景下,我们将以开源图数据库Neo4j为对象,分析其对开源软件的依赖关系和可能造成的影响。

依赖关系建模

Neo4j是一款流行的开源图数据库产品,包括沃尔玛、思科、eBay等国际知名企业都使用Neo4j创造业务价值,其在Github上也拥有庞大的开发者社群。在本文中,将以Github上Neo4j:5.9.0项目为例,分析其对开源项目的依赖关系。

首先解析该项目,可以发现其高度依赖于两百多个开源软件,而这些开源软件也存在嵌套依赖关系。我们将项目和开源软件抽象成点,并将开源许可协议设置成属性,它们之间的依赖关系抽象成边,具体图模型如下图所示。

图模型
▲ 图模型
项目一度依赖
▲ 项目一度依赖

Neo4j:5.9.0项目开源软件依赖关系中,包含ASF(Apache Software Foundation)、MPL(Mozilla Public License)、EPL(Eclipse Public License)、GNU(General Public License)等非Neo4j开源软件协议,其中遵循GPL(General Public License)类开源协议的组件,在软件商用过程中可能会引发企业知识产权风险,例如著作权侵权风险、专利侵权风险、商业秘密泄露风险等,从而产生法律纠纷。下面我们来看开源软件具体依赖链条可能会造成的风险情况。

依赖分析 - 关键节点

在一个网络中,最重要的节点不一定是权重最大、优先级最高的点,而是那些在群体间扮演着中介作用的节点。比如我们生活中的经纪人、中间商等,他们能够控制网络中的关键资源或信息流动。近似中介中心性(RABrandes Betweenness Centrality)算法常用于衡量顶点在网络中的重要性,即找到此类关键节点。在开源软件依赖网络中,可调用该算法寻找图中具备中介属性的开源软件,查看其开源许可协议,并分析这些节点对下游软件的影响,具体查询情况如下图所示。

近似中介中心性算法
▲ 近似中介中心性算法

Galaxybase Studio内置图算法引擎,通过CALL语句进行算法调用,并将查询结果按算法得分降序排序,剔除项目点neo4j:5.9.0,我们选取得分前三的节点,分别为org.junit.jupiter:junit-jupiter:5.9.3、com.vladsch.flexmark:flexmark-util:0.62.2和jakarta.ws.rs:jakarta.ws.rs-api:2.1.6三个开源项目。第一步,将这三个项目在图中找到,并将其双击展开。第二步,通过最短路径算法找到其与项目neo4j:5.9.0的依赖关系,以其中一条路径为例在画布上展示。

查询结果展示
▲ 查询结果展示

从画布上可以看到,依赖节点的分布密度符合算法执行结果。项目neo4j:5.9.0通过其它开源项目与上述三个项目产生依赖,而这三个项目在图上属于关键节点,其下游存在大量依附的开源组件。我们选取其中一项:org.junit.jupiter:junit-jupiter:5.9.3进行分析。查询可知该项目属于Junit,是一个Java语言的单元测试框架,遵循EPL(Eclipse Public License 1.0)许可协议。该协议规定将EPL下的源码混合进项目发布时,需做私人协议声明,声明的代码需继续遵守协议。而一旦由于开源许可协议或其它不可抗因素产生项目禁用,neo4j:5.9.0项目将无法进行内部单元测试,这对项目的稳定运行会造成重大影响。

依赖分析 - 近似中转节点

在开源软件的依赖网络中,不同软件包之间的功能存在差异,但当功能及接口兼容时,部分软件包可以实现平替。例如,针对日志文件会有不同的软件包提供支持,它们之间可以实现替换。此外,如果一个软件包开源协议由于变更导致不可用,那么该软件包的旧版依旧可以实现替换。紧密中心性(Closeness Centrality)算法是一种用于衡量顶点在图中的重要性的算法,它可以反映顶点的有效传播能力,具有最高紧密中心性得分的顶点到各个顶点的传播代价最小。在开源软件依赖网络中,可调用该算法寻找图中具备中转性质的开源软件,查看其开源许可协议,并分析节点周围依赖情况,具体查询结果如下图所示。

紧密中心性算法
▲ 紧密中心性算法

通过CALL语句调用gapl.ClosenessCentrality,并将查询结果按算法得分降序排序,剔除项目点neo4j:5.9.0。我们选择其中一项:org.apache.logging.log4j:log4j-core:2.20.0进行结果说明。

第一步,随机选取开源项目,比如javax.activation:activation:1.1,找到其通过中转节点与项目neo4j:5.9.0产生的依赖路径。

过中转节点最短路径
▲ 过中转节点最短路径

第二步,将中转节点移除,找到开源项目javax.activation:activation:1.1与项目neo4j:5.9.0产生依赖的最短路径。

移除后最短路径
▲ 移除后最短路径

从画布上可以看到,移除中转节点后,原始三跳就能产生的依赖路径需要增至四跳才能完成。而在实际开源项目中,是不存在真实中转节点的,每个需要依赖的开源软件均在项目中发挥重要作用。一旦由于不可靠因素产生软件禁用,往往导致项目不可运行。而通过开源组件的嵌套关系绕过禁用协议,也会增加项目开发的成本和不稳定性。

结语

通过上文两个图算法,我们能够直观地发现Neo4j的开源项目neo4j:5.9.0对开源软件高度依赖,导致该项目存在巨大的安全风险、知识产权风险、供应链安全风险。

因此,选择闭源项目以保证软件的安全性和可信性至关重要。 当前国内的图数据库厂商中,创邻科技7年磨一剑,成功自研出国内唯一成熟、商用、全自主知识产权的闭源Galaxybase图平台,已通过工信部中国软件评测中心《软件产品源代码溯源》评估,核心代码100%自研,能够完全满足各行业对国产数据库“自主可控”的诉求,完全避免因某个开源软件停止维护或出现严重的安全漏洞,而导致的业务中断可能与研发成本的浪费。

未来,我们也希望更多的用户能够最大程度地摆脱对开源软件的依赖,构建自主可控的防火墙。

猜你喜欢

转载自blog.csdn.net/qq_41604676/article/details/132598641