CN114780391A - 代码安全缺陷分析方法、装置、设备及存储介质 - Google Patents

Abstract

本申请提供一种代码安全缺陷分析方法、装置、设备及存储介质，其中，代码安全缺陷分析方法包括：对被测对象进行静态分析，得到所述被测对象中存在的代码安全缺陷；对所述被测对象进行软件成分分析，识别出所述被测对象中存在的第三方组件的源文件；从各所述代码安全缺陷中，确定出所述源文件对应的代码安全缺陷。这样，就无需开发人员在得到被测对象中存在的所有代码安全缺陷之后，再进行人工筛选，从而降低了人力成本，提高了安全缺陷的修复效率。

Description

代码安全缺陷分析方法、装置、设备及存储介质

技术领域

本申请涉及软件技术领域，具体而言，涉及一种代码安全缺陷分析方法、装置、设备及存储介质。

背景技术

源代码的静态分析技术和软件成分分析技术，是两种最常见的应用安全测试技术，并通常分别以独立的产品形态存在。源代码的静态分析，可以通过程序分析技术发现源代码中存在的缓冲区溢出、SQL(Structured Query Language，结构化查询语言)注入等各种安全缺陷。软件成分分析技术，则可以通过源代码或者二进制中的特征值识别项目中所使用的第三方组件。

目前，当通过直接使用源代码的方式引入第三方组件时，第三方组件的源代码会作为被测对象的一部分，从而也会被静态分析产品所检测，产生相应的源代码安全缺陷。但是，对于这些第三方组件的源代码所产生的安全缺陷，由于第三方组件的源代码并非是开发人员自己所写的代码，通常开发人员无法进行修复。这就导致当静态分析产品检测完毕后，开发人员还需要进一步的通过人工筛选的方式，从所有的安全缺陷中筛选出第三方组件的源代码所产生的安全缺陷，进而对所识别出的所有安全缺陷中，除这些安全缺陷(即第三方组件的源代码所产生的安全缺陷)以外的其他安全缺陷进行修复。这就需要投入大量的人力成本，且筛选效率低下，严重影响安全缺陷的修复效率。

发明内容

本申请实施例的目的在于提供一种代码安全缺陷分析方法、装置、电子设备及计算机可读存储介质，用以解决目前当静态分析产品检测完毕后，开发人员还需要进一步的通过人工筛选的方式，从所有的安全缺陷中筛选出第三方组件的源代码所产生的安全缺陷，需要投入大量的人力成本，且筛选效率低下，严重影响安全缺陷的修复效率的问题。

本申请实施例的目的还在于提供一种第三方组件的源文件识别方法、装置、电子设备及计算机可读存储介质，用以解决目前第三方组件的识别成功率低的问题。

本申请实施例提供了一种代码安全缺陷分析方法，包括：对被测对象进行静态分析，得到所述被测对象中存在的代码安全缺陷；对所述被测对象进行软件成分分析，识别出所述被测对象中存在的第三方组件的源文件；从各所述代码安全缺陷中，确定出所述源文件对应的代码安全缺陷。

在上述实现过程中，在对被测对象进行静态分析，得到被测对象中存在的所有代码安全缺陷之后，通过对被测对象进行软件成分分析，识别出被测对象中存在的第三方组件的源文件，进而即可从各代码安全缺陷中，确定出属于第三方组件的源文件对应的代码安全缺陷。这样，就无需开发人员在得到被测对象中存在的所有代码安全缺陷之后，再进行人工筛选，从而降低了人力成本，提高了代码安全缺陷的筛选效率，从而提高了安全缺陷的修复效率。

进一步地，所述方法还包括：截获所述被测对象在编译过程中所产生的编译指令；收集所述编译过程中涉及的所有源文件；所述对被测对象进行静态分析，得到所述被测对象中存在的代码安全缺陷，包括：对所述编译指令和所述所有源文件进行分析，得到所述被测对象中存在的代码安全缺陷；所述对所述被测对象进行软件成分分析，识别出所述被测对象中存在的第三方组件的源文件，包括：对所述所有源文件进行软件成分分析，识别出所述第三方组件的源文件。

在上述实现过程中，通过获取被测对象在编译过程中所产生的编译指令以及编译过程中涉及的所有源文件，进而可以基于编译指令和源文件进行静态分析，得到更为准确的被测对象中所存在的代码安全缺陷；基于编译过程中涉及的所有源文件进行软件成分分析，可以保证软件成分分析结果的可靠性。

进一步地，收集所述编译过程中涉及的所有源文件，包括：根据所述编译指令，获取在所述编译过程中所述编译指令涉及到的所有源文件。

在上述实现过程中，通过根据编译指令，获取该编译指令在编译过程中涉及到的所有源文件，这就通过编译指令，实现了编译指令相关的源文件的提取(即使编译指令相关的源文件位于不同目录，也会被同时提取并关联)，这就可以降低由于在引入第三方组件源代码时，对目录组织进行改动所造成的在收集源文件时容易出现的文件缺失、缺少组织的不足，保证对于进行软件成分分析所需的源文件的收集可靠性，从而保证软件成分分析结果的可靠性。

进一步地，从各所述代码安全缺陷中，确定出所述源文件对应的代码安全缺陷之后，所述方法还包括：标记所述源文件对应的代码安全缺陷。

在上述实现过程中，通过对被测对象中属于第三方组件的代码安全缺陷进行标记，可以使得后续工程师在查阅或进行代码安全缺陷修复时，可以很容易的区分出哪些属于第三方组件的代码安全缺陷，进而可以针对性的进行代码安全缺陷的修复，提高修复效率。

进一步地，从各所述代码安全缺陷中，确定出所述源文件对应的代码安全缺陷之后，所述方法还包括：从各所述代码安全缺陷中，去除所述第三方组件的源文件对应的代码安全缺陷。

在上述实现过程中，通过从各代码安全缺陷中，去除第三方组件的源文件对应的代码安全缺陷，可以使得后续工程师在查阅或进行代码安全缺陷修复时，仅进行非第三方组件对应的代码安全缺陷的修复，从而提高修复效率。

进一步地，所述方法还包括：从所述被测对象的静态分析结果中，获取所述第三方组件的各源文件的静态分析结果；根据所述第三方组件的各源文件的静态分析结果，确定所述第三方组件的实际使用情况。

在上述实现过程中，通过根据第三方组件的各源文件的静态分析结果，可以确定出第三方组件的实际使用情况，从而利于工程师了解被测对象中第三方组件的实际使用情况。相比于传统的软件成分分析产品所输出的分析结果而言，根据第三方组件的各源文件的静态分析结果，可以更为准确地确定出第三方组件的实际使用情况，例如可以更为准确地确定出被测对象中实际使用到的第三方组件的组件模块、组件功能，从而有效地增强了软件成分分析过程中，针对第三方组件使用情况的分析能力。

本申请实施例还提供了一种第三方组件的源文件识别方法，包括：截获被测对象在编译过程中所产生的编译指令；根据所述编译指令，获取在所述编译过程中所述编译指令涉及到的所有源文件；对所述所有源文件进行软件成分分析，识别出所述被测对象中存在的第三方组件的源文件。

在上述实现过程中，通过截获被测对象在编译过程中所产生的编译指令，然后根据编译指令，获取该编译指令涉及到的所有源文件，进而对所有源文件进行软件成分分析，识别出被测对象中存在的第三方组件。这样可以降低由于在引入第三方组件源代码(即源文件)时，对目录组织进行改动所造成的在收集源文件时容易出现的文件缺失、缺少组织的不足，从而保证对于进行软件成分分析所需的源文件的收集可靠性，从而保证软件成分分析结果的可靠性。

本申请实施例还提供了一种代码安全缺陷分析装置，包括：静态分析模块，用于对被测对象进行静态分析，得到所述被测对象中存在的代码安全缺陷；软件成分分析模块，用于对所述被测对象进行软件成分分析，识别出所述被测对象中存在的第三方组件的源文件；区分处理模块，用于从各所述代码安全缺陷中，确定出所述源文件对应的代码安全缺陷。

本申请实施例还提供了一种第三方组件的源文件识别装置，包括：截取模块，用于截获被测对象在编译过程中所产生的编译指令；源文件获取模块，用于根据所述编译指令，获取在所述编译过程中所述编译指令涉及到的所有源文件；第三方组件识别模块，用于对所述所有源文件进行软件成分分析，识别出所述被测对象中存在的第三方组件的源文件。

本申请实施例还提供了一种电子设备，包括处理器、存储器及通信总线；所述通信总线用于实现处理器和存储器之间的连接通信；所述处理器用于执行存储器中存储的一个或者多个程序，以实现上述任一种的代码安全缺陷分析方法，或实现上述的第三方组件的源文件识别方法。

本申请实施例中还提供了一种计算机可读存储介质，所述计算机可读存储介质存储有一个或者多个程序，所述一个或者多个程序可被一个或者多个处理器执行，以实现上述任一种的代码安全缺陷分析方法，或实现上述的第三方组件的源文件识别方法。

附图说明

为了更清楚地说明本申请实施例的技术方案，下面将对本申请实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本申请的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。

图1为本申请实施例提供的一种代码安全缺陷分析方法的流程示意图；

图2为本申请实施例提供的一种第三方组件的源文件识别方法的流程示意图；

图3为本申请实施例提供的一种代码安全缺陷分析装置的结构示意图；

图4为本申请实施例提供的一种第三方组件的源文件识别装置的结构示意图；

图5为本申请实施例提供的一种电子设备的结构示意图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行描述。

实施例一：

为了解决目前当静态分析产品检测完毕后，开发人员还需要进一步的通过人工筛选的方式，从所有的安全缺陷中识别出非第三方组件的源代码所产生的安全缺陷，需要投入大量的人力成本，且筛选效率低下，严重影响安全缺陷的修复效率的问题，本申请实施例中提供了一种代码安全缺陷分析方法。可以参见图1所示，图1为本申请实施例中提供的一种代码安全缺陷分析方法的流程示意图，包括：

S101：对被测对象进行静态分析，得到被测对象中存在的代码安全缺陷。

需要说明的是，本申请实施例中所述的被测对象是指具有项目代码或软件代码等具有代码安全缺陷检测需求，或具有第三方组件识别需求的代码集合。

在本申请实施例中，对被测对象进行静态分析的过程，可以是采用现在已有的或未来将会出现的静态分析技术来实现。例如可以通过在不运行被测对象的代码的情况下，通过词法分析、语法分析、控制流分析、数据流分析等分析技术对被测对象的程序代码进行扫描，验证被测对象的各部分代码是否满足规范性、安全性、可靠性、可维护性等指标，从而识别出被测对象所具有的代码安全缺陷。上例中，所采用的词法分析、语法分析、控制流分析、数据流分析等分析技术为静态分析技术中的常规技术，在此不做赘述。

S102：对被测对象进行软件成分分析，识别出被测对象中存在的第三方组件的源文件。

需要说明的是，在本申请实施例中，步骤S101和步骤S102之间不具有时序限制。也即可以先执行步骤S101，再执行步骤S102；也可以先执行步骤S102，再执行步骤S101；还可以同时执行步骤S101和步骤S102。

应理解，软件成分分析技术是常见的应用安全测试技术，软件成分分析技术可以通过源文件或者二进制文件的特征值，识别出被测对象中所使用的第三方组件，并确定出被测对象中的哪些源文件属于第三方组件的源文件。

在本申请实施例的一种可行实施方式中，可以直接采用常规的软件成分分析产品对被测对象进行软件成分分析，识别出被测对象中存在的第三方组件的源文件。

此外，考虑到在通过源代码引入第三方组件时，往往会对目录组织进行改动，从而改变第三方组件的源代码的原有组织结构。可能会对软件成分分析产品的识别造成一些困难，导致软件成分分析产品在收集源文件时，出现文件缺失、缺少组织等情况，导致第三方组件的识别成功率降低。为此，在本申请实施例的另一种可行实施方式中，可以通过收集编译过程中涉及的所有源文件，通过对编译过程中涉及的所有源文件进行软件成分分析，识别出第三方组件的源文件。

示例性的，可以截获被测对象在编译过程中所产生的编译指令，然后根据所截获的编译指令，获取该编译指令涉及到的所有源文件，然后对编译过程中涉及的所有源文件进行软件成分分析，识别出第三方组件的源文件。

这样，通过编译指令，实现了编译指令相关的源文件的提取(即使编译指令相关的源文件位于不同目录，也会被同时提取并关联)，这就可以降低由于在引入第三方组件源代码时，对目录组织进行改动所造成的在收集源文件时容易出现的文件缺失、缺少组织的不足，保证对于进行软件成分分析所需的源文件的收集可靠性，从而保证软件成分分析结果的可靠性。

需要说明的是，在本申请实施例中，可以通过使用修改环境变量、预加载库等技术截获编译指令。

还需要说明的是，在本申请实施例中，针对同一编译指令，其所涉及的源文件可以和该编译指令关联，从而便于后续进行软件成分分析。

应理解，在根据所截获的编译指令，获取该编译指令涉及到的所有源文件的同时，还可以根据所截获的编译指令，获取该编译指令所涉及到的所有lib、dll等二进制文件。类似的，对应同一编译指令的二进制文件和源文件可以关联。

在进行软件成分分析时，可以将所获取到的源文件和二进制文件输入至软件成分分析产品中，实现对于第三方组件的识别。

需要注意的是，在本申请实施例的一种可选实施方式中，在截获被测对象在编译过程中所产生的编译指令，并收集编译过程中涉及的所有源文件之后，还可以将编译指令和源文件输入到静态分析产品中，从而对编译指令和源文件进行分析，得到被测对象中存在的代码安全缺陷。这样，在进行静态分析时，考虑了编译指令，可以使得在静态分析时，可以按照该编译指令进行编译参数的适配，然后再进行源文件的分析，从而可以使得分析过程中源文件的状态更接近其在被测对象中的状态，使得分析得到的被测对象中所存在的代码安全缺陷更为准确。

示例性的，在本申请实施例中，可以先将编译指令转换为编译参数，该编译参数的格式与静态分析时所采用的编译器相适配，然后在该编译器中配置该编译参数。然后对源文件进行词法分析、语法分析、数据流分析、符号执行分析等，得到被测对象中存在的代码安全隐患。

还应理解，在本申请实施例中，在获取到源文件后，可以对源文件进行重命名，并存放至同一目录下，以适配后续的静态分析产品或软件成分分析产品的规范要求。

S103：从各代码安全缺陷中，确定出第三方组件的源文件对应的代码安全缺陷。

在本申请实施例的一种可选实施方式中，在从各代码安全缺陷中，确定出第三方组件的源文件对应的代码安全缺陷之后，还可以对确定出的第三方组件的源文件对应的代码安全缺陷进行标记。这样，可以使得后续工程师在查阅或进行代码安全缺陷修复时，可以很容易的区分出哪些属于第三方组件的代码安全缺陷，进而可以针对性的进行代码安全缺陷的修复，提高修复效率。

在本申请实施例的一种可选实施方式中，在从各代码安全缺陷中，确定出第三方组件的源文件对应的代码安全缺陷之后，也可以将这些第三方组件的源文件对应的代码安全缺陷进行去除，从而仅向工程师反馈除第三方组件的代码安全缺陷外的其他代码安全缺陷。

此外，在本申请实施例中，在执行步骤S101和步骤S102之后，还可以从被测对象的静态分析结果中，获取第三方组件的各源文件的静态分析结果，然后根据第三方组件的各源文件的静态分析结果，确定第三方组件的实际使用情况。

例如，可以根据被测对象各部分代码的静态分析结果中，记录的各部分代码的功能或作用，确定出第三方组件的各源文件对应的功能或作用，从而识别出被测对象中实际使用到的第三方组件的组件模块、组件功能等，有效地增强软件成分分析过程中，针对第三方组件使用情况的分析能力。

本申请实施例所提供的代码安全缺陷分析方法，在对被测对象进行静态分析，得到被测对象中存在的所有代码安全缺陷之后，通过对被测对象进行软件成分分析，识别出被测对象中存在的第三方组件的源文件，进而即可从各代码安全缺陷中，确定出属于第三方组件的源文件对应的代码安全缺陷。这样，就无需开发人员在得到被测对象中存在的所有代码安全缺陷之后，再进行人工筛选，从而降低了人力成本，提高了代码安全缺陷的筛选效率，从而提高了安全缺陷的修复效率。

此外，当通过源代码引入第三方组件时，往往会对目录组织进行改动，这会改变第三方组件的源代码的原有组织结构。例如，在C/C++语言开发中，对于第三方组件的源代码的使用，常常会将.h头文件和.c/.cpp源文件分别放到不同的目录中进行管理。这样，会对软件成分分析产品的识别造成一些困难，可能导致软件成分分析产品在收集源文件时，出现文件缺失、缺少组织等情况，导致第三方组件的识别成功率降低。

为了解决目前第三方组件的识别成功率低的问题，本申请实施例中提供了一种第三方组件的源文件识别方法。可以参见图2所示，图2为本申请实施例中提供的一种代码安全缺陷分析方法的流程示意图，包括：

S201：截获被测对象在编译过程中所产生的编译指令。

如前文所述，在本申请实施例中，可以通过使用修改环境变量、预加载库等技术截获编译指令。

S202：根据编译指令，获取在编译过程中，该编译指令涉及到的所有源文件。

S203：对所有源文件进行软件成分分析，识别出被测对象中存在的第三方组件的源文件。

类似的，在根据所截获的编译指令，获取该编译指令涉及到的所有源文件的同时，还可以根据所截获的编译指令，获取该编译指令所涉及到的所有lib、dll等二进制文件。对应同一编译指令的二进制文件和源文件可以关联。在进行软件成分分析时，可以仅对源文件进行分析，实现对于第三方组件的源文件的识别，也可以将所获取到的源文件和二进制文件都输入至软件成分分析产品中，实现对于第三方组件的源文件和二进制文件的识别。

本申请实施例所提供的第三方组件的源文件识别方法，通过截获被测对象在编译过程中所产生的编译指令，然后根据编译指令，获取该编译指令涉及到的所有源文件，进而对所有源文件进行软件成分分析，识别出被测对象中存在的第三方组件。这样可以降低由于在引入第三方组件源代码时，对目录组织进行改动所造成的在收集源文件时容易出现的文件缺失、缺少组织的不足，从而保证对于进行软件成分分析所需的源文件的收集可靠性，从而保证软件成分分析结果的可靠性。

应理解，本申请实施例所提供的代码安全缺陷分析方法和第三方组件的源文件识别方法，可以应用于各类具有数据处理能力的电子设备上，例如可以应用于服务器、电脑主机等电子设备上。此外，本申请实施例所提供的代码安全缺陷分析方法和第三方组件的源文件识别方法，还可以应用于各类具有数据处理能力的电子设备集群中，例如可以应用于服务器集群、虚拟机集群中。在本申请实施例中，对于本申请实施例所提供的代码安全缺陷分析方法和第三方组件的源文件识别方法的应用场景不做限制。

实施例二：

本实施例在实施例一的基础上，以一种较具体的实现过程为例，为本申请做进一步示例说明。

首先，可以使用修改环境变量、预加载库等技术截获被测对象的编译指令，并根据编译指令收集此次编译过程中涉及到的所有源文件或者lib、dll等二进制文件。

接着，将源文件和编译指令关联，并将源文件按照静态分析产品和软件分析产品的要求进行重命名，并放置于同一目录下。

将源文件和编译指令输入至静态分析产品中。此时，静态分析产品可以将编译指令转换为所采用的编译器的编译参数，并加载至该编译器中。然后，对源文件进行词法分析、语法分析、数据流分析、符号执行分析等分析，得到被测对象中存在的代码安全隐患。

将源文件和二进制文件输入软件成分分析产品中，识别出被测对象中存在的第三方组件。

从静态分析产生的代码安全缺陷中，确定出属于第三方组件的源文件对应的代码安全缺陷进行标记，后续默认对标记的代码安全缺陷进行筛除，以避免对审计人员或者开发人员造成干扰。此外，从被测对象的静态分析结果中，获取第三方组件的各源文件的静态分析结果，根据第三方组件的各源文件的静态分析结果，确定第三方组件的实际使用情况，如实际使用的组件模块、组件功能等。

通过上述方案，一方面能够有效减少第三方组件源代码引入带来的静态分析结果干扰，另一方面也能够有效地提升第三方组件识别的检出率和准确率。此外，还可以有效地增强成分分析系统中针对第三方组件使用情况的分析能力。

实施例三：

基于同一发明构思，本申请实施例中还提供代码安全缺陷分析装置300和第三方组件的源文件识别装置400。请参阅图3和图4所示，图3示出了采用图1所示的方法的代码安全缺陷分析装置，图4示出了采用图2所示的方法的第三方组件的源文件识别装置。应理解，装置300和装置400具体的功能可以参见上文中的描述，为避免重复，此处适当省略详细描述。装置300和装置400包括至少一个能以软件或固件的形式存储于存储器中或固化在装置300、装置400的操作系统中的软件功能模块。具体地：

参见图3所示，装置300包括：静态分析模块301，软件成分分析模块302和区分处理模块303。其中：

静态分析模块301，用于对被测对象进行静态分析，得到所述被测对象中存在的代码安全缺陷；

软件成分分析模块302，用于对所述被测对象进行软件成分分析，识别出所述被测对象中存在的第三方组件的源文件；

区分处理模块303，用于从各所述代码安全缺陷中，确定出所述源文件对应的代码安全缺陷。

在本申请实施例的一种可行实施方式中，装置300还可以包括信息获取模块，用于截获所述被测对象在编译过程中所产生的编译指令，以及收集所述编译过程中涉及的所有源文件。

该可行实施方式中，静态分析模块301可以具体用于，对所述编译指令和所述所有源文件进行分析，得到所述被测对象中存在的代码安全缺陷。

软件成分分析模块302，可以具体用于，对所述所有源文件进行软件成分分析，识别出所述第三方组件的源文件。

在上述可行实施方式中，所述信息获取模块可以具体用于，根据所述编译指令，获取在所述编译过程中所述编译指令涉及到的所有源文件。

在本申请实施例中，所述区分处理模块303还用于，在从各所述代码安全缺陷中，确定出所述源文件对应的代码安全缺陷之后，标记所述源文件对应的代码安全缺陷。

在本申请实施例中，所述区分处理模块303还用于，在从各所述代码安全缺陷中，确定出所述源文件对应的代码安全缺陷之后，从各所述代码安全缺陷中，去除所述第三方组件的源文件对应的代码安全缺陷。

在本申请实施例中，装置300还可以包括使用情况分析模块，用于从所述被测对象的静态分析结果中，获取所述第三方组件的各源文件的静态分析结果，根据所述第三方组件的各源文件的静态分析结果，确定所述第三方组件的实际使用情况。

参见图4所示，装置400包括：截取模块401，源文件获取模块402和第三方组件识别模块403。其中：

截取模块401，用于截获被测对象在编译过程中所产生的编译指令；

源文件获取模块402，用于根据所述编译指令，获取在所述编译过程中所述编译指令涉及到的所有源文件；

第三方组件识别模块403，用于对所述所有源文件进行软件成分分析，识别出所述被测对象中存在的第三方组件。

需要理解的是，出于描述简洁的考量，部分实施例一中描述过的内容在本实施例中不再赘述。

实施例四：

本实施例提供了一种电子设备，参见图5所示，其包括处理器501、存储器502以及通信总线503。其中：

通信总线503用于实现处理器501和存储器502之间的连接通信。

处理器501用于执行存储器502中存储的一个或多个程序，以实现上述实施例一和/或实施例二中的代码安全缺陷分析方法，或实现上述实施例一和/或实施例二中的第三方组件的源文件识别方法。

可以理解，图5所示的结构仅为示意，电子设备还可包括比图5中所示更多或者更少的组件，或者具有与图5所示不同的配置。例如，电子设备还可以具有无线通信模组、USB数据插口、显示器等组件。

本实施例还提供了一种计算机可读存储介质，如软盘、光盘、硬盘、闪存、U盘、SD(Secure Digital Memory Card，安全数码卡)卡、MMC(Multimedia Card，多媒体卡)卡等，在该计算机可读存储介质中存储有实现上述各个步骤的一个或者多个程序，这一个或者多个程序可被一个或者多个处理器执行，以实现上述实施例一和/或实施例二中的代码安全缺陷分析方法，或实现上述实施例一和/或实施例二中的第三方组件的源文件识别方法。在此不再赘述。

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

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

再者，在本申请各个实施例中的各功能模块可以集成在一起形成一个独立的部分，也可以是各个模块单独存在，也可以两个或两个以上模块集成形成一个独立的部分。

在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。

在本文中，多个是指两个或两个以上。

以上所述仅为本申请的实施例而已，并不用于限制本申请的保护范围，对于本领域的技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。

Claims (11)

1.一种代码安全缺陷分析方法，其特征在于，包括：

对被测对象进行静态分析，得到所述被测对象中存在的代码安全缺陷；

对所述被测对象进行软件成分分析，识别出所述被测对象中存在的第三方组件的源文件；

从各所述代码安全缺陷中，确定出所述源文件对应的代码安全缺陷。

2.如权利要求1所述的代码安全缺陷分析方法，其特征在于，所述方法还包括：

截获所述被测对象在编译过程中所产生的编译指令；

收集所述编译过程中涉及的所有源文件；

所述对被测对象进行静态分析，得到所述被测对象中存在的代码安全缺陷，包括：对所述编译指令和所述所有源文件进行分析，得到所述被测对象中存在的代码安全缺陷；

所述对所述被测对象进行软件成分分析，识别出所述被测对象中存在的第三方组件的源文件，包括：对所述所有源文件进行软件成分分析，识别出所述第三方组件的源文件。

3.如权利要求2所述的代码安全缺陷分析方法，其特征在于，收集所述编译过程中涉及的所有源文件，包括：

根据所述编译指令，获取在所述编译过程中所述编译指令涉及到的所有源文件。

4.如权利要求1-3任一项所述的代码安全缺陷分析方法，其特征在于，从各所述代码安全缺陷中，确定出所述源文件对应的代码安全缺陷之后，所述方法还包括：

标记所述源文件对应的代码安全缺陷。

5.如权利要求1-3任一项所述的代码安全缺陷分析方法，其特征在于，从各所述代码安全缺陷中，确定出所述源文件对应的代码安全缺陷之后，所述方法还包括：

从各所述代码安全缺陷中，去除所述第三方组件的源文件对应的代码安全缺陷。

6.如权利要求1-3任一项所述的代码安全缺陷分析方法，其特征在于，所述方法还包括：

从所述被测对象的静态分析结果中，获取所述第三方组件的各源文件的静态分析结果；

根据所述第三方组件的各源文件的静态分析结果，确定所述第三方组件的实际使用情况。

7.一种第三方组件的源文件识别方法，其特征在于，包括：

截获被测对象在编译过程中所产生的编译指令；

根据所述编译指令，获取在所述编译过程中所述编译指令涉及到的所有源文件；

对所述所有源文件进行软件成分分析，识别出所述被测对象中存在的第三方组件的源文件。

8.一种代码安全缺陷分析装置，其特征在于，包括：

静态分析模块，用于对被测对象进行静态分析，得到所述被测对象中存在的代码安全缺陷；

软件成分分析模块，用于对所述被测对象进行软件成分分析，识别出所述被测对象中存在的第三方组件的源文件；

区分处理模块，用于从各所述代码安全缺陷中，确定出所述源文件对应的代码安全缺陷。

9.一种第三方组件的源文件识别装置，其特征在于，包括：

截取模块，用于截获被测对象在编译过程中所产生的编译指令；

源文件获取模块，用于根据所述编译指令，获取在所述编译过程中所述编译指令涉及到的所有源文件；

第三方组件识别模块，用于对所述所有源文件进行软件成分分析，识别出所述被测对象中存在的第三方组件的源文件。

10.一种电子设备，其特征在于，包括：处理器、存储器及通信总线；

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

所述处理器用于执行所述存储器中存储的程序，以实现如权利要求1至6中任一项所述的代码安全缺陷分析方法，或实现如权利要求7所述的第三方组件的源文件识别方法。

11.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质存储有一个或者多个程序，所述一个或者多个程序可被一个或者多个处理器执行，以实现如权利要求1至6任一项所述的代码安全缺陷分析方法，或实现如权利要求7所述的第三方组件的源文件识别方法。

Images