A sast-based code security training data generation method

Abstract

The present application relates to the technical field of SAST static detection, and particularly to a code security training data generation method based on SAST, comprising the following steps: generating code security training data through SAST, covering source file screening, vulnerability detection, result confirmation, content splicing and sample standardization. The present application improves the representativeness and legality of source files by introducing a path identification and annotation information screening mechanism and combining an update time index, enhances the coverage and accuracy of vulnerability positioning by parallel analysis of multiple tools and merging of abnormal marking results, improves the reliability of vulnerability confirmation by using rule labels and path structure dual consistency verification, realizes complete expression of the context of training samples by splicing control logic and calling information in function body content, and unifies sample structure and format in the training data construction stage by combining rule labels, descriptions and repair suggestions, effectively supporting the application adaptation and generalization ability of the code security model in the static detection scene.

Description

Technical Field

[0001] This invention relates to the field of SAST static detection technology, and in particular to a method for generating code security training data based on SAST. Background Technology

[0002] SAST (Static Analysis Tree) technology involves static analysis of software source code, bytecode, or binary files without executing the program to identify potential security vulnerabilities, coding defects, and non-compliant implementation logic. This includes syntax tree construction, control flow analysis, data flow tracing, vulnerability pattern matching, and security rule formulation. By using automated tools to intervene in the early stages of software development, it helps to promptly discover and locate security risks in the code, serving as a crucial support for software security assurance systems. Traditional code security training data generation refers to the process of collecting representative security vulnerability samples from existing software projects and labeling and organizing them to build security detection models or enhance static analysis tools. This typically involves manually labeling combined with vulnerability database screening methods to extract vulnerability and fix pairs. The samples are then classified, deduplicated, and cleaned according to a predefined labeling system, or specific vulnerability pattern fragments are screened from a large amount of source code using regular expressions. However, this approach has significant limitations in maintaining the integrity of the vulnerability context, improving labeling efficiency, and expanding data scale.

[0003] In the traditional process of generating code security training data, manual annotation and vulnerability database retrieval are the main methods. The sample extraction process is easily affected by subjective bias, resulting in limited sample coverage and incomplete expression of contextual information. Regular expression matching is difficult to extract complex or cross-function vulnerability patterns, leading to a low proportion of high-quality security samples in the training data. Inconsistent labels cause confusion in subsequent processing. In many fields, high-quality, large-scale synthetic training data focusing on program code security is particularly scarce. Existing public datasets have sparse and scattered data on vulnerability patterns, secure coding standards, and remediation strategies, which makes it difficult to support the generalization of security rules in multiple scenarios. Ultimately, this limits the deep training capabilities of large models in the direction of secure code understanding and generation. Summary of the Invention

[0004] The purpose of this invention is to address the shortcomings of existing technologies by proposing a code-safe training data generation method based on SAST.

[0005] To achieve the above objectives, the present invention adopts the following technical solution: a method for generating code security training data based on SAST, comprising the following steps:

[0006] S1: Obtain the project source code file set, read the source file path identifier, language comment header and update time index, classify the source files by path and filter by language, record and organize the source files that conform to the open source license and belong to the target language, and generate the number of source files that meet the detection requirements.

[0007] S2: Based on the source file paths included in the number of source files to be detected, perform vulnerability detection processing on the nodes in the control flow graph, syntax structure tree and call relationship graph, collect the results of anomaly markers located in the source files, and generate the number of scan anomaly hits based on merging all anomaly items in the same source file.

[0008] S3: Based on the location results of the number of abnormal hits in the scan, extract the corresponding scan rule labels and marked location numbers, count all records where the marked paths and rule labels are consistent, filter the record locations with consistent hits, and generate a consistency vulnerability confirmation result.

[0009] S4: Based on the recorded position in the consistency vulnerability confirmation result, obtain the content of the corresponding function body from the source file, execute the content splicing task in the construction of training input units, record the set size of all spliced ​​training input units, and generate context training input units.

[0010] S5: Based on the context training input unit, combine it with the corresponding rule tags, description content and repair suggestions to perform the structure construction and sample format standardization of the security training data, and put it into the corpus resource directory according to the unified corpus template to generate SAST code security training data generation record.

[0011] As a further aspect of the present invention, the number of source files that meet the detection criteria includes the total number of source files, target language types, open-source protocol types, and path classification tags; the number of scan anomaly hits includes the number of vulnerability nodes, tool hit counts, anomaly type tags, and tool detection coverage; the consistency vulnerability confirmation results include rule tag mapping results, path structure matching results, consistency vulnerability location indexes, and consistency verification rates; the context training input unit includes function body code segments, control logic flags, nested structure levels, and call relationship nodes; and the SAST code security training data generation record includes training sample numbers, rule tag sets, security description information, remediation suggestion text, and corpus template format.

[0012] As a further aspect of the present invention, the open-source license specifically refers to the restriction that the source code of the open-source project can be legally used in the training data generation process, including but not limited to MIT, Apache 2.0, BSD, and MPL.

[0013] As a further aspect of the present invention, the specific steps for obtaining the number of source files that meet the detection criteria are as follows:

[0014] S111: Obtain the collection of source code files for the open source platform project, and perform path parsing operation on each source code file in the collection. Match the source file path identifier with the corresponding directory structure, extract the functional module tag and hierarchical index number corresponding to the source code file based on the directory hierarchy keywords contained in the path, perform path classification processing on the source files, and generate a source file path clustering structure set.

[0015] S112: Based on the source file path clustering structure set, extract the corresponding source code file content in each clustering structure, extract the language comment headers in the source files, match the language type identifier in the comment content with the target language type set, mark the source code files that match successfully as target language files, and compare them according to the update time index in the source file record, and remove source files whose update time index field value is less than the set language validity period benchmark value to obtain the target language source file set;

[0016] S113: Based on the target language source file set, perform an open source protocol retrieval operation on the beginning of each source file in the set, extract the open source protocol identifier contained therein and match it with a preset set of legal protocols, filter source files whose protocol fields completely belong to the set of legal protocols, count the number of source files that meet the conditions, and obtain the number of source files that meet the detection criteria.

[0017] As a further aspect of the present invention, the specific steps for obtaining the number of scan anomaly hits are as follows:

[0018] S211: Based on the source file paths included in the number of source files to be detected, load the source code files specified by each path in sequence, perform structural deconstruction and semantic extraction operations on all nodes in the control flow graph, syntax structure tree and call relationship graph corresponding to the source code, determine whether there are abnormal references in the control branch jump relationship, whether there are uninitialized object accesses or potential resource leakage points in the function call chain, and mark the nodes that meet the abnormal logic pattern to generate a set of structural abnormal markers;

[0019] S212: Based on the structural anomaly marker set, aggregate the anomaly nodes marked by each type of analysis tool in the same source file, establish tool source index labels and perform merging and reorganization processing on the anomaly node identifiers. By judging whether there is an overlap between the file path to which the node belongs and the semantic expression content of the node, and based on whether the calculated value of the node semantic similarity exceeds the semantic merging threshold, filter out redundant marker information and obtain the same source anomaly node index set.

[0020] S213: Based on the correspondence between each group of source files and abnormal nodes recorded in the same source abnormal node index set, count the number of abnormal nodes in each source file after being marked and merged by the tool, and classify and map the statistical results according to the file path index to establish the abnormal node number mapping for each source file and obtain the number of scan abnormal hits.

[0021] As a further aspect of the present invention, the specific steps for obtaining the consistency vulnerability confirmation result are as follows:

[0022] S311: Based on each source file path and corresponding abnormal node index number recorded in the number of scan anomaly hits, retrieve tool annotation information for each abnormal node, extract the bound scan rule tags and corresponding marker position numbers, construct a set of source file path, rule tag, and marker position triplet, and generate a rule position mapping matrix.

[0023] S312: According to the rule label of each record in the rule position mapping matrix, match the standard label information one by one, verify the label consistency by string full matching, and compare whether the marked path structure is the same as the source file path level. Calculate and obtain the label path consistency difference index, perform path label joint judgment, and if it is less than the path consistency threshold, it can be determined as a consistent label path combination to obtain the label path consistency index set.

[0024] S313: Based on all record combinations filtered in the label path consistency index set, group them together by file path and rule label, perform statistical processing on the number of records in each group, determine whether there are at least two different tools that label the same rule label and path combination in each group, and if the condition is met, include the corresponding location number, summarize all location number sets that meet the condition, and obtain the consistency vulnerability confirmation result.

[0025] As a further aspect of the present invention, the formula for calculating the tag path consistency difference index is as follows:

[0026] ;

[0027] in, Indicates the first The consistency difference index of the tag path of each record. Indicates the first The first record of the source path Layer directory number, This represents the first rule tag path in the dictionary. Layer numbering, Indicates the total number of path levels. Indicates the first The first record The existence Boolean flag for each path keyword. Indicates the first The normalized structure depth score corresponding to each path keyword in the path, with a value ranging from 0 to 1. This indicates the total number of path keywords.

[0028] As a further aspect of the present invention, the specific steps for obtaining the context training input unit are as follows:

[0029] S411: Based on the position of each record in the consistency vulnerability confirmation result, extract the corresponding line number from the source file, trace back upwards to locate the function body structure range, determine whether the line where the record is located is in the function declaration block, record the start and end lines of the function body according to the start and end positions of the curly braces structure, retrieve all lines of code in the function body, extract the complete code text in the area as a function fragment representation, and obtain the function body statement fragment set;

[0030] S412: Based on the set of function body statement fragments, perform structural parsing operations on the control logic symbols, structural nesting flags and function call statements contained in each function code segment, identify branch jump characters and structural nesting characters, mark the line index and indentation level, and scan all external call statements appearing in the function body. Establish call summary information by recording the name of the called function and the number of parameters, and concatenate the content according to the structural position order to construct a single context block structure corresponding to each sample, thereby obtaining the function context concatenation unit.

[0031] S413: Based on the structure content already constructed in the function context splicing unit, number and classify all generated context units according to the sample index, count the number of successfully spliced ​​samples in the current training batch, map them to the training input structure set, record the total number of the structure set and mark the starting index number in the construction of the training corpus, establish a unified structured data structure, and obtain the context training input unit.

[0032] As a further aspect of the present invention, the specific steps for obtaining the SAST code security training data generation record are as follows:

[0033] S511: Based on the context training input unit, extract the corresponding rule tags, vulnerability descriptions and remediation suggestions respectively, extract the tag number, description sentence fragment and suggestion sentence content matched by each sample, and assemble the information in order, use delimiters to divide the structure into content, determine whether the content length exceeds the set length limit and perform trimming and padding, and establish a tag description combination structure.

[0034] S512: Based on the tag description combined structure, extract the structural content and concatenate it with the context training input unit, place the context fragment at the front of the combined structure, and sequentially concatenate the rule tag number, vulnerability description fragment, and repair suggestion field, and map the concatenation result to the unified corpus template format, perform format legality verification on the structural template, exclude missing field and extra field abnormal items, and obtain standard corpus sample records.

[0035] S513: Based on the standard corpus sample records, serialize and store them in the corpus resource directory path structure according to the sample index number order, create a training data storage index list, identify the file name, storage path, and content summary hash information of each sample, perform consistency detection on the number and structure format of the stored sample records, record the total number of samples and the construction completion timestamp, and generate a SAST code security training data generation record.

[0036] Compared with the prior art, the advantages and positive effects of the present invention are as follows:

[0037] This invention improves the representativeness and legitimacy of source files by introducing a path identifier and annotation information filtering mechanism combined with an update time index. It enhances the coverage and accuracy of vulnerability localization by using multiple tools in parallel analysis and merging anomaly marking results. It improves the reliability of vulnerability confirmation by using rule tags and path structure dual consistency verification. It integrates control logic and call information in function body content splicing to achieve a complete expression of the training sample context. In the training data construction stage, it combines rule tags, descriptions and repair suggestions to standardize the sample structure and format. Overall, it improves the efficiency of training sample generation and expands the data scale while ensuring data quality and context integrity. It effectively supports the application adaptation and generalization capabilities of code security models in static detection scenarios. Attached Figure Description

[0038] Figure 1 This is a flowchart of the main steps of the present invention;

[0039] Figure 2 This invention conforms to the flowchart for obtaining the number of source files to be detected;

[0040] Figure 3 This is a flowchart illustrating the process of obtaining the number of abnormal hits in the scan according to the present invention.

[0041] Figure 4 This is a flowchart of the process for obtaining the consistency vulnerability confirmation results of this invention;

[0042] Figure 5 This is a flowchart of the process for obtaining the context training input unit in this invention;

[0043] Figure 6 This is a flowchart illustrating the process of generating and obtaining SAST code security training data for this invention. Detailed Implementation

[0044] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the invention.

[0045] In the description of this invention, it should be understood that the terms "length," "width," "upper," "lower," "front," "rear," "left," "right," "vertical," "horizontal," "top," "bottom," "inner," and "outer," etc., indicating orientation or positional relationships, are based on the orientation or positional relationships shown in the accompanying drawings and are only for the convenience of describing the invention and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation, and therefore should not be construed as a limitation of the invention. Furthermore, in the description of this invention, "a plurality of" means two or more, unless otherwise explicitly specified.

[0046] Please see Figure 1 A method for generating code security training data based on SAST, comprising the following steps:

[0047] S1: Obtain a collection of source code files from multiple open-source platforms, read the source file path identifiers, language comment headers, and update time indexes, classify the source files by path and filter by language, record and organize the source files that conform to the open-source license and belong to the target language, and generate the number of source files that meet the detection criteria.

[0048] S2: Based on the source file paths included in the number of source files detected, static analysis tools such as Semgrep, CodeQL, and SonarQube are used in sequence to perform vulnerability detection on the nodes in the control flow graph, syntax structure tree, and call relationship graph. The abnormal marking results located by each tool in the source file are collected, and the number of scan anomaly hits is generated based on merging all abnormal items in the same source file.

[0049] S3: Based on the location results of the number of abnormal hits in the scan, extract the corresponding scan rule labels and marked location numbers from the detection items of each tool. By matching the dictionary corresponding to the rule labels and comparing the marked path structure, count all records where the marked path and rule label are consistent, filter the record locations with consistent hits, and generate consistency vulnerability confirmation results.

[0050] S4: Based on the position of each record in the consistency vulnerability confirmation result, obtain the content of the corresponding function body from the source file, complete the content splicing task in the construction of training input units by identifying control logic characters, nested structure flags and call relationship information, record the total number of training input units that have been spliced, and generate context training input units.

[0051] S5: Based on the context training input unit, it is combined with the corresponding rule labels, description content and repair suggestions to perform the structure construction and sample format standardization of the security training data. All training samples are placed into the corpus resource directory according to the unified corpus template to generate SAST code security training data generation record.

[0052] The number of source files that meet the detection criteria includes the total number of source files, target language types, open-source license types, and path classification tags. The number of anomaly hits includes the number of vulnerability nodes, tool hit counts, anomaly type tags, and tool detection coverage. The consistency vulnerability confirmation results include rule tag mapping results, path structure matching results, consistency vulnerability location indexes, and consistency verification rates. The context training input units include function body code segments, control logic flags, nested structure levels, and call relationship nodes. The SAST code security training data generation record includes training sample numbers, rule tag sets, security description information, remediation suggestion text, and corpus template format.

[0053] Please see Figure 2 The specific steps of S1 are as follows:

[0054] S111: Obtain the collection of source code files for the open source platform project, and perform path parsing operation on each source code file in the collection. Match the source file path identifier with the corresponding directory structure, extract the functional module tag and hierarchical index number corresponding to the source code file based on the directory hierarchy keywords contained in the path, perform path classification processing on the source files, and generate a source file path clustering structure set.

[0055] After obtaining a collection of source code files from multiple open-source platforms, it is necessary to retrieve the path information of each source code file in the collection one by one, and decompose the path into segments using the " / " symbol. For example, the path " / project1 / src / moduleA / utils / file1.java" can be decomposed into [project1, src, moduleA, utils, file1.java], corresponding to five levels: project name, source code directory, functional module, utility class, and file name, respectively. Based on the hierarchical structure, directory tag rules are set, with the third level as the functional module tag and its subsequent levels as its subordinate indexes. This method allows the path to be categorized as a utility class file under the "moduleA" module. For a large number of such paths, a keyword matching table can be set up to standardize and unify common functional modules, such as uniformly marking "util, tools, common" as "utility module," thereby extracting a unified tag from the path. Taking a Java project as an example, let... The functional module tags are defined as: controller, service layer, data access layer, tool module, configuration module, etc. The path " / project2 / service / user / handler.java" can be categorized as a user processing class under the service layer module, and "service" is extracted as the functional tag, and "user" as the functional subclass. After path parsing, a key-value mapping structure is established, where the key is the functional module tag and the value is the corresponding path set, forming a preliminary clustering structure. Next, the aggregation degree of each tag in the path set is statistically analyzed. If the number of paths corresponding to a certain tag exceeds a set threshold of 50, then the tag is determined to be a main module, and its path set is aggregated into the core clustering structure. Taking the "service" tag extracted from the example path set as an example, if 64 paths belong to this module, meeting the threshold condition, then they are aggregated as main module paths. This path clustering structure records the correspondence between module names and path sets through a dictionary structure and stores it in a structured table for easy subsequent processing, as shown in Table 1.

[0056] Table 1. Clustering Structure of Source Code File Paths

[0057] Module tags Directory path example Number of paths controller / project1 / src / controller / user 48 Service layer / project2 / service / user 64 Tool Module / project3 / common / utils 52 Configuration module / project4 / config 31

[0058] As shown in Table 1, the "service layer" module has a large number of path affiliations, so it is aggregated into the core path clustering structure to finally generate the source file path clustering structure set.

[0059] S112: Based on the source file path clustering structure set, extract the corresponding source code file content in each cluster structure, extract the language comment headers in the source files, match the language type identifier in the comment content with the target language type set, mark the source code files that match successfully as target language files, and compare them according to the update time index in the source file record, remove source files whose update time index field value is less than the set language validity period benchmark value, and obtain the target language source file set;

[0060] Based on the source file path clustering structure set, the content of the source code file pointed to by each path in the structure is called. The comment sections defined at the beginning of the file are extracted, with the extraction rule starting with " / / " or " / ** / ", and the first non-empty comment section being the extraction target. Language declaration markers are analyzed in the extracted content. Generally, the language type is explicitly declared in the comment section, such as "Language: Java" or "@language=Python". If the declaration exists, the declaration value is compared with the target language set. For example, if the target set is {Java, Python, Go}, then the file with a successful match is marked as a source file of the target language. If there is no explicit declaration, the language type is inferred based on the file extension, such as ".py" for Python, ".java" for Java, etc. This extension mapping requires a static table for fast judgment. Then, the timestamp record at the beginning of the source file is read, generally in the format of the timestamp in the comment section. The last modified date is set to "YYYY-MM-DD". This date is compared with the set language validity period benchmark. If the benchmark is "2022-01-01", all source files modified before this date will be removed. For example, if a Java file's comment information is "Language: Java\nLastModified: 2021-08-15", it is identified as Java, but removed because its update date is earlier than the benchmark date. Another file with "Language: Go\nLastModified: 2023-04-10" is marked as the target language and retained. The benchmark "2022-01-01" is the language stability test threshold, set based on the historical version control frequency. Files updated within the last two years are considered valid. Of the 180 files in the sample set, 117 met the language matching and time conditions, generating the target language source file set.

[0061] S113: Based on the target language source file set, perform an open source license retrieval operation on the beginning of each source file in the set, extract the open source license identifier contained therein and match it with the preset legal license set, filter source files whose license fields completely belong to the legal license set, count the number of source files that meet the conditions, and obtain the number of source files that meet the detection criteria.

[0062] Based on the target language source file set, the open-source license field is searched in the header of each source file. The search scope is limited to the first 200 lines of text in the source file. Common open-source license keywords, such as "MITLicense", "ApacheLicense2.0", and "GNU General Public License", are searched by string matching. To ensure matching accuracy, a standard list of license keywords is constructed, containing 14 legal license fields. A full-word matching method is used to avoid false positives. If "Licensed under the ApacheLicense, Version 2.0" appears in a file comment, it is identified as conforming to the license. Fields; at the same time, to avoid misidentification, an exclusion list for illegal protocols needs to be set. For example, if the words "Proprietary" or "All rights reserved" are present, the file will be removed. For example, if file A has a comment containing "License: MITLicense" and file B has a comment containing "All rights reserved", file A will be kept and file B will be removed. After filtering out the legal protocol files in this way, their index numbers are recorded and the total number of files that meet the conditions is counted. Assuming that there are 117 files in the target language source file set, of which 93 files contain legal protocol fields and 24 files are removed because they do not declare or declare illegal protocols, the final number of source files that meet the detection criteria is obtained.

[0063] Please see Figure 3 The specific steps of S2 are as follows:

[0064] S211: Based on the source file paths included in the number of source files to be detected, the source code files specified by each path are loaded sequentially. The static rule sets preset by Semgrep, CodeQL and SonarQube are called respectively. The structure deconstruction and semantic extraction operations are performed on all nodes in the control flow graph, syntax structure tree and call relationship graph corresponding to the source code. By judging whether there are abnormal references in the control branch jump relationship, whether there are uninitialized object accesses or potential resource leakage points in the function call chain, the nodes that meet the abnormal logic pattern are marked, and a set of structural abnormal markers is generated.

[0065] Based on each source file path listed in the number of source files to be detected, the actual source code file content pointed to by the path is extracted sequentially, and then input into the corresponding static analysis tool according to the file extension. If the source file is in ".java" format, it is simultaneously input into Semgrep, CodeQL, and SonarQube. Analysis is initiated using preset rule sets, which define exception types such as abnormal jumps in control flow nodes, illegal semantic combinations in the syntax tree, and undeclared or null pointer references in the function call graph. For example, in Semgrep, the rule "functions contain branches with no return statements" is set. When the following code segment "if(condition){returnx;} / / else branch has no return" is encountered, it will be marked as an exception node. Subsequently, each tool constructs three structural graphs based on its static engine: source file control flow graph, syntax tree, and function graph. Each node in the graph structure is scanned one by one to see if it satisfies the exception rules. If it does, the node's structure type, line number, and context summary are recorded. The exception result set is written to the control flow graph. During the process, the control transfer relationship of each node needs to be checked one by one to see if there are nodes without outgoing edges or infinite loop paths. For example, if node A points to nodes B and C, and neither B nor C has an outgoing path, then node A is marked as the starting point of the exception. If there are problems such as undefined variables or incompatible types in the node expression in the syntax tree structure, then the syntax node is recorded as an illegal subtree. If the target address of a function call in the call relationship graph is empty or points to a released resource, then the call node is marked as a risky call point. During the tool's operation, the number of times each node is marked needs to be recorded, and the node numbering range for each type of structure graph needs to be renumbered to avoid cross-graph conflicts, so as to ensure the independence and consistency of the tool's positioning process in different source files. In actual implementation, a test project contained a total of 8 source files. Semgrep located 13 exception nodes in 5 of the files, CodeQL located 19 exception nodes in 6 files, and SonarQube located 21 exception nodes in 7 files, obtaining a total set of structural exception markers.

[0066] S212: Based on the set of structural anomaly markers, aggregate the anomaly nodes marked by each type of analysis tool in the same source file, establish tool source index labels and merge and reorganize the anomaly node identifiers. By judging whether there is overlap between the file path to which the node belongs and the semantic expression content of the node, and based on whether the calculated value of the node semantic similarity exceeds the semantic merging threshold, redundant marker information is filtered out to obtain the index set of anomaly nodes from the same source.

[0067] Based on the information structure of each source file and its corresponding anomalous node stored in the structural anomaly tag set, the anomaly tags of each tool type are first aggregated according to file path to ensure that different tool tags in the same source file can be uniformly classified. Then, semantic content aggregation processing is performed on the anomalous nodes of the same tool in the same file. Specifically, the semantic vector of the code line corresponding to the node is extracted (using a pre-trained code language model (such as CodeBERT, GraphCodeBERT, CodeT5, etc.)). The semantic vector is projected into a 256-dimensional space, and the semantic similarity value between two nodes in the same file is calculated using cosine similarity. If the similarity value is higher than the semantic merging threshold of 0.85 (determined based on data statistical analysis, obtained by measuring the semantic similarity of common anomaly structure samples), then the similarity distribution of node pairs considered semantically redundant is analyzed by calculating the cosine similarity between each type of anomalous node pair. Finally, the average of these samples is used as the merging threshold. If a node is deemed semantically redundant, its first node is retained, while the rest are discarded. This threshold is set by calculating the average of 10 pre-constructed common abnormal structure samples. During the test, a Java project had a source file "userController.java". Semgrep marked lines 52 and 54 as potentially accessing uninitialized fields. The cosine similarity was calculated to be 0.914, which met the threshold condition. Therefore, only line 52 was retained and line 54 was discarded. Then, tool identifier fields were added to all aggregated nodes, with "sem_", "codeql_", and "sonar_" as prefixes embedded in the node index. At the same time, an index mapping table was constructed to map the original tags to the merged tags one by one. After merging all source files, the deduplicated node set was output uniformly, and the source tool information and semantic summary content were added to each node as the basis for subsequent statistics. Finally, the index set of common source abnormal nodes was obtained.

[0068] S213: Based on the correspondence between each group of source files and abnormal nodes recorded in the same source abnormal node index set, count the number of abnormal nodes in each source file after being marked and merged by the tool, and classify and map the statistical results according to the file path index to establish the abnormal node number mapping for each source file and obtain the number of scan abnormal hits.

[0069] Based on the path index and merge node number of each record in the same-source abnormal node index set, the number of abnormal nodes after semantic merging in each source file is counted item by item. The file path and the corresponding number of abnormal nodes are written into the statistical mapping table structure in the form of key-value pairs. If the path " / src / auth / loginHandler.java" corresponds to 6 abnormal nodes, a data item with the key value of path and the value of "6" is written. After traversing all path records in the index set and counting the number of abnormal nodes contained in each path, a two-dimensional mapping data structure is generated with the source file path as the first dimension index and the number of abnormal nodes as the second dimension record. Then, the number of abnormal nodes for all paths is written into a unified table as an abnormal hit record for subsequent readability display. The table uses one path per row and "source file path" and "number of abnormal nodes" fields in each column. The specific records are shown in Table 2.

[0070] Table 2. Number of Scan Anomalies Hit

[0071] Source file path Number of abnormal nodes / src / auth / loginHandler.java 6 / src / user / userService.java 3 / src / db / connectionManager.java 9 / src / util / dataValidator.java 4

[0072] As shown in Table 2, the path " / src / db / connectionManager.java" had the most abnormal nodes in this round of detection, with 9 items. This number comes from the joint tagging of SonarQube and CodeQL and is obtained after semantic merging. The final count of scan anomaly hits is obtained.

[0073] Please see Figure 4 The specific steps of S3 are as follows:

[0074] S311: Based on the source file path and corresponding abnormal node index number recorded in the number of scan anomaly hits, retrieve tool annotation information for each abnormal node, extract the bound scan rule tags and corresponding marker position numbers, construct a set of source file path, rule tag, and marker position triplet, and generate a rule position mapping matrix.

[0075] Based on each source file path and its corresponding anomaly node index number recorded in the anomaly hit count, the static analysis tool information field associated with each node is first extracted. The rule label field and location number field in the tool output structure are then parsed. The label value corresponding to the "rule_id" field is combined with the line number identified by "line_number" to form the label location information. Simultaneously, the source file path identifier is retained. These three pieces of information are uniformly constructed into a path-label-number triplet record structure. Next, records are clustered according to the source file dimension. The clustering method is to aggregate all triples under the same path. During this process, duplicate records are deduplicated, retaining the first occurrence of the label-number pair and marking its source tool. For example, for the path " / api / use..." If SonarQube and CodeQL both label line 45 with the same tag "U001", then two records {userController.java, U001, 45} are formed. During clustering, one record is retained, and the number of source tools is recorded as 2. Then, all similar triples from this source file are written into a mapping structure, using the path as the key and the triple set as the value, forming a regular location set mapping table. If userService.java contains 4 unique triples, then the set size corresponding to that path is 4. After this process, an overall matrix is ​​constructed, and a primary key index is established according to the path dimension and uniformly numbered. Simultaneously, the triple set capacity for each path is recorded for subsequent analysis operations, as shown in Table 3.

[0076] Table 3. Source file path corresponding to the rule location matrix structure table

[0077] Source file path Number of tags Example of label position combination / api / user / userController.java 3 {(U001,45),(U002,78),(U004,102)} / service / auth / loginService.java 2 {(A015,30),(A016,85)} / data / db / dbAccess.java 4 {(D011,22), (D012,41), (D013,67), (D014,90)}

[0078] As shown in Table 3, each source file path has been bound to the corresponding tag location set, generating a rule location mapping matrix.

[0079] S312: Based on the rule label of each record in the rule location mapping matrix, match the canonical label information one by one, verify the label consistency by string full matching, and compare whether the marked path structure is the same as the source file path level, using the formula:

[0080] ;

[0081] Calculate the consistency difference index of tag path Perform a joint judgment on path labels. If the values ​​are less than the path consistency threshold, the combination of label paths is considered consistent, resulting in a label path consistency index set; where, Indicates the first The consistency difference index of the tag path of each record. Indicates the first The first record of the source path Layer directory number, This represents the first rule tag path in the dictionary. Layer numbering, Indicates the total number of path levels. Indicates the first The first record The existence Boolean flag for each path keyword. Indicates the first The normalized structure depth score corresponding to each path keyword in the path ranges from 0 to 1 (the specific calculation method is: divide the keyword's level number in the path (e.g., the nth level of directory) by the total number of levels in the path, i.e. ,in Indicates the level number where the keyword is located. This represents the total number of levels in the path. For example, if a keyword is located at level 3 in a 4-level path, its score is 0.75. Indicates the total number of path keywords;

[0082] After recording each path in the rule location mapping matrix, to evaluate whether the structure of each tag path is consistent with the path defined in the rule tag dictionary, it is necessary to jointly calculate the difference in structure hierarchy numbering and the depth of keyword distribution. The structure path consistency difference index formula is used for calculation, and the structure numbering sequence of the source path " / api / user / auth / controller" is set as follows: The structure of the corresponding rule tag dictionary is as follows: The difference in level numbers is then... Total number of levels The first calculation result is The path keywords are set to "auth", "controller", and "impl", where the source path contains "auth" and "controller" and its boolean value is... The normalized depth scores are respectively The weighted term is The square root is ,final If the path consistency threshold is set to 1.2, this value is derived from the quantile boundaries obtained by statistically analyzing the distribution of the difference between the rule tag path hierarchy and the keyword structure matching degree. The maximum mean of the tag path hierarchy difference is set to an upper limit of 0.8, and the maximum confidence tolerance root value of the keyword structure scoring item is set to 0.9. The sum of these two values ​​is the upper bound critical value of the acceptable error in the path structure. Therefore, the threshold of 1.2 is defined as the upper limit reference for tag path structure matching. This value shows a linear increasing trend as the number of keywords m or the number of path levels n increases, mainly fluctuating with the increase of path depth and keyword embedding density. If the current result... If the consistency criteria are not met, the path label pair will be removed and not included in the label path consistency index set.

[0083] The path consistency difference index in the above formula The design employs a weighted fusion logic of the structural hierarchy difference average term and the keyword semantic distribution term. Specifically, the first term... This represents the average absolute difference between the source path and the rule path at each level of the structural hierarchy. It is used to quantify the structural offset of the path at the directory level. The absolute value operation is used to eliminate directional influences, retaining only the magnitude of the difference. The summation is then divided by the total number of levels. This can prevent the amplification of differences caused by varying path lengths, forming a normalized index of structural offset; the second item Used to evaluate the semantic matching degree of keywords in the path, where Indicates whether the keyword exists. The structure depth normalization score is represented by the sum of the two to calculate the structure matching weight of each keyword. The square root of the sum of all keyword weights reflects the degree of aggregation and dispersion of the keyword structure distribution. The square root operation here has a harmonizing effect of compressing high weight fluctuations and enhancing the sensitivity of intermediate values. Finally, the two dimensionless but independent indicators are directly added together, so that the structural offset and semantic offset can reflect the consistency difference of path matching on the same scale. This logic, by uniformly evaluating the path features from two completely different sources, makes the judgment result subject to the dual constraints of structural alignment and semantic coverage.

[0084] The Tag Path Consistency Difference Index is used to quantitatively evaluate the degree of matching between the source code path structure and the rule tag path in terms of hierarchical order and keyword semantics. This index comprehensively considers two core dimensions: first, the consistency of the path structure hierarchy numbering, that is, whether the position number of the source path and the rule path in each level directory is aligned, reflecting the similarity of the directory structure; second, whether the path contains keywords associated with the rule tags, and whether the position of these keywords in the path has structural rationality, reflecting the embedding strength of semantic identifiers. This index is calculated by taking the absolute average of the path hierarchy numbering differences, and then superimposing the weighted square root value of the path keyword existence and its structural depth score, thereby mapping structural differences and semantic differences to a single value. The lower the value, the more consistent the path structure is with the tag definition; the higher the value, the greater the deviation. Therefore, this index can be used as a criterion for judging the consistency of path and tag matching, and can be used to screen tag path combinations that conform to the standard structural characteristics.

[0085] S313: Based on all record combinations filtered in the tag path consistency index set, group them together by file path and rule tag, perform statistical processing on the number of records in each group, determine whether there are at least two different tools that label the same rule tag and path combination in each group, and if the condition is met, include the corresponding location number, summarize all location number sets that meet the conditions, and obtain the consistency vulnerability confirmation result.

[0086] Based on the confirmed consistent tag path combination records in the tag path consistency index set, a record aggregation operation is performed. First, a composite index is constructed using the source file path field and the rule tag field as primary keys. Then, all source tools under each composite index are counted, and combinations with more than or equal to 2 source tools are selected. This indicates that two or more tools are labeled at the same path and the same tag position. Such combination records are defined as having a consistency hit effect. Subsequently, all corresponding code position numbers in this type of combination are included to generate a consistency hit position number list, while retaining their corresponding paths and tag values ​​to construct a consistency verification list. The list structure uses a three-element identifier method of path + tag + position to uniformly represent it. If a path is jointly labeled by Semgrep and CodeQL at line 45 under the tag "U001", then the record is included. Finally, a total of 27 common one-fatal records are counted, numbered and summarized to obtain the consistency vulnerability confirmation results.

[0087] Please see Figure 5 The specific steps of S4 are as follows:

[0088] S411: Based on the position of each record in the consistency vulnerability confirmation result, extract the corresponding line number from the source file, trace back upwards to locate the function body structure range, determine whether the line where the record is located is in the function declaration block, record the start and end lines of the function body according to the start and end positions of the curly braces structure, retrieve all lines of code in the function body, extract the complete code text in the area as a function fragment representation, and obtain the function body statement fragment set;

[0089] Based on the location of each record in the consistency vulnerability confirmation results, the corresponding line number information is extracted from the source file. First, a path mapping operation is performed on each location number to obtain the complete content of the source file where that location number is located. Then, the upper-level function definition statement is located according to the language structure rules. The function body is marked by matching the function declaration keyword and the opening bracket symbol "{". Then, the search is performed downwards to find the matching closing bracket "}" to mark the end line of the function body. During this process, the nesting level of brackets is counted to ensure the accuracy of the structure closure. The function body range is constructed by obtaining the content of all lines of code within this range. In the actual example, if the record location is line 47 and the source file is in Java, it is necessary to determine whether line 47 is a line ending with "p". Within the structure starting with `publicvoidprocessRequest(){`, if its function body is between line 45 and line 62, all code content between line 45 and line 62 is extracted as the function body fragment corresponding to the vulnerability record. During this process, cases where the complete structure cannot be matched are discarded. For example, if the brackets in a certain code segment are not paired, that position is considered illegal and will not participate in subsequent concatenation statistics. After extraction, the function body text is converted into structural units and stored in a collection, uniformly named with an index identifier for subsequent concatenation processing. In the sample set, there are a total of 86 records, of which 78 successfully extracted function body fragments, and 8 were discarded due to structural incompleteness, as shown in Table 4.

[0090] Table 4 shows examples of successful function body extraction.

[0091] Index Number start line End line Was the extraction successful? R001 45 62 yes R002 13 28 yes R003 71 95 no R004 102 132 yes

[0092] As shown in Table 4, some records were excluded due to structural integrity issues, while the remaining samples were used for context construction, ultimately yielding a set of function body statement fragments.

[0093] S412: Based on the set of function body statement fragments, perform structural parsing operations on the control logic symbols, structural nesting flags and function call statements contained in each function code segment, identify branch jump characters and structural nesting characters, mark the line index and indentation level, and scan all external call statements appearing in the function body. By recording the name of the called function and the number of parameters, establish call summary information, and concatenate the content according to the structural position order to construct a single context block structure corresponding to each sample, thus obtaining the function context concatenation unit.

[0094] Based on the structured code content of each segment in the function body statement fragment set, its semantic structure is subdivided. First, control logic symbols are extracted, and each line of text is scanned for keywords such as if, else, switch, case, and break. If they appear, their line number is recorded, and their corresponding conditional structure type is marked. Simultaneously, the nesting level of curly braces {} in the function body structure is determined, and the nesting depth index of each line of code is constructed. If the function body starts from level 1 and a for loop appears within an if nesting, its depth is counted as 2; if an if loop is contained within a for loop, its depth is counted as 3. Finally, the nesting depth value of each line of code is generated. Simultaneously, call information is analyzed. Call statements such as "call method name (parameters)" are identified through keywords, and the call method name is extracted and its line number, number of parameters, and other information are recorded. Whether it is a cross-module reference, if "processData (userId)" appears, the method name called is extracted as processData, the number of parameters is 1, and the call summary is recorded. Finally, the extracted control structure statements, nested distribution tags and function call summary information are concatenated in the order from top to bottom according to the function body structure to form a context unit that combines structure and semantics. In example R001, the extracted structure is as follows: 3 control statements, maximum nesting depth of 3, 2 function calls, namely validateUser and saveData, corresponding to line numbers 48 and 57. All information is concatenated to form the following fragment: if nested 3 levels, call validateUser → call saveData, the structure is complete, marked as a valid context unit, and finally the function context concatenation unit is obtained.

[0095] S413: Based on the structure content already constructed in the function context splicing unit, number and classify all generated context units according to the sample index, count the number of successfully spliced ​​samples in the current training batch, map them to the training input structure set, record the total number of structure sets and mark the starting index number in the construction of the training corpus, establish a unified structured data structure, and obtain the context training input unit.

[0096] Based on all the constructed content in the function context concatenation unit, each context unit structure is uniformly marked with an index number, and a training number sequence is established. Batch classification is performed on all structure contents according to the number, forming an index-statement pair mapping table. Then, the number of context units that have completed structure concatenation in the current batch is counted, and their original paths and position number mappings are recorded. If the byte length of a function body structure after concatenation exceeds 4096 characters, it is marked as an overflow sample and removed from the training set. In the actual test, out of 78 function body samples, 3 exceeded the maximum length setting, and the remaining 75 samples successfully established context structures. The training number for each context structure is uniformly defined in the structure record table, starting from T0001 and sequentially numbered to T0075. The path and function name information of each sample are also recorded. A training data structure index table is constructed for subsequent input mapping processing, as shown in Table 5.

[0097] Table 5. Context Training Input Unit Construction Record Table

[0098] Training number Original path function name state T0001 / src / user / userService.java processRequest success T0002 / api / auth / loginController.java loginUser success T0003 / data / compute / processor.java calculateData Excessive length rejection T0004 / utils / helper / stringParser.java parseTokens success

[0099] As shown in Table 5, some context units were removed because they exceeded the byte threshold, and the remaining numbers constituted the training set, ultimately obtaining the context training input units.

[0100] Please see Figure 6 The specific steps of S5 are as follows:

[0101] S511: Based on the context training input unit, extract the corresponding rule tags, vulnerability descriptions and remediation suggestions respectively, extract the tag number, description sentence fragment and suggestion sentence content matched by each sample, and assemble the information in order. Use delimiters to divide the structure into content, determine whether the content length exceeds the set length limit and perform pruning and padding, and establish a tag description combination structure.

[0102] The training input unit is context-based. It requires extracting the static code fragment location corresponding to each record from the unit, retrieving the matching field index through a mapping table, and sequentially calling the rule tag, vulnerability description, and remediation suggestion data associated with each code sample. The rule tag is determined by the number field in the tag repository, typically a 5-digit integer. The vulnerability description is extracted from the development security specification document, and text fragments are obtained by searching according to the vulnerability type field. The remediation suggestion content selects matching items from the template suggestion set extracted from the audit report. The three fields are arranged in the order of number-description-suggestion, and are concatenated using double forward slashes " / / " as separators. Finally, it is determined whether the total length after merging the fields exceeds the agreed-upon length limit. The description field has a character limit of 512 characters. When the field exceeds the limit, it is segmented by period and the first three complete sentences are taken as the trimming result. At the same time, it is determined whether the length of the suggestion field is less than 64 characters. If it is insufficient, the general template semantics of the corresponding vulnerability type are retrieved from the suggestion field corpus for semantic filling. For example, when the repair suggestion is only "input validation is incomplete", it needs to be supplemented to "input validation is incomplete, it is recommended to add length judgment and character filtering operation". After the field is completed, each sample merges its context fragment, tag number, description statement and suggestion statement into a four-field data frame. The data frame is stored in a structured format, each field is identified by a tag header, and a field content index is established to form the final tag description combination structure.

[0103] Table 6 Standard Vulnerability Training Sample Field Configuration Table

[0104] Sample number Label number Describe the field length (in characters). Recommended field length (in characters) Whether to cut Fill or not? 00001 20013 528 45 yes yes 00002 10007 476 72 no no 00003 30021 502 61 yes yes

[0105] As shown in Table 6, different numbered samples may trigger pruning logic due to exceeding the character limit during the label description combination process, and it is suggested that the field triggers semantic supplementation strategy due to insufficient lower limit. The structure generated by the three fields has field sequence specification and length boundary control logic.

[0106] S512: Based on the tag description, combine the structure, extract the structural content and concatenate it with the context training input unit, place the context fragment at the beginning of the combination, and concatenate the rule tag number, vulnerability description fragment, and remediation suggestion field in sequence. Map the concatenation result to the unified corpus template format, perform format legality verification on the structure template, exclude missing field and extra field anomalies, and obtain standard corpus sample records.

[0107] Based on the tag description combined structure, its internal four-field content structure needs to be called. Combined with the data order of the source training input unit, field merging is performed. The context training fragment content is placed at the beginning as the starting point for splicing, followed by the tag number, description statement, and suggestion field content. "[##]" is inserted between each field as a field boundary marker to ensure the spliced ​​corpus structure has a fixed separation logic. After splicing, the sample structure is mapped into a unified corpus template. The template field order is fixed as context field, tag field, description field, and suggestion field. Each field in the corpus template has a field marker at the beginning for subsequent structure parsing. Two checks are performed to verify the validity of the structure. First, it is determined whether the number of fields is equal to 4. Second, it is determined whether the length of each field is within a preset threshold. The length of the context field is limited to 1024 characters, the tag field has a fixed length of 5 characters, and the description field does not exceed 512 characters. It is recommended that each field be no shorter than 64 characters. When a field is abnormal, the corpus is excluded, and the error type is recorded in the log as a missing field or a field out of bounds. Valid samples are output by a formatted template. Each formatted corpus entry is presented in JSON structure and written to the standard corpus sample record set. The final standard corpus sample record has a fixed structure specification and field value boundary constraints.

[0108] S513: Based on standard corpus sample records, serialize and store them in the corpus resource directory path structure according to the sample index number order, create a training data storage index list, identify the file name, storage path, and content summary hash information of each sample, perform consistency checks on the number and structure format of the stored sample records, record the total number of samples and the construction completion timestamp, and generate SAST code security training data generation record.

[0109] Based on all data entries that passed the field validity check in the standard corpus sample records, these corpus entries are sorted according to their index numbers assigned in the original input order, and prefixed with numbers according to the sample sequence number. All formatted corpus entries are sequentially written into the corpus resource directory under the specified path structure. The path structure is organized in the format of "project number / sample sequence number". The sample file name is named using the sample number + hash digest. The content digest is obtained by performing SHA-256 hash operation on the string content of the corpus entry and using the hash value to check the content consistency. At the same time, a training data storage index list file is constructed, which records the storage path, file name, hash check value and field digest information of each sample. Then, a consistency check process is performed on all written samples. The hash of each file content is compared with the corresponding value in the index list. If the comparison result is completely consistent and all samples are successfully matched, the sample status flag is updated to "completed" and written to the status file, recording the corpus construction timestamp and the total number of samples. Finally, a SAST code security training data generation record is generated.

[0110] The above are merely preferred embodiments of the present invention and are not intended to limit the present invention in any other way. Any person skilled in the art may make changes or modifications to the above-disclosed technical content to create equivalent embodiments that can be applied to other fields. However, any simple modifications, equivalent changes, and modifications made to the above embodiments based on the technical essence of the present invention without departing from the scope of the present invention shall still fall within the protection scope of the present invention.

Claims

1. A method for generating code security training data based on SAST, characterized in that, Includes the following steps: S1: Obtain the project source code file set, read the source file path identifier, language comment header and update time index, classify the source files by path and filter by language, record and organize the source files that conform to the open source license and belong to the target language, and generate the number of source files that meet the detection requirements. S2: Based on the source file paths included in the number of source files to be detected, perform vulnerability detection processing on the nodes in the control flow graph, syntax structure tree and call relationship graph, collect the results of anomaly markers located in the source files, and generate the number of scan anomaly hits based on merging all anomaly items in the same source file. S3: Based on the location results of the number of abnormal hits in the scan, extract the corresponding scan rule labels and marked location numbers, count all records where the marked paths and rule labels are consistent, filter the record locations with consistent hits, and generate a consistency vulnerability confirmation result. S4: Based on the recorded position in the consistency vulnerability confirmation result, obtain the content of the corresponding function body from the source file, execute the content splicing task in the construction of training input units, record the set size of all spliced ​​training input units, and generate context training input units. S5: Based on the context training input unit, combine it with the corresponding rule tags, description content and repair suggestions to perform the structure construction and sample format standardization of the security training data, and put it into the corpus resource directory according to the unified corpus template to generate SAST code security training data generation record. The specific steps for obtaining the consistency vulnerability confirmation result are as follows: S311: Based on each source file path and corresponding abnormal node index number recorded in the number of scan anomaly hits, retrieve tool annotation information for each abnormal node, extract the bound scan rule tags and corresponding marker position numbers, construct a set of source file path, rule tag, and marker position triplet, and generate a rule position mapping matrix. S312: According to the rule label of each record in the rule position mapping matrix, match the standard label information one by one, verify the label consistency by string full matching, and compare whether the marked path structure is the same as the source file path level. Calculate and obtain the label path consistency difference index, perform path label joint judgment, and if it is less than the path consistency threshold, it can be determined as a consistent label path combination to obtain the label path consistency index set. S313: Based on all record combinations filtered in the label path consistency index set, group them together by file path and rule label, perform statistical processing on the number of records in each group, determine whether there are at least two different tools that label the same rule label and path combination in each group, and if the condition is met, include the corresponding location number, summarize all location number sets that meet the condition, and obtain the consistency vulnerability confirmation result.

2. The method for generating code security training data based on SAST according to claim 1, characterized in that, The number of source files that meet the detection criteria includes the total number of source files, target language types, open-source license types, and path classification tags. The number of scan anomaly hits includes the number of vulnerability nodes, tool hit counts, anomaly type tags, and tool detection coverage. The consistency vulnerability confirmation results include rule tag mapping results, path structure matching results, consistency vulnerability location indexes, and consistency verification rates. The context training input unit includes function body code segments, control logic flags, nested structure levels, and call relationship nodes. The SAST code security training data generation record includes training sample numbers, rule tag sets, security description information, remediation suggestion text, and corpus template format.

3. The method for generating code security training data based on SAST according to claim 1, characterized in that, The open-source license restricts the use of open-source project source code for generating training data.

4. The method for generating code security training data based on SAST according to claim 1, characterized in that, The specific steps for obtaining the number of source files that meet the detection criteria are as follows: S111: Obtain the collection of source code files for the open source platform project, and perform path parsing operation on each source code file in the collection. Match the source file path identifier with the corresponding directory structure, extract the functional module tag and hierarchical index number corresponding to the source code file based on the directory hierarchy keywords contained in the path, perform path classification processing on the source files, and generate a source file path clustering structure set. S112: Based on the source file path clustering structure set, extract the corresponding source code file content in each clustering structure, extract the language comment headers in the source files, match the language type identifier in the comment content with the target language type set, mark the source code files that match successfully as target language files, and compare them according to the update time index in the source file record, and remove source files whose update time index field value is less than the set language validity period benchmark value to obtain the target language source file set; S113: Based on the target language source file set, perform an open source protocol retrieval operation on the beginning of each source file in the set, extract the open source protocol identifier contained therein and match it with a preset set of legal protocols, filter source files whose protocol fields completely belong to the set of legal protocols, count the number of source files that meet the conditions, and obtain the number of source files that meet the detection criteria.

5. The method for generating code security training data based on SAST according to claim 1, characterized in that, The specific steps for obtaining the number of scan anomaly hits are as follows: S211: Based on the source file paths included in the number of source files to be detected, load the source code files specified by each path in sequence, perform structural deconstruction and semantic extraction operations on all nodes in the control flow graph, syntax structure tree and call relationship graph corresponding to the source code, determine whether there are abnormal references in the control branch jump relationship, whether there are uninitialized object accesses or potential resource leakage points in the function call chain, and mark the nodes that meet the abnormal logic pattern to generate a set of structural abnormal markers; S212: Based on the structural anomaly marker set, aggregate the anomaly nodes marked by each type of analysis tool in the same source file, establish tool source index labels and perform merging and reorganization processing on the anomaly node identifiers. By judging whether there is an overlap between the file path to which the node belongs and the semantic expression content of the node, and based on whether the calculated value of the node semantic similarity exceeds the semantic merging threshold, filter out redundant marker information and obtain the same source anomaly node index set. S213: Based on the correspondence between each group of source files and abnormal nodes recorded in the same source abnormal node index set, count the number of abnormal nodes in each source file after being marked and merged by the tool, and classify and map the statistical results according to the file path index to establish the abnormal node number mapping for each source file and obtain the number of scan abnormal hits.

6. The method for generating code security training data based on SAST according to claim 1, characterized in that, The formula for calculating the tag path consistency difference index is as follows: ； in, Indicates the first The consistency difference index of the tag path of each record. Indicates the first The first record of the source path Layer directory number, This represents the first rule tag path in the dictionary. Layer numbering, Indicates the total number of path levels. Indicates the first The first record The existence Boolean flag for each path keyword. Indicates the first The normalized structure depth score corresponding to each path keyword in the path. This indicates the total number of path keywords.

7. The method for generating code security training data based on SAST according to claim 1, characterized in that, The specific steps for obtaining the context training input unit are as follows: S411: Based on the position of each record in the consistency vulnerability confirmation result, extract the corresponding line number from the source file, trace back upwards to locate the function body structure range, determine whether the line where the record is located is in the function declaration block, record the start and end lines of the function body according to the start and end positions of the curly braces structure, retrieve all lines of code in the function body, extract the complete code text in the area as a function fragment representation, and obtain the function body statement fragment set; S412: Based on the set of function body statement fragments, perform structural parsing operations on the control logic symbols, structural nesting flags and function call statements contained in each function code segment, identify branch jump characters and structural nesting characters, mark the line index and indentation level, and scan all external call statements appearing in the function body. Establish call summary information by recording the name of the called function and the number of parameters, and concatenate the content according to the structural position order to construct a single context block structure corresponding to each sample, thereby obtaining the function context concatenation unit. S413: Based on the structure content already constructed in the function context splicing unit, number and classify all generated context units according to the sample index, count the number of successfully spliced ​​samples in the current training batch, map them to the training input structure set, record the total number of the structure set and mark the starting index number in the construction of the training corpus, establish a unified structured data structure, and obtain the context training input unit.

8. The method for generating code security training data based on SAST according to claim 1, characterized in that, The specific steps for obtaining the SAST code security training data generation record are as follows: S511: Based on the context training input unit, extract the corresponding rule tags, vulnerability descriptions and remediation suggestions respectively, extract the tag number, description sentence fragment and suggestion sentence content matched by each sample, and assemble the information in order, use delimiters to divide the structure into content, determine whether the content length exceeds the set length limit and perform trimming and padding, and establish a tag description combination structure. S512: Based on the tag description combined structure, extract the structural content and concatenate it with the context training input unit, place the context fragment at the front of the combined structure, and sequentially concatenate the rule tag number, vulnerability description fragment, and repair suggestion field, and map the concatenation result to the unified corpus template format, perform format legality verification on the structural template, exclude missing field and extra field abnormal items, and obtain standard corpus sample records. S513: Based on the standard corpus sample records, serialize and store them in the corpus resource directory path structure according to the sample index number order, create a training data storage index list, identify the file name, storage path, and content summary hash information of each sample, perform consistency detection on the number and structure format of the stored sample records, record the total number of samples and the construction completion timestamp, and generate a SAST code security training data generation record.

Images