A knowledge graph-based software security hazard detection method and system

Abstract

This invention discloses a software security vulnerability detection method and system based on knowledge graphs. The method includes: defining core entities and key relationships; collecting three types of data—code vulnerabilities, data flow records, and security rules and historical handling documents—and organizing them into "entity tables" and "relationship tables"; automatically recommending potential relationships of unrelated entities during data upload, manually completing a small number of uncertain relationships, and constructing a basic security knowledge graph; detecting vulnerabilities through three methods: using rule-to-graph query statements to find basic vulnerabilities, designing path rules to locate cross-module vulnerabilities, and matching keywords with historical cases to obtain handling solutions; relying on the graph's relationships, matching the vulnerabilities with corresponding historical solutions and security rules to generate standardized guidelines for operation and maintenance remediation; after handling, creating "add entity" and "add relationship" templates, filling in the new content, and uploading them to achieve dynamic graph updates. This lays the foundation for efficient detection.

Description

Technical Field

[0001] This invention belongs to the field of software security testing technology, and more specifically, relates to a method and system for detecting software security vulnerabilities based on knowledge graphs. Background Technology

[0002] In today's rapidly evolving software industry, the complexity and scale of software systems are continuously increasing, shifting from traditional monolithic applications to distributed and microservice architectures, and undergoing frequent iterations and updates. This significantly increases the difficulty of detecting software security vulnerabilities. Currently, traditional software security testing methods still face many unresolved practical problems and struggle to meet the security requirements of complex systems.

[0003] First, existing detection methods largely rely on isolated vulnerability signature libraries or static code scanning rules, lacking in-depth analysis of the relationships between software components. These methods often only identify known single vulnerabilities, failing to detect the cascading risks hidden in component dependencies and data interactions. For example, a minor configuration flaw in one component might affect multiple core modules through the call chain, but traditional detection tools, lacking a view of component relationships, struggle to uncover such cross-module hidden risks, resulting in significant blind spots in security detection.

[0004] Secondly, the detection results are disconnected from business scenarios, making it impossible to effectively assess the actual impact of vulnerabilities. Traditional tools primarily output detection reports focusing on vulnerability type and severity level, without analyzing them in conjunction with the software's business function hierarchy and core process dependencies. When faced with a large number of detection results, operations and development personnel struggle to quickly determine which vulnerabilities directly threaten core business operations, leading to unreasonable resource allocation. Prioritizing the remediation of non-critical vulnerabilities while high-impact vulnerabilities persist increase the risk of business data leaks and service interruptions.

[0005] Finally, there is insufficient adaptability to new security vulnerabilities. As attack methods evolve, unknown vulnerabilities and zero-day vulnerabilities constantly emerge. Traditional detection methods rely on predefined signature libraries, which have long update cycles and struggle to respond quickly to new threats. Simultaneously, dynamic changes to software systems, such as adding third-party components or adjusting business logic, introduce new security risks. However, existing detection methods lack the ability to adapt to these dynamic changes in real time, causing detection results to lag behind the actual security status of the system.

[0006] Against this backdrop, there is an urgent need for a security detection solution that can integrate software-related information, business scenarios, and adapt to dynamic risks, in order to overcome the limitations of existing detection methods, improve the comprehensiveness, accuracy, and practicality of software security vulnerability detection, ensure the stable operation of software systems, and reduce the losses caused by security incidents. Summary of the Invention

[0007] This invention aims to address issues such as the lack of component correlation analysis, the disconnect between hidden dangers and business operations, and insufficient adaptation to new threats in traditional detection methods. By structurally associating security elements, combining business assessments of their impact, and dynamically adapting to changes in risks, it improves the comprehensiveness and accuracy of hidden danger detection, thereby helping to efficiently ensure the security of software systems.

[0008] To address the aforementioned deficiencies or improvement needs of existing technologies, as a first aspect of this invention, the present invention provides a software security vulnerability detection method based on knowledge graphs, comprising:

[0009] S1. First, define the core entities and key relationships; second, collect three types of data, including code vulnerability data, data flow records, and industry-standard security rules and historical vulnerability handling documents, and organize the data in different formats into standardized "entity table" and "relationship table" formats.

[0010] S2. When uploading data, it will automatically analyze and recommend potential relationships between unrelated entities based on entity attribute characteristics; it will only manually complete a small number of relationships that the tool cannot determine, thus completing the construction of a basic security knowledge graph.

[0011] S3. Multi-dimensional software security vulnerability detection is achieved through three methods: First, software security rules are transformed into graph query statements, and the statements are executed to detect basic vulnerabilities; second, path matching rules corresponding to cross-module risks are designed, and the graph's "path query" function is used to locate cross-module related vulnerabilities; third, feature keywords of the vulnerabilities to be detected are extracted and matched with feature keywords of historical cases in the knowledge graph to obtain corresponding handling solutions and complete case analogy detection.

[0012] S4. For the identified security risks, based on the entity relationships in the knowledge graph, the corresponding historical case handling solutions and security rule requirements are automatically matched, and standardized and operable handling guidelines are generated accordingly for operation and maintenance personnel to refer to and complete the risk repair.

[0013] S5. After the safety hazard is handled, two standardized templates are developed for "new entities" and "new relationships". New entities and relationships generated during the handling process are filled in according to the templates, and then the data is uploaded through the graph database template import function to realize the dynamic updating of the knowledge graph.

[0014] Furthermore, the core entities in S1 include software modules, security elements, data links, and historical cases; wherein, the software module refers to the core component unit with independent functions in the software system; the security elements cover the key elements that ensure software security; the data link is the path for data flow in the software system, recording the transmission process and flow status of data between different modules and components; the historical cases refer to past security vulnerability events and corresponding handling records, including information such as historical vulnerability types, handling plans, and repair results.

[0015] Furthermore, the key relationships in S1 include five types of relationships: “module-containment-component”, “vulnerability-impact-module”, “rule-constraint-data link”, “case-correspondence-vulnerability”, and “module-dependency-module”.

[0016] The "module-containment-component" relationship is used to characterize the subordinate relationship between a software module and its internal core components; the "vulnerability-impact-module" relationship is used to reflect the effect of code vulnerabilities on software modules, clarifying the scope of modules affected by vulnerabilities; the "rule-constraint-data link" relationship is used to define the control relationship of security rules on data flow paths, and to standardize the security requirements that data links must follow; the "case-correspondence-vulnerability" relationship is used to establish the matching relationship between historical cases and related vulnerabilities, clarifying the type of vulnerability targeted by the case; the "module-dependency-module" relationship is used to describe the functional dependency relationship between different software modules, reflecting the collaboration logic between modules.

[0017] Furthermore, the specific process in S1 of unifying data of different formats into standardized "entity table" and "relationship table" formats is as follows:

[0018] To achieve standardized transformation of collected data into "entity tables" and "relationship tables," a mapping model between data features and entity / relationship attributes is established, as follows:

[0019] Let the collected data set be It contains three types of raw information: code vulnerability data, data flow records, and security rules and historical case data; the core entity set is... It covers four core entities: software modules, security elements, data links, and historical cases. Based on this, entity attribute mapping functions are defined:

[0020] ,

[0021] in, An attribute that represents a certain type of entity; These are descriptive features of the attributes of this type of entity; For the matching function, when collecting data Includes entity attribute description features When the information is consistent, the result is 1; otherwise, it is 0. This function extracts information that meets the entity attribute requirements from the collected data by matching data features with entity attribute descriptions and aggregating them to form the attribute values ​​of the corresponding entities in the "entity table".

[0022] Let the set of key relationships be... It contains different association types; the entity pair set is It is composed of pairs of different entities from the core entity set, and the relation feature matching function is defined accordingly:

[0023] ,

[0024] in, Describe the characteristics of a certain type of relationship; It is data collection The middle also involves entity pairs The function determines the entity pair by judging whether the entity pair contains relational features. Corresponding relation type Then, the entities and their corresponding relationships are filled into the "relationship table" to complete the standardized processing of the relationship data.

[0025] Furthermore, the specific process in S2 of automatically analyzing and recommending potential relationships between unrelated entities based on entity attribute features is as follows:

[0026] After S1 standardization, let the unrelated entities to be analyzed be entities. With entity The attribute sets of the two are as follows:

[0027] ,

[0028] Each attribute item corresponds to the attribute definition of the core entity in S1; first, the entity attribute similarity function is defined:

[0029] ,

[0030] in, Representing entities Attribute Collection The first in Each attribute item; Representing entities Attribute Collection The first in The function quantifies the degree of correlation between two entities at the attribute level by calculating the ratio of the number of completely matching attribute items in the attribute sets of the two entities to the maximum number of elements in the attribute sets of the two entities. The higher the ratio, the stronger the consistency of the two entities in the core attributes, and the greater the possibility of a potential relationship.

[0031] Next, based on the key relation set R defined in S1, each type of relation is... Preset attribute association feature set ;

[0032] Define relation feature adaptation function:

[0033] ,

[0034] This function determines the entity. With entity After the attribute sets are combined, does it contain a certain type of relation? All required attribute association features—if they are included, it means that the attribute features of both parties meet the logical requirements of the relationship, and the fit is 1; otherwise, the fit is 0.

[0035] Finally, construct the potential relationship recommendation decision function:

[0036] ,

[0037] in, This is a threshold derived from the statistical similarity of historical associated entity attributes in S1; when the entity With entity When the attribute similarity exceeds a threshold and the feature fit with a certain type of relation r is 1, the relation... This means that a potential relationship is identified between two entities, and a recommendation result is output.

[0038] Furthermore, the specific process of converting software security rules into graph query statements and executing these statements to detect fundamental vulnerabilities in S3 is as follows:

[0039] Let G be the set of software security rules defined in S1, and let each rule... It includes rule constraint objects and constraint conditions; the core entity set constructed by S1 is E, the key relationship set is R, and the entity attribute set in the "entity table" is denoted as A;

[0040] First, define the rule-entity-relationship mapping function. ,in For rules The core entity corresponding to the constraint object, For rules The corresponding key relationship: by matching the rule constraint object with the core entity type, the rule constraint logic with the key relationship connotation, this function transforms each security rule into a corresponding combination of "entity-relationship", providing core elements for the construction of graph query statements;

[0041] Based on the above mapping results, define a graph query statement generation function:

[0042] ,

[0043] in, For rules Entity attribute filtering conditions for constraint transformation The logic for generating graph query statements uses the entities obtained through mapping. ,relation As the subject of the query, with Generate a word search statement that conforms to the syntax of the graph database, based on the filtering criteria;

[0044] Finally, define the basic hazard detection verification function:

[0045] ,

[0046] This function executes the generated graph query statement; if the query result is not empty, it means that there are entity records that meet the "entity attributes do not meet the rule constraints", which is determined to be a basic security risk and recorded as risk; if the query result is empty, it means that all related entities meet the rule constraints, which is determined to be a basic security risk and recorded as safe.

[0047] Furthermore, the path matching rules corresponding to cross-module risks in S3 are specifically as follows:

[0048] First, determine whether the module flow of the data link meets the basic conditions for risk triggering; based on the "module-dependency-module" relationship defined in S1, check whether there is a module sub-sequence in the module sequence through which the data flows that is consistent with the requirements of the cross-module risk rules;

[0049] Next, determine whether the data link violates security constraints; compare the data link attributes recorded in the S1 "Entity Table" to check whether the link does not meet the constraint requirements in the cross-module risk rules;

[0050] A data link is considered a cross-module risk path only if it simultaneously meets both the conditions of "having a compliant module sub-sequence" and "violating security constraints". Otherwise, it is not considered a risk path.

[0051] Furthermore, the specific process of case analogy detection in S3 is as follows:

[0052] Let C be the set of historical cases in S1, and let each case... Includes a set of characteristic keywords The safety element entity corresponding to the potential hazard to be detected is Its set of characteristic keywords is ;

[0053] First, define the feature intersection function:

[0054] ,

[0055] This function extracts the common feature keywords between the potential hazards to be detected and historical cases. The more overlapping elements there are, the higher the degree of overlap between the two in terms of core features.

[0056] Next, we define the feature dimension set as D, and define the dimension coverage function:

[0057] ,

[0058] This function determines whether the feature intersection covers all preset dimensions—if it does, it means the two overlap in all key dimensions, and the matching is comprehensive; otherwise, there are missing dimensions. Finally, the case analogy decision function is defined:

[0059] ,

[0060] When the potential hazard to be detected shares common characteristic keywords with a historical case, and these keywords cover all preset dimensions, the two are considered to be matched and recorded as "match". The handling plan of the historical case can be used as a reference. Otherwise, they are considered to be mismatched and recorded as "mismatch".

[0061] As a second aspect of the present invention, a software security vulnerability detection system based on knowledge graphs is also provided, comprising:

[0062] The entity relationship definition and standardized unit are used to first complete the definition of core entities and key relationships; secondly, to collect three types of data, including code vulnerability data, data flow records, and industry-standard security rules and historical vulnerability handling documents, and to unify the different formats of data into standardized formats of "entity table" and "relationship table".

[0063] The basic knowledge graph construction unit is used to automatically analyze and recommend potential relationships between unrelated entities based on entity attribute features during data upload; it only manually completes a small number of relationships that the tool cannot determine, thus completing the construction of the basic security knowledge graph.

[0064] The multi-dimensional vulnerability identification unit is used to complete the detection of multi-dimensional software security vulnerabilities in three ways: First, it transforms software security rules into graph query statements and executes the statements to detect basic vulnerabilities; second, it designs path matching rules corresponding to cross-module risks and uses the graph's "path query" function to locate cross-module related vulnerabilities; third, it extracts the feature keywords of the vulnerabilities to be detected, matches them with the feature keywords of historical cases in the knowledge graph, obtains the corresponding handling solutions, and completes case analogy detection.

[0065] The standardized remediation guide generation unit is used to automatically match the corresponding historical case handling solutions and security rule requirements based on the entity association relationships in the knowledge graph for the detected and identified security risks. Based on this, it generates standardized and operable handling guidelines for operation and maintenance personnel to refer to and complete the remediation of risks.

[0066] The knowledge graph dynamic update unit is used to develop two standardized templates for "new entities" and "new relationships" after the handling of security risks is completed. New entities and relationships generated during the handling process are filled in according to the templates, and then the data is uploaded through the graph database template import function to realize the dynamic update of the knowledge graph.

[0067] As a third aspect of the invention, a computer-readable storage medium is also provided, on which a computer program is stored, wherein the computer program is executed by a processor of any step of the knowledge graph-based software security vulnerability detection method.

[0068] In summary, compared with the prior art, the above-described technical solutions conceived by this invention can achieve the following beneficial effects:

[0069] 1. This invention discloses a software security vulnerability detection method based on a knowledge graph. It defines core entities and key relationships, collects three types of data: code vulnerability data, data flow records, and industry-standard security rules and historical vulnerability handling documents. The method unifies the different data formats into standardized "entity tables" and "relationship tables." Simultaneously, during data upload, it automatically recommends potential relationships between unrelated entities and manually completes a few relationships that tools cannot determine, thus constructing a basic security knowledge graph. This process solves the problems of messy data formats and missing relational information in traditional detection methods, providing standardized and structured data support for subsequent vulnerability detection. It reduces the cost of manual data processing and ensures the integrity of entities and relationships in the knowledge graph, laying the foundation for efficient detection.

[0070] 2. This invention provides a software security vulnerability detection method based on a knowledge graph. It identifies software security vulnerabilities through three multi-dimensional detection methods: converting software security rules into graph query statements to detect basic vulnerabilities; designing cross-module risk path matching rules and utilizing the graph's "path query" function to locate cross-module related vulnerabilities; and extracting feature keywords of the vulnerabilities to be detected and matching them with keywords from historical cases in the graph to complete case analogy detection. This technology overcomes the limitations of traditional single detection methods, not only accurately identifying basic explicit vulnerabilities but also capturing implicit cross-module related risks. Furthermore, it leverages historical cases to quickly obtain handling directions, significantly improving the comprehensiveness and targeting of vulnerability detection and avoiding the problems of missed detections, false detections, or unclear detection directions in traditional detection methods.

[0071] 3. This invention provides a knowledge graph-based software security vulnerability detection method. By relying on the entity relationships in the knowledge graph, it automatically matches historical case handling plans and security rule requirements for detected security vulnerabilities, generating standardized and operable handling guidelines. Simultaneously, after vulnerability handling is completed, new data is organized using two standardized templates: "Adding Entities" and "Adding Relationships," and the knowledge graph is dynamically updated through the graph database import function. This design avoids the problem of non-standard handling caused by maintenance personnel making decisions based on experience, reduces the difficulty of vulnerability remediation, and improves handling efficiency. Furthermore, it allows the knowledge graph to continuously adapt to changes in the software security environment, ensuring that subsequent detection and handling are always supported by the latest knowledge, forming a virtuous cycle of "detection-handling-update." Attached Figure Description

[0072] Figure 1 This is a flowchart of a software security vulnerability detection method based on knowledge graphs according to an embodiment of the present invention;

[0073] Figure 2 This is a diagram illustrating the access point in an embodiment of the present invention.

[0074] Figure 3 This is a schematic diagram of the system units in an embodiment of the present invention. Detailed Implementation

[0075] 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. Furthermore, the technical features involved in the various embodiments of this invention described below can be combined with each other as long as they do not conflict with each other.

[0076] Example 1

[0077] Please refer to Figure 1 This embodiment 1 provides a software security vulnerability detection method based on knowledge graphs, including:

[0078] S1. First, define the core entities and key relationships; second, collect three types of data, including code vulnerability data, data flow records, and industry-standard security rules and historical vulnerability handling documents, and organize the data in different formats into standardized "entity table" and "relationship table" formats.

[0079] S2. When uploading data, it will automatically analyze and recommend potential relationships between unrelated entities based on entity attribute characteristics; it will only manually complete a small number of relationships that the tool cannot determine, thus completing the construction of a basic security knowledge graph.

[0080] S3. Multi-dimensional software security vulnerability detection is achieved through three methods: First, software security rules are transformed into graph query statements, and the statements are executed to detect basic vulnerabilities; second, path matching rules corresponding to cross-module risks are designed, and the graph's "path query" function is used to locate cross-module related vulnerabilities; third, feature keywords of the vulnerabilities to be detected are extracted and matched with feature keywords of historical cases in the knowledge graph to obtain corresponding handling solutions and complete case analogy detection.

[0081] S4. For the identified security risks, based on the entity relationships in the knowledge graph, the corresponding historical case handling solutions and security rule requirements are automatically matched, and standardized and operable handling guidelines are generated accordingly for operation and maintenance personnel to refer to and complete the risk repair.

[0082] S5. After the safety hazard is handled, two standardized templates are developed for "new entities" and "new relationships". New entities and relationships generated during the handling process are filled in according to the templates, and then the data is uploaded through the graph database template import function to realize the dynamic updating of the knowledge graph.

[0083] This embodiment 1 further elaborates on the above steps.

[0084] (1) Definition and standardization of entity relationships

[0085] In the method of this embodiment 1, the clear definition of core entities and key relationships, and the standardized processing of multi-source data are the foundation for constructing an effective knowledge graph, and also the key link to solve problems such as "dispersed and disordered data", "fuzzy entity associations" and "difficulty in tracing hidden dangers" in traditional software security testing.

[0086] First, it is necessary to define and clarify the core entities and key relationships. Core entities encompass four categories, corresponding to the core elements of software system security management: Software modules are independent functional units within a software system, such as business processing modules and data storage modules; their functional integrity directly impacts the overall operational security of the software. Security elements include key aspects of software security such as code vulnerabilities, security rules, and permission configurations, serving as the core basis for identifying security risks. Data links record the flow path and status of data between different modules and components; their compliance determines the security of data transmission. Historical cases integrate past security incidents and their handling records, including vulnerability types, remediation plans, and handling results, providing reference experience for current vulnerability handling.

[0087] Key relationships focus on the core logical connections between entities, categorized into five types: "Module-Containment-Component" relationships clarify the hierarchical relationship between a software module and its internal components, addressing the problem of "unclear module functional composition and difficulty in locating component risks"; "Vulnerability-Impact-Module" relationships reflect the scope of a code vulnerability's impact on a module, avoiding situations where "vacuum-defined vulnerability impact boundaries make it impossible to accurately identify affected modules"; "Rule-Constraint-Data Link" relationships standardize the control requirements of security rules on data flow, ensuring that data links comply with security standards; "Case-Correspondence-Vulnerability" relationships establish a match between historical cases and vulnerability types, addressing the problem of "difficulty in reusing past handling experience"; and "Module-Dependency-Module" relationships describe the functional dependencies between modules, clarifying module collaboration logic and providing a basis for analyzing cross-module risks.

[0088] After completing the above definitions, the three types of collected data (code vulnerability data, data flow records, and industry-standard security rules and historical vulnerability handling documents) need to be standardized and organized into "entity tables" and "relationship tables." In traditional detection, these data often cannot be efficiently correlated and analyzed due to inconsistent formats and scattered information. Standardization can solve this problem, giving the data structured and relational characteristics.

[0089] Specifically, the process of unifying data of different formats into standardized "entity tables" and "relationship tables" formats is as follows:

[0090] To achieve standardized transformation of collected data into "entity tables" and "relationship tables," a mapping model between data features and entity / relationship attributes is established, as follows:

[0091] Let the collected data set be It contains three types of raw information: code vulnerability data, data flow records, and security rules and historical case data; the core entity set is... It covers four core entities: software modules, security elements, data links, and historical cases. Based on this, entity attribute mapping functions are defined:

[0092] ,

[0093] in, Attributes that represent a certain type of entity, such as the "name" and "functional description" of a software module, and the "type" and "risk characteristics" of a security element; These are descriptive features of the entity's attributes, such as "the business domain to which the module belongs" and "the vulnerability triggering scenario"; For the matching function, when collecting data Includes entity attribute description features When the information is consistent, the result is 1; otherwise, it is 0. This function extracts information that meets the entity attribute requirements from the collected data by matching data features with entity attribute descriptions and aggregating them to form the attribute values ​​of the corresponding entities in the "entity table".

[0094] Let the set of key relationships be... It contains different association types; the entity pair set is It is composed of pairs of different entities from the core entity set, and the relation feature matching function is defined accordingly:

[0095] ,

[0096] in, Characteristics that indicate a certain type of relationship, such as "the subordinate relationship between modules and components" or "the relationship between the impact of vulnerabilities on the functionality of modules"; It is data collection The middle also involves entity pairs The function determines the entity pair by checking whether the associated information includes relational characteristics, such as "the demand matching module contains API interface components" or "SQL injection vulnerability causes the demand matching module to malfunction". Corresponding relation type Then, the entities and their corresponding relationships are filled into the "relationship table" to complete the standardized processing of the relationship data.

[0097] This series of processes not only solved the problems of chaotic multi-source data formats and ambiguous entity relationships, but also provided structured data support for subsequent knowledge graph construction, enabling software security testing to shift from "fragmented investigation" to "system correlation analysis," greatly improving the accuracy and efficiency of hidden danger detection, and laying a solid foundation for ensuring the safe operation of software systems.

[0098] (2) Construction of basic maps

[0099] In the data upload stage, the core step of automatically analyzing the potential relationships between unrelated entities through entity attribute features, and then supplementing it with a small amount of manual completion to build a basic security knowledge graph, is to overcome the pain points of traditional software security management such as "isolated and unrelated entities, low efficiency of manual sorting, and difficulty in reusing knowledge accumulation".

[0100] In traditional models, entities in software systems (such as modules, vulnerabilities, and rules) are often stored in a scattered manner, and the relationships between entities need to be manually sorted out one by one. This is not only time-consuming and labor-intensive, but also prone to omissions or misjudgments due to differences in human experience, thus affecting the comprehensiveness of subsequent risk assessment. The process of automatically analyzing and recommending potential relationships, however, is based on standardized entity data. Through dual verification of attribute associations and relationship logic, it efficiently locates reasonable relationships between entities, significantly reducing manual costs and improving the accuracy of relationship matching.

[0101] Specifically, the process of automatically analyzing and recommending potential relationships between unrelated entities based on entity attribute features is as follows:

[0102] After S1 standardization, let the unrelated entities to be analyzed be entities. With entity The attribute sets of the two are as follows:

[0103] ,

[0104] Each attribute item corresponds to the attribute definition of the core entity in S1 (such as the "functional domain" and "business scenario" of a software module, and the "risk impact scope" and "triggering conditions" of a security element); first, the entity attribute similarity function is defined:

[0105]

[0106] in, Representing entities Attribute Collection The first in Each attribute item; Representing entities Attribute Collection The first in The function quantifies the degree of correlation between two entities at the attribute level by calculating the ratio of the number of completely matching attribute items in the attribute sets of the two entities to the maximum number of elements in the attribute sets of the two entities. The higher the ratio, the stronger the consistency of the two entities in the core attributes, and the greater the possibility of a potential relationship.

[0107] Next, based on the key relation set R defined in S1, each type of relation is... Preset attribute association feature set (For example, the feature set of the relationship "module-containment-component" is "component functionality belongs to a subset of module functionality" and "component deployment depends on module resources", while the feature set of the relationship "vulnerability-impact-module" is "vulnerability triggering scope covers the module's business domain" and "vulnerability affects the module's core functionality").

[0108] Define relation feature adaptation function:

[0109] ,

[0110] This function determines the entity. With entity After the attribute sets are combined, does it contain a certain type of relation? All required attribute association features—if they are included, it means that the attribute features of both parties meet the logical requirements of the relationship, and the fit is 1; otherwise, the fit is 0.

[0111] Finally, construct the potential relationship recommendation decision function:

[0112] ,

[0113] in, The threshold is derived from the statistical similarity of historical associated entity attributes in S1 (e.g., by analyzing the attribute similarity of entity pairs with a known "module-containment-component" relationship, taking the minimum value as θ); when the entity With entity When the attribute similarity exceeds a threshold and the feature fit with a certain type of relation r is 1, the relation... This means that a potential relationship is identified between two entities, and a recommendation result is output.

[0114] Through automated analysis, the vast majority of entity relationships can be quickly identified. Only a small number of relationships that the tool cannot determine due to incomplete attribute information or complex relationship characteristics require manual completion. Finally, all entities and identified relationships are integrated to form a basic security knowledge graph. This graph structures the scattered entities and relationships, solving the problem of "fragmented" knowledge in the software security field, enabling subsequent vulnerability detection to quickly trace risks and locate problems based on entity associations.

[0115] (3) Multi-dimensional hazard identification

[0116] In software security vulnerability detection, three types of differentiated detection methods complement each other, and the core is to solve the pain points of traditional detection such as "incomplete coverage, inaccurate positioning, and lack of evidence for handling"—it avoids the omission of basic vulnerabilities due to human verification, breaks through the bottleneck of cross-module risks being difficult to track, and enables the rapid reuse of historical experience in vulnerability handling, thus building a full-process protection system for software security.

[0117] The first type of basic vulnerability detection essentially transforms abstract security rules into actionable graph query actions, solving the problems of "difficult rule execution and low efficiency of manual verification." In the traditional model, software security rules (such as "sensitive data must be encrypted" and "interface parameters must be verified") rely heavily on manual, item-by-item verification, which is not only time-consuming but also prone to omissions due to differences in human experience. However, by leveraging knowledge graphs, each rule is first mapped to entities (such as data links and software modules) and relationships (such as "rule-constraint-data link") in the graph, clarifying the core object of the query. Then, the rule requirements are transformed into filtering conditions for entity attributes (such as "data type = sensitive data and encryption status = unencrypted"), generating an executable query statement for the graph. After executing the statement, if an entity matching the conditions is found, it indicates a basic vulnerability where the rule is not met; if no result is found, it indicates that the rule has been effectively implemented. This approach shifts rule verification from "subjective human judgment" to "objective data matching," significantly improving detection efficiency while avoiding omissions caused by human error.

[0118] Specifically, the process of converting software security rules into graph query statements and executing these statements to detect basic vulnerabilities is as follows:

[0119] Let G be the set of software security rules defined in S1, and let each rule... It includes rule constraint objects (such as data links and software modules) and constraint conditions (such as "sensitive data flow must be encrypted" and "module interface must verify parameters"); the core entity set constructed by S1 is E (including software modules, data links, etc.), the key relationship set is R (including "rule-constraint-data link" and "vulnerability-impact-module", etc.), and the entity attribute set in the "entity table" is denoted as A (such as the "data type" and "encryption status" of the data link, and the "interface verification method" of the module).

[0120] First, define the rule-entity-relationship mapping function. ,in For rules The core entity corresponding to the constraint object (e.g., the constraint object of the rule "sensitive data transfer must be encrypted" is the data link, i.e., e is the data link entity), For rules The corresponding key relationships (such as the "rule-constraint-data link" relationship corresponding to the above rules, i.e., r is this type of relationship) are used to transform each security rule into a corresponding combination of "entity-relationship" by matching the rule constraint object with the core entity type, the rule constraint logic with the connotation of the key relationship, thus providing core elements for the construction of graph query statements.

[0121] Based on the above mapping results, define a graph query statement generation function:

[0122] ,

[0123] in, For rules The entity attribute filtering conditions transformed from constraints (e.g., the constraint condition of the rule "sensitive data transfer requires encryption" is transformed into "the data link entity's "data type" = sensitive data and "encryption status" = unencrypted") The logic for generating graph query statements uses the entities obtained through mapping. ,relation As the subject of the query, with To filter the data, generate a query statement that conforms to the graph database syntax (e.g., matching records in the "data link" entity that satisfy "data type" = sensitive data and "encryption status" = unencrypted, and where the "security rule" has a "rule-constraint-data link" relationship).

[0124] Finally, define the basic hazard detection verification function:

[0125] ,

[0126] This function executes the generated graph query statement; if the query result is not empty, it means that there are entity records that meet the "entity attributes do not meet the rule constraints", which is determined to be a basic security risk and recorded as risk; if the query result is empty, it means that all related entities meet the rule constraints, which is determined to be a basic security risk and recorded as safe.

[0127] The second type of cross-module correlation risk detection utilizes the knowledge graph's "path query" function to locate flow risks, addressing the issues of "difficulty in tracing risks between modules and easy concealment of correlation risks." In software systems, data flows between multiple modules (e.g., from the access module to the processing module and then to the storage module). Cross-module risks are often hidden within these flow paths. Traditional detection methods can only check individual modules and cannot trace the correlation risks between modules. Based on the knowledge graph, it first checks whether the module flow sequence of the data link contains sub-sequences required by risk rules based on the "module-dependency-module" relationship (e.g., if the rule focuses on the flow risk of "access module → processing module," it checks whether the link contains such a sub-sequence). Then, it compares the attributes of the data link (e.g., encryption status, permission verification status) to determine whether security constraints are violated. Only when both conditions of "existence of a risky sub-sequence" and "violation of constraints" are met is it determined to be a cross-module risk path. This method can accurately pinpoint risk nodes in the flow between modules, preventing cross-module risks from being overlooked due to "isolated investigation."

[0128] The third type of case analogy detection addresses the problem of "no reference for vulnerability handling and low efficiency in solution development" by reusing historical handling experience through feature matching. In traditional vulnerability handling, operations and maintenance personnel often need to analyze vulnerabilities and develop solutions from scratch, which is not only time-consuming but may also lead to unreasonable solutions due to insufficient experience. However, historical cases stored in the knowledge graph contain key information such as vulnerability type, affected modules, and handling solutions. During detection, feature keywords (such as vulnerability type and affected modules) are first extracted from the vulnerability to be detected, and then compared with the keywords of historical cases. If common keywords cover core dimensions such as "vulnerability type" and "scope of impact," it indicates a high degree of similarity, and the handling solution of the historical case can be directly used as a reference.

[0129] Specifically, the process of case analogy testing is as follows:

[0130] Let C be the set of historical cases in S1, and let each case... Includes a set of characteristic keywords (Such as vulnerability type, affected modules, triggering scenarios, etc., derived from the attributes of historical cases in the S1 "Entity Table"); the security element entity corresponding to the vulnerability to be detected is... Its set of characteristic keywords is (Extracted from potential hazards to be detected, and) (The keywords should be consistent, such as including vulnerability type, affected modules, etc.)

[0131] First, define the feature intersection function:

[0132] ,

[0133] This function extracts the common feature keywords between the potential hazards to be detected and historical cases. The more overlapping elements there are, the higher the degree of overlap between the two in terms of core features.

[0134] Next, define the feature dimension set as D (i.e., the feature keyword dimensions common to all historical cases and the vulnerabilities to be detected, such as "vulnerability type", "affected module", "triggering condition", etc., derived from the attribute definitions of historical case entities in S1), and define the dimension coverage function:

[0135] ,

[0136] This function determines whether the feature intersection covers all preset dimensions—if it does, it means the two overlap in all key dimensions, and the matching is comprehensive; otherwise, there are missing dimensions. Finally, the case analogy decision function is defined:

[0137] ,

[0138] When the potential hazard to be detected shares common characteristic keywords with a historical case, and these keywords cover all preset dimensions, the two are considered to be matched and recorded as "match". The handling plan of the historical case can be used as a reference. Otherwise, they are considered to be mismatched and recorded as "mismatch".

[0139] This process shifts hazard management from "experience-driven" to "data-driven," shortening the time required to develop solutions, ensuring the rationality of response measures, and enabling the efficient reuse of historical safety knowledge.

[0140] (4) Generation of standardized repair guidelines

[0141] After completing the multi-dimensional detection of software security vulnerabilities, the core step is to transform the detection results into actionable remediation actions. This process relies on the entity association capabilities of knowledge graphs to solve the pain points of "fragmented handling solutions", "inconsistent remediation standards" and "difficulty in reusing experience" in traditional operations and maintenance, ensuring that vulnerability remediation is accurate, efficient and compliant with regulations.

[0142] First, a knowledge graph is used to construct a link between potential vulnerabilities and resources for handling them. Each type of security vulnerability identified is mapped to a specific entity in the knowledge graph. For example, an "SQL injection vulnerability" is associated with the affected "demand matching module" entity, the corresponding "vulnerability-impact-module" relationship, and historical case entities matched during detection. Based on these relationships, the system automatically traces two core handling criteria: one is historical case handling plans, which are the remediation steps, tools used, verification methods, and remediation results recorded in historical cases in the knowledge graph that match the current vulnerability characteristics. For example, the "interface parameter filtering configuration + vulnerability reproduction verification" plan for a similar SQL injection vulnerability in 2024; the other is security rule requirements, which are the industry security rules corresponding to the associated "rule-constraint-module" relationship, such as hard requirements like "user input parameters must be filtered by regular expressions" and "vulnerability remediation must be verified through penetration testing."

[0143] Next, the system integrates and standardizes the handling criteria. It deduplicates and complements the matched historical solutions and security rules—if different historical cases have similar remediation steps, the optimal process is retained; if security rules have specific requirements for remediation accuracy (such as "filtering rules must cover common injection characters"), they are converted into actionable step details. Simultaneously, it supplements adaptation information based on the specific scenario of the current vulnerability, such as the version information of the affected modules and the compatibility requirements of related components, to avoid the "scenario mismatch" problem that may occur when directly reusing historical solutions.

[0144] Subsequently, a standardized handling guide was generated. The guide is presented in a clear, step-by-step format, with four core parts: First, basic information about the potential hazard, clearly defining the hazard type, affected entities (modules / data links), and risk level to help operations personnel quickly locate the problem; second, preconditions for remediation, listing the required tools (such as code auditing tools, configuration management platforms), permissions (such as module code modification permissions), and environmental requirements (such as test environment image configuration); third, a step-by-step remediation process, clearly defining the operation content, execution standards, and judgment criteria for each step, for example, "Step 1: Locate the interface with unfiltered parameters in the module using code auditing tools; standard: the interface list must include all user input entry points"; "Step 2: Configure regular expression filtering rules; standard: the rules must cover 10 common injection characters such as single quotes and double quotes"; fourth, verification and rollback solutions, specifying the verification methods after remediation (such as penetration test cases, functional regression scope) and rollback steps for abnormal situations (such as restoring the backup configuration file path).

[0145] Finally, the operations and maintenance personnel completed the remediation according to the guidelines. The standardized nature of the guidelines ensures that operations and maintenance personnel with different experience levels can uniformly perform the remediation actions, avoiding incomplete remediation due to differences in individual experience. After the remediation is completed, the remediation results reported by the operations and maintenance personnel (such as the reasons for verification success / failure) will be synchronously transmitted back to the knowledge graph, providing data support for the optimization of subsequent handling plans and forming a closed-loop management of "detection-handling-feedback".

[0146] This process achieves precise matching of disposal resources through the association capabilities of knowledge graphs, solves the problem of inconsistent repair actions through standardized transformation, and ultimately shifts the repair of hidden dangers from "relying on personal experience" to "relying on standardized knowledge", which greatly improves the efficiency and quality of repair. At the same time, the accumulated repair data further enhances the practical value of knowledge graphs.

[0147] (5) Dynamic updates of knowledge graph

[0148] After security vulnerabilities are addressed, new entity information (such as new vulnerabilities and new security components) and entity relationships (such as "new vulnerability - impact - new module" and "security component - protection - data link") are generated. This information is an important supplement to the knowledge graph. Dynamic updates are achieved by combining standardized templates with graph database imports. The core solution is to address the problems of "scattered accumulation of new information, lagging graph content, and lack of new data support for subsequent detection," ensuring that the knowledge graph can continuously adapt to new software security protection needs.

[0149] First, two standardized templates were developed: one for "New Entities" and the other for "New Relationships." The template design must align with the actual scenarios of security vulnerability handling, ensuring coverage of the core dimensions of new information and avoiding incomplete information due to missing fields. The "New Entities" template explicitly defines fixed fields. For example, for the "New Vulnerability" entity, fields include vulnerability name, vulnerability type (e.g., SQL injection, buffer overflow), risk level (e.g., high-risk, medium-risk), discovery time, and a description of the impact scope. For the "New Security Component" entity, fields include component name, component function (e.g., data encryption, permission verification), deployment module, and version number. These fields maintain consistency with the attribute dimensions of similar entities in the existing knowledge graph, ensuring that new entities can form effective associations with existing entities. The "New Relationships" template focuses on the relationship logic between entities. Fixed fields include source entity name, target entity name, relationship type (selected from previously defined key relationships, such as "vulnerability-impact-module" or "component-protection-link"), relationship description (e.g., "A new vulnerability causes a delay in the user authentication module response"), and establishment basis (e.g., handling report number, test verification record), avoiding graph confusion due to non-standard relationship definitions.

[0150] Next, the team fills in the new entity and relationship information according to the template. The vulnerability handling team extracts new information from various documents throughout the handling process (such as remediation reports, test records, and component deployment instructions), and fills in the corresponding template fields one by one. For example, after handling a "logic vulnerability," if an "abnormal request interception component" is added, forming a "interception component - protection - user login module" relationship, the team will fill in the component's name, function, deployment module, etc., in the "Add Entity" template, and clearly define the source entity (interception component), target entity (user login module), relationship type (component - protection - module), and relationship description in the "Add Relationship" template. During the filling process, the team must refer to the entity naming conventions of the previous knowledge graph (such as using the "business domain + function" format for module names) and relationship definition standards to ensure that the new information is consistent with the existing graph content format and avoid matching errors during subsequent import.

[0151] Finally, data is uploaded using the graph database template import function to complete the graph update. The graph database's template import function supports batch reading of data according to preset formats, eliminating the need for manual entry and significantly improving update efficiency. During operation, first upload the completed "Add Entity" and "Add Relationship" template files (such as CSV or JSON formats) to the graph database management platform, select the corresponding import template (matching the previously defined standardized template), and the system will automatically verify the completeness of the template fields and the correctness of the data format—if there are missing fields or format errors (such as the risk level being entered as "high" instead of "high risk"), it will prompt for correction; after successful verification, the system will automatically integrate the new entity as a node and the new relationship as an edge into the existing knowledge graph, establishing associations between the new entity and existing entities (such as the association between a new vulnerability and an affected module, or the association between a new component and a deployment module).

[0152] The entire update process ensures the standardization of new information through standardized templates and achieves efficient uploading through graph database import functionality. Ultimately, this allows the knowledge graph to absorb new experiences and data generated from vulnerability handling in real time. This not only solves the problems of "slow updates and outdated content" in traditional knowledge graphs but also provides more comprehensive knowledge support for subsequent software security vulnerability detection. For example, when encountering similar new vulnerabilities in the future, the existing vulnerability information and handling associations in the graph can quickly assist in detection and solution matching, forming a virtuous cycle of "handling-updating-reapplication" and continuously improving the accuracy and efficiency of software security protection.

[0153] Please refer to Figure 2The security vulnerability detection method in Embodiment 1 can fully demonstrate its value in complex network architectures with multiple regions and business modules, such as the private cloud platform shown in the figure. Taking this platform as an example, the terminals and devices in the business area and operation and maintenance area correspond to the "software module" entities in the method. Their functional interactions and data flow paths constitute the concrete basis of the "module-dependency-module" and "data link" relationships in the knowledge graph. The application servers and database servers in the server area are the underlying support units of the "software modules". Their potential system and database vulnerabilities belong to the "security element" entities, providing associated objects for the "vulnerability-impact-module" relationship. The security tools such as cloud bastion hosts and cloud EDR in the security management area correspond to the "security rule" entities, which are the source of constraints for the "rule-constraint-data link" relationship. At the same time, the access point A simulates the scenario of external penetration testing, which can generate "historical case" entities containing attack paths, vulnerability types, and handling solutions, providing typical scenario support for "cross-module risk detection" and "case analogy detection". The internal vulnerability scanning of access point B fits the identification logic of internal module vulnerabilities in "basic vulnerability detection". Overall, the elements and detection scenarios of each region on the platform can be completely mapped to the core entities, key relationships and detection logic of the knowledge graph of this invention. It serves as a practical carrier for the detection, handling and dynamic updating of the knowledge graph, and strongly supports the intelligent management of software security risks throughout the entire process.

[0154] Furthermore, the method proposed in Embodiment 1 has broad application prospects in fields with extremely high software security requirements, such as autonomous driving, intelligent robots, and fintech. Software systems in these fields often face complex data flow and multi-module collaboration scenarios. Traditional detection methods are prone to missing cross-module risks and new hidden dangers. However, this method, through multi-dimensional detection, standardized handling, and dynamic graph updates, can accurately identify hidden dangers and efficiently provide remediation solutions, thus building a solid defense for the safe operation of core businesses.

[0155] From an industry development perspective, as the complexity of software systems continues to increase, the concealment and correlation of security vulnerabilities are constantly strengthening. The technical approach of Example 1 can be further extended to scenarios such as enterprise-level software operation and maintenance and industrial software protection. Its "detection-handling-update" closed-loop model, based on knowledge graphs, can help more industries solve the problems of difficulty in reusing security knowledge and low efficiency in handling vulnerabilities, promoting the transformation of software security management from "passive response" to "proactive prevention," and providing important reference for the standardization and intelligent development of the software security industry.

[0156] Example 2

[0157] Please refer to Figure 3 This embodiment 2 provides a software security vulnerability detection system based on knowledge graphs, including:

[0158] The entity relationship definition and standardized unit are used to first complete the definition of core entities and key relationships; secondly, to collect three types of data, including code vulnerability data, data flow records, and industry-standard security rules and historical vulnerability handling documents, and to unify the different formats of data into standardized formats of "entity table" and "relationship table".

[0159] The basic knowledge graph construction unit is used to automatically analyze and recommend potential relationships between unrelated entities based on entity attribute features during data upload; it only manually completes a small number of relationships that the tool cannot determine, thus completing the construction of the basic security knowledge graph.

[0160] The multi-dimensional vulnerability identification unit is used to complete the detection of multi-dimensional software security vulnerabilities in three ways: First, it transforms software security rules into graph query statements and executes the statements to detect basic vulnerabilities; second, it designs path matching rules corresponding to cross-module risks and uses the graph's "path query" function to locate cross-module related vulnerabilities; third, it extracts the feature keywords of the vulnerabilities to be detected, matches them with the feature keywords of historical cases in the knowledge graph, obtains the corresponding handling solutions, and completes case analogy detection.

[0161] The standardized remediation guide generation unit is used to automatically match the corresponding historical case handling solutions and security rule requirements based on the entity association relationships in the knowledge graph for the detected and identified security risks. Based on this, it generates standardized and operable handling guidelines for operation and maintenance personnel to refer to and complete the remediation of risks.

[0162] The knowledge graph dynamic update unit is used to develop two standardized templates for "new entities" and "new relationships" after the handling of security risks is completed. New entities and relationships generated during the handling process are filled in according to the templates, and then the data is uploaded through the graph database template import function to realize the dynamic update of the knowledge graph.

[0163] Example 3

[0164] This embodiment 3 also provides a computer-readable storage medium storing a computer program. When the computer program is executed by a processor, it can implement any step of a knowledge graph-based software security vulnerability detection method.

[0165] The computer-readable storage medium may include various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0166] For a description of the computer-readable storage medium provided in this application, please refer to the above method embodiments; further details will not be repeated here.

[0167] Those skilled in the art will readily understand that the above description is merely a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A method for detecting software security vulnerabilities based on knowledge graphs, characterized in that, include: S1. First, complete the definition of core entities and key relationships; Secondly, three types of data were collected, including code vulnerability data, data flow records, and industry-standard software security rules and historical vulnerability handling documents. The data in different formats were then uniformly organized into standardized "entity tables" and "relationship tables". S2. When uploading data, it will automatically analyze and recommend potential relationships between unrelated entities based on entity attribute characteristics; it will only manually complete a small number of relationships that the tool cannot determine, thus completing the construction of a basic security knowledge graph. S3. Multi-dimensional software security vulnerability detection is achieved through three methods: First, software security rules are transformed into graph query statements, and the statements are executed to detect basic vulnerabilities; second, path matching rules corresponding to cross-module risks are designed, and the graph's "path query" function is used to locate cross-module related vulnerabilities; third, feature keywords of the vulnerabilities to be detected are extracted and matched with feature keywords of historical cases in the knowledge graph to obtain corresponding handling solutions and complete case analogy detection. S4. For the identified security risks, based on the entity relationships in the knowledge graph, the corresponding historical case handling solutions and security rule requirements are automatically matched, and standardized and operable handling guidelines are generated accordingly for operation and maintenance personnel to refer to and complete the risk repair. S5. After the safety hazard is handled, two standardized templates are developed for "new entities" and "new relationships". New entities and relationships generated during the handling process are filled in according to the templates, and then the data is uploaded through the graph database template import function to realize the dynamic updating of the knowledge graph. The core entities encompass four categories, each corresponding to a core element of software system security management: Software modules are independent functional units within a software system, and their functional integrity directly impacts the overall operational security of the software; security elements include key aspects of software security such as code vulnerabilities, security rules, and permission configurations, serving as the core basis for identifying security risks; data links record the flow path and status of data between different modules and components, and their compliance determines the security of data transmission; historical cases integrate past software security incidents and their handling records, including vulnerability types, remediation plans, and handling results, providing reference experience for current vulnerability handling. The key relationships focus on the core connection logic between entities, and fall into five categories: The "module-containment-component" relationship clarifies the subordinate relationship between a software module and its internal components, solving the problems of "unclear module functional composition and difficulty in locating component risks"; The "vulnerability-impact-module" relationship reflects the scope of a code vulnerability's impact on a module, avoiding situations where "the boundaries of the vulnerability's impact are unclear, making it impossible to identify the affected modules." The "rules-constraints-data links" relationship specification outlines the security rules for controlling data flow and ensuring that data links comply with security standards. The "case-correspondence-vulnerability" relationship establishes a match between historical cases and vulnerability types, solving the problem of "difficulty in reusing past handling experience"; The "module-dependency-module" relationship describes the functional dependencies between modules, clarifies the module collaboration logic, and provides a basis for analyzing cross-module risks.

2. The software security vulnerability detection method based on knowledge graphs according to claim 1, characterized in that, The core entities in S1 include software modules, security elements, data links, and historical cases. The software module refers to a core component of the software system with independent functions. The security elements encompass key elements that ensure software security. The data link is the path for data flow within the software system, recording the transmission process and flow status of data between different modules and components. The historical cases refer to past security vulnerability events and corresponding handling records, including information such as historical vulnerability types, handling solutions, and remediation results.

3. The software security vulnerability detection method based on knowledge graphs according to claim 1, characterized in that, The key relationships in S1 include five types: "module-contains-component", "vulnerability-impact-module", "rule-constraint-data link", "case-correspondence-vulnerability", and "module-dependency-module". The "module-containment-component" relationship is used to characterize the subordinate relationship between a software module and its internal core components; the "vulnerability-impact-module" relationship is used to reflect the effect of code vulnerabilities on software modules, clarifying the scope of modules affected by vulnerabilities; the "rule-constraint-data link" relationship is used to define the control relationship of security rules on data flow paths, and to standardize the security requirements that data links must follow; the "case-correspondence-vulnerability" relationship is used to establish the matching relationship between historical cases and related vulnerabilities, clarifying the vulnerability type targeted by the case; the "module-dependency-module" relationship is used to describe the functional dependency relationship between different software modules, reflecting the collaboration logic between modules.

4. The software security vulnerability detection method based on knowledge graphs according to claim 1, characterized in that, The specific process in S1 of unifying data of different formats into a standardized format of "entity table" and "relationship table" is as follows: To achieve standardized transformation of collected data into "entity tables" and "relationship tables," a mapping model between data features and entity / relationship attributes is established, as follows: Let the collected data set be It contains three types of raw information: code vulnerability data, data flow records, and security rules and historical case data; the core entity set is... It covers four core entities: software modules, security elements, data links, and historical cases. Based on this, entity attribute mapping functions are defined: in, An attribute that represents a certain type of entity; These are descriptive features of the attributes of this type of entity; For the matching function, when collecting data Includes entity attribute description features When the information is consistent, the result is 1; otherwise, it is 0. This function extracts and aggregates information that meets the entity attribute requirements from the collected data by matching data features with entity attribute descriptions, thereby forming the attribute values ​​of the corresponding entities in the "entity table". Let the set of key relationships be... It contains different association types; the entity pair set is It is composed of pairs of different entities from the core entity set, and the relation feature matching function is defined accordingly: in, Describe the characteristics of a certain type of relationship; It is data collection The middle also involves entity pairs The function determines the entity pair by judging whether the entity pair contains relational features. Corresponding relation type Then, the entities and their corresponding relationships are filled into the "relationship table" to complete the standardized processing of the relationship data.

5. The software security vulnerability detection method based on knowledge graphs according to claim 1, characterized in that, The specific process in S2 of automatically analyzing and recommending potential relationships between unrelated entities based on entity attribute features is as follows: After S1 standardization, let the unrelated entities to be analyzed be entities. With entity The attribute sets of the two are as follows: Each attribute item corresponds to the attribute definition of the core entity in S1; first, the entity attribute similarity function is defined: in, Representing entities Attribute Collection The first in Each attribute item; Representing entities Attribute Collection The first in The function quantifies the degree of correlation between two entities at the attribute level by calculating the ratio of the number of completely matching attribute items in the attribute sets of the two entities to the maximum number of elements in the attribute sets of the two entities. The higher the ratio, the stronger the consistency of the two entities in the core attributes, and the greater the possibility of a potential relationship. Next, based on the key relation set R defined in S1, each type of relation is... Preset attribute association feature set ; Define relation feature adaptation function: This function determines the entity. With entity After the attribute sets are combined, does it contain a certain type of relation? All required attribute association features—if they are included, it means that the attribute features of both parties meet the logical requirements of the relationship, and the fit is 1; otherwise, the fit is 0. Finally, construct the potential relationship recommendation decision function: in, This is a threshold derived from the statistical similarity of historical associated entity attributes in S1; when the entity With entity When the attribute similarity exceeds a threshold and the feature fit with a certain type of relation r is 1, the relation... This means that a potential relationship is identified between two entities, and a recommendation result is output.

6. The software security vulnerability detection method based on knowledge graphs according to claim 1, characterized in that, The specific process of converting software security rules into graph query statements and executing these statements to detect basic vulnerabilities in S3 is as follows: Let G be the set of software security rules defined in S1, and let each rule... It includes rule constraint objects and constraint conditions; the core entity set constructed by S1 is E, the key relationship set is R, and the entity attribute set in the "entity table" is denoted as A; First, define the rule-entity-relationship mapping function. ,in For rules The core entity corresponding to the constraint object, For rules The corresponding key relationship: by matching the rule constraint object with the core entity type, the rule constraint logic with the key relationship connotation, this function transforms each security rule into a corresponding combination of "entity-relationship", providing core elements for the construction of graph query statements; Based on the above mapping results, define a graph query statement generation function: in, For rules Entity attribute filtering conditions for constraint transformation The logic for generating graph query statements uses the entities obtained through mapping. ,relation As the subject of the query, with Generate a word search statement that conforms to the syntax of the graph database, based on the filtering criteria; Finally, define the basic hazard detection verification function: This function executes the generated graph query statement; if the query result is not empty, it means that there are entity records that meet the "entity attributes do not meet the rule constraints", which is determined to be a basic security risk and recorded as risk; if the query result is empty, it means that all related entities meet the rule constraints, which is determined to be no basic risk and recorded as safe.

7. The software security vulnerability detection method based on knowledge graphs according to claim 1, characterized in that, The specific path matching rules for cross-module risks in S3 are as follows: First, determine whether the module flow of the data link meets the basic conditions for risk triggering; based on the "module-dependency-module" relationship defined in S1, check whether there is a module subsequence in the module sequence through which the data flows that is consistent with the requirements of the cross-module risk rules; Next, determine whether the data link violates security constraints; compare the data link attributes recorded in the S1 "Entity Table" to check whether the link does not meet the constraint requirements in the cross-module risk rules; A data link is considered a cross-module risk path only if it simultaneously meets both the conditions of "having a compliant module sub-sequence" and "violating security constraints". Otherwise, it is not considered a risk path.

8. The software security vulnerability detection method based on knowledge graphs according to claim 1, characterized in that, The specific process of case analogy detection in S3 is as follows: Let C be the set of historical cases in S1, and let each case... Includes a set of characteristic keywords The safety element entity corresponding to the hidden danger to be detected is , Its set of characteristic keywords is ; First, define the feature intersection function: This function extracts the common feature keywords between the potential hazards to be detected and historical cases. The more overlapping elements there are, the higher the degree of overlap between the two in terms of core features. Next, we define the feature dimension set as D, and define the dimension coverage function: This function determines whether the feature intersection covers all preset dimensions. If it does, it means that the two overlap in all key dimensions and the matching is comprehensive. Otherwise, there are missing dimensions. Finally, define the case analogy decision function: When the potential hazard to be detected shares common characteristic keywords with a historical case, and these keywords cover all preset dimensions, the two are considered to be matched and recorded as "match". The handling plan of the historical case can be used as a reference. Otherwise, they are considered to be mismatched and recorded as "mismatch".

9. A knowledge graph-based software security vulnerability detection system, used to implement the knowledge graph-based software security vulnerability detection method as described in claim 1, characterized in that, include: Entity relationship definition and standardized units are used to first complete the definition of core entities and key relationships; Secondly, three types of data were collected, including code vulnerability data, data flow records, and industry-standard software security rules and historical vulnerability handling documents. The data in different formats were then uniformly organized into standardized "entity tables" and "relationship tables". The basic knowledge graph construction unit is used to automatically analyze and recommend potential relationships between unrelated entities based on entity attribute features during data upload; it only manually completes a small number of relationships that the tool cannot determine, thus completing the construction of the basic security knowledge graph. The multi-dimensional vulnerability identification unit is used to complete the detection of multi-dimensional software security vulnerabilities in three ways: First, it transforms software security rules into graph query statements and executes the statements to detect basic vulnerabilities; second, it designs path matching rules corresponding to cross-module risks and uses the graph's "path query" function to locate cross-module related vulnerabilities; third, it extracts the feature keywords of the vulnerabilities to be detected, matches them with the feature keywords of historical cases in the knowledge graph, obtains the corresponding handling solutions, and completes case analogy detection. The standardized remediation guide generation unit is used to automatically match the corresponding historical case handling solutions and security rule requirements based on the entity association relationships in the knowledge graph for the detected and identified security risks. Based on this, it generates standardized and operable handling guidelines for operation and maintenance personnel to refer to and complete the remediation of risks. The knowledge graph dynamic update unit is used to develop two standardized templates for "new entities" and "new relationships" after the handling of security risks is completed. New entities and relationships generated during the handling process are filled in according to the templates, and then the data is uploaded through the graph database template import function to realize the dynamic update of the knowledge graph.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, The computer program is executed by a processor according to any one of claims 1-8, which describes a method for detecting software security vulnerabilities based on knowledge graphs.

Images