Methods, apparatus and equipment for data security compliance testing

Abstract

This application provides a method, apparatus, and device for data security compliance testing, applicable to the big data field. The method includes: acquiring metadata and the application's source code, wherein the metadata characterizes the attributes of data entities processed by the source code; analyzing the transmission paths of sensitive data entities in the source code using a static code analysis engine; constructing a data lineage graph based on the transmission paths and metadata, wherein nodes in the data lineage graph represent data entities, and edges represent data flow relationships between data entities; traversing the nodes and edges of the data lineage graph based on atomic detection rules, matching the attributes of nodes and edges with the triggering conditions of the atomic detection rules; and, in response to a successful match, verifying the data entities or data flow relationships according to the constraints in the corresponding atomic detection rules, and determining the data security compliance of the application based on the verification results.

Description

Technical Field

[0001] This application relates to the financial field, specifically to the field of big data technology, and more specifically to a method, apparatus, device, medium, and program product for data security compliance testing. Background Technology

[0002] Currently, data security compliance assurance primarily relies on manual verification, traditional application security testing tools, and data lineage technology. Manual verification, depending on expert experience, struggles to comprehensively cover the fine-grained processing logic at the code level, resulting in inefficiency and subjective bias. Traditional security testing tools focus on identifying and locating functional security flaws in application code or runtime, lacking the ability to specifically inspect the compliance of sensitive data throughout its entire lifecycle and failing to understand the end-to-end flow of data within the complete business process. Existing data lineage technologies mostly remain at the macro-level description of database tables or service interfaces, unable to delve into the variable-level details within the application code, and struggling to track the specific transmission and changes of sensitive data in method parameters, return values, and local variables. Summary of the Invention

[0003] In view of the above problems, this application provides a method, apparatus, device, medium and program product for data security compliance testing.

[0004] According to a first aspect of this application, a method for data security compliance detection is provided, comprising: acquiring metadata and the source code of an application, wherein the metadata is used to characterize the attributes of data entities processed by the source code; analyzing the transmission path of sensitive data entities in the source code through a static code analysis engine; constructing a data lineage graph based on the transmission path and metadata, wherein the nodes of the data lineage graph characterize data entities from the data storage layer to the application layer, and the edges of the data lineage graph characterize the data flow relationship between data entities; traversing the nodes and edges of the data lineage graph based on atomic detection rules, matching the attributes of the nodes and edges with the triggering conditions of the atomic detection rules; and in response to a successful match, verifying the data entities or data flow relationships according to the constraints in the corresponding atomic detection rules, and determining the data security compliance of the application based on the verification results.

[0005] According to embodiments of this application, the transmission path of sensitive data entities in the source code is analyzed using a static code analysis engine, including: parsing the source code using the static code analysis engine to generate an abstract syntax tree; identifying the definition location and usage location of the sensitive data entities based on the abstract syntax tree; and tracing the transmission path of the sensitive data entities from the definition location to the usage location based on a data flow analysis algorithm.

[0006] According to embodiments of this application, a data lineage graph is constructed based on transmission paths and metadata, including: generating variable-level lineages of sensitive data entities within different services according to transmission paths, wherein the services are implemented by at least one application, and the variable-level lineages are used to record the transmission paths between variables of sensitive data entities within the application; connecting the variable-level lineages within different services through inter-service call relationships to form a cross-service data flow chain; and constructing a directed attribute graph model as the data lineage graph based on metadata, variable-level lineages, and data flow chains.

[0007] According to embodiments of this application, the method further includes: identifying sensitive data entities in the source code based on classification and grading tags in metadata.

[0008] According to an embodiment of this application, the method further includes: breaking down pre-defined compliance requirements into atomic detection rules; and storing the atomic detection rules in a compliance rule library, wherein the atomic detection rules in the compliance rule library are loaded by a rule engine.

[0009] According to an embodiment of this application, the method further includes: adjusting the atomic detection rules in the compliance rule base through the configuration interface of the rule engine; wherein, the adjustment includes adding new atomic detection rules, modifying or disabling existing atomic detection rules.

[0010] According to an embodiment of this application, determining the data security compliance of an application based on the verification results includes: generating a violation detection report when the verification results indicate that a data entity or data flow relationship does not meet the constraints of the atomic detection rules, wherein the violation detection report includes the code location where the violation occurred and the data flow relationship of the sensitive data entity that triggered the violation in the data lineage graph.

[0011] According to a second aspect of this application, an apparatus for data security compliance detection is provided, comprising: an acquisition module for acquiring metadata and the source code of an application, wherein the metadata is used to characterize the attributes of data entities processed by the source code; an analysis module for analyzing the transmission path of sensitive data entities in the source code using a static code analysis engine; a construction module for constructing a data lineage graph based on the transmission path and metadata, wherein the nodes of the data lineage graph characterize data entities from the data storage layer to the application layer, and the edges of the data lineage graph characterize the data flow relationship between data entities; a matching module for traversing the nodes and edges of the data lineage graph based on atomic detection rules, and matching the attributes of the nodes and edges with the triggering conditions of the atomic detection rules; and a verification module for verifying the data entities or data flow relationships according to the constraints in the corresponding atomic detection rules in response to a successful match, and determining the data security compliance of the application based on the verification results.

[0012] According to a third aspect of this application, an electronic device is provided, comprising: one or more processors; and a memory for storing one or more computer programs, wherein the one or more processors execute the one or more computer programs to implement the steps of the method described above.

[0013] According to a fourth aspect of this application, a computer-readable storage medium is also provided, on which a computer program or instructions are stored, wherein the computer program or instructions, when executed by a processor, implement the steps of the above-described method.

[0014] According to a fifth aspect of this application, a computer program product is also provided, including a computer program or instructions that, when executed by a processor, implement the steps of the above-described method. Attached Figure Description

[0015] The above-mentioned contents, other objects, features and advantages of this application will become clearer from the following description of embodiments with reference to the accompanying drawings, in which:

[0016] Figure 1 The illustrations depict application scenarios of methods, apparatus, devices, media, and program products for data security compliance testing according to embodiments of this application.

[0017] Figure 2 A flowchart illustrating a method for data security compliance detection according to an embodiment of this application is shown schematically.

[0018] Figure 3 A flowchart illustrating a data pedigree mapping method according to an embodiment of this application is shown schematically.

[0019] Figure 4 This schematically illustrates a structural block diagram of an apparatus for data security compliance testing according to an embodiment of this application; and

[0020] Figure 5 A block diagram schematically illustrates an electronic device suitable for implementing a method for data security compliance testing according to an embodiment of this application. Detailed Implementation

[0021] The embodiments of this application will now be described with reference to the accompanying drawings. However, it should be understood that these descriptions are exemplary only and are not intended to limit the scope of this application. In the following detailed description, numerous specific details are set forth to provide a thorough understanding of the embodiments of this application for ease of explanation. However, it will be apparent that one or more embodiments may be implemented without these specific details. Furthermore, descriptions of well-known structures and technologies are omitted in the following description to avoid unnecessarily obscuring the concepts of this application.

[0022] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the scope of this application. The terms “comprising,” “including,” etc., as used herein indicate the presence of features, steps, operations, and / or components, but do not exclude the presence or addition of one or more other features, steps, operations, or components.

[0023] All terms used herein (including technical and scientific terms) have the meanings commonly understood by those skilled in the art, unless otherwise defined. It should be noted that the terms used herein are to be interpreted in a manner consistent with the context of this specification, and not in an idealized or overly rigid way.

[0024] When using expressions such as "at least one of A, B and C", they should generally be interpreted in accordance with the meaning that is commonly understood by those skilled in the art (e.g., "a system having at least one of A, B and C" should include, but is not limited to, a system having A alone, a system having B alone, a system having C alone, a system having A and B, a system having A and C, a system having B and C, and / or a system having A, B and C, etc.).

[0025] In the technical solution of this application, the user information (including but not limited to user personal information, user image information, user device information, such as location information) and data (including but not limited to data used for analysis, stored data, and displayed data) involved are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, storage, use, processing, transmission, provision, disclosure, and application of related data all comply with relevant laws, regulations, and standards, take necessary confidentiality measures, do not violate public order and good morals, and provide corresponding operation entry points for users to choose to authorize or refuse.

[0026] In related technologies, data security and compliance assurance primarily employs methods such as manual verification and interpretation of technical specifications, traditional application security testing tools, and data lineage techniques. Security and compliance personnel, based on complex data security technical specifications, manually review system design documents, configuration information, and even portions of code logic to verify whether the system complies with regulatory requirements. Simultaneously, tools such as static application security testing, dynamic application security testing, and interactive application security testing are widely used to identify and locate functional security flaws in application code or runtime, such as common threats like structured query language injection, cross-site scripting, privilege escalation, and buffer overflows. Furthermore, existing data lineage tools typically focus on a macro-level perspective, depicting the flow of data between database tables or fields, or tracing the call paths of data between different services or application interfaces.

[0027] While the aforementioned solutions are widely adopted, they have significant limitations and pain points in ensuring that data meets specific compliance policies throughout its entire lifecycle (from collection, transmission, storage, processing, sharing to destruction). First, manual verification is inefficient and unreliable, failing to comprehensively cover complex business logic, particularly prone to overlooking fine-grained processing of sensitive data at the code level, such as de-identification algorithms, encryption logic, and conditional judgments, leading to compliance blind spots. Faced with massive amounts of code, frequent changes, and large-scale systems, manual review is slow and costly, unable to support the demands of large-scale, high-frequency compliance checks. Understanding and interpreting complex technical specifications heavily relies on individual experience and ability, lacking unified and objective execution standards, easily introducing subjective biases, and causing inconsistencies or distortions in compliance requirements during actual implementation. Second, traditional security testing tools suffer from capability misalignment; their core design goal is to discover functional security flaws, lacking the ability to specifically check whether data complies with specific compliance policies throughout its lifecycle. These tools typically perform isolated code snippet scanning or single-point runtime detection, making it difficult to understand the end-to-end flow of sensitive data within the complete business process. They cannot effectively trace the source of sensitive data, its specific processing methods within business logic, and its final destination, thus hindering a systematic assessment of compliance across the entire chain. Finally, existing data lineage tools also lack sufficient depth. Current data lineage analysis tools primarily remain at the macro-level description of database tables or fields, or service or application interface levels, failing to delve into the variable-level details within the application code, such as tracing the specific assignment, transmission, and changes of sensitive data in method parameters, return values, and local variables. Therefore, existing tools cannot accurately depict the specific processing of sensitive data within core business logic, which is crucial for verifying whether compliance strategies are being correctly implemented.

[0028] In summary, organizations currently face the following core challenges in meeting data security compliance requirements. First, the ambiguity and unverifiability of implementation: Regulatory provisions are often abstract and highly principled, making it difficult to directly map to specific code implementations and data flows. This results in a subjective, ambiguous, and difficult-to-automate verification of compliance requirements. Second, insufficient granularity and incomplete coverage of detection: Traditional static code analysis tools struggle to accurately track the complete flow path of sensitive data within complex applications and across service call boundaries, especially lacking fine-grained tracking at the variable level, making it difficult to uncover compliance risks deeply hidden in code logic. Third, delayed response and high maintenance costs: Compliance requirements are frequently updated, and existing detection technologies typically require modification of the core engine code and recompilation and deployment to support new rules or modify old rules, resulting in long response cycles and high maintenance costs.

[0029] In view of this, embodiments of this application provide a method, apparatus, device, medium, and program product for data security compliance testing.

[0030] Figure 1 The illustration schematically depicts application scenarios of methods, apparatus, devices, media, and program products for data security compliance testing according to embodiments of this application.

[0031] like Figure 1 As shown, application scenario 100 according to an embodiment of this application may include a first terminal device 101, a second terminal device 102, a database 103, a network 104, and a server 105. The network 104 serves as a medium for providing a communication link between the first terminal device 101, the second terminal device 102, the database 103, and the server 105. The network 104 may include various connection types, such as wired or wireless communication links or fiber optic cables. For example, a user can use the first terminal device 101 and the second terminal device 102 to interact with the server 105 and / or the database 103 through the network 104 to receive or send information, etc.

[0032] The first terminal device 101 and the second terminal device 102 can be electronic devices such as smartphones, wearable devices, personal computers, intelligent voice interaction devices, smart home appliances, intelligent vehicles, in-vehicle terminals, aircraft, unmanned vending terminals, and extended reality devices. Extended reality devices can include virtual reality devices, augmented reality devices, and mixed reality devices. The terminal devices can install and run client applications for the target application, which can include, but is not limited to, financial transaction applications, payment applications, shopping applications, web browser applications, search applications, instant messaging tools, email clients, and social media platform software (for example only). These applications can collect, process, and transmit sensitive user data (such as personal identification information, bank account information, and transaction records) during operation, therefore, compliance testing of the application's data processing behavior is required. Furthermore, this application embodiment does not limit the form of the target application, including but not limited to applications, mini-programs, etc., installed on the terminal device, and can also be in web page form.

[0033] Server 105 can be a server providing data security compliance testing services, such as a backend management server for performing source code security reviews, data flow path tracing, and compliance verification on applications deployed within an enterprise (this is just an example). The backend management server can process received application source code, metadata, etc., and feed back the testing results (such as violation detection reports and compliance assessment results) to terminal devices or the enterprise compliance management platform. The server can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing cloud computing services such as cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communications, middleware services, domain name services, security services, content delivery networks, and big data. The server can serve as the backend server for a data security compliance testing platform, providing continuous compliance testing services to the enterprise.

[0034] Database 103 is a professional storage system for storing and managing data. It can store various types of data related to data security and compliance testing, such as the source code of the application to be tested, metadata (including classification and grading labels and attribute information of data entities), the generated data lineage graph, the atomic testing rule base (including pre-defined atomic rules after decomposing compliance requirements), historical testing records, and violation testing reports. It supports structured, semi-structured, or unstructured data storage and has management capabilities such as adding, deleting, modifying, querying, backing up, and restoring data. In this application scenario, Database 103 can connect to Server 105 via a communication link. Server 105 can obtain the source code and metadata to be tested from Database 103 based on testing requirements, and can also synchronously store the data lineage graph, violation testing reports, and other results generated during the testing process to Database 103, thereby achieving persistent and efficient access to testing data.

[0035] It should be noted that the method for data security compliance testing provided in this application embodiment can generally be executed by server 105 and / or terminal devices 101-102. Accordingly, the apparatus for data security compliance testing provided in this application embodiment can generally be located in server 105 and / or terminal devices 101-102.

[0036] It should be understood that Figure 1 The number of terminal devices, networks, databases, and servers shown is merely illustrative. Depending on implementation needs, any number of terminal devices, networks, databases, and servers can be included.

[0037] It should be noted that the method and apparatus for data security compliance testing in this application can be used in scenarios such as the financial field, or in any field other than the financial field. The application field of the method and apparatus for data security compliance testing in this application is not limited.

[0038] The following will be based on Figure 1 The described scene, through Figure 2 and Figure 3 A method for data security compliance detection according to embodiments of this application will be described in detail.

[0039] Figure 2 A flowchart illustrating a method for data security compliance detection according to an embodiment of this application is shown schematically. Figure 2 As shown, the method 200 for data security compliance detection according to an embodiment of this application may include steps S210 to S250.

[0040] In step S210, metadata and the source code of the application are obtained, wherein the metadata is used to characterize the attributes of the data entities processed by the source code.

[0041] In embodiments of this application, user consent or authorization may be obtained before acquiring metadata and application source code. For example, before step S210, a request may be sent to the user to acquire metadata and application source code. If the user consents or authorizes the acquisition of metadata and application source code, step S210 is executed.

[0042] When acquiring metadata and source code, you can connect to a metadata management system to obtain information such as data asset classification and grading labels, basic metadata, etc. Simultaneously, you can obtain application source code, configuration files, application programming interface (API) definition files, database schemas, and other related data. Metadata is used to characterize the attributes of the data entities processed by the source code, such as data type, sensitivity level, classification and grading labels, and storage location, providing a foundation for subsequent sensitive data entity identification. After obtaining the metadata and source code, you can perform format parsing and structured processing on the source code to form an analyzable data foundation.

[0043] For example, source code can be parsed into an abstract syntax tree structure, extracting key syntax elements such as class definitions, method declarations, variable declarations, and method calls, and establishing reference and calling relationships between code elements, thereby providing structured input for subsequent static analysis.

[0044] In step S220, the transmission path of sensitive data entities in the source code is analyzed using a static code analysis engine.

[0045] The static code analysis engine is the core component of this system. Through deep data flow analysis, control flow analysis, inter-process analysis, and taint analysis techniques, it can parse the application source code without executing the code, trace the transmission path of sensitive data between variables, method parameters, and return values, and identify the data processing logic within it.

[0046] First, the static code analysis engine can designate entity class fields located in the data access layer of sensitive data entities as taint sources. Then, through inter-process data flow analysis, it tracks the propagation of tainted data in the method call chain, recording the path from the data access layer to the business logic layer, and then via service calls to the application interface layer. It identifies and records data flow behaviors such as assignment operations, method parameter passing, and return value passing during the transmission of tainted data, as well as processing operations such as encryption, desensitization, logging, and serialization. Finally, it outputs the complete transmission path of sensitive data in the source code, including variables, method parameters, return values, and related data processing operations, providing foundational data for subsequent data lineage graph construction.

[0047] In step S230, a data lineage graph is constructed based on the transmission path and metadata. The nodes of the data lineage graph represent data entities from the data storage layer to the application layer, and the edges of the data lineage graph represent the data flow relationship between data entities.

[0048] Data lineage graphs are a type of directed attribute graph model that covers the complete data flow path from the data storage layer to the application layer, including the database / storage layer (table / field-level sensitive data source points), the data access layer (object-relational mapping entity assignment operations), the application service layer (internal calculation, transformation, and transmission of sensitive data), and the application programming interface / user interface layer (interface input / output and front-end model data).

[0049] The data lineage graph integrates variable-level fine-grained lineage with cross-service call-level lineage, enabling precise characterization of the entire flow of sensitive data. Variable-level fine-grained lineage can accurately trace local variables within a method, recording the assignment and propagation relationships of sensitive data between different variables within the same method. Cross-service call-level lineage, by analyzing interface parameter transmission, can trace the flow path of sensitive data between different microservices, revealing the complete flow of sensitive data even in a distributed architecture.

[0050] Graph nodes represent data entities and can include various types: database table field nodes, carrying attributes such as table name, field name, sensitivity level, and encryption status; class field nodes, carrying attributes such as class name, field name, field type, and annotation information; method parameter nodes, carrying attributes such as method signature, parameter name, and parameter location; local variable nodes, carrying attributes such as variable name, variable type, and line number; and API parameter nodes, carrying attributes such as interface path, parameter name, and parameter type. Graph edges represent the data flow relationships between data entities and carry rich attribute information, such as the type of data transfer (assignment, method call parameters, return value transfer, collection element transfer, etc.), the location in the code (filename, line number), whether it has been encrypted or de-identified, and whether it involves log output.

[0051] When constructing a data lineage graph, it's not only possible to establish data flow relationships within the same application, but also to establish cross-application data lineage connections by analyzing the interface call relationships between services. For example, when service A calls the interface of service B and passes sensitive data as a parameter, the system can establish a data flow edge between the API call node of service A and the interface parameter node of service B, thus achieving cross-service boundary lineage connectivity.

[0052] In step S240, based on the atomic detection rules, the nodes and edges of the data lineage graph are traversed, and the attributes of the nodes and edges are matched with the triggering conditions of the atomic detection rules.

[0053] Atomized inspection rules refer to the smallest independently executable inspection units derived from complex compliance requirements. Each atomized inspection rule is an independent, automatically executed compliance check item. The rule structure may include: trigger conditions, used to match specific data classification tags, node types, or data flow scenarios; constraints, used to define the technical requirements that must be met, such as "Level 4 data must be stored encrypted," "sensitive data is prohibited from being output in logs," and "personal information must be anonymized"; and violation descriptions, used to define standardized descriptions of the violation scenarios, facilitating the subsequent generation of compliance reports and remediation suggestions.

[0054] The system traverses the constructed fine-grained data lineage graph. For each node and edge in the graph, it checks whether its attributes match the triggering conditions of any atomic detection rules. During the traversal, graph traversal algorithms, such as depth-first search or breadth-first search, can be used to ensure that every element in the graph is covered. Simultaneously, it can extract attribute information such as node type, sensitivity level, code location, and associated encryption / de-identification metadata in real time and compare it with the triggering conditions in the rule base.

[0055] For example, when traversing a node that carries the attribute "customer ID number" and has a sensitivity level of "4", a detection rule matching the data category and sensitivity level can be triggered; when traversing an edge that carries the attribute "transmission type is log output" and has an associated sensitivity level of "level 3 or above", a sensitive data log output detection rule can be triggered.

[0056] In step S250, in response to a successful match, the data entity or data flow relationship is verified according to the constraints in the corresponding atomic detection rule, and the data security compliance of the application is determined based on the verification result.

[0057] If a match is successful, the system can verify whether the current data entity or data flow path meets the requirements based on the constraints. This verification process can employ different verification logic depending on the rule type. For example, for encrypted storage rules, it can check whether the data entity is associated with an encrypted operation node on its flow path in the data lineage graph. Specifically, it can start from this node and trace back along the data flow direction to find whether there are operations such as calling encryption functions, setting encryption annotations, or writing to encrypted storage media. If an encryption operation exists, the verification passes; otherwise, the verification fails and a violation is recorded. As another example, for de-identified display rules, it can check whether the API interface output node is associated with de-identification processing operations. The system can analyze the complete path from the data source to the API output node to confirm whether there are calls to de-identification functions, the use of de-identification annotations, or processing through de-identification filters. If no de-identification processing is found in the entire path, it can be determined as a violation.

[0058] If the verification passes, the node or edge can be marked as compliant. If the verification fails, the violation information can be recorded, including the violation type, triggering rule, violation location (code file name, line number), involved code elements, and system-generated repair suggestions.

[0059] For example, in a compliance testing scenario of a commercial bank's credit approval system, the system first connects to a metadata management system to obtain classification and grading labels for the "Customer Table.ID Number" field as Level 4 sensitive data and the "Loan Application Form.Monthly Income" field as Level 3 sensitive data. Simultaneously, it obtains the source code of the credit approval system. A static code analysis engine parses the source code, setting the ID number field (marked as Level 4) as a taint source in the entity class field corresponding to the data access layer. Through inter-process data flow analysis, it is discovered that this field is assigned from the ID number field in the loan application entity class to the local variable "Identity Number," then passed as a parameter to the identity verification method, and finally, via service calls, to the application interface layer's interface for obtaining credit results. Based on the above transmission path and metadata, the system constructs an end-to-end data lineage graph covering the storage layer, data access layer, business logic layer, and application interface layer to present the complete flow path of the ID number field. Subsequently, the system traversed the graph nodes and edges, matching the atomic detection rule that "Level 4 sensitive data must be stored in an encrypted manner." The verification revealed that the data flow path was read from the database and only underwent format verification without calling any encryption methods or annotating encryption. Therefore, the system determined that the program violated data security compliance regulations.

[0060] It is understandable that this application's embodiments effectively address the fundamental problems of subjective interpretation and unverifiability in traditional compliance reviews by establishing a closed-loop verification chain of compliance requirements (regulatory provisions or internal policies), atomic detection rules, and code-level data flow paths. Specifically, by transforming abstract compliance requirements into automatically executable engineered checkpoints (i.e., atomic detection rules), the subjectivity, ambiguity, and unverifiability of compliance requirement implementation are resolved, achieving quantifiable, automated, and repeatable verification of compliance. Simultaneously, by constructing an end-to-end data lineage graph covering the entire technology stack and possessing variable-level fine-grainedness and cross-service views, the limitations of traditional lineage analysis are overcome, enabling sensitive data flow tracking at the code variable level. This allows for the discovery of compliance risks hidden deep within complex business logic, eliminating detection blind spots. Furthermore, by automating graph construction and traversal detection, inefficient and error-prone manual auditing is replaced, ensuring the comprehensiveness and consistency of detection results and providing efficient and accurate technical support for enterprise data security compliance governance.

[0061] In embodiments of this application, the method further includes: identifying sensitive data entities in the source code based on classification and grading tags in the metadata.

[0062] In practical application development, data assets stored in databases can be categorized and tagged with different levels of sensitivity. For example, "ID card number" can be tagged as Level 4 sensitive data, "phone number" as Level 3 sensitive data, and "user name" as Level 2 sensitive data. However, these categorization and tagged attributes exist in metadata management systems (such as data asset management platforms), while entity objects in the source code (such as entity class fields and data access objects) are not directly associated with these attributes. Therefore, this embodiment introduces an automatic sensitive data entity identification mechanism based on metadata categorization and tagged attributes. Through the mapping relationship between metadata and code, sensitive attributes at the data level can be passed to data entities at the code level.

[0063] First, classification and grading tags for data assets can be obtained from a metadata management system. This information is typically organized at the table-field level. After obtaining the source code, a static code analysis engine can be used to identify the data entities in the source code that correspond to the database table fields. Common mapping methods include entity class mapping in object-relational mapping frameworks and code locations that directly use database access interfaces. The system can parse these mapping relationships and establish associations between database table fields and entity class fields, method parameters, variables, etc., in the source code. Then, the classification and grading tags from the metadata can be passed to the corresponding source code data entities.

[0064] In other embodiments, automatic propagation and inheritance of sensitive labels can also be supported. When a data entity is assigned to another variable or passed as a parameter to a method, the sensitive label can be automatically propagated along the data flow path, ensuring that all derived variables and parameters inherit the original sensitive attributes.

[0065] Understandably, the automatic identification of sensitive data entities based on metadata classification and grading labels enables the direct reuse of existing data asset classification and grading results. It automatically transfers sensitive attributes at the data level to data entities at the code level, providing an accurate and complete starting point for subsequent taint source identification, data flow tracing, and compliance verification, effectively improving the automation level and accuracy of detection.

[0066] Based on the above embodiments, in this embodiment, a static code analysis engine is used to analyze the transmission path of sensitive data entities in the source code, including: parsing the source code with the static code analysis engine to generate an abstract syntax tree; identifying the definition and usage locations of sensitive data entities based on the abstract syntax tree; and tracing the transmission path of sensitive data entities from the definition location to the usage location based on a data flow analysis algorithm.

[0067] Static code analysis engines first perform lexical and syntactic analysis on the application's source code, transforming it into an abstract syntax tree (AST). An AST is an abstract representation of the source code, organizing syntactic elements in a tree-like structure. Each node can represent a syntactic structure, such as package declarations, class definitions, method declarations, variable declarations, assignment statements, method calls, conditional branches, and loop structures. ASTs preserve the hierarchical structure and syntactic relationships of the code while ignoring irrelevant syntactic details like parentheses and semicolons, providing a structured data foundation for subsequent code analysis.

[0068] During the generation of the abstract syntax tree, the engine can record the location information of each syntax node, including the source code file name, starting line number, ending line number, starting column number, ending column number, etc., to quickly locate code locations with compliance risks.

[0069] After obtaining the abstract syntax tree (Abstract Syntax Tree), the definition and usage locations of these entities can be identified within the Abstract Syntax Tree based on the sensitive data entity information. The definition location refers to the code position where the sensitive data entity is first declared or initialized, such as the declaration statements of entity class fields, local variables, and method parameters. The usage location refers to the code position where the sensitive data entity is read, assigned, passed, or used as a parameter, such as statements where variables are assigned to other variables, variables used as method call parameters, variables used as return values, and variables involved in calculations or conditional statements.

[0070] The identification process can be implemented by traversing the abstract syntax tree and matching node types. For each sensitive data entity, the abstract syntax tree can be searched for syntax nodes that match its name and context, and the location information and node type of these nodes can be recorded. For example, for entity class fields, the field declaration nodes under the class definition node can be found; for method parameters, the parameter definition nodes in the method declaration node can be found; and for local variables, the variable declaration nodes in the method body can be found.

[0071] After identifying the definition and usage locations of sensitive data entities, data flow analysis algorithms can be used to trace the propagation path of these entities from their definition locations to their usage locations without actually executing the code. This involves starting from the definition location of the sensitive data entity and analyzing its propagation process within the code along the program's control and data flow directions. Throughout the tracing process, a complete data flow graph can be constructed. Nodes in the graph represent locations within the code (variable declarations, method call points, etc.), and edges represent data flow relationships. Each edge can carry rich attribute information, such as the propagation type, its location in the code, and whether it has undergone encryption or de-identification processing. Ultimately, the complete propagation path from the taint source to all usage points can be output.

[0072] Understandably, by parsing the source code into a structured syntax tree representation and combining it with data flow analysis techniques, accurate tracking of sensitive data entities was achieved.

[0073] Figure 3 A flowchart illustrating a data lineage mapping method according to an embodiment of this application is shown schematically.

[0074] Based on the above embodiments, in this embodiment, as follows: Figure 3 As shown, a data lineage graph is constructed based on the transmission path and metadata, including: in step S310, generating variable-level lineages of sensitive data entities within different services according to the transmission path, wherein the service is implemented by at least one application, and the variable-level lineage is used to record the transmission path between variables of sensitive data entities within the application; in step S320, connecting the variable-level lineages within different services through the call relationship between services to form a cross-service data flow chain; and in step S330, constructing a directed attribute graph model as the data lineage graph based on metadata, variable-level lineages, and data flow chains.

[0075] In real-world distributed system architectures, applications are typically deployed as microservices, and sensitive data often flows across multiple services. Building only the data lineage within a single service cannot present the full picture of sensitive data flow throughout the entire business chain. Therefore, this embodiment constructs an end-to-end data lineage graph covering the entire chain by integrating variable-level lineages within services with inter-service call relationships.

[0076] Based on the propagation paths output by the enhanced static code analysis engine, variable-level lineages can be generated for each service (i.e., each independently deployed application). Variable-level lineages record the precise propagation paths of sensitive data entities within the service, including the complete variable-level flow relationships from entity fields in the data access layer, to local variables in the business logic layer, and finally to return values ​​in the interface layer. Each variable-level lineage records the relationships between variables (assignment, method parameter passing, return value passing, etc.) in the form of directed edges, and carries attribute information such as its code location and whether it has been encrypted or de-identified.

[0077] Building upon this, the variable-level lineage within different services can be connected by analyzing the call relationships between services. These call relationships can be identified by analyzing the interface definitions and call code in the source code, determining how parameters containing sensitive data are passed between services. When the system detects that service A's API call passes sensitive data as a parameter to service B, the system can establish a cross-service data flow edge between service A's output node and service B's input node, thereby linking the variable-level lineage within the two services to form a complete cross-application / service data flow chain.

[0078] Based on metadata (including data classification, grading, tags, storage location, etc.), variable-level lineage within each service, and cross-service data flow chains, a directed attribute graph model can be constructed to generate an end-to-end data lineage graph covering the database / storage layer, data access layer, application service layer, and application programming interface / user interface layer, integrating fine-grained code variable-level tracing and cross-service call-level views. The nodes of this graph represent data entities at different levels, including database table fields, entity class fields, method parameters, local variables, and API parameters; the edges represent the flow relationships between data entities and carry attributes such as transmission type, code location, and service boundary. Through this graph, end-to-end coverage from the data storage layer, data access layer, application service layer to the API interface layer can be achieved, clearly presenting the complete flow path of sensitive data in a distributed microservice architecture.

[0079] Understandably, by integrating the data lineage graph constructed from the variable-level lineage within services and the call relationships between services, a precise depiction of the complete flow path of sensitive data in a distributed microservice architecture is achieved. This breaks through the limitations of traditional lineage analysis, which only stays at the table or field level, eliminates detection blind spots in microservice architecture, and ultimately improves the depth, accuracy, and coverage of compliance detection.

[0080] In embodiments of this application, the method further includes: breaking down pre-defined compliance requirements into atomic detection rules; and storing the atomic detection rules in a compliance rule base, wherein the atomic detection rules in the compliance rule base are loaded by a rule engine.

[0081] In practical data security compliance governance, regulations and internal policies are usually expressed in natural language, which is complex and subject to subjective interpretation, making it difficult to directly translate into automatically executable detection logic. To address this issue, this embodiment introduces a compliance requirement decomposition and rule base management mechanism, transforming abstract compliance requirements into structured, independently executable atomic detection rules.

[0082] First, pre-defined compliance requirements can be broken down. These requirements can originate from external regulations or internal corporate policies (such as data classification and protection specifications, and secure development guidelines). During this breakdown, complex regulatory provisions and internal policies can be decomposed according to dimensions such as data objects, technical scenarios, and constraints, forming independent, single-responsibility atomic detection rules. Each atomic detection rule can include the following core elements: a unique identifier for rule identification and management; the data object to which the rule applies, specifying the data category, classification label, or data type; triggering conditions, defining the scenario in which the rule is activated, such as "when the data entity's sensitivity level is level 4" or "when data flows to an API interface"; constraints, defining the technical requirements that must be met, such as "encrypted storage required," "anonymized display required," and "prohibition of output to logs"; and a violation description, used to standardize the description of the violation scenario, facilitating the generation of compliance reports and remediation suggestions.

[0083] The decomposed atomic detection rules can be stored in a compliance rule repository, which supports adding, deleting, modifying, and querying rules, as well as version management and categorization. Through centralized management of the rule repository, enterprises can uniformly maintain compliance detection rules across the entire company, ensuring that different business systems and development teams adhere to consistent compliance standards. Furthermore, the rule repository supports dynamic rule updates; when regulations and policies change, only the corresponding rules need to be updated in the rule repository, without modifying the detection engine code.

[0084] Atomic detection rules in the compliance rule base can be loaded through the rule engine. The rule engine is a rule execution component that supports hot loading, achieving separation of rules and execution logic through decoupling design. The rule engine loads all atomic rules in the compliance rule base when the system starts and continuously monitors for changes to the rule base. When rules are added, modified, or deleted in the rule base, the rule engine can hot-load the updated rules in real time without restarting the detection system. During the detection process, the rule engine can traverse the node and edge attributes of the data lineage graph, dynamically match atomic rules in the rule base, automatically trigger rule verification, and generate violation detection reports.

[0085] Understandably, the centralized management and hot-loading mechanism of the compliance rule base enables compliance strategies to respond quickly to regulatory changes without frequent modifications to the detection engine code, thus significantly reducing the maintenance costs of compliance strategies. Meanwhile, the decoupled design of the rule engine and the data lineage graph gives the system excellent scalability, allowing for flexible addition or adjustment of detection rules according to business needs.

[0086] In embodiments of this application, the method further includes: adjusting the atomic detection rules in the compliance rule base through the configuration interface of the rule engine; wherein, the adjustment includes adding new atomic detection rules, modifying or disabling existing atomic detection rules.

[0087] The rules engine adopts a modular architecture design that completely decouples the rules engine from the core detection engine. The rules engine provides a configuration interface, which can take the form of a management console, command-line tool, or configuration file, allowing compliance administrators to perform rule management operations. Through this configuration interface, users can flexibly adjust the atomic detection rules in the compliance rule base. Specifically, they can add new atomic detection rules; for example, when new regulations require "biometric information to be stored separately," a corresponding detection rule can be added to the rule base. They can also modify existing atomic detection rules; for example, when the sensitive data classification standard changes from "level 4 requires encryption" to "level 3 and above all require encryption," the constraints of the corresponding rule can be updated. Furthermore, they can deactivate temporarily inapplicable or outdated rules to prevent invalid detections from interfering with normal results.

[0088] After the rule adjustment is completed, the rule engine can make the new rules effective through a hot-reloading mechanism, without restarting the core code analysis engine or the graph database service. Newly added or modified rules can take effect immediately in the next scan task or real-time monitoring process. This hot-reloading mechanism is based on a decoupled design between the rule engine and the detection engine. That is, when the detection engine traverses the data lineage graph, it does not directly embed rule logic but instead retrieves the currently effective rule set from the rule engine in real time. The rule engine, on the other hand, can listen for changes in the rule database. Once a rule change is detected, it immediately updates the rule cache in memory to ensure that subsequent rules use the latest rules.

[0089] Understandably, by dynamically adjusting and hot-loading the detection rules, compliance response speed is significantly improved and maintenance costs are reduced. When faced with new regulatory requirements or changes in internal policies, only the rule base file needs to be updated and hot-loaded, without the need to modify, compile, or deploy core system code. The rule effectiveness cycle is shortened from the traditional days or even weeks to minutes, thereby significantly reducing the maintenance costs of compliance policies and the risk of business interruption.

[0090] Based on the above embodiments, in this embodiment, the data security compliance of the application is determined according to the verification results, including: when the verification results indicate that the data entity or data flow relationship does not meet the constraints of the atomic detection rules, a violation detection report is generated, wherein the violation detection report includes the code location where the violation occurred and the data flow relationship of the sensitive data entity that triggered the violation in the data lineage graph.

[0091] After completing the traversal of the data lineage graph and verifying the atomicity detection rules, the detection results can be summarized and analyzed to generate a detailed compliance detection report. When the verification results indicate that a data entity or data flow relationship does not meet the constraints of the atomicity detection rules, a violation detection report can be automatically generated, providing developers and compliance managers with precise violation location and remediation guidance.

[0092] A violation detection report can include the following key information: Violation description, which outputs a description of the atomic detection rule that triggered the violation, clearly informing the user which compliance requirement was violated. For example, "Sensitive data was not stored encrypted" or "Level 4 data was output in plaintext in the log." The code location where the violation occurred, which is the specific code location where the violation occurred, extracted by the system from the node or edge attributes of the data lineage graph, including the source code file name, start line number, end line number, class name, method name, etc. Through precise code location, developers can quickly jump to the location of the violating code for repair. The sensitive data entity that triggered the violation, which identifies the sensitive data entity that triggered the violation, including the entity name (e.g., variable name, field name), data type (e.g., ID card number, bank card number), sensitivity level (e.g., Level 4 sensitivity), and a complete description of the entity in the data lineage graph. The complete data flow path of the violation (determined through data flow relationships), which is the complete data flow path of the sensitive data entity that triggered the violation extracted by the system from the data lineage graph, displaying the entire chain of sensitive data flow from the source to the violation point in a graphical or textual manner. By analyzing the complete data flow path, the root cause of the violation can be determined. Missing or non-compliant protection measures can be explicitly identified based on the constraints of the atomic detection rules, pinpointing the missing protection measures in the current data entity or data flow relationship. Remediation suggestions are generated by the system based on the violation type and contextual information.

[0093] After generating the violation detection report, the report can be output in various formats. For example, it can be displayed as a list of issues in the development integration environment, making it easy for developers to fix them immediately; or it can be pushed to the relevant responsible persons via email or message notification to ensure that violations are handled in a timely manner.

[0094] Understandably, generating violation detection reports can transform abstract compliance verification results into specific and actionable remediation guidelines, significantly improving the discoverability and remediability of compliance issues.

[0095] Based on the above-described method for data security compliance testing, this application also provides an apparatus for data security compliance testing. The following will be combined with... Figure 4 The device is described in detail.

[0096] Figure 4 A schematic block diagram of an apparatus for data security compliance testing according to an embodiment of this application is shown.

[0097] like Figure 4 As shown, the device 400 for data security compliance detection in this embodiment includes an acquisition module 410, an analysis module 420, a construction module 430, a matching module 440, and a verification module 450.

[0098] The acquisition module 410 is used to acquire metadata and the application's source code, wherein the metadata is used to characterize the attributes of data entities processed by the source code. In one embodiment, the acquisition module 410 can be used to perform step S210 described above, which will not be repeated here.

[0099] The analysis module 420 is used to analyze the transmission path of sensitive data entities in the source code using a static code analysis engine. In one embodiment, the analysis module 420 can be used to perform step S220 described above, which will not be repeated here.

[0100] The construction module 430 is used to construct a data lineage graph based on the transmission path and metadata. Nodes in the data lineage graph represent data entities from the data storage layer to the application layer, and edges represent the data flow relationships between data entities. In one embodiment, the construction module 430 can be used to execute step S230 described above, which will not be repeated here.

[0101] The matching module 440 is used to traverse the nodes and edges of the data lineage graph based on the atomic detection rules, and match the attributes of the nodes and edges with the triggering conditions of the atomic detection rules. In one embodiment, the matching module 440 can be used to execute step S240 described above, which will not be repeated here.

[0102] The verification module 450 is used to verify the data entity or data flow relationship according to the constraints in the corresponding atomic detection rule in response to a successful match, and to determine the data security compliance of the application based on the verification result. In one embodiment, the verification module 450 can be used to perform step S250 described above, which will not be repeated here.

[0103] According to an embodiment of this application, the analysis module 420 can be specifically used to: parse the source code through a static code analysis engine to generate an abstract syntax tree; identify the definition location and usage location of sensitive data entities based on the abstract syntax tree; and trace the transmission path of sensitive data entities from the definition location to the usage location based on a data flow analysis algorithm.

[0104] According to an embodiment of this application, the construction module 430 can be specifically used to: generate variable-level lineages of sensitive data entities within different services based on the transmission path, wherein the service is implemented by at least one application, and the variable-level lineage is used to record the transmission path between variables of sensitive data entities within the application; connect the variable-level lineages within different services through the call relationship between services to form a cross-service data flow chain; and construct a directed attribute graph model as a data lineage graph based on metadata, variable-level lineages, and data flow chains.

[0105] According to an embodiment of this application, the analysis module 420 can also be used to: determine sensitive data entities in the source code based on classification and grading tags in metadata.

[0106] According to an embodiment of this application, the matching module 440 can also be used to: decompose the pre-set compliance requirements into atomic detection rules; and store the atomic detection rules in a compliance rule library, wherein the atomic detection rules in the compliance rule library are loaded by a rule engine.

[0107] According to an embodiment of this application, the matching module 440 can also be used to: adjust the atomic detection rules in the compliance rule base through the configuration interface of the rule engine; wherein, the adjustment includes adding new atomic detection rules, modifying or disabling existing atomic detection rules.

[0108] According to an embodiment of this application, the verification module 450 can be specifically used to: generate a violation detection report when the verification result indicates that the data entity or data flow relationship does not meet the constraints of the atomic detection rule, wherein the violation detection report includes the code location where the violation occurred and the data flow relationship of the sensitive data entity that triggered the violation in the data lineage graph.

[0109] According to embodiments of this application, any multiple modules among the acquisition module 410, analysis module 420, construction module 430, matching module 440, and verification module 450 can be combined into one module, or any one of these modules can be split into multiple modules. Alternatively, at least some of the functions of one or more of these modules can be combined with at least some of the functions of other modules and implemented in one module. According to embodiments of this application, at least one of the acquisition module 410, analysis module 420, construction module 430, matching module 440, and verification module 450 can be at least partially implemented as hardware circuitry, such as a field-programmable gate array (FPGA), a programmable logic array (PLA), a system-on-a-chip, a system-on-a-substrate, a system-on-package, an application-specific integrated circuit (ASIC), or implemented in hardware or firmware by any other reasonable means of integrating or packaging the circuitry, or implemented in software, hardware, or firmware, or in any suitable combination of any of these three implementation methods. Alternatively, at least one of the acquisition module 410, analysis module 420, construction module 430, matching module 440 and verification module 450 may be implemented at least partially as a computer program module, which can perform corresponding functions when the computer program module is run.

[0110] Figure 5 A block diagram schematically illustrates an electronic device suitable for implementing a method for data security compliance testing according to an embodiment of this application.

[0111] like Figure 5 As shown, an electronic device 500 according to an embodiment of this application includes a processor 501, which can perform various appropriate actions and processes according to a program stored in a read-only memory 502 or a program loaded from a storage portion 508 into a random access memory 503. The processor 501 may include, for example, a general-purpose microprocessor, an instruction set processor and / or an associated chipset and / or a dedicated microprocessor. The processor 501 may also include onboard memory for caching purposes. The processor 501 may include a single processing unit or multiple processing units for executing different steps of the method flow according to an embodiment of this application.

[0112] Random access memory 503 stores various programs and data required for the operation of electronic device 500. Processor 501, read-only memory 502, and random access memory 503 are interconnected via bus 504. Processor 501 executes various steps of the method flow according to embodiments of this application by executing programs stored in read-only memory 502 and / or random access memory 503. It should be noted that programs may also be stored in one or more memories other than read-only memory 502 and random access memory 503. Processor 501 may also execute various steps of the method flow according to embodiments of this application by executing programs stored in one or more memories.

[0113] According to embodiments of this application, the electronic device 500 may further include an input / output interface 505, which is also connected to a bus 504. The electronic device 500 may also include one or more of the following components connected to the input / output interface 505: an input section 506 including a keyboard, mouse, etc.; an output section 507 including a cathode ray tube, liquid crystal display, etc., and a speaker, etc.; a storage section 508 including a hard disk, etc.; and a communication section 509 including a network interface card, such as a local area network card, modem, etc. The communication section 509 performs communication processing via a network such as the Internet. A drive 510 is also connected to the input / output interface 505 as needed. A removable medium 511, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., is installed on the drive 510 as needed so that computer programs read from it can be installed into the storage section 508 as needed.

[0114] Embodiments of this application also provide a computer-readable storage medium, which may be included in the device / apparatus / system described in the above embodiments; or it may exist independently and not assembled into the device / apparatus / system. The computer-readable storage medium carries one or more programs, which, when executed, implement the method according to the embodiments of this application.

[0115] According to embodiments of this application, the computer-readable storage medium can be a non-volatile computer-readable storage medium, such as including but not limited to: portable computer disks, hard disks, random access memory, read-only memory, erasable programmable read-only memory, portable compact disk read-only memory, optical storage devices, magnetic storage devices, or any suitable combination thereof. In embodiments of this application, the computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. For example, according to embodiments of this application, the computer-readable storage medium may include the read-only memory 502, and / or random access memory 503, and / or one or more memories other than read-only memory 502 and random access memory 503 described above.

[0116] Embodiments of this application also include a computer program product comprising a computer program containing program code for performing the methods shown in the flowchart. When the computer program product is run on a computer system, the program code is used to cause the computer system to implement the methods provided in the embodiments of this application.

[0117] In one embodiment, the computer program may rely on a tangible storage medium such as an optical storage device or a magnetic storage device. In another embodiment, the computer program may also be transmitted and distributed in the form of signals over a network medium, and may be downloaded and installed via the communication section 509, and / or installed from a removable medium 511. The program code contained in the computer program can be transmitted using any suitable network medium, including but not limited to: wireless, wired, etc., or any suitable combination thereof.

[0118] In embodiments of this application, the computer program can be downloaded and installed from a network via communication section 509, and / or installed from removable medium 511. When the computer program is executed by processor 501, it performs the functions defined in the system of this application embodiment. According to embodiments of this application, the systems, devices, apparatuses, modules, units, etc., described above can be implemented by computer program modules.

[0119] According to embodiments of this application, program code for executing the computer programs provided in the embodiments of this application can be written in any combination of one or more programming languages. Specifically, these computational programs can be implemented using high-level procedural and / or object-oriented programming languages, and / or assembly / machine languages. The program code can be executed entirely on the user's computing device, partially on the user's device, partially on a remote computing device, or entirely on a remote computing device or server. In cases involving remote computing devices, the remote computing device can be connected to the user's computing device via any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computing device (e.g., via the Internet using an Internet service provider).

[0120] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram or flowchart, and combinations of blocks in a block diagram or flowchart, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0121] Those skilled in the art will understand that the features described in the various embodiments of this application can be combined and / or combined in various ways, even if such combinations or combinations are not explicitly described in this application. In particular, the features described in the various embodiments of this application can be combined and / or combined in various ways without departing from the spirit and teachings of this application. All such combinations and / or combinations fall within the scope of this application.

Claims

1. A method for data security compliance detection, characterized in that, include: Obtain metadata and the application's source code, wherein the metadata is used to characterize the attributes of the data entities processed by the source code; The transmission path of sensitive data entities in the source code is analyzed using a static code analysis engine. Based on the transmission path and the metadata, a data lineage graph is constructed, wherein the nodes of the data lineage graph represent data entities from the data storage layer to the application layer, and the edges of the data lineage graph represent the data flow relationships between the data entities. Based on the atomic detection rules, the nodes and edges of the data lineage graph are traversed, and the attributes of the nodes and edges are matched with the triggering conditions of the atomic detection rules; and In response to a successful match, the data entity or data flow relationship is verified according to the constraints in the corresponding atomic detection rule, and the data security compliance of the application is determined based on the verification result.

2. The method of claim 1, wherein, The step of analyzing the transmission path of sensitive data entities in the source code using a static code analysis engine includes: The source code is parsed using the static code analysis engine to generate an abstract syntax tree; Based on the abstract syntax tree, identify the definition and usage locations of the sensitive data entities; and Based on data flow analysis algorithms, the transmission path of the sensitive data entity is traced from the defined location to the usage location.

3. The method of claim 1, wherein, The construction of a data lineage graph based on the transmission path and the metadata includes: Based on the transmission path, a variable-level lineage of the sensitive data entity is generated within different services, wherein the service is implemented by at least one application, and the variable-level lineage is used to record the transmission path of the sensitive data entity between variables within the application. The variable-level lineages within different services are connected through inter-service call relationships to form a cross-service data flow chain; and Based on the metadata, the variable-level lineage, and the data flow chain, a directed attribute graph model is constructed as the data lineage graph.

4. The method of claim 1, wherein, The method further includes: Sensitive data entities in the source code are identified based on the classification and grading tags in the metadata.

5. The method of claim 1, wherein, The method further includes: The pre-defined compliance requirements are broken down into the aforementioned atomized detection rules; and The atomic detection rules are stored in a compliance rule base, and the atomic detection rules in the compliance rule base are loaded by a rule engine.

6. The method of claim 5, wherein, The method further includes: The atomic detection rules in the compliance rule base can be adjusted through the configuration interface of the rule engine. The adjustments include adding new atomization detection rules, modifying or disabling existing atomization detection rules.

7. The method of claim 1, wherein, The step of determining the data security compliance of the application based on the verification results includes: When the verification result indicates that the data entity or data flow relationship does not meet the constraints of the atomic detection rule, a violation detection report is generated. The violation detection report includes the code location where the violation occurred and the data flow relationship of the sensitive data entity that triggered the violation in the data lineage graph.

8. An apparatus for data security compliance testing, characterized in that, include: The acquisition module is used to acquire metadata and the source code of the application, wherein the metadata is used to characterize the attributes of the data entities processed by the source code; The analysis module is used to analyze the transmission path of sensitive data entities in the source code through a static code analysis engine; A construction module is used to construct a data lineage graph based on the transmission path and the metadata, wherein the nodes of the data lineage graph represent data entities from the data storage layer to the application layer, and the edges of the data lineage graph represent the data flow relationships between the data entities; The matching module is used to traverse the nodes and edges of the data lineage graph based on atomic detection rules, and match the attributes of the nodes and edges with the triggering conditions of the atomic detection rules; and The verification module is used to verify the data entity or data flow relationship according to the constraints in the corresponding atomic detection rules in response to a successful match, and to determine the data security compliance of the application based on the verification results.

9. An electronic device, comprising: One or more processors; Memory, used to store one or more computer programs. The characteristic feature is that the one or more processors execute the one or more computer programs to implement the steps of the method according to any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program or instructions stored thereon, characterized in that, When the computer program or instructions are executed by a processor, they implement the steps of the method according to any one of claims 1 to 7.

11. A computer program product, comprising a computer program or instructions, characterized in that, When the computer program or instructions are executed by a processor, they implement the steps of the method according to any one of claims 1 to 7.

Images