CN111625466A - 一种软件检测方法、装置及计算机可读存储介质 - Google Patents

Abstract

本申请提供了一种软件检测方法、装置及计算机可读存储介质，该软件检测方法包括：获取目标检测软件中各模块以及基于开源项目源码开发的各组件之间的相关关系；基于相关关系确定目标组件的关联模块；根据对应于目标组件的开源许可协议，以及目标组件与关联模块之间的相关关系，检测目标检测软件的协议感染模块。通过本申请方案的实施，自动根据开源项目的使用要求以及开源项目在软件中的实际使用情况，对软件被开源许可协议感染的具体感染范围进行界定，保证了软件感染范围检测操作的有效性和便捷性，提升了软件感染范围检测结果的准确性。

Description

一种软件检测方法、装置及计算机可读存储介质

技术领域

本申请涉及电子技术领域，尤其涉及一种软件检测方法、装置及计算机可读存储介质。

背景技术

在软件开发领域中，研发人员通常需要基于他人公开发布的开源项目的源码进行衍生软件的开发，而开源项目的源码的使用通常受开源许可协议约束，进而要求研发人员在软件开发过程中合规使用开源项目的源码。

目前，在开源合规领域，大多数扫描工具都专注于软件项目风险识别上，即只是针对源码做特征码识别和匹配，然后识别出源码与软件项目的匹配度，找出软件项目受开源项目的开源许可协议感染的风险点，但在精准界定软件受开源项目协议感染的感染范围上尚缺乏有效措施。

发明内容

本申请实施例提供了一种软件检测方法、装置及计算机可读存储介质，至少能够解决相关技术中无法准确、有效界定软件受开源项目协议感染的感染范围的问题。

本申请实施例第一方面提供了一种软件检测方法，包括：

获取目标检测软件中各模块以及基于开源项目源码开发的各组件之间的相关关系；其中，所述开源项目源码通过预设开源许可协议约束使用；

基于所述相关关系确定目标组件的关联模块；

根据对应于所述目标组件的所述开源许可协议，以及所述目标组件与所述关联模块之间的相关关系，检测所述目标检测软件的协议感染模块。

本申请实施例第二方面提供了一种软件检测装置，包括：

获取模块，用于获取目标检测软件中各模块以及基于开源项目源码开发的各组件之间的相关关系；其中，所述开源项目源码通过预设开源许可协议约束使用；

确定模块，用于基于所述相关关系确定目标组件的关联模块；

检测模块，用于根据对应于所述目标组件的所述开源许可协议，以及所述目标组件与所述关联模块之间的相关关系，检测所述目标检测软件的协议感染模块。

本申请实施例第三方面提供了一种电子装置，包括：存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，处理器执行计算机程序时，实现上述本申请实施例第一方面提供的软件检测方法中的各步骤。

本申请实施例第四方面提供了一种计算机可读存储介质，其上存储有计算机程序，计算机程序被处理器执行时，实现上述本申请实施例第一方面提供的软件检测方法中的各步骤。

由上可见，根据本申请方案所提供的软件检测方法、装置及计算机可读存储介质，获取目标检测软件中各模块以及基于开源项目源码开发的各组件之间的相关关系；基于相关关系确定目标组件的关联模块；根据对应于目标组件的开源许可协议，以及目标组件与关联模块之间的相关关系，检测目标检测软件的协议感染模块。通过本申请方案的实施，自动根据开源项目的使用要求以及开源项目在软件中的实际使用情况，对软件被开源许可协议感染的具体感染范围进行界定，保证了软件感染范围检测操作的有效性和便捷性，提升了软件感染范围检测结果的准确性。

附图说明

图1为本申请第一实施例提供的软件检测方法的基本流程示意图；

图2为本申请第一实施例提供的一种软件架构的有向图；

图3为本申请第一实施例提供的一种感染范围检测方法的流程示意图；

图4为本申请第一实施例提供的一种感染模块标记示意图；

图5为本申请第二实施例提供的软件检测方法的细化流程示意图；

图6为本申请第三实施例提供的一种软件检测装置的程序模块示意图；

图7为本申请第三实施例提供的另一种软件检测装置的程序模块示意图；

图8为本申请第四实施例提供的电子装置的结构示意图。

具体实施方式

为使得本申请的发明目的、特征、优点能够更加的明显和易懂，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而非全部实施例。基于本申请中的实施例，本领域技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

本实施例首先对开源项目源码的传染性进行说明。在实际应用中，软件开发人员通常会将自己开发的软件通过公共渠道进行发布，使得受益者可以自由获取到贡献者所提供的软件的源码，也即开源代码，而为了保证贡献者对所发布的开源项目源码的著作权，开源项目源码通过预设开源许可协议约束使用。常见的开源许可协议包括：BSD、Apache、GPL、LGPL、MIT、MPL等。

以GPL协议为例，GPL协议的主要内容是只要在一个软件中使用(“使用”指类库引用，修改后的代码或者衍生代码)受GPL约束的源码，则该软件项目必须也遵从GPL协议，既必须也是开源和免费，这就是所谓的源码的开源许可协议的“传染性”，使得使用源码的软件产品被“感染”。

而LGPL协议是GPL协议的一个主要为类库使用设计的开源协议。和GPL要求任何使用/修改/衍生自GPL类库的软件必须采用GPL协议不同，LGPL允许软件通过类库应用方式使用LGPL类库而不需要开源软件代码。但是，如果修改LGPL协议的代码或者衍生，则所有修改的代码中，涉及修改部分的额外代码和衍生代码都必须采用LGPL协议。由此可见，不同的开源许可对于受益者有着不同的约束目的，其对于软件项目的感染范围有所不同。

在实际应用中，为了合规使用开源项目源码，研发工程师需要界定出软件受开源项目感染的范围，从而有针对性的进行开源合规治理。

为了解决相关技术中无法准确、有效界定软件开源项目感染范围的缺陷，本申请第一实施例提供了一种软件检测方法，如图1为本实施例提供的软件检测方法的基本流程图，该软件检测方法包括以下的步骤：

步骤101、获取目标检测软件中各模块以及基于开源项目源码开发的各组件之间的相关关系。

具体的，在本实施例中，单个开源项目源码不仅限于受单开源许可协议Sigle-Licensing约束使用，也可以受双开源协议Dual-Licensing约束或多开源协议Multi-Licensing约束使用。本实施例的软件是根据用户需求选择各种技术手段进行设计开发，而得到的由多个分离部分组成的一个完成、可靠、有效的整体，这里的分离部分也即功能模块和组件，软件内的各个分离部分按照彼此之间的相关关系协调工作。

另外，在本实施例中，对软件中各个分离部分之间相关关系的描述可以通过统一建模语言(UML，Unified Modeling Language)类图实现，其中，UML类图中的相关关系包括：泛化、实现、关联、聚合、组合、依赖等具体类型。

在本实施例的一些实施方式中，相关关系优选为依赖关系，相对应的，获取目标检测软件中各模块以及基于开源项目源码开发的各组件之间的相关关系包括：获取目标检测软件中，各模块之间以及模块与基于开源项目源码开发的各组件之间的接口调用关系；基于接口调用关系确定各模块之间以及模块与组件之间的依赖关系。

具体的，在本实施例中，依赖关系被标记为<<use>>，是一种使用的关系，也即一个对象的实现需要另一个对象的协助。A模块依赖于B模块意味着，A模块可以调用B模块暴露的应用程序接口(API，Application Programming Interface)，但B模块绝不允许调用A模块的API。还应当说明的是，对象之间产生依赖的主要方式是数据引用和函数调用。应当说明的是，本实施例的依赖关系的具体类型可以包括：动态库链接、静态库链接、修改源码方式使用、不修改源码方式使用、调用可执行文件。

步骤102、基于相关关系确定目标组件的关联模块。

具体的，在本实施例中，关联模块包括目标组件的直接关联模块和间接关联模块，其中，直接关联模块与目标组件之间直接产生联系，而间接关联模块则需要通过其它关联模块与目标组件产生联系。在实际应用中，软件的感染风险存在于与使用开源项目开发的组件关联的模块，由此本实施例需要对关联模块进行定位，然后再进一步从关联模块中确定感染范围。

在本实施例一些实施方式中，基于相关关系确定目标组件的关联模块包括：将相关关系作为边，将模块以及组件作为顶点，生成有向图；将有向图中与目标组件组成单向链路的所有模块，确定为目标组件的关联模块；其中，单向链路中所有相邻顶点之间的边的方向相同。

具体的，有向图是指一个有序三元组{V(D)，A(D)，ψD}，其中，V(D)，A(D)为三元组的两个元素，体现为有向图中的顶点，ψD为三元组两个元素之间的关联函数，也即本实施例的相关关系，体现为有向图中的边。如图2所示为本实施例提供的一种软件架构的有向图，模块与模块之间、模块与组件之间均连接有一条有向边(如箭头所示)，其中模块3、模块1之间的有向边与模块1、组件1之间的有向边的方向相同，从而三者组成一条单向链路，模块3与模块1均为组件1的关联模块，其中，模块1与组件1直接关联，模块3与组件1间接关联，同理，模块3与模块2均为组件2的关联模块，在此不再赘述。本实施例通过软件中各对象之间的相关关系绘制有向图，然后基于有向图来分析组件的关联模块，可以保证关联模块确定行为的效率和准确性。

在本实施例一些实施方式中，在基于相关关系确定目标组件的关联模块之前，还包括：获取对应于各组件的开源许可协议的协议感染风险等级；将协议感染风险等级高于预设等级阈值的组件确定为目标组件。

具体的，在实际应用中，所开发的软件中可能同时包括多个组件，而各组件分别基于不同开源项目源码开发，那么对应于各组件的开源许可协议也会相应不同，本实施例考虑到不同开源许可协议的约束情况有所不同，从而不同开源许可协议对软件的感染风险也有所不同，本实施例为了降低数据处理量，保证感染范围界定操作的效率，考虑到协议感染风险等级较低的组件造成软件项目感染的概率较低，而仅将协议感染风险等级较高的组件确定为目标组件，并仅针对高感染风险的目标组件的关联模块进行感染检测。

步骤103、根据对应于目标组件的开源许可协议，以及目标组件与关联模块之间的相关关系，检测目标检测软件的协议感染模块。

具体的，本实施例的目标组件与关联模块之间的相关关系用于表征软件中模块对开源项目源码的实际使用情况，而开源许可协议关联于开源项目源码的使用要求，本实施例在对使用开源项目源码的组件相关联的模块进行定位之后，将开源项目源码的实际使用情况与使用要求进行比对，即可确定关联模块是否受开源许可协议感染，以实现对软件感染范围进行界定。

如图3所示为本实施例提供的一种感染范围检测方法的流程示意图，在本实施例的一些实施方式中，根据对应于目标组件的开源许可协议，以及目标组件与关联模块之间的相关关系，检测目标检测软件的协议感染模块具体包括以下步骤：

步骤301、获取对应于目标组件的开源许可协议的合规使用条件列表；

步骤302、将目标组件与关联模块之间的相关关系，与合规使用条件列表进行比对；

步骤303、根据比对结果检测目标检测软件的协议感染模块。

具体的，本实施例针对开源许可协议可以对应配置有一个合规使用条件列表，以LGPL协议为例，其合规使用条件列表包括动态链接依赖、不修改源码方式使用，若关联模块与目标组件之间的相关关系为静态库链接或修改源码方式使用，由于相关关系与合规使用条件列表中的对象不相匹配，则关联模块被目标组件感染。

请继续参阅图2，若组件1为修改LGPL源码所开发的组件，组件2为LGPL库，上述模块1与模块2之间的依赖关系为调用可执行文件，模块3与模块2之间的依赖关系为调用可执行文件，模块2与组件2之间的依赖关系为作为第三方类库引用，模块3与模块1之间的依赖关系为静态库链接，模块1与组件1之间的依赖关系为修改源码方式使用，由于LGPL协议的合规使用条件列表包括动态链接依赖、不修改源码方式使用，那么可以得知模块3与模块1针对开源项目源码的使用不合规，两者为开源项目源码的衍生模块，而确定模块3与模块1受感染；另外，模块2将组件2的LGPL库作为第三方类库进行引用，属于协议许可范围内的合规使用，从而模块2为独立模块。

此外，还应当说明的是，为了规避应用对开源项目源码的使用风险，还可以对协议感染模块进行感染治理，继续承接上述举例，可以将组件1配置为不修改LGPL源码所开发的组件，那么模块1与组件1的依赖关系变为不修改源码方式使用，从而使得其依赖关系满足LGPL协议的合规使用条件，即模块1为安全使用开源项目源码的模块。

在本实施例的一些实施方式中，在检测目标检测软件的协议感染模块之后，还包括：获取各协议感染模块的感染类型；基于感染类型对各协议感染模块进行对应标记。

具体的，在本实施例中，在完成感染范围检测之后，本实施例还可以对感染情况进行直观展示，以助于指导研发人员进行有针对性的感染治理。如图4所示为本实施例提供的一种感染模块标记示意图，其中，若模块3和模块1被组件1感染，两种采用同一种虚框标记方式，而若模块被组件2感染，而可以采用另一种不同的虚框标记方式。

在本实施例的一些实施方式中，根据比对结果检测目标检测软件的协议感染模块之后，还包括：从合规使用条件列表中获取关联于相关关系的目标合规使用条件；根据目标合规使用条件确定对应的感染等级；基于感染等级对协议感染模块输出相应提示。

具体的，在实际应用中，若软件内多个模块受感染，各模块可能会相对不同合规使用条件违规，而不同违规行为所引起的感染严重程度有所不同，本实施例针对协议感染模块与组件之间的相关关系对合规使用条件进行确定，然后各合规使用条件均对应一感染等级，然后基于该感染等级对相应感染模块输出提示，从而可以有效指示研发人员进行感染治理。

基于上述本申请实施例的技术方案，获取目标检测软件中各模块以及基于开源项目源码开发的各组件之间的相关关系；基于相关关系确定目标组件的关联模块；根据对应于目标组件的开源许可协议，以及目标组件与关联模块之间的相关关系，检测目标检测软件的协议感染模块。通过本申请方案的实施，自动根据开源项目的使用要求以及开源项目在软件中的实际使用情况，对软件被开源许可协议感染的具体感染范围进行界定，保证了软件感染范围检测操作的有效性和便捷性，提升了软件感染范围检测结果的准确性。

图5中的方法为本申请第二实施例提供的一种细化的软件检测方法，该软件检测方法包括：

步骤501、获取目标检测软件中各模块以及基于开源项目源码开发的各组件之间的相关关系。

本实施例的开源项目源码通过预设开源许可协议约束使用，另外，本实施例的相关关系优选的可以为依赖关系，依赖关系的具体类型可以包括：动态库链接、静态库链接、修改源码方式使用、不修改源码方式使用、调用可执行文件。

步骤502、获取对应于各组件的开源许可协议的协议感染风险等级。

步骤503、将协议感染风险等级高于预设等级阈值的组件确定为目标组件。

本实施例为了降低数据处理量，保证感染范围界定操作的效率，考虑到协议感染风险等级较低的组件造成软件项目感染的概率较低，而仅将协议感染风险等级较高的组件确定为目标组件，并仅针对高感染风险的目标组件的关联模块进行感染检测。

步骤504、将相关关系作为边，将模块以及组件作为顶点，生成有向图。

步骤505、将有向图中与目标组件组成单向链路的所有模块，确定为目标组件的关联模块。

在本实施例中，单向链路中所有相邻顶点之间的边的方向相同。本实施例通过软件中各对象之间的相关关系绘制有向图，然后基于有向图来分析组件的关联模块，可以保证关联模块确定行为的效率和准确性。

步骤506、将目标组件与关联模块之间的相关关系，与对应于目标组件的开源许可协议的合规使用条件列表进行比对，检测得到目标检测软件的协议感染模块。

本实施例的目标组件与关联模块之间的相关关系用于表征软件中模块对开源项目源码的实际使用情况，而开源许可协议的合规使用条件用于表征开源项目源码的使用要求，然后将两者进行比对，即可确定关联模块是否受开源许可协议感染，以实现对软件感染范围进行界定。

步骤507、基于协议感染模块的感染属性，对协议感染模块进行对应可视化标记。

在本实施例中，在完成感染范围检测之后，本实施例还可以对感染情况进行直观展示，以助于指导研发人员进行有针对性的感染治理。

应当理解的是，本实施例中各步骤的序号的大小并不意味着步骤执行顺序的先后，各步骤的执行顺序应以其功能和内在逻辑确定，而不应对本申请实施例的实施过程构成唯一限定。

本申请实施例公开了一种软件检测方法，获取目标检测软件中各模块以及基于开源项目源码开发的各组件之间的相关关系；基于相关关系确定目标组件的关联模块；根据对应于目标组件的开源许可协议，以及目标组件与关联模块之间的相关关系，检测目标检测软件的协议感染模块。通过本申请方案的实施，自动根据开源项目的使用要求以及开源项目在软件中的实际使用情况，对软件被开源许可协议感染的具体感染范围进行界定，保证了软件感染范围检测操作的有效性和便捷性，提升了软件感染范围检测结果的准确性。

图6为本申请第三实施例提供的一种软件检测装置。该软件检测装置可用于实现前述实施例中的软件检测方法。如图6所示，该软件检测装置主要包括：

获取模块601，用于获取目标检测软件中各模块以及基于开源项目源码开发的各组件之间的相关关系；其中，开源项目源码通过预设开源许可协议约束使用；

确定模块602，用于基于相关关系确定目标组件的关联模块；

检测模块603，用于根据对应于目标组件的开源许可协议，以及目标组件与关联模块之间的相关关系，检测目标检测软件的协议感染模块。

在本实施例一些实施方式中，确定模块602具体用于：将相关关系作为边，将模块以及组件作为顶点，生成有向图；将有向图中与目标组件组成单向链路的所有模块，确定为目标组件的关联模块；其中，单向链路中所有相邻顶点之间的边的方向相同。

在本实施例一些实施方式中，相关关系为依赖关系，相对应的，获取模块601具体用于：获取目标检测软件中，各模块之间以及模块与基于开源项目源码开发的各组件之间的接口调用关系；基于接口调用关系确定各模块之间以及模块与组件之间的依赖关系。

如图7所示为本实施例提供的另一种软件检测装置，在本实施例一些实施方式中，软件检测装置还包括：标记模块604，用于在检测目标检测软件的协议感染模块之后，获取各协议感染模块的感染类型；基于感染类型对各协议感染模块进行对应标记。

在本实施例的一些实施方式中，软件检测装置还包括：确定模块602还用于：在基于相关关系确定目标组件的关联模块之前，获取对应于各组件的开源许可协议的协议感染风险等级；将协议感染风险等级高于预设等级阈值的组件确定为目标组件。

进一步地，在本实施例的一些实施方式中，检测模块603具体用于：获取对应于目标组件的开源许可协议的合规使用条件列表；将目标组件与关联模块之间的相关关系，与合规使用条件列表进行比对；根据比对结果检测目标检测软件的协议感染模块。

请再次参阅图7，更进一步地，在本实施例的一些实施方式中，软件检测装置还包括：输出模块605，用于在根据比对结果检测目标检测软件的协议感染模块之后，从合规使用条件列表中获取关联于相关关系的目标合规使用条件；根据目标合规使用条件确定对应的感染等级；基于感染等级对协议感染模块输出相应提示。

应当说明的是，第一、二实施例中的软件检测方法均可基于本实施例提供的软件检测装置实现，所属领域的普通技术人员可以清楚的了解到，为描述的方便和简洁，本实施例中所描述的软件检测装置的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

根据本实施例所提供的软件检测装置，获取目标检测软件中各模块以及基于开源项目源码开发的各组件之间的相关关系；基于相关关系确定目标组件的关联模块；根据对应于目标组件的开源许可协议，以及目标组件与关联模块之间的相关关系，检测目标检测软件的协议感染模块。通过本申请方案的实施，自动根据开源项目的使用要求以及开源项目在软件中的实际使用情况，对软件被开源许可协议感染的具体感染范围进行界定，保证了软件感染范围检测操作的有效性和便捷性，提升了软件感染范围检测结果的准确性。

请参阅图8，图8为本申请第四实施例提供的一种电子装置。该电子装置可用于实现前述实施例中的软件检测方法。如图8所示，该电子装置主要包括：

存储器801、处理器802、总线803及存储在存储器801上并可在处理器802上运行的计算机程序，存储器801和处理器802通过总线803连接。处理器802执行该计算机程序时，实现前述实施例中的软件检测方法。其中，处理器的数量可以是一个或多个。

存储器801可以是高速随机存取记忆体(RAM，Random Access Memory)存储器，也可为非不稳定的存储器(non-volatile memory)，例如磁盘存储器。存储器801用于存储可执行程序代码，处理器802与存储器801耦合。

进一步的，本申请实施例还提供了一种计算机可读存储介质，该计算机可读存储介质可以是设置于上述各实施例中的电子装置中，该计算机可读存储介质可以是前述图8所示实施例中的存储器。

该计算机可读存储介质上存储有计算机程序，该程序被处理器执行时实现前述实施例中的软件检测方法。进一步的，该计算机可存储介质还可以是U盘、移动硬盘、只读存储器(ROM，Read-Only Memory)、RAM、磁碟或者光盘等各种可以存储程序代码的介质。

在本申请所提供的几个实施例中，应该理解到，所揭露的装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，模块的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个模块或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或模块的间接耦合或通信连接，可以是电性，机械或其它的形式。

作为分离部件说明的模块可以是或者也可以不是物理上分开的，作为模块显示的部件可以是或者也可以不是物理模块，即可以位于一个地方，或者也可以分布到多个网络模块上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。

另外，在本申请各个实施例中的各功能模块可以集成在一个处理模块中，也可以是各个模块单独物理存在，也可以两个或两个以上模块集成在一个模块中。上述集成的模块既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。

集成的模块如果以软件功能模块的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个可读存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例方法的全部或部分步骤。而前述的可读存储介质包括：U盘、移动硬盘、ROM、RAM、磁碟或者光盘等各种可以存储程序代码的介质。

需要说明的是，对于前述的各方法实施例，为了简便描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本申请并不受所描述的动作顺序的限制，因为依据本申请，某些步骤可以采用其它顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作和模块并不一定都是本申请所必须的。

在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其它实施例的相关描述。

以上为对本申请所提供的软件检测方法、装置及计算机可读存储介质的描述，对于本领域的技术人员，依据本申请实施例的思想，在具体实施方式及应用范围上均会有改变之处，综上，本说明书内容不应理解为对本申请的限制。

Claims (10)

1.一种软件检测方法，其特征在于，包括：

获取目标检测软件中各模块以及基于开源项目源码开发的各组件之间的相关关系；其中，所述开源项目源码通过预设开源许可协议约束使用；

基于所述相关关系确定目标组件的关联模块；

根据对应于所述目标组件的所述开源许可协议，以及所述目标组件与所述关联模块之间的相关关系，检测所述目标检测软件的协议感染模块。

2.根据权利要求1所述的软件检测方法，其特征在于，所述基于所述相关关系确定目标组件的关联模块包括：

将所述相关关系作为边，将所述模块以及所述组件作为顶点，生成有向图；

将所述有向图中与目标组件组成单向链路的所有模块，确定为所述目标组件的关联模块；其中，所述单向链路中所有相邻顶点之间的边的方向相同。

3.根据权利要求1所述的软件检测方法，其特征在于，所述相关关系为依赖关系，所述获取目标检测软件中各模块以及基于开源项目源码开发的各组件之间的相关关系包括：

获取目标检测软件中，各模块之间以及所述模块与基于开源项目源码开发的各组件之间的接口调用关系；

基于所述接口调用关系确定所述各模块之间以及所述模块与所述组件之间的依赖关系。

4.根据权利要求1所述的软件检测方法，其特征在于，所述检测所述目标检测软件的协议感染模块之后，还包括：

获取各所述协议感染模块的感染类型；

基于所述感染类型对各所述协议感染模块进行对应标记。

5.根据权利要求1所述的软件检测方法，其特征在于，所述基于所述相关关系确定目标组件的关联模块之前，还包括：

获取对应于所述各组件的开源许可协议的协议感染风险等级；

将所述协议感染风险等级高于预设等级阈值的组件确定为所述目标组件。

6.根据权利要求1至5中任意一项所述的软件检测方法，其特征在于，所述根据对应于所述目标组件的所述开源许可协议，以及所述目标组件与所述关联模块之间的相关关系，检测所述目标检测软件的协议感染模块包括：

获取对应于所述目标组件的所述开源许可协议的合规使用条件列表；

将所述目标组件与所述关联模块之间的相关关系，与所述合规使用条件列表进行比对；

根据比对结果检测所述目标检测软件的协议感染模块。

7.根据权利要求6所述的软件检测方法，其特征在于，所述根据比对结果检测所述目标检测软件的协议感染模块之后，还包括：

从所述合规使用条件列表中获取关联于所述相关关系的目标合规使用条件；

根据所述目标合规使用条件确定对应的感染等级；

基于所述感染等级对所述协议感染模块输出相应提示。

8.一种软件检测装置，其特征在于，包括：

获取模块，用于获取目标检测软件中各模块以及基于开源项目源码开发的各组件之间的相关关系；其中，所述开源项目源码通过预设开源许可协议约束使用；

确定模块，用于基于所述相关关系确定目标组件的关联模块；

检测模块，用于根据对应于所述目标组件的所述开源许可协议，以及所述目标组件与所述关联模块之间的相关关系，检测所述目标检测软件的协议感染模块。

9.一种电子装置，其特征在于，包括：存储器、处理器及总线；

所述总线用于实现所述存储器、处理器之间的连接通信；

所述处理器用于执行存储在所述存储器上的计算机程序；

所述处理器执行所述计算机程序时，实现权利要求1至7中任意一项所述方法中的步骤。

10.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时，实现权利要求1至7中的任意一项所述方法中的步骤。

Images