CN115033892A - 一种组件漏洞分析方法、装置、电子设备及存储介质 - Google Patents

一种组件漏洞分析方法、装置、电子设备及存储介质 Download PDF

Info

Publication number
CN115033892A
CN115033892A CN202210953667.8A CN202210953667A CN115033892A CN 115033892 A CN115033892 A CN 115033892A CN 202210953667 A CN202210953667 A CN 202210953667A CN 115033892 A CN115033892 A CN 115033892A
Authority
CN
China
Prior art keywords
vulnerability
suspected
project
suspicious
determining
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
Application number
CN202210953667.8A
Other languages
English (en)
Inventor
张涛
张弛
杜玉洁
谭博迈
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Beijing Anpro Information Technology Co ltd
Original Assignee
Beijing Anpro Information Technology Co ltd
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Beijing Anpro Information Technology Co ltd filed Critical Beijing Anpro Information Technology Co ltd
Priority to CN202210953667.8A priority Critical patent/CN115033892A/zh
Publication of CN115033892A publication Critical patent/CN115033892A/zh
Pending legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/57—Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
    • G06F21/577—Assessing vulnerabilities and evaluating computer system security

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Computer Security & Cryptography (AREA)
  • General Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Computing Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

本申请提供了一种组件漏洞分析方法、装置、电子设备及存储介质，方法包括：构建漏洞数据库，所述漏洞数据库中存储有第三方组件包含的已知漏洞、与所述已知漏洞对应的漏洞函数和与所述漏洞函数对应的可能触发所述已知漏洞的风险参数；检测项目引用的第三方组件，将所述第三方组件包含的已知漏洞确定为可疑漏洞；从所述漏洞数据库中获取与所述可疑漏洞对应的漏洞函数和与所述漏洞函数对应的可能触发所述可疑漏洞的风险参数；确定所述可疑漏洞在所述项目中是否会被触发，若所述可疑漏洞可触发，则将所述可疑漏洞确定为目标漏洞。通过构建含有丰富漏洞特征的漏洞数据库，对检测出的第三方组件漏洞进行可触发性分析，能够减少SCA对无效漏洞的报告。

Description

一种组件漏洞分析方法、装置、电子设备及存储介质
技术领域
本公开主要涉及软件成分分析技术领域，特别涉及一种组件漏洞分析方法、装置、电子设备及存储介质。
背景技术
随着DevSecOps概念的快速普及和推广，开发安全已经变成了近几年的热门词汇。目前，在软件开发的过程中，第三方组件（包括开源组件、商业化的闭源组件）引用的比例越来越高，由于引用第三方组件而引入安全风险的问题也日益突出。目前，行业内普遍认为软件成分分析(Software Composition Analysis, SCA)是治理组件引用带来的安全风险问题的有效方案。SCA是一种对软件的组成部分进行识别、分析和追踪的技术，专门用于分析软件中使用的各种第三方组件，以识别和清点组件及其构成和依赖关系，并识别已知的安全漏洞或者潜在的许可证授权问题，把这些风险排查在应用系统投产之前。
现有的SCA工具在对项目进行组件识别后，一旦发现含有已知漏洞的第三方组件被引入，不论漏洞是否会被触发，均会被SCA工具检测出来并报告给用户，这实际上是一种非常粗粒度的组件漏洞检测方法，将导致大量无法触发的漏洞也被呈现在用户面前，浪费漏洞治理的资源和精力。因此，如何借助SCA工具实现更细粒度的组件漏洞检测，成为一个技术难题。
发明内容
本申请公开的实施例旨在提供一种组件漏洞分析方法、装置、电子设备及存储介质，以解决上述问题。
在本公开的第一方面中，提供了一种组件漏洞分析方法，包括：
构建漏洞数据库，所述漏洞数据库中存储有第三方组件包含的已知漏洞、与所述已知漏洞对应的漏洞函数和与所述漏洞函数对应的可能触发所述已知漏洞的风险参数；
检测项目引用的第三方组件，将所述第三方组件包含的已知漏洞确定为可疑漏洞；
从所述漏洞数据库中获取与所述可疑漏洞对应的漏洞函数和与所述漏洞函数对应的可能触发所述可疑漏洞的风险参数；
确定所述可疑漏洞在所述项目中是否会被触发，若所述可疑漏洞可触发，则将所述可疑漏洞确定为目标漏洞。
可选地，所述确定所述可疑漏洞在所述项目中是否会被触发，若所述可疑漏洞可触发，则将所述可疑漏洞确定为目标漏洞，包括：
确定所述可疑漏洞所在的第三方组件是否会被所述项目调用；
若所述可疑漏洞所在的第三方组件会被所述项目调用，则确定与所述可疑漏洞对应的漏洞函数是否会被所述项目调用；
若与所述可疑漏洞对应的漏洞函数会被所述项目调用，则确定可能触发所述可疑漏洞的风险参数是否能传递到与所述可疑漏洞对应的漏洞函数，若是，则将所述可疑漏洞确定为目标漏洞。
可选地，所述确定所述可疑漏洞所在的第三方组件是否会被所述项目调用，包括：
检测所述项目的源代码中是否存在所述第三方组件的加载语句；若存在，则确定所述可疑漏洞所在的第三方组件会被所述项目调用。
可选地，所述确定与所述可疑漏洞对应的漏洞函数是否会被所述项目调用，包括：
检测所述项目的源代码中是否存在与所述可疑漏洞对应的漏洞函数的调用语句；若不存在，则确定与所述可疑漏洞对应的漏洞函数不会被所述项目调用；若存在，则检测是否存在从所述项目的入口到与所述可疑漏洞对应的漏洞函数的调用语句之间的可达路径；
若存在所述可达路径，则确定与所述可疑漏洞对应的漏洞函数会被所述项目调用。
可选地，所述检测是否存在从所述项目的入口到与所述可疑漏洞对应的漏洞函数的调用语句之间的可达路径，包括：
定位所述项目中所有的与所述可疑漏洞对应的漏洞函数的调用语句，标记为可疑漏洞点；
对所述项目的入口生成过程间控制流图ICFG；
遍历所述过程间控制流图ICFG的节点，确定是否存在所述可疑漏洞点，若存在，则将所述可疑漏洞点确定为可达漏洞点，并将所述项目的入口到所述可达漏洞点之间的路径确定为可达路径。
可选地，所述确定可能触发所述可疑漏洞的风险参数是否能传递到与所述可疑漏洞对应的漏洞函数，包括：
对所述可达漏洞点生成数据依赖图DDG；
基于所述数据依赖图DDG确定传入所述可达漏洞点的实际参数集合；
确定所述实际参数集合中是否存在所述风险参数，若是，则说明触发所述可疑漏洞需要的风险参数能传递到所述漏洞函数。
可选地，所述检测是否存在从所述项目的入口到与所述可疑漏洞对应的漏洞函数的调用语句之间的可达路径，包括：
定位所述项目中所有的与所述可疑漏洞对应的漏洞函数的调用语句，标记为可疑漏洞点；
利用符号执行工具获取从所述项目的入口到所述可疑漏洞点的路径约束集合；
对所述路径约束集合进行约束求解，若存在有解的路径约束，则将所述有解的路径约束对应的路径确定为可达路径，并获取与所述可达路径对应的具体输入集合。
可选地，所述确定可能触发所述可疑漏洞的风险参数是否能传递到与所述可疑漏洞对应的漏洞函数，包括：
确定所述具体输入集合中是否存在所述风险参数，若是，则说明触发所述可疑漏洞需要的风险参数能传递到所述漏洞函数。
在本公开的第二方面中，提供了一种组件漏洞分析装置，包括：
漏洞数据库构建模块，用于构建漏洞数据库，所述漏洞数据库中存储有第三方组件包含的已知漏洞、与所述已知漏洞对应的漏洞函数和与所述漏洞函数对应的可能触发所述已知漏洞的风险参数；
组件漏洞检测模块，用于检测项目引用的第三方组件，将所述第三方组件包含的已知漏洞确定为可疑漏洞；
可疑漏洞信息获取模块，用于从所述漏洞数据库中获取所述可疑漏洞对应的漏洞函数和与所述漏洞函数对应的可能触发所述可疑漏洞的风险参数；
可触发性分析模块，用于确定所述可疑漏洞在所述项目中是否会被触发，若所述可疑漏洞可触发，则将所述可疑漏洞确定为目标漏洞。
可选地，所述可触发性分析模块包括：
组件调用检测模块，用于确定所述可疑漏洞所在的第三方组件是否会被所述项目调用；
函数调用检测模块，用于若所述可疑漏洞所在的第三方组件会被所述项目调用，则确定与所述可疑漏洞对应的漏洞函数是否会被所述项目调用；
参数传递检测模块，用于若与所述可疑漏洞对应的漏洞函数会被所述项目调用，则确定可能触发所述可疑漏洞的风险参数是否能传递到与所述可疑漏洞对应的漏洞函数，若是，则将所述可疑漏洞确定为目标漏洞。
本公开的实施例提供的技术方案可以有以下有益效果：
通过构建含有丰富漏洞信息的漏洞数据库，特别是在存储漏洞基本信息的基础上，还收集了漏洞函数信息、可能触发漏洞的风险参数信息，存储了更细粒度的漏洞特征，并基于此对检测出的第三方组件漏洞进行可触发性分析，分析待测项目是否实际具备漏洞触发的必需条件，从而能够将不可触发的漏洞过滤掉或者标记为低优先级，大大减少了无效漏洞的报告，避免SCA用户面对海量的组件漏洞报告而消耗过多的资源和精力。
应当理解，发明内容部分中所描述的内容并非旨在限定本公开的实施例的关键或重要特征，亦非用于限制本公开的范围。本公开的其它特征将通过以下的描述变得容易理解。
附图说明
为了更清楚地说明本公开实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单的介绍，显而易见地，下面描述中的附图仅仅是本公开的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图示出的结构获得其他的附图。
图1为根据一示例性实施例示出的一种组件漏洞分析方法的流程图；
图2为根据一示例性实施例示出的一种组件漏洞分析方法的流程图；
图3为根据一示例性实施例示出的一种组件漏洞分析方法的流程图；
图4为根据一示例性实施例示出的一种组件漏洞分析方法的流程图；
图5为根据一示例性实施例示出的一种组件漏洞分析装置的结构示意图；
图6为根据一示例性实施例示出的一种组件漏洞分析装置的结构示意图；
图7为根据一示例性实施例示出的一种电子设备的结构示意图。
具体实施方式
下面将参照附图更详细地描述本公开的实施例。虽然附图中显示了本公开的某些实施例，然而应当理解的是，本公开可以通过各种形式来实现，而且不应该被解释为限于这里阐述的实施例，相反提供这些实施例是为了更加透彻和完整地理解本公开。应当理解的是，本公开的附图及实施例仅用于示例性作用，并非用于限制本公开的保护范围。
在本公开的实施例的描述中术语“包括”及其类似用语应当理解为开放性包含，即“包括但不限于”。术语“基于”应当理解为“至少部分地基于”。术语“一个实施例”或“该实施例”应当理解为“至少一个实施例”。术语“第一”、“第二”等等可以指代不同的或相同的对象。下文还可能包括其他明确的和隐含的定义。
现有的SCA工具对项目引用的第三方组件进行检测后，直接将第三方组件中包含的已知漏洞全部报告出来。然而，项目引用了含有漏洞的第三方组件并不必然引入了漏洞。如果希望获得更细粒度的漏洞检测结果，有必要在基于组件识别关联出已知漏洞后，分析项目中是否实际存在已知漏洞、漏洞是否会被触发，从而过滤掉实际不存在或者不会被触发的漏洞。
在本公开的实施例的描述中，“可触发性分析”是指分析某一漏洞在待测项目中是否有可能被触发，或者说，分析某一漏洞的触发条件在待测项目中能否被满足。根据漏洞原理，漏洞所在的函数、传入漏洞函数的参数是触发漏洞的关键要素，因此在进行可触发性分析时，漏洞函数、传入漏洞函数的参数是重点关注对象。
实施例一：
参照图1，本公开的实施例提出了一种组件漏洞分析方法，包括步骤S101-S104：
S101：构建漏洞数据库，所述漏洞数据库中存储有第三方组件包含的已知漏洞、与所述已知漏洞对应的漏洞函数和与所述漏洞函数对应的可能触发所述已知漏洞的风险参数；
具体地，漏洞数据库是进行组件漏洞检测和分析的基础，漏洞数据库内容的丰富程度将直接影响SCA的检测能力。构建漏洞数据库需要在网络上收集大量的漏洞信息。漏洞信息的来源包括但不限于NVD（National Vulnerability Database, 美国国家漏洞库）、CNVD（China National Vulnerability Database, 国家信息安全漏洞共享平台）、CNNVD（China National Vulnerability Database of Information Security, 中国国家信息安全漏洞库）、GitHub-GHSA等通用漏洞数据库，以及安全邮件列表等站点、软件风险相关的新闻资讯和RSS订阅，甚至还可以手工录入一些最新的漏洞信息。
在本公开的实施例中，可以收集以下漏洞信息：
漏洞基本信息：漏洞基本信息包括但不限于CVE编号、CWE信息、漏洞描述等。其中，CVE(Common Vulnerabilities & Exposures, 通用漏洞披露)编号是一个通用的漏洞ID，CWE(Common Weakness Enumeration, 通用缺陷枚举)信息表示了漏洞缺陷的种类，漏洞描述包含漏洞的技术细节描述。
漏洞函数信息：漏洞函数是指容易出现漏洞的函数，在一些漏洞的漏洞描述里可以直接找到漏洞函数；如果无法直接获取漏洞函数，则可以通过解析公开的漏洞patch补丁、poc(proof of concept)文件等来提取漏洞函数。其中，poc文件以Exploit-DB漏洞利用库、Seebug漏洞平台等为数据来源。对于每一个CVE漏洞，可能涉及一个或多个漏洞函数，为进行更准确的漏洞可触发性分析，需要尽可能全面地收集漏洞涉及的所有漏洞函数，将其以集合或列表的形式存储起来。每一个漏洞函数的信息包括但不限于函数名、函数形参。
与漏洞函数对应的可能触发漏洞的风险参数信息：当可能触发漏洞的风险参数作为实参传递给了漏洞函数的形参时，便会导致漏洞函数的运行，从而导致漏洞被触发。因此，提前收集可能触发漏洞的风险参数对于对漏洞可触发性的分析也有着重要作用。收集可能触发漏洞的风险参数信息依赖于对漏洞原理和漏洞技术细节信息的收集，包括对漏洞源代码、漏洞补丁或者poc/exp文件的解析。可能触发某一漏洞的风险参数可能不只一个，可以将风险参数集合或列表的形式存储起来。还可以针对漏洞函数的每一个形参分别收集可能触发漏洞的风险参数，构建出风险参数集合或列表与漏洞函数的形参的对应关系。当然，并非漏洞函数的每一个形参均会传入可能触发漏洞的实参，可能触发漏洞的输入有时仅仅是针对漏洞函数的某一个形参。
在本公开的实施例中，收集漏洞信息主要依靠爬虫技术、网页分析技术和自然语言处理技术。相关的具体实现方法系现有技术，且不是本公开的重点，故不加以详述。
在本公开的实施例中，对于收集到的漏洞信息，需要对漏洞信息进行去重、校验正确性，然后将不同维度的漏洞信息进行关联。例如，可以构造出漏洞-漏洞函数-函数形参-可能触发漏洞的风险参数的映射。
在本公开的实施例中，漏洞数据库可以是以CVE编号为索引，每一个CVE漏洞关联了其所在的第三方组件名称和版本号，以及该漏洞的基本信息、漏洞函数信息和漏洞函数的风险参数信息；也可以是以第三方组件为索引，每一特定版本的第三方组件关联了其包含的多个CVE漏洞，而每一个CVE漏洞关联了该漏洞的基本信息、漏洞函数信息和漏洞函数的风险参数信息。漏洞数据库可以采用各类数据库结构实现，但不作为限制。
在本公开的实施例中，除了构建漏洞数据库之外，还可以构建第三方组件信息库，用于存储所有第三方组件的相关信息，并与漏洞数据库建立映射关系。在检测出项目引用的第三方组件后，可以基于第三方组件信息库与漏洞数据库之间的映射关系，确定出项目因引用第三方组件而可能引入的所有已知漏洞。
在本公开的实施例中，还可以对漏洞数据库进行定期或实时的更新，将最新发布的漏洞及时更新入库，能够有效保障漏洞数据的更新速度和实时性。
通过构建含有丰富漏洞信息的漏洞数据库，特别是在存储漏洞基本信息的基础上，还收集了漏洞函数信息、可能触发漏洞的风险参数信息，存储了更细粒度的漏洞特征，为组件漏洞的可触发性分析奠定了基础，能够帮助SCA工具实现更细粒度的漏洞检测功能。
S102：检测项目引用的第三方组件，将所述第三方组件包含的已知漏洞确定为可疑漏洞；
具体地，检测项目引用的第三方组件的方法可以是通过对项目的组件依赖管理文件进行解析。例如，通过解析pom文件来获得jar包的开源组织名、jar包名称、版本号和哈希值等标识内容。检测项目引用的第三方组件的方法也可以是对项目进行特征比对，从预先构建的第三方组件库中匹配出项目所引用的第三方组件。例如，对项目中的每一个文件进行哈希计算，通过在第三方组件库中进行指纹匹配确定引用的第三方组件，还可以从目录结构等多个维度提取项目文件特征来进行第三方组件的识别。本公开对检测项目引用的第三方组件的具体方式不予以限制。
在检测出项目引用的第三方组件之后，可以通过组件名称、组件版本号或者组件哈希值等特征从漏洞数据库中查询出项目引用的第三方组件所包含的已知漏洞，将这些已知漏洞确定为可疑漏洞。
在本公开的实施例中，基于预先收集的第三方组件包含的已知漏洞信息，通过识别项目引用的第三方组件来确定项目中可能存在的已知漏洞，能够对项目进行初步的风险分析，实现粗粒度的漏洞检测。
S103：从所述漏洞数据库中获取与所述可疑漏洞对应的漏洞函数和与所述漏洞函数对应的可能触发所述可疑漏洞的风险参数；
具体地，对于通过步骤S102确定的可疑漏洞，可以从漏洞数据库中获取到对应的漏洞函数信息、与漏洞函数对应的可能触发可疑漏洞的风险参数信息。可以通过漏洞数据库中存储的CVE编号索引到相关信息，也可以通过漏洞数据库中存储的第三方组件特征索引到相关信息。
通过从漏洞数据库中提取可疑漏洞对应的漏洞函数信息、与漏洞函数对应的可能触发可疑漏洞的风险参数信息，为下一步的漏洞可触发性分析提供了数据基础。
S104：确定所述可疑漏洞在所述项目中是否会被触发，若所述可疑漏洞可触发，则将所述可疑漏洞确定为目标漏洞。
具体地，基于步骤S103中获取到的数据，确定所述可疑漏洞在所述项目中是否会被触发。触发漏洞需要满足一定的触发条件。根据漏洞原理，漏洞所在的函数、传入漏洞函数的参数是触发漏洞的关键要素。因此，利用预先收集到的可疑漏洞的漏洞函数信息、与漏洞函数对应的可能触发可疑漏洞的风险参数信息，可以分析项目是否实际具备触发可疑漏洞的必需条件。如果所述可疑漏洞在所述项目中是可以触发的，则将其确定为目标漏洞，而如果所述可疑漏洞在所述项目中不可触发，则将其排除，或者将其标记为不可触发的漏洞或低优先级的漏洞。
在本公开的实施例中，基于预先收集、存储在漏洞数据库中的与可疑漏洞对应的漏洞函数信息和与漏洞函数对应的可能触发可疑漏洞的风险参数信息，分析待测项目是否实际具备触发可疑漏洞的必需条件，仅当可疑漏洞可触发时，才将可疑漏洞确定为目标漏洞，从而能够将不可触发的可疑漏洞过滤掉或者标记为低优先级，大大减少了无效漏洞的报告，避免SCA用户面对海量的组件漏洞报告而消耗过多的资源和精力。
具体地，图2为本公开的实施例提供的确定可疑漏洞是否会被触发的方法流程图。参照图2，确定所述可疑漏洞在所述项目中是否会被触发包括步骤S401-S403：
S401：确定所述可疑漏洞所在的第三方组件是否会被所述项目调用；
具体地，首先要确定所述可疑漏洞所在的第三方组件会被所述项目调用，这是可疑漏洞可触发的必备条件之一。因为，当前的应用开发迭代速度较快且模块化程度较高，开发人员很难细致地审查代码的精简程度与相互之间的严谨性，通过步骤S102识别出的项目引用的第三方组件，并不一定会在项目实际运行时被调用。
在本公开的实施例中，确定所述可疑漏洞所在的第三方组件是否会被所述项目调用，可以通过以下方法来实现：检测所述项目的源代码中是否存在所述第三方组件的加载语句；若存在，则确定所述可疑漏洞所在的第三方组件会被所述项目调用。
具体地，将检测可疑漏洞所在的第三方组件是否会被项目实际调用放在对可疑漏洞进行可触发性分析的第一步，是因为第三方组件被调用是可疑漏洞在项目中会被触发的最基础的条件。若第三方组件根本不会被项目调用，则无需进行后续的分析判断，可以直接将相应的可疑漏洞排除，或者将其标记为不可触发的漏洞或低优先级的漏洞。若第三方组件会被项目调用，则进入下一步。
通过检测项目源代码中是否存在第三方组件的加载语句，可以确认项目是否实际会调用第三方组件，即是否具备引入第三方组件所包含的漏洞的前提；且将此步骤放在可疑漏洞可触发性分析的第一步，可以首先过滤掉一部分由于组件未被项目调用而不具备可触发性的可疑漏洞；同时还可以验证步骤S102对项目引用的第三方组件进行识别的准确性，排除错误识别的情形。
S402：若所述可疑漏洞所在的第三方组件会被所述项目调用，则确定与所述可疑漏洞对应的漏洞函数是否会被所述项目调用；
具体地，在确定所述可疑漏洞所在的第三方组件会被所述项目调用之后，可以进一步确定与所述可疑漏洞对应的漏洞函数是否会被所述项目调用。因为漏洞往往仅由一个或几个函数引入到第三方组件中，所以也存在开发人员在进行项目开发时引入了含有漏洞的第三方组件却没有直接或间接地调用引入漏洞的函数的情况，这就意味着即使项目实际调用了第三方组件却没有调用漏洞函数，也就是说，项目并未引入漏洞，漏洞不会被触发。
通过分析项目是否调用了可疑漏洞对应的漏洞函数，可以进一步过滤掉一部分由于项目仅调用了部分组件但未调用组件中存在漏洞的函数而不具备可触发性的可疑漏洞，由此能够进一步减少无效漏洞的报告。
在本公开的实施例中，所述确定与所述可疑漏洞对应的漏洞函数是否会被所述项目调用，可以通过以下方法来实现：
检测所述项目的源代码中是否存在与所述可疑漏洞对应的漏洞函数的调用语句；若不存在，则确定与所述可疑漏洞对应的漏洞函数不会被所述项目调用；若存在，则检测是否存在从所述项目的入口到与所述可疑漏洞对应的漏洞函数的调用语句之间的可达路径；若存在所述可达路径，则确定与所述可疑漏洞对应的漏洞函数会被所述项目调用。
具体地，首先确定项目的源代码中是否存在可疑漏洞对应的漏洞函数的调用语句。第三方组件中通常封装了一些函数的实现逻辑，并对外提供了调用这些函数的接口。因此，若项目调用了第三方组件的函数，在项目的源代码中可以找到这些函数的调用语句，调用语句中则包含有相应的函数名称。
在本公开的实施例中，预先构建的漏洞数据库存储了可疑漏洞对应的漏洞函数信息，漏洞函数信息包括但不限于漏洞函数的名称，因此可以通过匹配函数名称来检测项目源代码中是否存在可疑漏洞的漏洞函数的调用语句。如果不存在，则说明项目未调用与所述可疑漏洞对应的漏洞函数，也就是说，项目并未引入所述可疑漏洞，无需再进行后续的分析判断，可以直接将相应的可疑漏洞排除，或者将其标记为不可触发的漏洞或低优先级的漏洞；如果存在，则可进一步检测是否存在从项目入口到漏洞函数调用语句之间的可达路径。
检测是否存在从项目入口到漏洞函数调用语句之间的可达路径，可以针对漏洞函数调用语句进行程序路径可达性分析。程序路径是程序中顺序执行的一个语句序列。在一个程序中，从一条语句到另一条语句之间，可能存在多个语句序列，但并非每个序列都是可达的。对于给定的目标路径，若任何输入都不能覆盖该路径，该路径称为不可达的。因此，从一个项目入口到一条漏洞函数调用语句之间可能存在多条程序路径，本公开将从中检测是否存在可达的程序路径。此外，一个项目还可能存在多个项目入口，一个可疑漏洞也可能涉及多个漏洞函数，因此，需要从多个项目入口到多个漏洞函数调用语句之间查找是否存在可达的程序路径。只要存在一条路径是可达的，就意味着漏洞函数会被项目调用。
在对漏洞函数调用位置进行路径可达性分析之前，首先确定项目源代码中存在漏洞函数调用语句，如果源代码中根本不存在对漏洞函数的调用语句，则漏洞不存在，也无须进行下一步的路径可达性分析。通过对漏洞函数所在位置进行路径可达性分析，可以确定项目执行路径能否到达漏洞函数所在位置，从而确定漏洞函数是否会被项目调用，进一步过滤掉一部分由于项目仅调用了部分组件但未调用组件中存在漏洞的函数而不具备可触发性的可疑漏洞，由此能够进一步减少无效漏洞的报告。
在本公开的实施例中，提供了一种基于控制流分析对漏洞函数调用语句进行路径可达性分析的具体实施方式。参照图3，包括步骤S4021-S4023：
S4021：定位所述项目中所有的与所述可疑漏洞对应的漏洞函数的调用语句，标记为可疑漏洞点；
具体地，在一个项目中，可能会有多个位置出现同一漏洞函数的调用语句，或者会出现同一可疑漏洞对应的多个漏洞函数的调用语句，只要是存在漏洞函数调用语句的位置，都是可能触发可疑漏洞的位置，因此均标记为可疑漏洞点。
例如，可以将可疑漏洞点标记为si，将一个项目所有的可疑漏洞点存入集合S={si}。
S4022：对所述项目的入口生成过程间控制流图ICFG；
具体地，在静态程序分析中，控制流图(Control Flow Graph, CFG)通过一个有向图来表示程序的控制流。CFG中的节点表示程序的基本块，有向边表示两个基本块可以从前一个基本块跳转到后一个基本块。控制流图显示了程序执行过程中可以遍历的所有路径。调用图(Call Graph, CG)是表示程序中函数之间调用关系的有向图。CG中的每个节点对应于一个函数。过程间控制流图(Inter-procedural Control Flow Graph, ICFG)则组合了CFG和CG。ICFG具有单一入口、单一出口的特性，当项目存在多个可能的入口时，需要对多个项目入口分别生成ICFG。
例如，可以将对多个项目入口生成的ICFG存入一个集合G，G={gk(V, E)}，其中V为节点集，E为边集。
S4023：遍历所述过程间控制流图ICFG的节点，确定是否存在所述可疑漏洞点，若存在，则将所述可疑漏洞点确定为可达漏洞点，并将所述项目的入口到所述可达漏洞点之间的路径确定为可达路径。
具体地，可以采用图路径搜索等算法遍历ICFG中的节点。如果存在可疑漏洞点，则将其确定为可达漏洞点，并获得从项目入口到可达漏洞点之间的路径；如果所有的ICFG的节点中都不存在可疑漏洞点，则说明从项目入口到可疑漏洞点之间不存在可达路径，可疑漏洞的漏洞函数不会被项目调用。
例如，遍历ICFG集合G，对于每个ICFG的gk(V, E)，如果∃x，使x∈S且x∈V，则x为可达漏洞点，从x所在的ICFG中确定从项目入口到x所在位置的可达路径xpath。
通过结合静态程序分析技术中的控制流分析，能够遍历程序执行路径，从中确定是否存在调用漏洞函数的可达路径，从而确定项目是否会实际调用可疑漏洞的漏洞函数，进一步过滤掉一部分由于项目仅调用了部分组件但未调用组件中存在漏洞的函数而不具备可触发性的可疑漏洞，由此能够进一步减少无效漏洞的报告。
在本公开的实施例中，还提供了一种基于符号执行对漏洞函数调用位置进行路径可达性分析的具体实施方式。参照图4，包括步骤S4024-S4026：
S4024：定位所述项目中所有的与所述可疑漏洞对应的漏洞函数的调用语句，标记为可疑漏洞点；
具体地，在一个项目中，可能会有多个位置出现同一漏洞函数的调用语句，或者会出现同一可疑漏洞对应的多个漏洞函数的调用语句，只要是存在漏洞函数调用语句的位置，都是可能触发可疑漏洞的位置，因此均标记为可疑漏洞点。
例如，可以将可疑漏洞点标记为si，将一个项目所有的可疑漏洞点存入集合S={si}。
S4025：利用符号执行工具获取从所述项目的入口到所述可疑漏洞点的路径约束集合；
具体地，符号执行(Symbolic Execution)是一种程序分析技术，它可以通过分析程序来得到让特定代码区域执行的输入。符号执行以符号值作为输入来执行程序，而非一般执行程序时使用的具体值。符号值的引入使得程序执行到路径分支时无法确定程序的走向，因此需要引入路径约束PC(Path Constraint)，它是指符号执行过程中对路径上条件分支走向的选择情况，根据PC的内容即可确定一条唯一的程序执行路径(Execution Path)。PC是一个布尔表达式，由符号执行路径上涉及的if条件语句中的表达式及表达式的真值选择拼接而成。符号执行工具包括但不限于一些开源的符号执行工具，例如KLEE等，本公开对此不作具体限制。
利用符号执行工具可以遍历从项目入口到可疑漏洞点si之间的所有执行路径，获得一个路径约束集合。当项目中存在多个项目入口时，符号执行工具需要遍历从任一项目入口到任一可疑漏洞点si之间的执行路径。在该路径约束集合中，每一个路径约束都是一个布尔表达式，都唯一对应着一条从一个项目入口到一个可疑漏洞点之间的执行路径。
S4026：对所述路径约束集合进行约束求解，若存在有解的路径约束，则将所述有解的路径约束对应的路径确定为可达路径，并获取与所述可达路径对应的具体输入集合。
具体地，在符号执行运行结束后，可将获得路径约束集合输入约束求解器，对路径约束集合进行求解，以确定相应的路径是否可达。若某一路径约束可解，则说明该路径是可达的，且所求出的解即为能够使程序按该路径执行的具体输入集合；若某一路径约束无解，则说明该路径不可达。约束求解可以简单地理解为解方程，有很多开源的约束求解器，例如Z3等，本公开对此不作具体限制。
利用符号执行工具可以遍历从项目入口到可疑漏洞位置之间的所有执行路径，并通过约束求解器确定其中的可达路径，从而确定与可疑漏洞对应的漏洞函数是否会被项目调用，进一步过滤掉一部分由于项目仅调用了部分组件但未调用组件中存在漏洞的函数而不具备可触发性的可疑漏洞，由此能够进一步减少无效漏洞的报告。
S403：若与所述可疑漏洞对应的漏洞函数会被所述项目调用，则确定可能触发所述可疑漏洞的风险参数是否能传递到与所述可疑漏洞对应的漏洞函数，若是，则将所述可疑漏洞确定为目标漏洞。
具体地，在确定与所述可疑漏洞对应的漏洞函数会被所述项目调用之后，还可以进一步确定可能触发所述可疑漏洞的风险参数是否能传递到与所述可疑漏洞对应的漏洞函数。当可能触发可疑漏洞的风险参数作为实参传递给了漏洞函数的形参时，便会导致漏洞函数的运行，从而导致可疑漏洞被触发。基于步骤S103从漏洞数据库中获取到的与所述漏洞函数对应的可能触发所述可疑漏洞的风险参数，分析其是否能传递到相应的漏洞函数，如果可以传递到，则会触发漏洞。
在确定项目会对漏洞函数进行调用之后，仍然不能确定可疑漏洞在项目中会被触发，因此本公开还对漏洞函数的传入参数进行了分析，基于预先收集、存储到漏洞数据库中的可能触发可疑漏洞的风险参数信息，可进一步过滤掉即使组件会被调用、漏洞函数会被调用但由于风险参数不会传入漏洞函数而不具备可触发性的可疑漏洞，由此能更进一步地减少无效漏洞的报告，实现更精细的第三方组件漏洞检测。
本公开的实施例提供了一种基于控制流分析和数据依赖分析确定风险参数能否传递到漏洞函数的具体实施方式。
具体地，在前述步骤S4023从过程间控制流图ICFG中确定出可达漏洞点之后：对所述可达漏洞点生成数据依赖图DDG；基于所述数据依赖图DDG确定传入所述可达漏洞点的实际参数集合；确定所述实际参数集合中是否存在所述风险参数，若是，则说明触发所述可疑漏洞需要的风险参数能传递到所述漏洞函数。
数据流分析(Data Flow Analysis)是一种用来获取相关数据沿着程序执行路径流动的信息分析技术，分析对象是程序执行路径上的数据流动或可能的取值。数据依赖图(Data Dependence Graph, DDG)在数据流分析中应用非常广泛，它是一种表示程序语句或基本块间数据依赖关系的有向图。通过生成DDG，可以分析程序中某一特定位置附近传入、传出的数据，进行数据流追踪。
对于从ICFG中确定出的可达漏洞点，可以生成包含可达漏洞点的DDG；可选地，可以先基于可达漏洞点所在的ICFG生成相应的过程间数据流图(Inter-procedural DataFlow Graph, IDFG)，进而生成DDG。生成DDG的具体方法属于现有技术，本公开对此不加以限制。
在DDG中可以从可达漏洞点所在位置回溯，确定传入所述可达漏洞点的实际参数集合，然后基于从漏洞数据库中获取到的可能触发所述可疑漏洞的风险参数，判断该实际参数集合中是否存在风险参数，若存在，则说明触发所述可疑漏洞需要的风险参数能传递到所述漏洞函数。
在基于控制流分析方法确定了可达漏洞点之后，进一步基于数据依赖分析追踪传入可达漏洞点的数据，进而确定可能触发所述可疑漏洞的风险参数能否传入相应的漏洞函数，可进一步过滤掉即使组件会被调用、漏洞函数会被调用但由于风险参数不会传入漏洞函数而不具备可触发性的可疑漏洞，由此能更进一步地减少无效漏洞的报告，实现更精细的第三方组件漏洞检测。
本公开的实施例还提供了一种基于符号执行和约束求解确定风险参数能否传递到漏洞函数的具体实施方式。
具体地，在前述步骤S4026利用约束求解器确定出从项目入口到与可疑漏洞对应的漏洞函数的调用语句之间的可达路径和与可达路径对应的具体输入集合之后：确定所述具体输入集合中是否存在所述风险参数，若是，则说明触发所述可疑漏洞需要的风险参数能传递到所述漏洞函数。
基于从漏洞数据库中获取到的可能触发所述可疑漏洞的风险参数，判断该具体输入集合中是否存在风险参数，若存在，则说明触发所述可疑漏洞需要的风险参数能传递到所述漏洞函数。
通过符号执行和约束求解，在确定可达路径之后能够直接解出可达路径对应的具体输入集合，进而确定可能触发所述可疑漏洞的风险参数能否传入相应的漏洞函数，可进一步过滤掉即使组件会被调用、漏洞函数会被调用但由于风险参数不会传入漏洞函数而不具备可触发性的可疑漏洞，由此能更进一步地减少无效漏洞的报告，实现更精细的第三方组件漏洞检测。
实施例二：
参照图5，本公开的实施例提出了一种组件漏洞分析装置500，包括如下模块：
漏洞数据库构建模块510，用于构建漏洞数据库，所述漏洞数据库中存储有第三方组件包含的已知漏洞、与所述已知漏洞对应的漏洞函数和与所述漏洞函数对应的可能触发所述已知漏洞的风险参数；
组件漏洞检测模块520，用于检测项目引用的第三方组件，将所述第三方组件包含的已知漏洞确定为可疑漏洞；
可疑漏洞信息获取模块530，用于从所述漏洞数据库中获取所述可疑漏洞对应的漏洞函数和与所述漏洞函数对应的可能触发所述可疑漏洞的风险参数；
可触发性分析模块540，用于确定所述可疑漏洞在所述项目中是否会被触发，若所述可疑漏洞可触发，则将所述可疑漏洞确定为目标漏洞。
其中，参照图6，可触发性分析模块540包括：
组件调用检测模块541，用于确定所述可疑漏洞所在的第三方组件是否会被所述项目调用；
函数调用检测模块542，用于若所述可疑漏洞所在的第三方组件会被所述项目调用，则确定与所述可疑漏洞对应的漏洞函数是否会被所述项目调用；
参数传递检测模块543，用于若与所述可疑漏洞对应的漏洞函数会被所述项目调用，则确定可能触发所述可疑漏洞的风险参数是否能传递到与所述可疑漏洞对应的漏洞函数，若是，则将所述可疑漏洞确定为目标漏洞。
实施例三：
参照图7，本公开的实施例还提出了一种电子设备600，该电子设备600包括至少一个处理器610；以及，与所述至少一个处理器610通信连接的存储器620；其中，所述存储器620存储有可被所述至少一个处理器610执行的指令，所述指令被所述至少一个处理器610执行，以使所述至少一个处理器610能够执行本公开的实施例所述的组件漏洞分析方法。
上述电子设备600中的上述元件可通过总线彼此连接，总线例如数据总线、地址总线、控制总线、扩展总线和局部总线之一或其任意组合。
实施例四：
本公开的实施例还提出了一种存储介质，其上存储有计算机程序，该程序被处理器执行时实现如本公开的实施例所述的组件漏洞分析方法。
本领域内的技术人员应当明白，本公开的实施例可提供为方法、系统、或计算机程序产品。因此，本公开可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本公开可采用在一个或多个其中包含有计算机可用程序代码的计算机可用非瞬时性存储介质（包括但不限于磁盘存储器、CD-ROM、光学存储器等）上实施的计算机程序产品的形式。
本公开是参照根据本公开的实施例的方法、装置、设备和计算机程序产品的流程图和/或方框图来描述的。应理解为可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
以上所述仅为本公开的较佳实施例，并不用以限制本公开，凡在本公开的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本公开的保护范围之内。

Claims (12)

1.一种组件漏洞分析方法，其特征在于，包括：
构建漏洞数据库，所述漏洞数据库中存储有第三方组件包含的已知漏洞、与所述已知漏洞对应的漏洞函数和与所述漏洞函数对应的可能触发所述已知漏洞的风险参数；
检测项目引用的第三方组件，将所述第三方组件包含的已知漏洞确定为可疑漏洞；
从所述漏洞数据库中获取与所述可疑漏洞对应的漏洞函数和与所述漏洞函数对应的可能触发所述可疑漏洞的风险参数；
确定所述可疑漏洞在所述项目中是否会被触发，若所述可疑漏洞可触发，则将所述可疑漏洞确定为目标漏洞。
2.如权利要求1所述的方法，其特征在于，所述确定所述可疑漏洞在所述项目中是否会被触发，若所述可疑漏洞可触发，则将所述可疑漏洞确定为目标漏洞，包括：
确定所述可疑漏洞所在的第三方组件是否会被所述项目调用；
若所述可疑漏洞所在的第三方组件会被所述项目调用，则确定与所述可疑漏洞对应的漏洞函数是否会被所述项目调用；
若与所述可疑漏洞对应的漏洞函数会被所述项目调用，则确定可能触发所述可疑漏洞的风险参数是否能传递到与所述可疑漏洞对应的漏洞函数，若是，则将所述可疑漏洞确定为目标漏洞。
3.如权利要求2所述的方法，其特征在于，所述确定所述可疑漏洞所在的第三方组件是否会被所述项目调用，包括：
检测所述项目的源代码中是否存在所述第三方组件的加载语句；若存在，则确定所述可疑漏洞所在的第三方组件会被所述项目调用。
4.如权利要求2所述的方法，其特征在于，所述确定与所述可疑漏洞对应的漏洞函数是否会被所述项目调用，包括：
检测所述项目的源代码中是否存在与所述可疑漏洞对应的漏洞函数的调用语句；若不存在，则确定与所述可疑漏洞对应的漏洞函数不会被所述项目调用；若存在，则检测是否存在从所述项目的入口到与所述可疑漏洞对应的漏洞函数的调用语句之间的可达路径；
若存在所述可达路径，则确定与所述可疑漏洞对应的漏洞函数会被所述项目调用。
5.如权利要求4所述的方法，其特征在于，所述检测是否存在从所述项目的入口到与所述可疑漏洞对应的漏洞函数的调用语句之间的可达路径，包括：
定位所述项目中所有的与所述可疑漏洞对应的漏洞函数的调用语句，标记为可疑漏洞点；
对所述项目的入口生成过程间控制流图ICFG；
遍历所述过程间控制流图ICFG的节点，确定是否存在所述可疑漏洞点，若存在，则将所述可疑漏洞点确定为可达漏洞点，并将所述项目的入口到所述可达漏洞点之间的路径确定为可达路径。
6.如权利要求5所述的方法，其特征在于，所述确定可能触发所述可疑漏洞的风险参数是否能传递到与所述可疑漏洞对应的漏洞函数，包括：
对所述可达漏洞点生成数据依赖图DDG；
基于所述数据依赖图DDG确定传入所述可达漏洞点的实际参数集合；
确定所述实际参数集合中是否存在所述风险参数，若是，则说明触发所述可疑漏洞需要的风险参数能传递到所述漏洞函数。
7.如权利要求4所述的方法，其特征在于，所述检测是否存在从所述项目的入口到与所述可疑漏洞对应的漏洞函数的调用语句之间的可达路径，包括：
定位所述项目中所有的与所述可疑漏洞对应的漏洞函数的调用语句，标记为可疑漏洞点；
利用符号执行工具获取从所述项目的入口到所述可疑漏洞点的路径约束集合；
对所述路径约束集合进行约束求解，若存在有解的路径约束，则将所述有解的路径约束对应的路径确定为可达路径，并获取与所述可达路径对应的具体输入集合。
8.如权利要求7所述的方法，其特征在于，所述确定可能触发所述可疑漏洞的风险参数是否能传递到与所述可疑漏洞对应的漏洞函数，包括：
确定所述具体输入集合中是否存在所述风险参数，若是，则说明触发所述可疑漏洞需要的风险参数能传递到所述漏洞函数。
9.一种组件漏洞分析装置，其特征在于，包括：
漏洞数据库构建模块，用于构建漏洞数据库，所述漏洞数据库中存储有第三方组件包含的已知漏洞、与所述已知漏洞对应的漏洞函数和与所述漏洞函数对应的可能触发所述已知漏洞的风险参数；
组件漏洞检测模块，用于检测项目引用的第三方组件，将所述第三方组件包含的已知漏洞确定为可疑漏洞；
可疑漏洞信息获取模块，用于从所述漏洞数据库中获取所述可疑漏洞对应的漏洞函数和与所述漏洞函数对应的可能触发所述可疑漏洞的风险参数；
可触发性分析模块，用于确定所述可疑漏洞在所述项目中是否会被触发，若所述可疑漏洞可触发，则将所述可疑漏洞确定为目标漏洞。
10.如权利要求9所述的装置，其特征在于，所述可触发性分析模块包括：
组件调用检测模块，用于确定所述可疑漏洞所在的第三方组件是否会被所述项目调用；
函数调用检测模块，用于若所述可疑漏洞所在的第三方组件会被所述项目调用，则确定与所述可疑漏洞对应的漏洞函数是否会被所述项目调用；
参数传递检测模块，用于若与所述可疑漏洞对应的漏洞函数会被所述项目调用，则确定可能触发所述可疑漏洞的风险参数是否能传递到与所述可疑漏洞对应的漏洞函数，若是，则将所述可疑漏洞确定为目标漏洞。
11.一种电子设备，其特征在于，包括：至少一个处理器；以及，与所述至少一个处理器通信连接的存储器；其中，所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够执行如权利要求1-8任一项所述的组件漏洞分析方法。
12.一种存储介质，存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现权利要求1-8任一项所述的组件漏洞分析方法。
CN202210953667.8A 2022-08-10 2022-08-10 一种组件漏洞分析方法、装置、电子设备及存储介质 Pending CN115033892A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202210953667.8A CN115033892A (zh) 2022-08-10 2022-08-10 一种组件漏洞分析方法、装置、电子设备及存储介质

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202210953667.8A CN115033892A (zh) 2022-08-10 2022-08-10 一种组件漏洞分析方法、装置、电子设备及存储介质

Publications (1)

Publication Number Publication Date
CN115033892A true CN115033892A (zh) 2022-09-09

Family

ID=83131200

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202210953667.8A Pending CN115033892A (zh) 2022-08-10 2022-08-10 一种组件漏洞分析方法、装置、电子设备及存储介质

Country Status (1)

Country Link
CN (1) CN115033892A (zh)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN116032654A (zh) * 2023-02-13 2023-04-28 山东省计算中心（国家超级计算济南中心） 一种固件漏洞检测及数据安全治理方法和系统
CN116738436A (zh) * 2023-06-11 2023-09-12 苏州棱镜七彩信息科技有限公司 一种漏洞可达性分析方法、系统、计算机设备和处理器
CN117390632A (zh) * 2023-10-12 2024-01-12 杭州孝道科技有限公司 一种对第三方开源组件漏洞的检测防御方法和系统

Citations (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105553917A (zh) * 2014-10-28 2016-05-04 腾讯科技（深圳）有限公司 一种网页漏洞的检测方法和系统
CN107944278A (zh) * 2017-12-11 2018-04-20 北京奇虎科技有限公司 一种内核漏洞检测方法及装置
CN108763928A (zh) * 2018-05-03 2018-11-06 北京邮电大学 一种开源软件漏洞分析方法、装置和存储介质
US20190147168A1 (en) * 2017-11-15 2019-05-16 Korea Internet & Security Agency Method and apparatus for identifying security vulnerability in binary and location of cause of security vulnerability
CN111191243A (zh) * 2019-08-15 2020-05-22 腾讯科技（深圳）有限公司 一种漏洞检测方法、装置和存储介质
CN112560045A (zh) * 2020-12-11 2021-03-26 腾讯科技（深圳）有限公司 应用程序漏洞检测方法、装置、计算机设备和存储介质
CN113434870A (zh) * 2021-07-14 2021-09-24 中国电子科技网络信息安全有限公司 基于软件依赖分析的漏洞检测方法、装置、设备及介质
CN113901484A (zh) * 2021-11-19 2022-01-07 国家电网有限公司信息通信分公司 一种基于风险的漏洞管理方法和装置
CN114500043A (zh) * 2022-01-25 2022-05-13 山东省计算中心（国家超级计算济南中心） 基于同源性分析的物联网固件漏洞检测方法及系统

Patent Citations (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105553917A (zh) * 2014-10-28 2016-05-04 腾讯科技（深圳）有限公司 一种网页漏洞的检测方法和系统
US20190147168A1 (en) * 2017-11-15 2019-05-16 Korea Internet & Security Agency Method and apparatus for identifying security vulnerability in binary and location of cause of security vulnerability
CN107944278A (zh) * 2017-12-11 2018-04-20 北京奇虎科技有限公司 一种内核漏洞检测方法及装置
CN108763928A (zh) * 2018-05-03 2018-11-06 北京邮电大学 一种开源软件漏洞分析方法、装置和存储介质
CN111191243A (zh) * 2019-08-15 2020-05-22 腾讯科技（深圳）有限公司 一种漏洞检测方法、装置和存储介质
CN112560045A (zh) * 2020-12-11 2021-03-26 腾讯科技（深圳）有限公司 应用程序漏洞检测方法、装置、计算机设备和存储介质
CN113434870A (zh) * 2021-07-14 2021-09-24 中国电子科技网络信息安全有限公司 基于软件依赖分析的漏洞检测方法、装置、设备及介质
CN113901484A (zh) * 2021-11-19 2022-01-07 国家电网有限公司信息通信分公司 一种基于风险的漏洞管理方法和装置
CN114500043A (zh) * 2022-01-25 2022-05-13 山东省计算中心（国家超级计算济南中心） 基于同源性分析的物联网固件漏洞检测方法及系统

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN116032654A (zh) * 2023-02-13 2023-04-28 山东省计算中心（国家超级计算济南中心） 一种固件漏洞检测及数据安全治理方法和系统
CN116032654B (zh) * 2023-02-13 2023-06-30 山东省计算中心（国家超级计算济南中心） 一种固件漏洞检测及数据安全治理方法和系统
CN116738436A (zh) * 2023-06-11 2023-09-12 苏州棱镜七彩信息科技有限公司 一种漏洞可达性分析方法、系统、计算机设备和处理器
CN117390632A (zh) * 2023-10-12 2024-01-12 杭州孝道科技有限公司 一种对第三方开源组件漏洞的检测防御方法和系统

Similar Documents

Publication Publication Date Title
Zheng et al. D2a: A dataset built for ai-based vulnerability detection methods using differential analysis
Ren et al. Empirical evaluation of smart contract testing: What is the best choice?
Cao et al. MVD: memory-related vulnerability detection based on flow-sensitive graph neural networks
Chen et al. Learning to prioritize test programs for compiler testing
CN115033892A (zh) 一种组件漏洞分析方法、装置、电子设备及存储介质
Wen et al. Exposing library API misuses via mutation analysis
Barabanov et al. Statistics of software vulnerability detection in certification testing
CN109255240B (zh) 一种漏洞处理方法和装置
Kim et al. Software vulnerability detection methodology combined with static and dynamic analysis
Bastani et al. Interactively verifying absence of explicit information flows in Android apps
Kellogg et al. Verifying object construction
He et al. Eunomia: enabling user-specified fine-grained search in symbolically executing WebAssembly binaries
Hua et al. On the effectiveness of deep vulnerability detectors to simple stupid bug detection
Feng et al. EXPLORER: query-and demand-driven exploration of interprocedural control flow properties
CN113849817A (zh) 一种JavaScript原型链污染漏洞的检测方法及装置
Hall et al. Establishing the source code disruption caused by automated remodularisation tools
Cai et al. Abstracting program dependencies using the method dependence graph
CN117389519A (zh) 一种面向操作系统生态的函数级软件供应链构建方法
Di Nardo et al. Augmenting field data for testing systems subject to incremental requirements changes
Gao et al. Automatic buffer overflow warning validation
Jonáš et al. Gray-box fuzzing via gradient descent and Boolean expression coverage
Pashchenko Decision Support of Security Assessment of Software Vulnerabilities in Industrial Practice
Yousaf et al. Efficient Identification of Race Condition Vulnerability in C code by Abstract Interpretation and Value Analysis
Jia et al. Cargo Ecosystem Dependency-Vulnerability Knowledge Graph Construction and Vulnerability Propagation Study
Puhan et al. Program crash analysis based on taint analysis

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination