Block chain code-oriented ecological vulnerability identification method and system

Abstract

The invention discloses a block chain code-oriented ecological vulnerability identification method and system. The method comprises the following steps: capturing public chain project error information and code submission information including a mapping relationship between a chain code problem and the code submission information; filtering the mapping relationship to obtain code submission information associated with the vulnerability; extracting a vulnerability code, a patch code and a patch code title from the code submission information associated with the vulnerability, and obtaining a corresponding vulnerability type based on the patch code title; abstracting the vulnerability code, and generating a patch mode according to the vulnerability code and the patch code; for the to-be-detected chain code, obtaining related codes with potential vulnerabilities according to the abstracted vulnerability code, and obtaining patch codes in the source project corresponding to the related codes with the potential vulnerabilities by calculating the code similarity; and determining a patch code for repairing the to-be-detected chain code in the patch codes in the source project based on the patch mode. According to the invention, the property safety of users on the block chain can be protected.

Description

Technical Field

[0001] The present invention belongs to the technical field of blockchain, and proposes a method and system for identifying blockchain code ecosystem vulnerabilities. Background Art

[0002] As a distributed ledger technology, blockchain is becoming increasingly popular, especially in implementing valuable cryptocurrencies and smart contracts. However, blockchain software systems inevitably have many vulnerabilities. Although vulnerabilities in smart contracts have been widely studied, security vulnerabilities in the underlying blockchain system have rarely been explored. A 2022 study showed that in the repair records of several mainstream blockchain security patches, blockchain system-layer vulnerability repairs accounted for 62%-78% of all blockchain vulnerability incidents, but among more than 2,000 repairs, there were only 33 Ethereum public vulnerabilities with CVE numbers and only 4 Bitcoin vulnerabilities, which means that a large number of blockchain vulnerabilities were repaired only after the attack occurred. It is urgent to design a vulnerability analysis and identification solution for the blockchain system layer.

[0003] Due to the open source nature of the blockchain ecosystem, new blockchains often fork or partially reuse the code of classic blockchains. Existing studies have shown that system-level vulnerabilities in blockchains are often concentrated in highly sensitive modules related to consensus, wallets, and networks, and modules related to verification, transaction association, block association, node association, and wallet keys are more susceptible. Upon investigation, the vulnerabilities of these modules often use the same or similar vulnerability code patterns, which provides the possibility of designing vulnerability detection methods using fork propagation and code similarity. Summary of the invention

[0004] In order to overcome the shortcomings of existing detection technologies in blockchain system-level vulnerability detection, the present invention provides a blockchain code ecosystem vulnerability identification method and system for analyzing potential intrinsic security risks in basic libraries and reused codes used by blockchain, and effectively protecting the property security of users on the blockchain.

[0005] To achieve the above objectives, the technical solution of the present invention includes the following contents.

[0006] A method for identifying vulnerabilities in blockchain code ecology, the method comprising:

[0007] Capture public chain project error information and code submission information, and build an original database containing the mapping relationship between chain code problems and code submission information;

[0008] Filter the mapping relationship between chain code issues and code submission information to obtain code submission information associated with the vulnerability;

[0009] Extracting vulnerability codes, patch codes, and patch code titles from the code submission information associated with the vulnerability, and obtaining corresponding vulnerability types based on the patch code titles, thereby generating a set including vulnerability types, vulnerability codes, and patch codes;

[0010] After abstracting the vulnerability code and generating a patch pattern based on the vulnerability code and the patch code, a final vulnerability database including vulnerability types, abstracted vulnerability codes and patch patterns is generated;

[0011] For a chain code to be detected, obtain relevant code with potential vulnerabilities based on the abstract vulnerability code, and obtain patch code in the source project corresponding to the relevant code with potential vulnerabilities by calculating code similarity;

[0012] Based on the patch mode, a patch code for repairing the to-be-detected chain code is determined in the patch code in the source project.

[0013] Furthermore, the capturing of public chain project error information and code submission information, and establishing an original database containing a mapping relationship between chain code problems and code submission information, includes:

[0014] Use GitHub API to collect information about each closed issue / PR in the public chain project error information; the information about the closed issue / PR includes: issue title, issue body, comments, events, and error category labels;

[0015] Crawling all code submission information of a repository, and after determining the code submission information related to the error among all the code submission information, extracting the code submission information related to the error; wherein the code submission information includes: submission title, submission message, affected files and id / URL;

[0016] Filter out closed issues / PRs without patch submission information;

[0017] Based on the event information of the closed issue page, the PR submission list, and the issue / PR number identified in the submission title and submission message, a mapping relationship between chaincode issues and code submission information is established;

[0018] An original database is established, wherein the original database includes a mapping relationship between chain code problems and code submission information, and chain code problems and code submission information involved in the mapping relationship between the chain code problems and code submission information.

[0019] Furthermore, filtering the mapping relationship between the chain code problem and the code submission information to obtain the code submission information associated with the vulnerability includes:

[0020] The chain code issues in the original database are screened according to the keywords related to security issues, and the mapping relationship between the screened chain code issues and the code submission information is obtained;

[0021] For the mapping relationship between the filtered chain code issues and code submission information, the chain code issues and code submission information containing common issues are filtered out through submission filtering, file filtering, tag filtering and keyword filtering to obtain the code submission information associated with the vulnerability; among them,

[0022] The submission filtering is to filter the code submission information by requiring that the code submission information contain code changes;

[0023] The file filtering is based on the file type of the corresponding source code in the code submission information, filtering the code submission information;

[0024] The tag filtering is based on the tags of chaincode issues / PRs and the tags of code submission information, filtering chaincode issues and code submission information;

[0025] The keyword filtering is to filter chaincode issues based on keywords in the title and body of the issue / PR.

[0026] Further, obtaining the corresponding vulnerability type based on the patch code title includes:

[0027] Deleting useless words in the patch code title to obtain keywords in the patch code title; wherein the useless words include: module information, version information, special words and adjectives;

[0028] Locate vulnerability type keywords among the keywords in the patch code title;

[0029] Word2vec is used to embed all vulnerability type keywords into the vector space, and the vulnerability type keyword vectors are clustered using the WMD text similarity measurement to obtain the blockchain code vulnerability type corresponding to the code submission information.

[0030] Furthermore, locating the vulnerability type keyword in the keywords in the patch code title includes:

[0031] For a patch code title containing a preposition and a verb, locating the vulnerability type keyword in the keywords in the patch code title includes:

[0032] If there is only one verb and one preposition in the patch code title, and the preposition appears after the verb, the verb and preposition are vulnerability type keywords;

[0033] If the patch code title does not have a verb but has a preposition, or does not have a preposition but has a verb, the preposition or verb is determined to be a vulnerability type keyword;

[0034] If multiple verbs appear in the patch code title, the verb with the highest frequency is considered as the vulnerability type keyword; if multiple prepositions appear in the title, the target preposition is determined to be the preposition that appears for the first time after the target verb as the vulnerability type keyword;

[0035] For vulnerability titles that do not contain both prepositions and verbs, locating vulnerability type keywords in keywords in patch code titles includes:

[0036] If only the target verb is present, all words after the target verb will be considered vulnerability type keywords;

[0037] If only the target preposition exists, all words before the target preposition will be considered vulnerability type keywords;

[0038] If no target word exists, the patch code title is used as the vulnerability type keyword.

[0039] Furthermore, the vulnerability code is abstracted, including:

[0040] Preserve control flow statements identified by keywords and preserve specific data types and operators;

[0041] and,

[0042] Remove function parameters and caller variables;

[0043] and,

[0044] Abstract variable names and variable values.

[0045] Furthermore, a patch pattern is generated according to the vulnerability code and the patch code, including:

[0046] Keep the diff code block in the patch code and separate the diff code block into separate fragments by consecutive + lines and - lines;

[0047] For each + line and - line, calculate the similarity with the code block in the vulnerable code;

[0048] When the similarity is greater than the set threshold, the + line or - line modifies the line;

[0049] When the similarity is less than the set threshold, the + or - line adds or deletes a row;

[0050] Based on the modified rows, newly added rows and deleted rows, a patch mode is obtained.

[0051] Furthermore, for a chain code to be detected, relevant codes with potential vulnerabilities are obtained according to the abstracted vulnerability code, and patch codes in the source project corresponding to the relevant codes with potential vulnerabilities are obtained by calculating code similarity, including:

[0052] Find the key statement in the abstract vulnerability code, and obtain the patch context containing the key statement in the corresponding patch code;

[0053] Retrieving code statements containing the key statements in the chain code to be detected to obtain candidate contexts;

[0054] Using multi-line code similarity measurement, the similarity between the patch context and the candidate context is calculated;

[0055] Based on the similarity between the patch context and the candidate context, the patch code in the source project corresponding to the relevant code with the potential vulnerability is obtained.

[0056] Furthermore, judging whether the patch code in the source project can repair the potential vulnerability of the chain code to be detected based on the patch mode includes:

[0057] For a patch code C in any of the acquired source projects, a similarity s between the patch code C and the patch pattern P is calculated, and a patch application state of the patch code C is obtained by determining whether the patch code C has been applied to the patch pattern P;

[0058] A factor conf=st is introduced; wherein t is a set threshold in the process of judging whether the patch code C has been applied to the patch pattern P;

[0059] The patch code C having the highest value of the factor conf and whose patch application state indicates that the patch code C has been applied to the patch pattern P is used as the patch code of the chain code to be detected.

[0060] A blockchain code ecosystem vulnerability identification system, characterized in that the system includes:

[0061] The original library construction module is used to capture the error information and code submission information of the public chain project and establish an original database containing the mapping relationship between chain code problems and code submission information;

[0062] The filtering module is used to filter the mapping relationship between chain code problems and code submission information to obtain code submission information associated with vulnerabilities;

[0063] A vulnerability database construction module is used to extract vulnerability codes, patch codes and patch code titles from the code submission information associated with the vulnerability, and after obtaining the corresponding vulnerability type based on the patch code title, generate a set including vulnerability types, vulnerability codes and patch codes; abstract the vulnerability code, and after generating a patch pattern based on the vulnerability code and the patch code, construct a final vulnerability database including vulnerability types, abstracted vulnerability codes and patch patterns;

[0064] The test module is used to obtain relevant codes with potential vulnerabilities based on abstract vulnerability codes for a chain code to be detected, and obtain patch codes in a source project corresponding to the relevant codes with potential vulnerabilities by calculating code similarity; based on the patch mode, determine the patch code in the patch code in the source project to repair the chain code to be detected.

[0065] Compared with the prior art, the present invention has the following beneficial effects:

[0066] The present invention constructs an efficient and accurate vulnerability identification and analysis system by deeply mining the error information and code submission records in the blockchain project, providing strong support for the security protection of the blockchain ecosystem. This solution innovatively combines natural language processing (NLP) technology with code similarity analysis algorithm to achieve comprehensive scanning and precise positioning of potential endogenous security risks in the blockchain source code library. Specifically, by capturing and analyzing the error reports and code submission history of the public chain project, a detailed original error database is constructed, and the NLP technology is used to intelligently associate problems with code records, effectively improving the accuracy and efficiency of vulnerability identification. Furthermore, this solution adopts a multi-dimensional association analysis strategy, including error utilization submission association, file modification association, tag association and keyword association, etc., to accurately filter out chain code error information directly related to the vulnerability. Subsequently, through cluster analysis technology, the code blocks corresponding to the error information are organized by module, and a collection containing vulnerability and patch submission records is constructed, which lays a solid foundation for the abstraction and identification of subsequent vulnerability patterns. In the vulnerability pattern abstraction stage, this solution not only focuses on the code characteristics of the vulnerability itself, but also deeply analyzes the context pattern of the patch code, and constructs a final vulnerability database containing vulnerability and patch submission patterns. This database not only enriches the blockchain security knowledge base, but also provides a valuable reference for subsequent security testing. In the vulnerability detection implementation phase, this solution uses the extracted patch context keywords to intelligently search for potentially relevant candidate contexts in the blockchain code to be tested. Through the multi-line code similarity calculation method, this solution can tolerate a certain degree of code differences and accurately compare the similarity between the patch code and the candidate code, so as to effectively determine whether the code to be tested has fixed the corresponding vulnerability and eliminate false positives. Finally, this solution can accurately detect unfixed vulnerabilities in the blockchain system and automatically generate a detailed detection report. This achievement not only helps the blockchain project team to promptly fix security vulnerabilities and improve the overall security of the system, but also provides a strong guarantee for the healthy development of the blockchain industry. BRIEF DESCRIPTION OF THE DRAWINGS

[0067] Figure 1 Flowchart of the method for identifying vulnerabilities in blockchain code ecology. DETAILED DESCRIPTION

[0068] The present invention is further described in detail below in conjunction with specific embodiments. The given examples are only for illustrating the present invention, but not for limiting the scope of the present invention.

[0069] The present invention is a method for identifying blockchain code ecosystem vulnerabilities. Figure 1 As shown, the following steps are included:

[0070] Step 1: Capture public chain project error information and code submission information, and establish an original database containing the mapping relationship between chain code problems and code submission information.

[0071] This example uses crawler technology to crawl all the submission logs and issue tracking records of representative public chains (such as Bitcoin, Ethereum, Monero, Stellar) from the code repository, specifically collecting their titles, submission messages, affected files and IDs / URLs, and the code blocks that were submitted for change. Next, the mapping relationship between chain code issues and submissions is preliminarily established by comparing code issue event information, associated submission lists, and title keywords.

[0072] In a preferred embodiment, the step 1 comprises the following steps:

[0073] Step 1.1: Use the GitHub API to collect all the information of each closed issue / PR (Pull Request), including the issue title, issue body, comments, events, and bug category labels. Only closed issues / PRs are considered, because unconfirmed issues do not have patches. Even for closed issues, they may not be real bugs and may not have patches (i.e. they are simply closed by the developer).

[0074] Step 1.2: For code commit information, first crawl all commits of a repository, and then determine which commits are related to the error. For each commit, collect its title, commit message, affected files, and id / URL.

[0075] Step 1.3: With the raw data in hand, the next step is to organize and associate issues with their corresponding commits. Specifically, they need to identify all the relevant commits for a given issue / PR - if an issue / PR has no patch commit, then it is not a real bug and will be filtered out.

[0076] Step 1.4: By specifically analyzing the vulnerability and patch submissions, three types of information that can be used for this association were observed: First, the event information of the issue page (for example, XXX mentioned this issue, and YYY added a submission) was used, and the submission URL was retrieved from these events. Second, for PRs with associations, their submission lists can be retrieved directly from their "Commits" tab. Although these two types of information are useful for most issues / PRs, some submissions may not appear in the issue's events or PR's submission list. To overcome this, a script was used to analyze the titles and messages of all submissions and identify the issue / PR number from them. Through these strategies, the relationship between issues and submissions was successfully established, and the construction of the original bug database was completed.

[0077] Step 2: Filter the mapping relationship between chain code issues and code submission information to obtain the code submission information associated with the vulnerability.

[0078] In the preferred technical solution provided by the present invention, the step 2 comprises the following steps:

[0079] Step 2.1: Perform preliminary filtering on the candidate information set obtained by the crawler by identifying keywords related to security issues. Screen out the issues and PRs containing these keywords as the preliminary vulnerability candidate set.

[0080] Step 2.2: Use a self-increasing sequence of filter frames to distinguish common errors from vulnerabilities. This filter frame analyzes the data from the aspects of code commits, files, tags, and keywords. Commit filtering: A valid vulnerability-patch information must contain code changes, so issues without any commits are directly excluded. File filtering: Through source code analysis, the file types of the actual source code are determined. For example, for Bitcoin commits, there are 152 different file types, but only seven file types (such as '.cpp', '.h', '.py', '.sh', '.cc', '.c', and '.java') contain actual source code. Other file types, such as '.yml' and '.mk', are unlikely to be related to vulnerabilities. In addition, commits that only contain test code and their related issues / PRs are also excluded. Through this filtering method, mapping entries that have no modifications to source code files (such as: test, configuration changes, resource updates) are excluded. Tag filtering: Certain words in the tags of issues / PRs can indicate whether an issue / PR is related to a vulnerability. First, we manually identified 48 tags that were not related to vulnerabilities from all 87 tags of the four blockchain projects, such as Refactoring, Docs, and type:feature. Through such tags, we deleted code submissions that were clearly not related to vulnerability fixes. Next, we used the same principle to further identify code submissions related to vulnerabilities. For example, the Privacy tag marked privacy-related bugs in the Bitcoin project, while the obsolete:vuln tag indicated an early vulnerability in Ethereum. In order to avoid false positives, we adopted a conservative strategy when assigning vulnerability tags. Only three tags were assigned (i.e., Privacy, obsolete:vuln, and the special tag SEC-XXX that appeared at the beginning of the issue / PR title). By identifying vulnerability-related tags, we filtered out bugs and code submissions related to vulnerability fixes. Keyword filtering: In order to expand the vulnerability dataset, we continued to filter patch information related to vulnerabilities in the set of submission records that were not related to vulnerabilities. Certain keywords in the title and body of an issue / PR can indicate whether an issue / PR is related to a vulnerability, while other keywords may imply that an issue / PR is not related to a vulnerability. We excluded words with a frequency of 1 in the title and text, and used NLP to cluster and group words according to semantics. We then manually checked the separated clusters to determine which clusters were related to or unrelated to the vulnerability, and obtained 62 vulnerability-related word groups and 79 non-vulnerability-related word groups. We then used vulnerability-unrelated word groups to exclude non-vulnerability code submissions, and further used vulnerability-related word groups to filter out vulnerability-patch association sets. On this basis, we removed duplicate, empty, and invalid code submissions in turn, and finally confirmed the vulnerability-related information and their fix submission records.

[0081] Step 3: Extract the vulnerability code, patch code and patch code title from the code submission information associated with the vulnerability, obtain the corresponding vulnerability type based on the patch code title, and generate a set including the vulnerability type, vulnerability code and patch code.

[0082] The present invention further extracts code blocks (vulnerability codes + patch codes) and titles of patch code blocks from the submission records corresponding to the error information, uses NLP keywords to extract and cluster vulnerability types, screens blockchain-specific vulnerability patches, and constructs a set including vulnerability types, vulnerability codes, and patch codes.

[0083] In the preferred technical solution provided by the present invention, the step 3 comprises the following steps:

[0084] Step 3.1: First, remove useless words in the problem details, such as module information, version information, special words, and adjectives, and regularize the remaining keywords.

[0085] Step 3.2: Use text positioning method to locate vulnerability type keywords.

[0086] 1) For text titles containing prepositions and verbs, the vulnerability type is between the target preposition and the target verb:

[0087] a) If there is only one verb and one preposition, and the preposition comes after the verb (with one or more words in between), then this verb and preposition are the target words.

[0088] b) If there is no verb but a preposition exists, or if there is no preposition but a verb exists, the preposition or verb will be determined as the target.

[0089] c) If multiple verbs appear in the title, the verb with the highest frequency is considered as the target verb.

[0090] d) If multiple prepositions appear in the title, the target preposition is determined to be the preposition that first appears after the target verb (with one or more words in between).

[0091] 2) For vulnerability titles that do not contain both prepositions and verbs, extract vulnerability type keywords as follows:

[0092] a) If only the target verb is present, all words after the target verb will be considered as type keywords.

[0093] b) If only the target preposition exists, all words before the target preposition will be considered as type keywords.

[0094] c) If no target word exists, the entire cleaned title will become the type keyword.

[0095] Step 3.3: Use word2vec to embed all vulnerability type keywords into the vector space, use the WMD text similarity measurement method to cluster the code, extract the category keywords related to blockchain-specific vulnerabilities, and use the clustering results to filter out blockchain code-specific vulnerabilities, thereby generating a set of vulnerability types, vulnerability codes, and patch codes.

[0096] Step 4: After abstracting the vulnerability code and generating a patch pattern based on the vulnerability code and patch code, a final vulnerability database containing vulnerability types, abstracted vulnerability codes, and patch patterns is generated.

[0097] In the preferred technical solution provided by the present invention, the step 4 comprises the following steps:

[0098] Step 4.1: Abstract vulnerable code patterns.

[0099] The present invention identifies control flow statements by retaining keywords, and retains specific data types and operators; removes function parameters and caller variables; abstracts variable names and variable values, NIL represents nil, null and none, BOL represents true and false, NUM represents numbers, TXT represents strings, LEN / SIZE represents size-related functions (such as len(), length(), size() and sizeof()), and ERR represents an error function.

[0100] Step 4.2: Generate patch pattern.

[0101] The present invention cleans and splits each patch code block, removes test code, adjacent context, and modifications to non-code files, retains only actual diff code blocks, and divides them into separate fragments through consecutive "+" and "-" lines.

[0102] Then, the modified code lines are paired, and for each + line and - line, the similarity with the code block in the vulnerability code is calculated and the lines with the highest similarity are paired to obtain the modified lines. Lines with a similarity with the vulnerability code less than 0.5 are regarded as simply added or deleted lines.

[0103] Based on the above steps, three types of patch patterns are obtained: a patch pattern containing only deleted lines, a patch pattern containing only added lines, and a patch pattern containing both deleted lines and added lines.

[0104] Step 5: For a chain code to be detected, obtain the relevant code with potential vulnerabilities based on the abstract vulnerability code, and obtain the patch code in the source project corresponding to the relevant code with potential vulnerabilities by calculating the code similarity.

[0105] In the preferred technical solution provided by the present invention, the step 5 comprises the following steps:

[0106] Step 5.1: Search for key statements: The key statements (ks) to be found in the first step are the code statements in the target code (patch code) that contain the abstracted vulnerability code. The searcher first searches for all code statements containing the patch context keywords in the target library, and then determines the search results by measuring the similarity between the searched ks and the original ks. If the measured similarity is higher than the set threshold, we consider it to be a possible candidate ks. In order to minimize the loss and avoid causing false negatives in subsequent steps, this step uses a relatively low threshold (0.25) based on a standardized metric, namely strsim() used in formula (1). This is acceptable because among all the searched candidate ks, we select the one with the highest similarity as the final candidate ks. Specifically, given a patch context pc = {(k 1 ,s 1 ),(k 2 ,s 2 ),…,(k m ,s m )}, where (k i ,s i ) represents the code statement s i Extract keyword k i , k i Search results for sr i Expressed as sr i =(k i ,[s′ i1 ,s′ i2 ,…,s′ in ]), where s′ ij The target library contains k i We determine s′ according to formula (1): pq The keyword is the final candidate ks.

[0107] p,q=argmax{strsim(s i ,s′ ij}f or 1≤i≤m,1≤j≤n (1)

[0108] Step 5.2: Determine the boundaries of the candidate context. Once the candidate ks is determined, the next step of the searcher is to retrieve the code statements surrounding it and determine its boundaries. Specifically, we need to expand the candidate ks of one line into a candidate context of multiple lines with boundaries corresponding to the original patch context. To do this, we first extract as many nearby code statements from the target code as represented in the patch context, denoted as C_LINES. Then, starting from ks, the searcher compares each code statement upward and downward with the start statement (ss) and end statement (es) in the patch context. The statements with the highest similarity and exceeding the above threshold (0.25) are then selected as the boundaries ss and es in the candidate context.

[0109] In the process of implementing candidate context search, the present invention adopts two automatic optimizations to further improve the context search accuracy and avoid unnecessary analysis in subsequent steps. The first is to exclude search results with different file types from the patch, and the second is to exclude search results with different sentence types.

[0110] Step 5.3: Check the similarity of the candidate context with the patch context: We further check whether the entire candidate context is indeed similar to the patch context by leveraging the same multi-line code similarity measure. If the measured similarity between the candidate context C and the patch context P exceeds a threshold, we consider C to be the context of the candidate clone and further process it; otherwise, we discard this candidate context. Note that since the similarity of multiple candidate contexts may exceed the threshold, all of these candidate contexts will be further processed.

[0111] The present invention abstracts the code similarity problem into this form: given a source code snippet S with p code statements and a target code snippet T with q code statements, we need to design an appropriate metric to determine their similarity. Intuitively, we can first calculate the similarity of each pair of code statements at the same position in S and T, and then normalize it to the range of [0, 1], that is, To calculate the similarity between S and T. To solve the above problems, the present invention determines two principles: (i) all code statements in S and T should be considered; (ii) the impact of the sorting problem should be adjustable. For the first principle, we determine the most similar code statement in T for each code statement in S, that is, for each statement S i ∈S, north wind then find T j ∈T, such that For the second principle, the present invention first defines indexes i and j as the relative positions of code statements in S and T. If S i The most similar statement to is T jThe basic idea is that the greater the difference between i and j, the greater the i and T j Therefore, the north wind introduces a parameter r∈[0,1] and r |i-j| To represent S i and T j By multiplying this reward by the original similarity, the impact of the sorting problem on code similarity can be adjusted. The specific calculation formula is as follows:

[0112]

[0113] in,

[0114] Step 6: Based on the code similarity, determine whether the vulnerability has been fixed in the chain code to be tested, eliminate false positives, detect unfixed blockchain system vulnerabilities, and generate a report.

[0115] In the preferred technical solution provided by the present invention, given a candidate code C of the target warehouse, the present invention compares it with the patch pattern. Note that P has three types:

[0116] (i) DEL-type: contains only deleted rows, i.e., P = [dp];

[0117] (ii) ADD-type: contains only the added rows, i.e., P = [ap];

[0118] (iii) CHA-type: contains deleted and added rows, i.e. P = [dp, ap]. We can determine the comparison logic as follows (where t is the threshold):

[0119] For type (i), if SIMILARITY(C, dp) ≥ t, then it is determined that C has not applied P; otherwise, it is determined that C has applied P. For type (ii), if SIMILARITY(C, ap) ≥ t, then it is determined that C has applied P; otherwise, it is determined that C has not applied P. For type (iii), if SIMILARITY(C, dp) ≥ t and SIMILARITY(C, ap) ≥ t and SIMILARITY(C, dp) ≥ SIMILARITY(C, ap), then it is determined that C has not applied P; otherwise, if SIMILARITY(C, dp) ≥ t and SIMILARITY(C, ap) ≥ t and SIMILARITY(C, dp) < SIMILARITY(C, ap), then it is determined that C has applied P. In addition, since the searcher may return multiple candidate contexts in the target repository, resulting in multiple candidate codes, i.e., Ci ∈ [C1, C2,..., Cn]. For each Ci, we calculate si = SIMILARITY(Ci, P) and determine its patch application status fvi ∈ {0, 1}, where fvi = 1 (= 0) indicates that Ci has (has not) applied P. Here, the present invention introduces a factor confi to measure the confidence of fvi in Ci, i.e., confi = si - t, that is, the larger si exceeds t, the higher the confidence of fvi in Ci. Finally, we can determine the status of P in the target repository through the most confident fvi, i.e., i = argmaxj confj. If the target repository has not applied P, a vulnerability is considered to exist; otherwise, the vulnerability is considered to have been repaired.

[0120] The above embodiments are only for illustrating the technical concept and features of the present invention, and their purpose is to enable those skilled in this field to understand the content of the present invention and implement it, and should not be used to limit the protection scope of the present invention. Any equivalent changes or modifications made according to the spirit and essence of the present invention should be covered by the protection scope of the present invention.

Claims

1. A method for identifying vulnerabilities in blockchain code ecology, characterized in that: The method comprises: Capture public chain project error information and code submission information, and build an original database containing the mapping relationship between chain code problems and code submission information; Filter the mapping relationship between chain code issues and code submission information to obtain code submission information associated with the vulnerability; Extracting vulnerability codes, patch codes, and patch code titles from the code submission information associated with the vulnerability, and obtaining corresponding vulnerability types based on the patch code titles, thereby generating a set including vulnerability types, vulnerability codes, and patch codes; After abstracting the vulnerability code and generating a patch pattern based on the vulnerability code and the patch code, a final vulnerability database including vulnerability types, abstracted vulnerability codes and patch patterns is generated; For a chain code to be detected, obtain relevant code with potential vulnerabilities based on the abstract vulnerability code, and obtain patch code in the source project corresponding to the relevant code with potential vulnerabilities by calculating code similarity; Based on the patch mode, a patch code for repairing the to-be-detected chain code is determined in the patch code in the source project.

2. The method according to claim 1, characterized in that The capturing of public chain project error information and code submission information, and establishing an original database containing a mapping relationship between chain code problems and code submission information, includes: Use GitHub API to collect information about each closed issue / PR in the public chain project error information; the information about the closed issue / PR includes: issue title, issue body, comments, events, and error category labels; Crawling all code submission information of a repository, and after determining the code submission information related to the error among all the code submission information, extracting the code submission information related to the error; wherein the code submission information includes: submission title, submission message, affected files and id / URL; Filter out closed issues / PRs without patch submission information; Based on the event information of the closed issue page, the PR submission list, and the issue / PR number identified in the submission title and submission message, a mapping relationship between chaincode issues and code submission information is established; An original database is established, wherein the original database includes a mapping relationship between chain code problems and code submission information, and chain code problems and code submission information involved in the mapping relationship between the chain code problems and code submission information.

3. The method according to claim 1, characterized in that The filtering of the mapping relationship between the chain code problem and the code submission information to obtain the code submission information associated with the vulnerability includes: The chain code issues in the original database are screened according to the keywords related to security issues, and the mapping relationship between the screened chain code issues and the code submission information is obtained; For the mapping relationship between the filtered chain code issues and code submission information, the chain code issues and code submission information containing common issues are filtered out through submission filtering, file filtering, tag filtering and keyword filtering to obtain the code submission information associated with the vulnerability; among them, The submission filtering is to filter the code submission information by requiring that the code submission information contain code changes; The file filtering is based on the file type of the corresponding source code in the code submission information, filtering the code submission information; The tag filtering is based on the tags of chaincode issues / PRs and the tags of code submission information, filtering chaincode issues and code submission information; The keyword filtering is to filter chaincode issues based on keywords in the title and body of the issue / PR.

4. The method according to claim 1, characterized in that: The obtaining the corresponding vulnerability type based on the patch code title includes: Deleting useless words in the patch code title to obtain keywords in the patch code title; wherein the useless words include: module information, version information, special words and adjectives; Locate vulnerability type keywords among the keywords in the patch code title; Word2vec is used to embed all vulnerability type keywords into the vector space, and the vulnerability type keyword vectors are clustered using the WMD text similarity measurement to obtain the blockchain code vulnerability type corresponding to the code submission information.

5. The method according to claim 4, characterized in that The method of locating the vulnerability type keywords in the keywords in the patch code title includes: For a patch code title containing a preposition and a verb, locating the vulnerability type keyword in the keywords in the patch code title includes: If there is only one verb and one preposition in the patch code title, and the preposition appears after the verb, the verb and preposition are vulnerability type keywords; If the patch code title does not have a verb but has a preposition, or does not have a preposition but has a verb, the preposition or verb is determined to be a vulnerability type keyword; If multiple verbs appear in the patch code title, the verb with the highest frequency is considered as the vulnerability type keyword; If multiple prepositions appear in the title, the target preposition is determined to be the preposition that appears first after the target verb as the vulnerability type keyword; For vulnerability titles that do not contain both prepositions and verbs, locating vulnerability type keywords in keywords in patch code titles includes: If only the target verb is present, all words after the target verb will be considered vulnerability type keywords; If only the target preposition exists, all words before the target preposition will be considered vulnerability type keywords; If no target word exists, the patch code title is used as the vulnerability type keyword.

6. The method according to claim 1, characterized in that Abstract the vulnerability code, including: Preserve control flow statements identified by keywords and preserve specific data types and operators; and, Remove function parameters and caller variables; and, Abstract variable names and variable values.

7. The method according to claim 1, characterized in that Generate a patch pattern based on the vulnerability code and patch code, including: Keep the diff code block in the patch code and separate the diff code block into separate fragments by consecutive + lines and - lines; For each + line and - line, calculate the similarity with the code block in the vulnerable code; When the similarity is greater than the set threshold, the + line or - line modifies the line; When the similarity is less than the set threshold, the + or - line adds or deletes a row; Based on the modified rows, newly added rows and deleted rows, a patch mode is obtained.

8. The method according to claim 1, characterized in that: For a chain code to be detected, obtain the relevant code with potential vulnerabilities based on the abstract vulnerability code, and obtain the patch code in the source project corresponding to the relevant code with potential vulnerabilities by calculating the code similarity, including: Find the key statement in the abstract vulnerability code, and obtain the patch context containing the key statement in the corresponding patch code; Retrieving code statements containing the key statements in the chain code to be detected to obtain candidate contexts; Using multi-line code similarity measurement, the similarity between the patch context and the candidate context is calculated; Based on the similarity between the patch context and the candidate context, the patch code in the source project corresponding to the relevant code with the potential vulnerability is obtained.

9. The method according to claim 1, characterized in that: The determining, based on the patch mode, whether the patch code in the source project can repair the potential vulnerability of the chain code to be detected includes: For a patch code C in any of the acquired source projects, a similarity s between the patch code C and the patch pattern P is calculated, and a patch application state of the patch code C is obtained by determining whether the patch code C has been applied to the patch pattern P; A factor conf=st is introduced; wherein t is a set threshold in the process of judging whether the patch code C has been applied to the patch pattern P; The patch code C having the highest value of the factor conf and whose patch application state indicates that the patch code C has been applied to the patch pattern P is used as the patch code of the chain code to be detected.

10. A blockchain code ecosystem vulnerability identification system, characterized in that: The system comprises: The original library construction module is used to capture the error information and code submission information of the public chain project and establish an original database containing the mapping relationship between chain code problems and code submission information; The filtering module is used to filter the mapping relationship between chain code problems and code submission information to obtain code submission information associated with vulnerabilities; A vulnerability database construction module is used to extract vulnerability codes, patch codes and patch code titles from the code submission information associated with the vulnerability, and after obtaining the corresponding vulnerability type based on the patch code title, generate a set including vulnerability types, vulnerability codes and patch codes; abstract the vulnerability code, and after generating a patch pattern based on the vulnerability code and the patch code, construct a final vulnerability database including vulnerability types, abstracted vulnerability codes and patch patterns; The test module is used to obtain relevant codes with potential vulnerabilities for a chain code to be detected based on the abstract vulnerability code, and obtain the patch code in the source project corresponding to the relevant code with potential vulnerabilities by calculating the code similarity; based on the patch mode, determine the patch code for repairing the chain code to be detected in the patch code in the source project.

Images