CN118153050A - 云服务系统中的漏洞检测方法、装置以及计算设备 - Google Patents
云服务系统中的漏洞检测方法、装置以及计算设备 Download PDFInfo
- Publication number
- CN118153050A CN118153050A CN202211513444.6A CN202211513444A CN118153050A CN 118153050 A CN118153050 A CN 118153050A CN 202211513444 A CN202211513444 A CN 202211513444A CN 118153050 A CN118153050 A CN 118153050A
- Authority
- CN
- China
- Prior art keywords
- party
- information
- target
- server
- code
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 238000001514 detection method Methods 0.000 title claims abstract description 87
- 238000000034 method Methods 0.000 claims abstract description 119
- 230000008569 process Effects 0.000 claims abstract description 73
- 238000010276 construction Methods 0.000 claims abstract description 66
- 230000015654 memory Effects 0.000 claims description 77
- 230000006870 function Effects 0.000 claims description 39
- 238000012360 testing method Methods 0.000 claims description 32
- 238000004590 computer program Methods 0.000 claims description 15
- 230000001419 dependent effect Effects 0.000 claims description 9
- 230000008676 import Effects 0.000 claims description 6
- 238000012544 monitoring process Methods 0.000 claims description 4
- 238000004806 packaging method and process Methods 0.000 claims description 3
- 238000004458 analytical method Methods 0.000 description 23
- 238000012545 processing Methods 0.000 description 23
- 238000007726 management method Methods 0.000 description 18
- 238000004891 communication Methods 0.000 description 10
- 238000011161 development Methods 0.000 description 10
- 238000010586 diagram Methods 0.000 description 10
- 206010047289 Ventricular extrasystoles Diseases 0.000 description 8
- 230000010354 integration Effects 0.000 description 8
- 238000005129 volume perturbation calorimetry Methods 0.000 description 8
- 230000003068 static effect Effects 0.000 description 6
- 238000013461 design Methods 0.000 description 5
- 230000007613 environmental effect Effects 0.000 description 5
- 230000001360 synchronised effect Effects 0.000 description 4
- 230000008878 coupling Effects 0.000 description 3
- 238000010168 coupling process Methods 0.000 description 3
- 238000005859 coupling reaction Methods 0.000 description 3
- 238000004519 manufacturing process Methods 0.000 description 3
- 230000003287 optical effect Effects 0.000 description 3
- 238000013500 data storage Methods 0.000 description 2
- 230000003993 interaction Effects 0.000 description 2
- 230000002093 peripheral effect Effects 0.000 description 2
- 238000013515 script Methods 0.000 description 2
- 239000004065 semiconductor Substances 0.000 description 2
- 239000007787 solid Substances 0.000 description 2
- 238000013459 approach Methods 0.000 description 1
- 238000013475 authorization Methods 0.000 description 1
- 230000009286 beneficial effect Effects 0.000 description 1
- 238000004422 calculation algorithm Methods 0.000 description 1
- 238000004364 calculation method Methods 0.000 description 1
- 238000000802 evaporation-induced self-assembly Methods 0.000 description 1
- 238000007689 inspection Methods 0.000 description 1
- 238000009434 installation Methods 0.000 description 1
- 238000012423 maintenance Methods 0.000 description 1
- 230000007246 mechanism Effects 0.000 description 1
- 229910021421 monocrystalline silicon Inorganic materials 0.000 description 1
- 230000008447 perception Effects 0.000 description 1
- 239000011148 porous material Substances 0.000 description 1
- 238000006467 substitution reaction Methods 0.000 description 1
- 238000011144 upstream manufacturing Methods 0.000 description 1
- 238000012795 verification Methods 0.000 description 1
Abstract
本申请实施例提供了一种云服务系统中的漏洞检测方法、装置以及计算设备,该云服务系统包括至少一个服务器,该方法可以由第一服务器执行,该第一服务器为该至少一个服务器中的任一个,该方法包括:获取被测代码对应的第一信息,该第一信息包括该被测代码在构建过程中所使用的构建命令的执行路径,其中,该被测代码对应多个第三方组件;根据该第一信息,从该多个第三方组件中,确定至少一个目标第三方组件,该目标第三方组件为该多个第三方组件中该被测代码实际依赖的第三方组件;对该目标第三方组件进行漏洞检测。通过对被测代码实际依赖的第三方组件进行漏洞检测可以提升漏洞检测的效率,同时提高漏洞检测的准确性。
Description
技术领域
本申请涉及软件工程技术领域,并且更具体地,涉及一种云服务系统中的漏洞检测方法、装置以及计算设备。
背景技术
开源代码的使用可以大幅度提高软件研发效率、缩短上市时间、降低开发成本。这些开源代码构成了软件供应链的一部分,虽然它们的集成是有益的,但与此同时,针对软件供应链薄弱环节的网络攻击也随之增加。
为解决此类问题,软件成分分析应运而生。软件成分分析即对软件的组成进行分析,识别出软件中使用的开源和第三方组件(例如第三方依赖库、框架等),以进一步检测出应用程序可能引入的开源漏洞风险。现有的软件成分分析工具在每次构建时自动进行全面软件成分分析,这可能阻塞代码上线进度并使开发人员不堪重负,此类工具在开发运维一体化(development and operations,DevOps)流水线中引入时会存在明显的效率问题。
发明内容
本申请提供一种云服务系统中的漏洞检测方法、装置以及计算设备,能够提升软件漏洞检测的效率,同时提高漏洞检测的准确性。
第一方面,提供了一种云服务系统中的漏洞检测方法,该云服务系统包括至少一个服务器,该方法可以由第一服务器执行,该第一服务器为该至少一个服务器中的任一个,该方法包括:该第一服务器获取被测代码对应的第一信息,该第一信息包括该被测代码在构建过程中所使用的构建命令的执行路径,其中,该被测代码对应多个第三方组件;该第一服务器根据该第一信息,从该多个第三方组件中,确定至少一个目标第三方组件,该目标第三方组件为该多个第三方组件中该被测代码实际依赖的第三方组件;该第一服务器对该目标第三方组件进行漏洞检测。
基于上述方案,云服务系统中的服务器可以通过获取被测代码构建过程所使用的构建命令的执行路径,确定该被测代码实际依赖的第三方组件,通过对该被测代码实际依赖的第三方组件进行漏洞检测可以提升的漏洞检测的效率,同时可以提高漏洞检测的准确性。
结合第一方面,在第一方面的某些实现方式中,该第一服务器确定该被测代码的依赖配置文件,该依赖配置文件存储在本地代码库对应的该执行路径下;该第一服务器解析该依赖配置文件,确定该目标第三方组件。
结合第一方面,在第一方面的某些实现方式中,该第一服务器将该被测代码的构建过程中所使用的构建工具的命令封装为函数;该第一服务器通过执行该函数监控该被测代码的构建过程并获取该第一信息。
基于上述方案,该第一服务器通过将构建工具的命令封装为函数监控被测代码的构建过程,可适用于不同内核的操作系统,同时资源占用也较小,该监控过程可以在不影响构建性能、开发无感知的情况下记录用户编译命令。
结合第一方面,在第一方面的某些实现方式中,该第一信息还包括该被测代码在构建过程中所使用的环境变量,在该第一服务器根据该第一信息,从该多个第三方组件中,确定至少一个目标第三方组件之前,该第一服务器导入该环境变量;该第一服务器在该环境变量下,根据该第一信息,从该多个第三方组件中,确定至少一个该目标第三方组件。
基于上述方案,在构建过程所使用的环境下确定该被测代码实际依赖的第三方组件,进行漏洞检测,可以提高漏洞检测的准确性。
结合第一方面,在第一方面的某些实现方式中,该第一信息还包括第一缓存目录,该第一缓存目录为该至少一个目标第三方组件的缓存目录,该第一服务器导入该被测代码构建过程中所使用的构建工具,并将该构建工具的本地缓存目录指向该第一缓存目录。
基于上述方案,通过将漏洞检测的第三方组件缓存目录指向构建过程中第三方组件的缓存目录,可以避免从远端下载第三方组件,可以提升软件成分分析的效率。
结合第一方面,在第一方面的某些实现方式中,该第一服务器在根据该第一信息,从该多个第三方组件中,确定至少一个目标第三方组件之前,判断该构建命令是否为与引用了第三方组件相关的构建命令;若该构建命令是与引用了第三方组件相关的构建命令,则该第一服务器根据该第一信息,从该多个第三方组件中,确定至少一个该目标第三方组件。
基于上述方案,在确定该被测代码实际依赖的第三方组件之前,可以判断构建命令是否为与第三方组件的引入相关的命令,提升漏洞检测的效率。
第二方面,提供一种云服务系统中的漏洞检测装置,该装置可以是该云服务系统中的任一服务器,该云服务系统包括至少一个服务器,该装置包括获取模块、确定模块和检测模块,该获取模块用于,获取被测代码对应的第一信息,该第一信息包括该被测代码在构建过程中所使用的构建命令的执行路径,其中,该被测代码对应多个第三方组件;该确定模块用于,根据该第一信息,从该多个第三方组件中,确定至少一个目标第三方组件,该目标第三方组件为该多个第三方组件中该被测代码实际依赖的第三方组件;该检测模块用于,对该目标第三方组件进行漏洞检测。
结合第二方面,在第二方面的某些实现方式中,该确定模块具体用于:确定该被测代码的依赖配置文件,该依赖配置文件存储在本地代码库对应的该执行路径下;解析该依赖配置文件,确定该目标第三方组件。
结合第二方面,在第二方面的某些实现方式中,该获取模块具体用于:将该被测代码的构建过程中所使用的构建工具的命令封装为函数;通过执行该函数监控该被测代码的构建过程并获取该第一信息。
结合第二方面,在第二方面的某些实现方式中,该第一信息还包括该被测代码在构建过程中所使用的环境变量,该确定模块还用于:导入该环境变量;该确定模块具体用于:在该环境变量下,根据该第一信息,从该多个第三方组件中,确定至少一个该目标第三方组件。
结合第二方面,在第二方面的某些实现方式中,该第一信息还包括第一缓存目录,该第一缓存目录为该至少一个目标第三方组件的缓存目录,该确定模块还用于:导入该被测代码构建过程中所使用的构建工具,将该构建工具的本地缓存目录指向该第一缓存目录。
结合第二方面,在第二方面的某些实现方式中,该确定模块还用于:判断该构建命令是否为与引用了第三方组件相关的构建命令;该确定模块具体用于:若该构建命令是与引用了第三方组件相关的构建命令,则根据该第一信息,从该多个第三方组件中,确定至少一个该目标第三方组件。
第二方面和第二方面的任意一个可能的实现方式的有益效果和第一方面以及第一方面的任意一个可能的实现方式的有益效果是对应的,不再赘述。
第三方面,提供了一种计算设备,包括处理器和存储器,可选地,还包括输入输出接口。其中所述处理器用于控制所述输入输出接口收发信息,所述存储器用于存储计算机程序,所述处理器用于从存储器中调用并运行该计算机程序,使得所述执行第一方面或第一方面任意一种可能的实现方式中所述的方法。
可选地,该处理器可以是通用处理器,可以通过硬件来实现也可以通过软件来实现。当通过硬件实现时,该处理器可以是逻辑电路、集成电路等;当通过软件来实现时,该处理器可以是一个通用处理器,通过读取存储器中存储的软件代码来实现,该存储器可以集成在处理器中,可以位于该处理器之外,独立存在。
第四方面,提供了一种计算设备集群,包括至少一个计算设备,每个计算设备包括处理器和存储器;所述至少一个计算设备的处理器用于执行所述至少一个计算设备的存储器中存储的指令,以使得所述计算设备集群执行第一方面或第一方面任意一种可能的实现方式中所述的方法。
第五方面,提供了一种芯片,该芯片获取指令并执行该指令来实现上述第一方面以及第一方面的任意一种实现方式中的方法。
可选地,作为一种实现方式,该芯片包括处理器与数据接口,该处理器通过该数据接口读取存储器上存储的指令,执行上述第一方面以及第一方面的任意一种实现方式中的方法。
可选地,作为一种实现方式,该芯片还可以包括存储器,该存储器中存储有指令,该处理器用于执行该存储器上存储的指令,当该指令被执行时,该处理器用于执行第一方面以及第一方面中的任意一种实现方式中的方法。
第六方面,提供了一种包含指令的计算机程序产品,当所述指令被区块链节点运行时,使得所述区块链节点执行如上述第一方面以及第一方面的任意一种实现方式中的方法。
第七方面,提供了一种包含指令的计算机程序产品,当所述指令被计算设备集群运行时,使得所述计算设备集群执行如上述第一方面以及第一方面的任意一种实现方式中的方法。
第八方面,提供了一种计算机可读存储介质,其特征在于,包括计算机程序指令,当所述计算机程序指令由计算设备执行时,所述计算设备执行如上述第一方面以及第一方面的任意一种实现方式中的方法。
作为示例,这些计算机可读存储包括但不限于如下的一个或者多个:只读存储器(read-only memory,ROM)、可编程ROM(programmable ROM,PROM)、可擦除的PROM(erasablePROM,EPROM)、Flash存储器、电EPROM(electrically EPROM,EEPROM)以及硬盘驱动器(harddrive)。
可选地,作为一种实现方式,上述存储介质具体可以是非易失性存储介质。
第九方面,提供了一种计算机可读存储介质,其特征在于,包括计算机程序指令,当所述计算机程序指令由计算设备集群执行时,所述计算设备集群执行如上述第一方面以及第一方面的任意一种实现方式中的方法。
作为示例,这些计算机可读存储包括但不限于如下的一个或者多个:只读存储器ROM、可编程ROM、可擦除的PROM、Flash存储器、电EPROM以及硬盘驱动器。
可选地,作为一种实现方式,上述存储介质具体可以是非易失性存储介质。
附图说明
图1是本申请实施例提供的一种云服务系统架构的示意图。
图2是本申请实施例提供的一种漏洞检测方法的示意性流程图。
图3是本申请实施例提供的在DevOps流程中集成漏洞检测功能的示意图。
图4是本申请实施例提供的一种装置400的示意性框图。
图5是本申请实施例提供的一种计算设备500的架构示意图。
图6是本申请实施例提供的一种计算设备集群的架构示意图。
图7是本申请实施例提供的计算设备500A和500B之间通过网络进行连接的示意图。
具体实施方式
下面将结合附图,对本申请中的技术方案进行描述。
本申请将围绕包括多个设备、组件、模块等的系统来呈现各个方面、实施例或特征。应当理解和明白的是,各个系统可以包括另外的设备、组件、模块等,并且/或者可以并不包括结合附图讨论的所有设备、组件、模块等。此外,还可以使用这些方案的组合。
另外,在本申请实施例中,“示例性地”、“例如”等表示作例子、例证或说明。本申请中被描述为“示例”的任何实施例或设计方案不应被解释为比其它实施例或设计方案更优选或更具优势。确切而言,使用示例的一词旨在以具体方式呈现概念。
本申请实施例描述的业务场景是为了更加清楚地说明本申请实施例的技术方案,并不构成对于本申请实施例提供的技术方案的限定。本领域普通技术人员可知,随着网络架构的演变和新业务场景的出现,本申请实施例提供的技术方案对于类似的技术问题,同样适用。
本申请中,“至少一个”是指一个或者多个,“多个”是指两个或两个以上。“和/或”,描述关联对象的关联关系,表示可以存在三种关系,例如,A和/或B,可以表示:包括单独存在A,同时存在A和B,以及单独存在B的情况,其中A,B可以是单数或者复数。字符“/”一般表示前后关联对象是一种“或”的关系。“以下至少一项(个)”或其类似表达,是指的这些项中的任意组合,包括单项(个)或复数项(个)的任意组合。例如,a,b,或c中的至少一项(个),可以表示:a,b,c,a-b,a-c,b-c,或a-b-c,其中a,b,c可以是单个,也可以是多个。
为了便于理解,下面介绍本申请实施例可能涉及的相关术语和概念。
1、软件供应链(software supply chain)
软件供应链可以是用于构建软件应用程序的组件、库和工具的列表。软件供应商通常通过组装开源和商业软件组件来创建产品。
2、持续集成(continuous integration)
持续集成是指在开发阶段,对项目进行持续性自动化编译、测试以达到控制代码质量的手段。持续集成可以让产品快速迭代的同时保持高质量,并且可以简化开发人员的工作流程。
3、构建调用栈(build call stack)
调用栈是一种在程序的执行过程中,存储函数调用信息的动态数据结构。构建调用栈是在持续集成的构建阶段,追踪编译脚本执行动作的一种机制。
4、软件成分分析(software composition analysis,SCA)
SCA用于分析开发人员使用的各种源代码、模块、框架和库,以识别和清点开源软件的组件及其构成和依赖关系,并识别已知的安全漏洞或者潜在的许可证授权问题。SCA的目的在于把这些风险排查在应用系统投产之前。
5、开发运维一体化(development and operations,DevOps)
DevOps是在软件生命周期内,从设计到编码,从开发环境部署到生产环境上,由开发人员和运维人员共同参与的软件迭代过程。
目前,开源代码的使用可以大幅度提高软件研发效率、缩短上市时间、降低开发成本。但同时带来的是,软件供应链暴露给攻击者的攻击面越来越多。并且越来越多的攻击者也发现针对供应链的攻击相对针对应用本身或系统的漏洞攻击可能更加容易,成本更低。
为解决此类问题,SCA的重要性逐年增长。为了更有效的确保企业软件供应链的安全,支撑安全的应用程序的开发和组装,可以将SCA功能安全无缝地集成到DevOps流程中,尽量“左移”检测开源软件组件是否带有已知的漏洞,及早发现安全风险。
以下是几种常见的开源SCA工具。
1、dependabot
dependabot是一款github静态解析的工具。该工具通过识别代码库中各语言的配置文件,将依赖树展示在代码库依赖视图中。dependabot的依赖树信息动态存储在后端,需逐层分开调用后端接口获取下层依赖信息。开发人员可通过配置dependabot的config文件控制检查目录及更新频率。在项目所依赖的上游软件包或应用程序发布新版本后,dependabot会在对应的GitHub仓库自动创建一个项目来更新依赖描述文件,并说明依赖更新内容,用户可选择是否合并该项目。
2、Synopsys
Synopsys是一款提供静态分析、软件组成分析和动态分析解决方案的平台。Synopsys提出的方案是将SCA流程从构建/测试隔离到流水线其它阶段中,并通过API调用集成到DevOps流程中。Synopsys支持并行运行进行SCA。
3、WhiteSource
WhiteSource是一个针对开源软件管理和许可证合规管理的平台。WhiteSource主要提供针对管理开源组件的一站式安全、许可和质量的解决方案,并对软件开发领域提供一款开源安全和许可证合规性的管理工具。该工具通过检测源文件和二进制文件实现了动态软件成分分析能力。在构建(build)和测试(test)阶段,当引入新的开源软件时,WhiteSource基于插件的能力会自动对组件的合法性和完整性进行校验,避免引入危险的开源软件;在发布(release)阶段,WhiteSource可自动为发布应用进行软件版权和许可信息进行风险检查;在监听(monitor)阶段,WhiteSource可自动检测用户的开源软件清单中的所有开源软件。
从以上可以看出,静态解析SCA工具如dependabot存在分析的滞后性。其依赖树信息动态存储在后端,在分析代码的间接依赖时需逐层调用后端接口获取下层依赖信息。动态解析SCA工具如WhiteSource、Synopsys可以实时解析依赖树,获取最新的依赖信息,解决了静态软件成分分析工具结果滞后性的问题。但该类工具在每次构建时自动进行全面的软件成分分析,这可能阻塞代码上线进度并使开发人员不堪重负。此类工具在DevOps流水线中引入时会有明显的效率问题。为此Synopsys将软件成分分析流程从构建/测试隔离到流水线其它阶段中,支持并行运行提升效率。但此方案相当于用资源换效率,增加了分析成本,并且工具的分析环境和构建环境不一致可能会影响分析结果的准确性。
有鉴于此,本申请实施例提供了一种云服务系统中的漏洞检测方法,可以更高效地分析代码依赖的第三方组件是否存在漏洞,同时,可以提高漏洞检测的准确性。
图1示出了本申请实施例提供的一种云服务系统架构的示意图。如图1所示,云服务系统可以包括客户端和数据中心,客户端可以通过互联网接入云管理平台。云管理平台与数据中心内部网络相连接,通常情况下,数据中心包含至少一个服务器,图1中示出的数据中心包括两个服务器(包括服务器#1和服务器#2)的情况。以服务器#1为例,服务器#1可以包括软件层和硬件层。其中,软件层可以包含多个虚拟机,以及宿主操作系统,该宿主操作系统包括虚拟机管理器和云管理平台客户端;硬件层可以包括处理器、内存、硬盘、网卡以及数据总线等等。
其中,云管理平台用于提供访问接口,例如,云管理平台用于提供界面或应用程序接口(application programming interface,API)。租户可操作客户端远程接入访问接口在云管理平台注册云账号和密码,并登录云管理平台。云管理平台对云账号和密码鉴权成功后,租户可进一步在云管理平台付费选择并购买特定规格(处理器、内存、磁盘)的虚拟机,付费购买成功后,云管理平台提供所购买的虚拟机的远程登录账号密码,客户端可远程登录该虚拟机,在该虚拟机中安装并运行租户的应用。云管理平台客户端可以用于接收云管理平台发送的控制面命令,根据控制面控制命令在服务器上创建并对虚拟机进行全生命周期管理。因此,租户可通过云管理平台在云数据中心中创建、管理、登录和操作虚拟机。其中,虚拟机也可称为“云服务器(elastic compute service,ECS)”、“弹性实例”,等等,不同的云服务提供商有不同的称呼。
图2是本申请实施例提供的一种云服务系统中的漏洞检测方法的示意性流程图。该方法可以由云服务系统中的第一服务器执行,该第一服务器可以为云服务系统中的任一服务器。如图2所示,该方法可以包括以下几个步骤。
S210,获取被测代码对应的第一信息,该第一信息包括该被测代码在构建过程中所使用的构建命令的执行路径。
其中,该被测代码可以是项目代码或软件代码等具有第三方组件识别需求的代码集合。该被测代码可以对应多个第三方组件。
被测代码的构建过程可以理解为将被测代码转换为二进制的过程。该构建命令可以包括至少一个编译命令,该至少一个编译命令中包括执行该构建过程的编译命令。该执行路径可以为该构建命令所运行的目录。
具体地,可以通过监控被测代码的构建过程获取该第一信息。
一个示例中,可以通过动态追踪工具监控被测代码的构建过程。动态追踪工具可以用于观测系统的调用、函数调用等,例如,常见的动态追踪工具有strace、arthas、ebpf等。在本申请的实施例中,可以通过该动态追踪工具获取被测代码构建过程中的构建命令和执行路径,即当前工作目录(current working directory,cwd)。
另一个示例中,监控被测代码的构建过程可以通过构建调用栈实现。
例如,构建调用栈的实现方式可以是,将构建过程中构建工具链的执行命令封装成对应的函数(function),以捕获和记录一次构建的构建命令和执行路径。
以Java项目为例,Java项目在构建过程中所使用的构建工具链可以包括包管理器,例如maven,gradle,npm等。Java项目可以通过该包管理器引入第三方组件。以maven为例,构建调用栈可以通过shell脚本将maven的构建命令封装成对应的函数(function)实现。这些包管理器通过shell命令调用应用程序的方式启动。其中,Shell是一个为用户提供操作界面的命令解析器(command interpreter),介于操作系统内核和用户之间,负责接收用户输入的指令并进行解释、将需要执行的操作传递给内核执行并将执行结果返回给用户。
例如,通常使用的编译命令为“mvn clean package”,如下function mvn()函数所示,用function mvn替换应用程序mvn,并将function mvn()嵌入到构建环境中,可以在每次执行mvn命令(例如上述“mvn clean package”)时,记录该构建命令和以及该命令的执行路径。
function mvn(){
${CID_MAVEN_HOME}/bin/mvn“$@”
SHELL_STATUS=$?//记录命令行参数
Return$SHELL_STATUS//记录执行路径
}
export-f mvn
通过构建调用栈监控被测代码的构建过程,可适用于不同内核的操作系统,同时对中央处理器(central processing unit,CPU)、内存等资源占用也较小,该监控过程可以在不影响构建性能、开发无感知的情况下记录用户编译命令。
可选地,该第一信息还可以包括代码语言、构建过程所使用的构建工具,例如包管理器、构建过程中所使用的第三方组件的缓存目录(记为第一缓存目录)中的至少一种。
S220,根据该第一信息,从该多个第三方组件中,确定至少一个目标第三方组件。
该目标第三方组件为该多个第三方组件中该被测代码实际依赖的第三方组件。
具体地,根据第一信息确定被测代码实际依赖的第三方组件可以包括:在本地代码库中查找构建命令的执行路径下的依赖配置文件,通过解析该依赖配置文件确定被测代码实际依赖的第三方组件。
其中,本地代码库中可以存储至少一个应用项目的代码,该至少一个应用项目包括该被测代码所属的项目。该依赖配置文件定义了应用项目构建过程中需要的信息,例如,该该项目构建可能需要的第三方组件的信息。
以maven工程为例,若监控到在A目录下执行了“mvn package”,则找到A目录下的pom.xml文件(依赖配置文件的一例);执行“mvn dependency:tree”操作可以解析依赖树信息,即解析得到被测代码实际历依赖的第三方组件的信息,或者说,解析得到实际参与被测代码构建过程的第三方组件的信息。
基于上述方案,通过确定被测代码实际依赖的第三方组件,可以过滤掉定义在依赖配置文件中但并未实际参与构建的第三方组件。对实际参与构建过程的第三方组件进行漏洞检测可以提升漏洞检测的效率。
S230,对该目标第三方组件进行漏洞检测。
具体地,可以将被测代码实际依赖的第三方组件的信息与漏洞数据库进行匹配,确定被测代码实际依赖的第三方组件是否存在漏洞。
示例性地,可以预先构建漏洞数据库,漏洞数据库存储有开源组件所对应的漏洞信息,通过该漏洞数据库可快速查找到实际依赖的第三方组件所存在的漏洞信息。
以maven工程为例,可以解析该命令执行目录下pom.xml的坐标信息,接着利用坐标信息与漏洞数据库中的相同坐标信息的开源组件,将该坐标信息对应的第三方组件的特征信息与该漏洞数据库中的相同坐标信息的开源组件的漏洞信息进行配对,若两者匹配则说明该坐标信息对应的第三方组件可能存在漏洞。
可选地,该方法还包括:
S240,确定该第一信息中构建命令是否为与引入第三方组件相关的构建命令。
作为示例,可以在调用构建栈捕获到一个构建命令的同时判断该构建命令是否与第三方组件的引入相关,若相关,则可以根据该构建命令以及该构建命令的执行路径确定被测代码实际依赖的第三方组件;若不相关,可以不记录该构建命令。
其中,与引入第三方组件相关的命令可以是用于构建过程执行的命令。以maven为例,与引入第三方组件相关的构建命令可以包括“mvn compile”、“mvn package”、“mvninstall”等。与引入第三方组件不相关的命令例如可以查询构建工具版本信息的命令。
通过确定该第一信息中与第三方组件引入相关的构建命令,可以提升漏洞检测的效率。
可选地,该方法还包括:
S250,导入构建过程所使用的构建环境。
该构建环境可以包括环境变量,即将构建过程所使用的环境变量作为漏洞检测的环境变量。
以maven工程为例,构建过程中的环境变量可以包括配置的环境变量MAVEN_HOME、PATH。
通过导入构建过程中的环境变量,可以直接在目标环境中,即被测代码实际使用的环境中进行漏洞检测,而无需安装构建环境,能够提高漏洞检测的准确率。在一些情况下,环境变量和系统变量也会影响漏洞检测的结果。
可选地,该构建环境还包括构建工具。即在漏洞检测过程中导入将构建过程所使用的构建工具,同时,还可以将构建工具的本地缓存目录指向第一缓存目录。该第一缓存目录为被测代码构建过程中第三方组件的缓存目录;或者说,该第一缓存目录为该至少一个目标第三方组件的缓存目录。
以maven项目为例,将构建工具的本地缓存目录指向第一缓存目录可以通过执行“export MAVEN_LOCAL_CACHE=/data/***(第一缓存目录)”实现。该第一缓存目录可以为~/.m2/repository或者为Maven的安装目录的conf子目录。
由于此时已完成一次完整构建过程,构建工具,第三方组件已保留在构建环境中,因此在漏洞检测过程中无需重新从远端进行更新数据,可以提升漏洞检测的效率。例如,主流包管理器如gradle、maven、npm、go等基本可以在1min内完成分析。
应理解,在本申请的各实施例中的各种数字序号的大小并不意味着执行顺序的先后,仅为描述方便进行的区分,不应对本申请实施例的实施过程构成任何限定。例如,步骤S240和S250可以在S230之前执行。
本申请实施例的技术方案的可以将漏洞检测功能集成到DevOps流程中的构建阶段,最大程度实现安全“左移”,检测开源软件组件是否带有已知的漏洞,及早发现安全风险。
图3为DevOps流程中集成漏洞检测功能的示意图,如图3所示,本申请在DevOps流程中的构建阶段利用构建调用栈工具监控整个构建过程,将一次构建过程涉及的代码语言、包管理工具、实际执行的构建命令、构建命令的命令执行目录等影响第三方组件引用的构建信息(第一信息)记录下来。在构建出包完成后,将记录下来的构建信息作为漏洞检测的输入,并复用该构建过程中所使用的构建环境(构建工具、执行路径、缓存的第三方组件等),高效准确地进行软件漏洞检测。
可选地,在检测到被测代码实际依赖的第三方组件后,可持续地与漏洞数据库进行比对,当出现安全问题时立刻通知用户,并持续地向用户进行策略警告、安全警告、漏洞警告、版本警告。同时也可以配置门禁(gated check-in,GC)规则,在构建阶段拦截,将安全风险“左移”,避免将问题遗留到后续测试,验证,部署阶段。
上文结合图1至图3,详细描述了本申请实施例提供的云服务系统中的漏洞检测方法,下面将结合图4至图7,详细描述本申请提供的云服务系统中的漏洞检测装置。
应理解,方法实施例的描述与装置实施例的描述相互对应,因此,未详细描述的部分可以参见前面方法实施例。
图4是本申请实施例提供的一种漏洞检测装置400的示意性框图。该装置400可以通过软件、硬件或者两者的结合实现。本申请实施例提供的漏洞检测装置400可以实现本申请实施例图2所示的方法流程。
该装置400包括:获取模块410、确定模块420以及检测模块430。
其中,该获取模块410用于获取被测代码对应的第一信息,该第一信息包括该被测代码在构建过程中所使用的构建命令的执行路径,其中,该被测代码对应多个第三方组件。
该确定模块420用于根据该第一信息,从该多个第三方组件中,确定至少一个目标第三方组件,该目标第三方组件为该多个第三方组件中该被测代码实际依赖的第三方组件。
该检测模块430用于对该目标第三方组件进行漏洞检测。
可选地,该确定模块420具体用于确定该被测代码的依赖配置文件,该依赖配置文件存储在本地代码库对应的该执行路径下;解析该依赖配置文件,确定该目标第三方组件。
可选地,该获取模块410具体用于将该被测代码的构建过程中所使用的构建工具的命令封装为函数;通过执行该函数监控该被测代码的构建过程并获取该第一信息。
该第一信息还可以包括该被测代码在构建过程中所使用的环境变量,该确定模块420还可以用于导入该环境变量;可选地,该确定模块420具体用于在该环境变量下,根据该第一信息,从该多个第三方组件中,确定至少一个该目标第三方组件。
该第一信息还可以包括第一缓存目录,该第一缓存目录为该至少一个目标第三方组件的缓存目录;可选地,该确定模块420还用于导入该被测代码构建过程中所使用的构建工具,将该构建工具的本地缓存目录指向该第一缓存目录。
可选地,该确定模块420还用于判断该构建命令是否为与引用了第三方组件相关的构建命令;该确定模块420具体用于若该构建命令是与引用了第三方组件相关的构建命令,则根据该第一信息,从该多个第三方组件中,确定至少一个该目标第三方组件。
可选地,该装置400还包括展示模块440,用于通过交互界面向所述用户展示所述漏洞检测的结果。
这里的装置400可以以功能模块的形式体现。这里的术语“模块”可以通过软件和/或硬件形式实现,对此不作具体限定。
例如,“模块”可以是实现上述功能的软件程序、硬件电路或二者结合。示例性地,接下来以获取模块为例,介绍获取模块的实现方式。类似地,其他模块,例如分析模块的实现方式可以参考获取模块的实现方式。
模块作为软件功能单元的一种举例,接收模块可以包括运行在计算实例上的代码。其中,计算实例可以包括物理主机(计算设备)、虚拟机、容器中的至少一种。进一步地,上述计算实例可以是一台或者多台。例如,获取模块可以包括运行在多个主机/虚拟机/容器上的代码。需要说明的是,用于运行该代码的多个主机/虚拟机/容器可以分布在相同的区域(region)中,也可以分布在不同的region中。进一步地,用于运行该代码的多个主机/虚拟机/容器可以分布在相同的可用区(availability zone,AZ)中,也可以分布在不同的AZ中,每个AZ包括一个数据中心或多个地理位置相近的数据中心。其中,通常一个region可以包括多个AZ。
同样,用于运行该代码的多个主机/虚拟机/容器可以分布在同一个虚拟私有云(virtual private cloud,VPC)中,也可以分布在多个VPC中。其中,通常一个VPC设置在一个region内,同一region内两个VPC之间,以及不同region的VPC之间跨区通信需在每个VPC内设置通信网关,经通信网关实现VPC之间的互连。
模块作为硬件功能单元的一种举例,获取模块可以包括至少一个计算设备,如服务器等。或者,接收模块也可以是利用专用集成电路(application-specific integratedcircuit,ASIC)实现、或可编程逻辑器件(programmable logic device,PLD)实现的设备等。其中,上述PLD可以是复杂程序逻辑器件(complex programmable logical device,CPLD)、现场可编程门阵列(field-programmable gate array,FPGA)、通用阵列逻辑(generic array logic,GAL)或其任意组合实现。
获取模块包括的多个计算设备可以分布在相同的region中,也可以分布在不同的region中。获取模块包括的多个计算设备可以分布在相同的AZ中,也可以分布在不同的AZ中。同样,获取模块包括的多个计算设备可以分布在同一个VPC中,也可以分布在多个VPC中。其中,所述多个计算设备可以是服务器、ASIC、PLD、CPLD、FPGA和GAL等计算设备的任意组合。
因此,在本申请的实施例中描述的各示例的模块,能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行,取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能,但是这种实现不应认为超出本申请的范围。
需要说明的是,本申请提供的漏洞检测装置在执行漏洞检测方法时,仅以上述各功能模块的划分进行举例说明,实际应用中,可以根据需要而将上述功能分配由不同的功能模块完成,即将装置的内部结构划分成不同的功能模块,以完成以上描述的全部或者部分功能。例如,获取模块可以用于执行漏洞检测方法中的任意步骤;确定模块可以用于执行漏洞检测方法中的任意步骤;检测模块可以用于执行漏洞检测方法中的任意步骤。获取模块、确定模块以及检测模块负责实现的步骤可根据需要指定,通过获取模块、确定模块和检测模块分别实现漏洞检测方法中不同的步骤来实现漏洞检测装置的全部功能。
另外,本申请提供的云服务系统中的漏洞检测装置与漏洞检测方法实施例属于同一构思,其具体实现过程详见上文中的方法实施例,这里不再赘述。
本申请实施例提供的漏洞检测方法可以由计算设备执行,该计算设备也可以被称为计算机系统。包括硬件层、运行在硬件层之上的操作系统层,以及运行在操作系统层上的应用层。该硬件层包括处理单元、内存和内存控制单元等硬件,随后对该硬件的功能和结构进行详细说明。该操作系统是任意一种或多种通过进程(process)实现业务处理的计算机操作系统,例如,Linux操作系统、Unix操作系统、Android操作系统、iOS操作系统或windows操作系统等。该应用层包含浏览器、通讯录、文字处理软件、即时通信软件等应用程序。并且,可选地,该计算机系统是智能手机等手持设备,或个人计算机等终端设备,本申请并未特别限定,只要能够通过本申请实施例提供的方法即可。本申请实施例提供的漏洞检测方法的执行主体可以是计算设备,或者,是计算设备中能够调用程序并执行程序的功能模块。
下面结合图5,对本申请实施例提供的一种计算设备进行详细描述。
图5是本申请实施例提供的一种计算设备500的架构示意图。该计算设备500可以是服务器或者计算机或者其他具有计算能力的设备。图5所示的计算设备500包括:至少一个处理器510和存储器520。
应理解,本申请不限定计算设备500中的处理器、存储器的个数。
处理器510执行存储器520中的指令,使得计算设备500实现本申请提供的漏洞检测方法。或者,处理器510执行存储器520中的指令,使得计算设备500实现本申请提供的各功能模块,从而实现本申请提供的漏洞检测方法。
可选地,计算设备500还包括通信接口530。通信接口530使用例如但不限于网络接口卡、收发器一类的收发模块,来实现计算设备500与其他设备或通信网络之间的通信。
可选地,计算设备500还包括系统总线540。计算设备500中,处理器510、存储器520和通信接口530分别与系统总线540连接。处理器510能够通过系统总线540访问存储器520,例如,处理器510能够通过系统总线540在存储器520中进行数据读写或代码执行。
该系统总线540是快捷外设部件互连标准(peripheral component interconnectexpress,PCI)总线或扩展工业标准结构(extended industry standard architecture,EISA)总线等。所述系统总线540分为地址总线、数据总线、控制总线等。为便于表示,图5中仅用一条粗线表示,但并不表示仅有一根总线或一种类型的总线。
一种可能的实现方式,处理器510的主要功能是解释计算机程序的指令(或者说,代码)以及处理计算机软件中的数据。其中,该计算机程序的指令以及计算机软件中的数据能够保存在存储器520或者缓存516中。
可选地,处理器510可能是集成电路芯片,具有信号的处理能力。
作为示例而非限定,处理器510是通用处理器、数字信号处理器(digital signalprocessor,DSP)、专用集成电路(application specific integrated circuit,ASIC)、现成可编程门阵列(field programmable gate array,FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。其中,通用处理器是微处理器等。例如,该处理器510是中央处理单元(central processing unit,CPU)。
可选地,每个处理器510可以包括至少一个处理单元512和内存控制单元514。
可选地,处理单元512也称为核心(core)或内核,是处理器最重要的组成部分。处理单元512是由单晶硅以一定的生产工艺制造出来的,处理器所有的计算、接受命令、存储命令、处理数据都由核心执行。处理单元512分别独立地运行程序指令,利用并行计算的能力加快程序的运行速度。各种处理单元都具有固定的逻辑结构,例如,处理单元包括例如,一级缓存、二级缓存、执行单元、指令级单元和总线接口等逻辑单元。
一种可能的实现方式中,内存控制单元514可以用于控制存储器520与处理单元512之间的数据交互。
具体地,内存控制单元514可以从处理单元512接收内存访问请求,并基于该内存访问请求控制针对内存的访问。作为示例而非限定,内存控制单元是内存管理单元(memorymanagement unit,MMU)等器件。
另一种可能的实现方式中,各内存控制单元514通过系统总线进行针对存储器520的寻址。并且在系统总线中配置仲裁器(图5中未示出),该仲裁器负责处理和协调多个处理单元512的竞争访问。
又一种可能的实现方式中,处理单元512和内存控制单元514通过芯片内部的连接线,例如地址线,通信连接,从而实现处理单元512和内存控制单元514之间的通信。
可选地,每个处理器510还可以包括缓存516。其中,缓存是数据交换的缓冲区(称作cache)。当处理单元512要读取数据时,会首先从缓存中查找需要的数据,如果找到了则直接执行,找不到的话则从存储器中找。由于缓存的运行速度比存储器快得多,故缓存的作用就是帮助处理单元512更快地运行。
存储器520能够为计算设备500中的进程提供运行空间,例如,存储器520中保存用于生成进程的计算机程序(具体地说,是程序的代码)。计算机程序被处理器运行而生成进程后,处理器在存储器520中为该进程分配对应的存储空间。进一步的,上述存储空间进一步包括文本段、初始化数据段、位初始化数据段、栈段、堆段等等。存储器520在上述进程对应的存储空间中保存进程运行期间产生的数据,例如,中间数据,或过程数据等等。
可选地,存储器也称为内存,其作用是用于暂时存放处理器510中的运算数据,以及与硬盘等外部存储器交换的数据。只要计算机在运行中,处理器510就会把需要运算的数据调到内存中进行运算,当运算完成后处理单元512再将结果传送出来。
作为示例而非限定,存储器520是易失性存储器或非易失性存储器,或可包括易失性和非易失性存储器两者。其中,非易失性存储器是只读存储器(read-only memory,ROM)、可编程只读存储器(programmable ROM,PROM)、可擦除可编程只读存储器(erasable PROM,EPROM)、电可擦除可编程只读存储器(electrically EPROM,EEPROM)或闪存。易失性存储器是随机存取存储器(random access memory,RAM),其用作外部高速缓存。通过示例性但不是限制性说明,许多形式的RAM可用,例如静态随机存取存储器(static RAM,SRAM)、动态随机存取存储器(dynamic RAM,DRAM)、同步动态随机存取存储器(synchronous DRAM,SDRAM)、双倍数据速率同步动态随机存取存储器(double data rate SDRAM,DDR SDRAM)、增强型同步动态随机存取存储器(enhanced SDRAM,ESDRAM)、同步连接动态随机存取存储器(synchlink DRAM,SLDRAM)和直接内存总线随机存取存储器(direct rambus RAM,DRRAM)。应注意,本文描述的系统和方法的存储器520旨在包括但不限于这些和任意其它适合类型的存储器。
以上列举的计算设备500的结构仅为示例性说明,本申请并未限定于此,本申请实施例的计算设备500包括现有技术中计算机系统中的各种硬件,例如,计算设备500还包括除存储器520以外的其他存储器,例如,磁盘存储器等。本领域的技术人员应当理解,计算设备500还可以包括实现正常运行所必须的其他器件。同时,根据具体需要,上述计算设备500还可包括实现其他附加功能的硬件器件。
此外,本领域的技术人员应当理解,上述计算设备500也可仅仅包括实现本申请实施例所必须的器件,而不必包括图5中所示的全部器件。
本申请实施例还提供了一种计算设备集群。该计算设备集群可以包括至少一台计算设备。该计算设备可以是服务器。在一些实施例中,计算设备也可以是台式机、笔记本电脑或者智能手机等终端设备。
如图6所示,所述计算设备集群包括至少一个计算设备500。计算设备集群中的一个或多个计算设备500中的存储器520中可以存有相同的用于执行漏洞检测方法的指令。
在一些可能的实现方式中,该计算设备集群中的一个或多个计算设备500中的存储器520也可以分别存有用于执行漏洞检测方法的部分指令。换言之,一个或多个计算设备500的组合可以共同执行用于执行漏洞检测方法的指令。
需要说明的是,计算设备集群中的不同的计算设备500中的存储器520可以存储不同的指令,分别用于执行漏洞检测装置的部分功能。也即,不同的计算设备500中的存储器520存储的指令可以实现将漏洞检测装置中的一个或多个模块的功能。
在一些可能的实现方式中,计算设备集群中的一个或多个计算设备可以通过网络连接。其中,网络可以是广域网或局域网等等。图7示出了一种可能的实现方式。如图7所示,两个计算设备500A和500B之间通过网络进行连接。
具体地,通过各个计算设备中的通信接口与所述网络进行连接。在这一类可能的实现方式中,计算设备500A中的存储器520有执行接收模块、检索模块和验证模块的功能的指令。同时,计算设备500B中的存储器520中存有执行摘要模块和摘要索引模块的功能的指令。
应理解,图7中示出的计算设备500A的功能也可以由多个计算设备500完成。同样,计算设备500B的功能也可以由多个计算设备500完成。
本实施例中,还提供了一种包含指令的计算机程序产品,所述计算机程序产品可以是包含指令的,能够运行在计算设备上或被储存在任何可用介质中的软件或程序产品。当其在区块链节点上运行时,使得计算设备执行上述漏洞检测方法,或者使得该计算设备实现上述漏洞检测装置的功能。
本实施例中,还提供了一种包含指令的计算机程序产品,所述计算机程序产品可以是包含指令的,能够运行在计算设备集群上或被储存在任何可用介质中的软件或程序产品。当其由计算设备集群运行时,使得计算设备集群执行上述漏洞检测方法,或者使得该计算设备集群实现上述漏洞检测装置的功能。
本实施例中,还提供了一种计算机可读存储介质,计算机可读存储介质可以是计算设备能够存储的任何可用介质或者是包含一个或多个可用介质的数据中心等数据存储设备。所述可用介质可以是磁性介质,(例如,软盘、硬盘、磁带)、光介质(例如,DVD)、或者半导体介质(例如固态硬盘)等。该计算机可读存储介质包括指令,当计算机可读存储介质中的指令在计算设备上被执行时,使得计算设备执行上述所提供的漏洞检测方法。
本实施例中,还提供了一种计算机可读存储介质,计算机可读存储介质可以是计算设备能够存储的任何可用介质或者是包含一个或多个可用介质的数据中心等数据存储设备。所述可用介质可以是磁性介质,(例如,软盘、硬盘、磁带)、光介质(例如,DVD)、或者半导体介质(例如固态硬盘)等。该计算机可读存储介质包括指令,当计算机可读存储介质中的指令由计算设备集群执行时,使得计算设备集群执行上述所提供的漏洞检测方法。
应理解,在本申请的各种实施例中,上述各过程的序号的大小并不意味着执行顺序的先后,各过程的执行顺序应以其功能和内在逻辑确定,而不应对本申请实施例的实施过程构成任何限定。
本领域普通技术人员可以意识到,结合本文中所公开的实施例描述的各示例的单元及算法步骤,能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行,取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能,但是这种实现不应认为超出本申请的范围。
所属领域的技术人员可以清楚地了解到,为描述的方便和简洁,上述描述的系统、装置和单元的具体工作过程,可以参考前述方法实施例中的对应过程,在此不再赘述。
在本申请所提供的几个实施例中所揭露的系统、装置和方法,可以通过其它的方式实现。例如,以上所描述的装置实施例仅仅是示意性的,例如,所述单元的划分,仅仅为一种逻辑功能划分,实际实现时可以有另外的划分方式,例如多个单元或组件可以结合或者可以集成到另一个系统,或一些特征可以忽略,或不执行。另一点,所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口,装置或单元的间接耦合或通信连接,可以是电性,机械或其它的形式。
所述作为分离部件说明的单元可以是或者也可以不是物理上分开的,作为单元显示的部件可以是或者也可以不是物理单元,即可以位于一个地方,或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
另外,在本申请各个实施例中的各功能单元可以集成在一个处理单元中,也可以是各个单元单独物理存在,也可以两个或两个以上单元集成在一个单元中。
所述功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时,可以存储在一个计算机可读取存储介质中。基于这样的理解,本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来,该计算机软件产品存储在一个存储介质中,包括若干指令用以使得一台计算机设备(可以是个人计算机,服务器,或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括:U盘、移动硬盘、只读存储器(read-only memory,ROM)、随机存取存储器(random access memory,RAM)、磁碟或者光盘等各种可以存储程序代码的介质。
以上所述,仅为本申请的具体实施方式,但本申请的保护范围并不局限于此,任何熟悉本技术领域的技术人员在本申请揭露的技术范围内,可轻易想到变化或替换,都应涵盖在本申请的保护范围之内。因此,本申请的保护范围应以所述权利要求的保护范围为准。
Claims (17)
1.一种云服务系统中的漏洞检测方法,其特征在于,所述云服务系统包括至少一个服务器,所述方法包括:
第一服务器获取被测代码对应的第一信息,所述第一信息包括所述被测代码在构建过程中所使用的构建命令的执行路径,其中,所述被测代码对应多个第三方组件,所述第一服务器为所述至少一个服务器中任一个;
所述第一服务器根据所述第一信息,从所述多个第三方组件中,确定至少一个目标第三方组件,所述目标第三方组件为所述多个第三方组件中所述被测代码实际依赖的第三方组件;
所述第一服务器对所述目标第三方组件进行漏洞检测。
2.根据权利要求1所述的方法,其特征在于,所述第一服务器根据所述第一信息,从所述多个第三方组件中,确定至少一个目标第三方组件,包括:
所述第一服务器确定所述被测代码的依赖配置文件,所述依赖配置文件存储在本地代码库对应的所述执行路径下;
所述第一服务器解析所述依赖配置文件,确定所述目标第三方组件。
3.根据权利要求1或2所述的方法,其特征在于,所述第一服务器获取被测代码对应的第一信息,包括:
所述第一服务器将所述被测代码的构建过程中所使用的构建工具的命令封装为函数;
所述第一服务器通过执行所述函数监控所述被测代码的构建过程并获取所述第一信息。
4.根据权利要求1至3中任一项所述的方法,其特征在于,所述第一信息还包括所述被测代码在构建过程中所使用的环境变量,在所述第一服务器根据所述第一信息,从所述多个第三方组件中,确定至少一个目标第三方组件之前,所述方法还包括:
所述第一服务器导入所述环境变量;
所述第一服务器根据所述第一信息,从所述多个第三方组件中,确定至少一个目标第三方组件,包括:
在所述环境变量下,所述第一服务器根据所述第一信息,从所述多个第三方组件中,确定至少一个所述目标第三方组件。
5.根据权利要求1至4中任一项所述的方法,其特征在于,所述第一信息还包括第一缓存目录,所述第一缓存目录为所述至少一个目标第三方组件的缓存目录,所述方法还包括:
所述第一服务器导入所述被测代码构建过程中所使用的构建工具,将所述构建工具的本地缓存目录指向所述第一缓存目录。
6.根据权利要求1至5中任一项所述的方法,其特征在于,在所述第一服务器根据所述第一信息,从所述多个第三方组件中,确定至少一个目标第三方组件之前,所述方法还包括:
所述第一服务器判断所述构建命令是否为与引用了第三方组件相关的构建命令;
所述第一服务器根据所述第一信息,从所述多个第三方组件中,确定至少一个目标第三方组件,包括:
若所述构建命令是与引用了第三方组件相关的构建命令,则所述第一服务器根据所述第一信息,从所述多个第三方组件中,确定至少一个所述目标第三方组件。
7.一种云服务系统中的漏洞检测装置,其特征在于,所述装置包括获取模块、确定模块和检测模块,
所述获取模块用于,获取被测代码对应的第一信息,所述第一信息包括所述被测代码在构建过程中所使用的构建命令的执行路径,其中,所述被测代码对应多个第三方组件;
所述确定模块用于,根据所述第一信息,从所述多个第三方组件中,确定至少一个目标第三方组件,所述目标第三方组件为所述多个第三方组件中所述被测代码实际依赖的第三方组件;
所述检测模块用于,对所述目标第三方组件进行漏洞检测。
8.根据权利要求7所述的装置,其特征在于,所述确定模块具体用于:
确定所述被测代码的依赖配置文件,所述依赖配置文件存储在本地代码库对应的所述执行路径下;
解析所述依赖配置文件,确定所述目标第三方组件。
9.根据权利要求7或8所述的装置,其特征在于,所述获取模块具体用于:
将所述被测代码的构建过程中所使用的构建工具的命令封装为函数;
通过执行所述函数监控所述被测代码的构建过程并获取所述第一信息。
10.根据权利要求7至9中任一项所述的装置,其特征在于,所述第一信息还包括所述被测代码在构建过程中所使用的环境变量,所述确定模块还用于:
导入所述环境变量;
所述确定模块具体用于:
在所述环境变量下,根据所述第一信息,从所述多个第三方组件中,确定至少一个所述目标第三方组件。
11.根据权利要求7至10中任一项所述的装置,其特征在于,所述第一信息还包括第一缓存目录,所述第一缓存目录为所述至少一个目标第三方组件的缓存目录,所述确定模块还用于:
导入所述被测代码构建过程中所使用的构建工具,将所述构建工具的本地缓存目录指向所述第一缓存目录。
12.根据权利要求7至11中任一项所述的装置,其特征在于,所述确定模块还用于:
判断所述构建命令是否为与引用了第三方组件相关的构建命令;
所述确定模块具体用于:
若所述构建命令是与引用了第三方组件相关的构建命令,则根据所述第一信息,从所述多个第三方组件中,确定至少一个所述目标第三方组件。
13.一种计算设备,其特征在于,包括处理器和存储器,所述处理器用于执行所述存储器中存储的指令,以使得所述计算设备执行如权利要求1至6中任一项所述的方法。
14.一种计算设备集群,其特征在于,包括至少一个计算设备,每个计算设备包括处理器和存储器;
所述至少一个计算设备的处理器用于执行所述至少一个计算设备的存储器中存储的指令,以使得所述计算设备集群执行如权利要求1至6中任一项所述的方法。
15.一种包含指令的计算机程序产品,其特征在于,当所述指令被计算设备集群运行时,使得所述计算设备集群执行如权利要求的1至6中任一项所述的方法。
16.一种计算机可读存储介质,其特征在于,包括计算机程序指令,当所述计算机程序指令由计算设备执行时,所述计算设备执行如权利要求1至6中任一项所述的方法。
17.一种计算机可读存储介质,其特征在于,包括计算机程序指令,当所述计算机程序指令由计算设备集群执行时,所述计算设备集群执行如权利要求1至6中任一项所述的方法。
Publications (1)
Publication Number | Publication Date |
---|---|
CN118153050A true CN118153050A (zh) | 2024-06-07 |
Family
ID=
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US11048620B2 (en) | Distributed system test device | |
AU2022204197B2 (en) | Security weakness and infiltration detection and repair in obfuscated website content | |
Wan et al. | Bug characteristics in blockchain systems: a large-scale empirical study | |
CN105283849B (zh) | 针对性能和细节的并行跟踪 | |
US8813039B2 (en) | Method and system for software defect reporting | |
CN110474900B (zh) | 一种游戏协议测试方法及装置 | |
US11200048B2 (en) | Modification of codified infrastructure for orchestration in a multi-cloud environment | |
US11609985B1 (en) | Analyzing scripts to create and enforce security policies in dynamic development pipelines | |
Duarte et al. | An empirical study of docker vulnerabilities and of static code analysis applicability | |
Alves et al. | Prioritizing test cases for early detection of refactoring faults | |
US11531763B1 (en) | Automated code generation using analysis of design diagrams | |
US11314856B2 (en) | Generating rule-based access control policies using a bytecode instrumentation system | |
KR20120078017A (ko) | 클라우드 컴퓨팅 기반 악성코드 분석 지원 시스템과 이를 사용하는 분석가 단말 | |
Lawall et al. | WYSIWIB: exploiting fine‐grained program structure in a scriptable API‐usage protocol‐finding process | |
CN110597496B (zh) | 应用程序的字节码文件获取方法及装置 | |
Alhawi et al. | Evaluation and application of two fuzzing approaches for security testing of IoT applications | |
US20140137083A1 (en) | Instrumenting computer program code by merging template and target code methods | |
US20230141948A1 (en) | Analysis and Testing of Embedded Code | |
CN111435348A (zh) | 创建用于数据分析功能的运行时可执行程序的方法 | |
US11620129B1 (en) | Agent-based detection of fuzzing activity associated with a target program | |
CN118153050A (zh) | 云服务系统中的漏洞检测方法、装置以及计算设备 | |
Ouyang et al. | MirrorTaint: Practical Non-intrusive Dynamic Taint Tracking for JVM-based Microservice Systems | |
KR102202923B1 (ko) | 공유 모듈 환경 내의 모듈 특정 트레이싱 기법 | |
CN113485905B (zh) | 数据交易中的测试方法、装置、设备以及计算机存储介质 | |
EP4276665A1 (en) | Analyzing scripts to create and enforce security policies in dynamic development pipelines |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication |