一种基于分级检测的C、C++语言软件成分分析方法及系统

摘要

本发明涉及一种基于分级检测的C、C++语言软件成分分析方法及系统，包括：用户提供可编译的C和/或C++项目依赖环境，并根据自身需求指定分析的级别判断为编译分析或者非编译分析；通过获取的编译命令列表，根据路径优先级在操作系统路径中查找依赖文件，调用操作系统的软件包管理工具判断依赖文件是否为操作系统安装的依赖组件并进行相应处理；对路径中的文件在SCA知识库中进行代码目录，二进制文件匹配，查询此部分的组件信息；合并各步骤得到的最终扫描结果。本发明可以根据用户输入选择和系统可支持的扫描途径，通过分级检测策略对项目逐步进行可行的扫描，在可行的时间、空间资源利用情况下进行尽量精确的扫描分析。

说明书

技术领域

本发明涉及软件安全技术领域，尤其涉及一种基于分级检测的C、C++语言软件成分分析方法及系统。

背景技术

软件成分分析产品(以下简称SCA)通常在开发过程中对应用程序进行分析，以检测开源软件组件是否带有已知的漏洞，例如具有可用安全补丁程序的过期库，以及需要相应授权许可(法律风险)的商业软件或第三方产品。Java，Python等成熟的高级编程语言一般提供通用的包管理工具进行项目的依赖组件管理，帮助用户方便，快速地进行依赖组件管理，SCA工具也能利用这些包管理工具，准确地定位到依赖组件及其版本。C++作为历史悠久的编程语言，在设计初期并没有过多考虑引入包管理工具，即使最近几年产生了Conan等C++包管理工具，但由于历史原因并没有受到广泛使用。并且因为C、C++一般直接跟操作系统接口强相关，原生编译一般会用到操作系统系统路径中的组件库、交叉编译一般会把多个目标环境的依赖库都提供在项目中(比如针对X86，ARM，MIPS一起提供不同版本的组件库)，导致直接扫描C，C++的项目路径不可避免地出现漏报跟误报。

但是C、C++的依赖组件是可以明确的，C、C++真正引入组件的步骤就是C、C++的编译过程，比如在预处理阶段引入依赖的头文件，在链接阶段引入依赖的库文件。大型项目的编译过程在时间跟空间的开销都比较大，完全依赖编译过程也不能完全覆盖用户的使用场景，因此如何解决该问题是目前需要考虑的。

需要说明的是，在上述背景技术部分公开的信息只用于加强对本公开的背景的理解，因此可以包括不构成对本领域普通技术人员已知的现有技术的信息。

发明内容

本发明的目的在于克服现有技术的缺点，提供了一种基于分级检测的C、C++语言软件成分分析方法及系统，解决了软件成分分析中C，C++依赖文件查找困难以及全量编译过程开销过大的问题。

本发明的目的通过以下技术方案来实现：一种基于分级检测的C、C++语言软件成分分析方法，所述分析方法包括：

编译步骤：用户提供可编译的C和/或C++项目依赖环境，根据自身需求指定分析的级别，并根据级别判断是否为编译分析，如果为编译分析则获取编译命令列表，如果为非编译分析则判断此项目是否有可利用的构建工具；

编译命令解析步骤：通过解析编译步骤获取的编译命令列表，根据路径优先级在操作系统路径中查找依赖文件，调用操作系统的软件包管理工具判断依赖文件是否为操作系统安装的依赖组件并进行相应处理；

文件特征扫描步骤：对路径中的文件在SCA知识库中进行代码目录，二进制文件匹配，查询此部分的组件信息；

结果合并步骤：合并各步骤得到的最终扫描结果。

所述如果为编译分析则获取编译命令列表包括：如果级别为全量编译分析，则捕获编译命令列表；如果是增量编译分析，则捕获合并编译命令列表；如果是通过缓存跳过编译分析，则获取缓存编译命令列表。

所述如果为非编译分析则判断此项目是否有可利用的构建工具包括：

如果级别为直接扫描分析，则为非编译分析，此时不对项目进行编译，扫描项目可利用的构建工具；

如果为Cmake构建工具，则执行Cmake构建工具获取编译命令列表，并通过编译命令解析步骤进行编译命令解析；

如果为Conan包管理器，则直接利用Conan命令获取Conan引入的依赖组件。

所述编译命令解析步骤具体包括：

解析编译步骤获取的编译命令列表得到依赖头文件、依赖库文件、编译文件搜索路径及优先级以及控制宏指令，根据这些信息搜索到真正编译依赖的文件列表或者通过依赖文件提取命令直接调用查询到依赖的文件；

如果依赖文件为通过操作系统包管理器按照或者手动直接引入的，则调用操作系统的软件包管理工具查询所有依赖文件列表得到操作系统包管理器组件，如果依赖文件不是操作系统依赖文件则执行文件特征扫描步骤。

一种基于分级检测的C、C++语言软件成分分析系统，它包括编译模块、编译命令解析模块、文件特征扫描模块和结果合并模块；

所述编译模块：用于用户提供可编译的C和/或C++项目依赖环境，并根据自身需求指定分析的级别，并根据级别判断是否为编译分析，如果为编译分析则获取编译命令列表，如果为非编译分析则判断此项目是否有可利用的构建工具；

所述编译命令解析模块：用于通过解析编译模块获取的编译命令列表，根据路径优先级在操作系统路径中查找依赖文件，调用操作系统的软件包管理工具判断依赖文件是否为操作系统安装的依赖组件并进行相应处理；

所述文件特征扫描模块：用于对路径中的文件在SCA知识库中进行代码目录，二进制文件匹配，查询此部分的组件信息；

所述结果合并模块：用于合并各模块得到的最终扫描结果。

本发明具有以下优点：一种基于分级检测的C、C++语言软件成分分析方法及系统，可以根据用户输入选择和系统可支持的扫描途径，通过分级检测策略对项目逐步进行可行的扫描，在可行的资源利用情况下进行尽量精确的扫描分析。

附图说明

图1为本发明方法的流程示意图；

图2为不同的分级检测效果示意图。

具体实施方式

为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。通常在此处附图中描述和示出的本申请实施例的组件可以以各种不同的配置来布置和设计。因此，以下结合附图中提供的本申请的实施例的详细描述并非旨在限制要求保护的本申请的保护范围，而是仅仅表示本申请的选定实施例。基于本申请的实施例，本领域技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都属于本申请保护的范围。下面结合附图对本发明做进一步的描述。

如图1所示，由于历史等原因C，C++并没有广泛适用的依赖包管理工具，软件成分分析工具在分析C，C++项目较其他成熟的语言更加困难，SCA工具或者针对项目路径直接扫描分析，导致引入未真正使用的组件，漏掉系统路径中引入的组件，造成大量的漏报跟误报；或者跟踪全量编译过程，但在时间跟空间资源消耗都很大，在真实用户环境很难执行，因此本发明具体涉及一种基于项目可编译环境分级检测的C、C++的软件成分分析方法，包括以下内容：

S1、用户提供可编译的C、C++项目依赖环境，根据自身需求指定分析的级别，开始执行SCA分析过程。级别包括：全量编译分析、增量编译分析、通过缓存跳过编译分析、直接扫描分析；

进一步地，S1步骤为用户输入步骤，要求使用用户根据待分析的C，C++项目的情况，根据编译信息和希望扫描的级别进行指令输入。具体为：项目依赖环境是否充分、是否可编译、是否已通过SCA工具进行过编译扫描、是否在之前的基础上有修改代码，希望进行增量扫描、是否不想进行全量编译分析，是否想直接文件分析等。然后根据情况输入分析指令：编译分析、增量编译分析、跳过编译利用缓存分析、Cmake，Conan等工具依赖检查分析，直接项目路径分析。

比如第一次可选择完整的编译分析，后续可选择跳过编译，缓存分析，比如修改了部分代码可选择缓存分析。在具体实施过程中，SCA工具可自行选择方式实现缓存，记录已进行过的编译分析中间结果，并在缓存分析、跳过编译分析步骤进行缓存合并，以得到最新的编译分析中间结果。

S2、如果级别为全量编译、增量编译以及通过缓存跳过编译分析，则执行编译过程，通过各执行环境的操作系统接口获取到完整的编译命令列表；

进一步地，S2步骤为编译分析阶段，SCA会调用用户提供的编译指令(比如make)，进行完整的编译过程。此步骤SCA会捕获具体的编译命令，具体的捕获方法跟用户的执行操作系统环境有关。

S3、解析上述步骤的编译命令列表，各编译器的编译命令行参数也不尽相同，但都能解析出：依赖头文件，依赖库文件，编译文件搜索路径及优先级，控制宏指令等，根据这些信息足够找到真正编译依赖的文件列表。或者GCC，Clang等部分编译器有-M、-MF等依赖文件提取命令，可直接调用查询到依赖的文件；

S4、依赖文件能分成两类：通过操作系统包管理器安装的和手动直接引入的。调用操作系统的软件包管理工具查询上述步骤的所有依赖文件列表，能区分出这两部分依赖文件。其中操作系统安装的软件包为结果的一部分，在最后步骤进行合并，手动直接引入的依赖部分在后续文件特征扫描类步骤继续查询匹配；

进一步地，S4步骤为依赖操作系统内部的组件管理工具依次对S3步骤得到的依赖文件进行查询。比如Linux系统有rpm，dkpg等内置的组件管理工具，可把通过操作系统安装的依赖组件进行查询，进而把依赖文件分成两部分：操作系统查询到的部分和操作系统没有查询到的部分。

S5、非编译大类不需要进行上述全量编译相关步骤，不对项目进行编译，扫描项目可利用的构建、依赖相关工具，比如Cmake构建工具，Conan等第三方包管理器工具等，每个相关工具都能提供部分依赖文件或组件相关的信息；

S501、Cmake构建工具能提取到可能执行的编译命令列表而不真正执行这些编译命令，获取到这些编译命令，可直接执行上述S3步骤进行编译命令解析，跳过S2编译步骤；

S502、Conan等包管理器能直接利用Conan命令，或者解析Conanfile.txt、Conanfile.py的方式获取到Conan引入的依赖组件，然后对炫目目录进行S6步骤的文件特征扫描；

S6、文件特征扫描：编译类最后得到的手动直接引入的依赖部分文件和非编译类直接传入的项目路径中的文件，我们都没办法通过包管理器等方式获取到组件信息。对这部分文件利用特定特征算法生成文件目录，二进制文件等指纹信息，在SCA知识库中匹配相似的组件，得到这部分依赖的组件信息；

进一步地，S6步骤把S4步骤操作系统没有查询到的这部分文件或S5步骤项目路径文件通过SCA的文件目录算法，二进制算法生成特征值，用这些特征值在SCA的知识库中进行比对分析，得到这部分依赖文件的组件信息。

S7：上述步骤可能产生的依赖组件信息包括：S4得到的操作系统包管理器组件，S5得到的构建工具、Conan等第三方包管理器引入依赖组件，S6步骤得到的文件特征扫描匹配到的组件，合并这些组件信息得到最终的扫描结果。

如图2所示，虽然C，C++具体的一次编译依赖项是确定，但本发明采用的分级策略本身即为一种降级策略，不同的分析等级得到不同精度分析结果，此为编译的时间跟空间资源限制条件下对项目组件分析的精度跟效率的权衡。

以上所述仅是本发明的优选实施方式，应当理解本发明并非局限于本文所披露的形式，不应看作是对其他实施例的排除，而可用于各种其他组合、修改和环境，并能够在本文所述构想范围内，通过上述教导或相关领域的技术或知识进行改动。而本领域人员所进行的改动和变化不脱离本发明的精神和范围，则都应在本发明所附权利要求的保护范围内。