Method for real-time identification and automatic correction of sensitive data operation based on data development IDE

Abstract

The application discloses a sensitive data operation real-time identification and automatic correction method based on a data development IDE, and belongs to the technical field of big data. Through a plug-in mechanism deeply integrated in the data development IDE, the SQL statements written by developers are monitored and analyzed in real time, and sensitive fields and their levels are automatically identified in combination with an enterprise-level sensitive data knowledge base. The system intelligently matches disposal strategies according to user roles, running environments and sensitive levels, and gives risk prompts in the editing interface in the form of visual markers. Users can trigger automatic correction by one key, replace plaintext sensitive fields with predefined safe function calls, and realize the compliance reconstruction of SQL statements. The whole process is completed in real time in the development stage, forming a closed loop from risk identification, strategy matching, interface prompting to automatic correction and audit tracing, and effectively improving the endogenous safety level and development efficiency of the data development link.

Description

Technical Field

[0001] This invention belongs to the field of big data technology, specifically relating to a method for real-time identification and automatic correction of sensitive data operations based on a data development IDE. Background Technology

[0002] With the continuous expansion of enterprise data assets and increasingly stringent data security compliance requirements, the protection of sensitive information during data development has become a crucial aspect of ensuring data security throughout its entire lifecycle. In current mainstream data development practices, engineers primarily use SQL scripts to query, process, and analyze databases. However, sensitive fields such as Personal Identification Information (PII), financial accounts, and contact information, if not properly handled, can easily lead to data breaches. Therefore, accurately identifying and compliantly handling sensitive data operations during the code writing phase has become a core issue in enhancing the inherent security capabilities of data development.

[0003] Among them, the sensitive data operation identification and correction technology based on the data development integrated development environment (IDE) aims to bring security control mechanisms forward to the coding stage to achieve real-time and proactive risk prevention and control. This technology focuses on dynamically parsing the syntax structure and semantic context of SQL statements written by developers. Combined with an enterprise-level sensitive data knowledge base and security policy center, it automatically determines whether the operated fields belong to the sensitive category and intelligently matches appropriate handling strategies based on factors such as environment attributes, user roles, and sensitivity levels. This allows for risk alerts and code corrections without interrupting the development process.

[0004] However, existing technologies still have significant drawbacks. Traditional solutions generally adopt a post-event auditing model, relying on log backtracking analysis of sensitive operations after code deployment. This leads to a severe delay in risk discovery, high remediation costs, and difficulty in tracing the scope of impact. Another type of plug-in component model attempts to intervene during the development phase, but it only exists as an independent function library or external interface, requiring developers to actively call it. It is highly dependent on their security awareness and operating habits, and is easily bypassed due to negligence or efficiency considerations, failing to ensure full coverage and strong consistency. More importantly, existing methods fail to deeply integrate with the IDE's own syntax parsing and editing capabilities, lacking awareness of internal contexts such as abstract syntax trees and symbol tables. This results in insufficient accuracy in sensitive data identification, correction suggestions that are out of touch with the actual code structure, and frequent window switching to query the data directory, severely disrupting the development process. Therefore, there is an urgent need for a method for real-time identification and correction of sensitive data operations that can be deeply integrated into the data development IDE, possess event-driven syntax awareness capabilities, and support adaptive strategy matching and one-click automatic correction. Summary of the Invention

[0005] The purpose of this invention is to provide a method for real-time identification and automatic correction of sensitive data operations based on a data development IDE, which can effectively solve the problems mentioned in the background art.

[0006] To achieve the above objectives, the technical solution adopted by the present invention is as follows:

[0007] A method for real-time identification and automatic correction of sensitive data operations based on a data development IDE includes the following steps:

[0008] Step 1: When the data development integrated development environment starts, register the security event listener module with the IDE's internal syntax event bus through the plugin registration interface to continuously subscribe to and capture the syntax change events generated by the SQL statements entered or modified by the developer in the editor;

[0009] Step 2: In response to the syntax change event, the IDE syntax context awareness module is invoked to obtain the complete abstract syntax tree and symbol resolution table from within the IDE, and the captured SQL statement is subjected to lexical and syntactic analysis to extract a structured list of data fields;

[0010] Step 3: Using the structured list of data fields as query input, call the sensitive data flow analysis module, and compare it with the symbol type information maintained internally by the IDE and the enterprise-level sensitive data knowledge base to identify whether each field belongs to the category of sensitive data, and mark the corresponding sensitivity level and Chinese semantic name;

[0011] Step 4: Execute the strategy matching logic based on the identification results. Take into account the current user's development role, runtime environment attributes, and the sensitivity level of the fields to determine the type of handling strategy to be triggered and generate strategy matching output.

[0012] Step 5: Call the IDE's native tag injection module, match the output according to the strategy, apply visual tags to sensitive fields with risks in the code editing interface, and bind hover information to display risk details and executable correction suggestions;

[0013] Step 6: When the user triggers the one-click correction command, the syntax-aware code correction module is activated, the security function template is parsed and the original field reference is replaced, and the plaintext sensitive fields are automatically encapsulated into the de-identified or encrypted function call, completing the compliance reconstruction of the SQL statement and ensuring that the new statement conforms to the IDE syntax validation rules.

[0014] Step 7: Write the corrected SQL statement back to the editing buffer, clear the original risk markers, update the code status to compliant, and synchronize the operation record to the background audit log system to obtain the behavior traceability chain.

[0015] Furthermore, the method also includes:

[0016] The security event listener module is implemented in Java through the UDF extension mechanism provided by the IDE. During the registration process, it requests listening permissions for the core syntax events ASTChangeEvent and SymbolResolutionCompleteEvent in order to obtain the complete semantic analysis intermediate representation generated by the compiler front end.

[0017] The list of data fields includes the operation action and the target data table;

[0018] The strategy matching output includes the risk location, processing requirements, and corresponding security function template;

[0019] The visual markers include a warning icon next to the line number and a wavy line prompt below the field.

[0020] Furthermore, the method also includes:

[0021] The IDE syntax context awareness module uses the IDE's internal API to access the abstract syntax tree node stream, parses the operation structure of DML statements including SELECT, INSERT, UPDATE, and DELETE according to preset traversal rules, restores the field alias mapping relationship, realizes the symbol expansion from u.name to users.user_name, and outputs a standardized set of operation object information.

[0022] Furthermore, the method also includes:

[0023] When performing tag queries, the sensitive data stream analysis module adopts a two-level caching mechanism. The first level is a local memory cache that stores frequently accessed sensitive field tags, and the second level is a distributed remote service interface that connects to the enterprise's unified data catalog platform, supporting dynamic updates to the sensitive asset list.

[0024] Furthermore, the method also includes:

[0025] The strategy matching logic makes adaptive judgments based on a predefined multidimensional decision matrix. The dimensions of the multidimensional decision matrix include the sensitivity level value range, the current logged-in user role category, and the environment identifier of the current database instance.

[0026] The rule engine calculates a unique matching disposal strategy code.

[0027] Furthermore, the method also includes:

[0028] When the sensitivity level is greater than or equal to 3 and the environment is a production instance, the matching strategy is set to forced blocking mode to prevent code saving or execution.

[0029] When the sensitivity level is 2 and the user role is a tester, the matching strategy is set to mild inspection mode, which only records issues in the issue panel without interrupting the editing process.

[0030] Furthermore, the method also includes:

[0031] The IDE native tag injection module calls the IDE document annotation model interface to create temporary diagnostic tags, which render red or yellow wavy line graphic elements in the editor view layer. Red represents error-level risk, and yellow represents warning-level risk. Circular warning dots are added to the line number area, which can be clicked to jump to the first risk location.

[0032] Furthermore, the method also includes:

[0033] The hover information box contains the original field name, sensitivity level numeric identifier, Chinese description name, data category label, and recommended security processing function name. Users can trigger the automated replacement process directly by clicking the Apply Correction button.

[0034] Furthermore, the method also includes:

[0035] Before performing the replacement, the syntax-aware code correction module performs context compatibility verification, analyzes the positional characteristics of the expression containing the target field, and determines whether it is in an aggregate function, grouping condition, or concatenation predicate. If there is a contextual conflict, the automatic replacement is paused and a manual intervention evaluation is prompted.

[0036] The security function template is defined using a parameterized placeholder format. During actual replacement, {column_name} is dynamically replaced with the actual reference path of the current field, while preserving the original alias and table prefix structure.

[0037] Furthermore, the method also includes:

[0038] All functional modules are encapsulated as plug-in components that can run in mainstream data development IDEs. The plug-ins are developed in Java and packaged into JAR format files. After installation, they are automatically injected into the IDE's core class loading path and are initialized and registered during the IDE process startup phase.

[0039] The policy center management backend supports administrators in configuring sensitivity level classification standards, defining role-environment-policy mapping relationship tables, uploading custom regular expression recognition patterns, and distributing updates to all connected client plugins in real time.

[0040] A performance threshold monitoring mechanism is set up so that when syntax parsing and tag injection operations continuously occupy CPU time for more than a preset duration, the system automatically degrades to a low-frequency polling mode.

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

[0042] This invention achieves a technological breakthrough by deeply integrating sensitive data operation identification and correction mechanisms into the data development IDE, changing the passive mode of traditional plug-in tools that rely on manual invocation, and realizing security intervention from the source of code writing. This method utilizes the IDE's native event-driven architecture to immediately initiate syntax parsing and sensitivity determination as the user inputs SQL statements. Leveraging the precise context awareness capabilities of abstract syntax trees and symbol tables, it significantly improves the accuracy and coverage of sensitive field identification. By constructing an adaptive matching relationship between strategy types and multi-dimensional contexts, the system can intelligently select the appropriate handling method based on different development scenarios. It can implement mandatory interception in high-risk situations and maintain silent auditing in low-risk environments, balancing security and development efficiency. Furthermore, relying on the IDE's standard interface to implement native tag injection and syntax-aware code correction, the risk warning and one-click repair functions are seamlessly integrated into the existing development interface, eliminating the need to switch windows or manually search for documentation, greatly reducing the compliance burden on developers. The entire process completes closed-loop processing within milliseconds, truly achieving seamless, automated, and intelligent data security protection, fundamentally eliminating the risk of exposure of plaintext sensitive data during the development process, and improving the intrinsic security level of the enterprise's data governance system. Attached Figure Description

[0043] Figure 1 This is a flowchart illustrating the workflow of a method for real-time identification and automatic correction of sensitive data operations based on a data development IDE, which is claimed in this embodiment.

[0044] Figure 2 This is a schematic diagram of SQL code input for a method for real-time identification and automatic correction of sensitive data operations based on a data development IDE, which is claimed in this embodiment.

[0045] Figure 3 This is a schematic diagram of a sensitive data knowledge base field for a method for real-time identification and automatic correction of sensitive data operations based on a data development IDE, which is claimed in this embodiment.

[0046] Figure 4 This is a schematic diagram illustrating a proposed modification to a method for real-time identification and automatic correction of sensitive data operations based on a data development IDE, for which protection is sought in this embodiment.

[0047] Figure 5 This is a schematic diagram illustrating the one-click correction effect of a method for real-time identification and automatic correction of sensitive data operations based on a data development IDE, which is claimed in this embodiment. Detailed Implementation

[0048] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of the embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of this application.

[0049] References to embodiments herein mean that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of this application. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a mutually exclusive, independent, or alternative embodiment. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.

[0050] Currently, with the continuous expansion of enterprise data assets and increasingly stringent data security compliance requirements, the protection of sensitive information during data development has become a crucial link in ensuring data security throughout its entire lifecycle. In mainstream data development practices, engineers primarily use SQL scripts to query, process, and analyze databases. However, sensitive fields such as personal identification information, financial accounts, and contact information, if not properly handled, can easily lead to data leakage risks. Existing technologies generally employ post-audit or plug-in component models, which suffer from problems such as delayed risk detection, reliance on manual calls, insufficient identification accuracy, and correction suggestions being detached from the code structure, making it difficult to achieve real-time, proactive, and comprehensive security control during the development phase. To address these technical problems, this invention proposes a technical solution that deeply integrates a sensitive data operation identification and correction mechanism into the data development IDE, possesses event-driven syntax awareness capabilities, and supports adaptive strategy matching and one-click automatic correction. This solution is applied to a real-time identification and automatic correction method for sensitive data operations based on a data development IDE.

[0051] The overall technical architecture of this invention includes a security event listener module, an IDE syntax context awareness module, a sensitive data flow analysis module, a policy matching logic unit, an IDE native tag injection module, a syntax awareness code correction module, and a background audit log system. These modules work collaboratively to form a complete closed loop from event capture, context parsing, sensitivity identification, policy decision-making, visual prompts to automatic correction and audit traceability.

[0052] refer to Figure 1 This embodiment requests protection for a method for real-time identification and automatic correction of sensitive data operations based on a data development IDE, including the following steps:

[0053] Step 1: When the data development integrated development environment starts, register the security event listener module with the IDE's internal syntax event bus through the plugin registration interface to continuously subscribe to and capture the syntax change events generated by the SQL statements entered or modified by the developer in the editor;

[0054] Step 2: In response to the syntax change event, the IDE syntax context awareness module is invoked to obtain the complete abstract syntax tree and symbol resolution table from within the IDE, and the captured SQL statement is subjected to lexical and syntactic analysis to extract a structured list of data fields;

[0055] Step 3: Using the structured list of data fields as query input, call the sensitive data flow analysis module, and compare it with the symbol type information maintained internally by the IDE and the enterprise-level sensitive data knowledge base to identify whether each field belongs to the category of sensitive data, and mark the corresponding sensitivity level and Chinese semantic name;

[0056] Step 4: Execute the strategy matching logic based on the identification results. Take into account the current user's development role, runtime environment attributes, and the sensitivity level of the fields to determine the type of handling strategy to be triggered and generate strategy matching output.

[0057] Step 5: Call the IDE's native tag injection module, match the output according to the strategy, apply visual tags to sensitive fields with risks in the code editing interface, and bind hover information to display risk details and executable correction suggestions;

[0058] Step 6: When the user triggers the one-click correction command, the syntax-aware code correction module is activated, the security function template is parsed and the original field reference is replaced, and the plaintext sensitive fields are automatically encapsulated into the de-identified or encrypted function call, completing the compliance reconstruction of the SQL statement and ensuring that the new statement conforms to the IDE syntax validation rules.

[0059] Step 7: Write the corrected SQL statement back to the editing buffer, clear the original risk markers, update the code status to compliant, and synchronize the operation record to the background audit log system to obtain the behavior traceability chain.

[0060] Furthermore, the method also includes:

[0061] The security event listener module is implemented in Java through the UDF extension mechanism provided by the IDE. During the registration process, it requests listening permissions for the core syntax events ASTChangeEvent and SymbolResolutionCompleteEvent in order to obtain the complete semantic analysis intermediate representation generated by the compiler front end.

[0062] The list of data fields includes the operation action and the target data table;

[0063] The strategy matching output includes the risk location, processing requirements, and corresponding security function template;

[0064] The visual markers include a warning icon next to the line number and a wavy line prompt below the field.

[0065] In the aforementioned method for real-time identification and automatic correction of sensitive data operations based on a data development IDE, step 1 involves registering a high-priority security event listener module with the IDE's internal syntax event bus via a plugin registration interface when the data development integrated development environment (IDE) starts. This module continuously subscribes to and captures syntax change events generated by SQL statements entered or modified by the developer in the editor. Specifically, the security event listener module is implemented in Java using the IDE's UDF extension mechanism. During registration, it requests listening permissions for two core syntax events: ASTChangeEvent and SymbolResolutionCompleteEvent, ensuring access to the complete semantic analysis intermediate representation generated by the compiler frontend. This listener module is given a higher event processing priority than regular syntax checkers to ensure it intervenes before any other syntax analysis process, thereby capturing the most original and unmodified code change flow. Its deep access permissions allow it to penetrate the IDE's sandbox isolation layer and directly read the memory addresses of the internal symbol table and abstract syntax tree nodes, avoiding information distortion or delay caused by intermediate proxy layers. The registration process occurs during the plugin loading phase after the IDE main process has initialized. By calling standard extension point interfaces such as `com.intellij.openapi.editor.event.DocumentListener` and `com.intellij.psi.PsiTreeChangeListener`, the listener instance is bound to the global event dispatcher, enabling unified monitoring of all open documents. Once a developer performs a character insertion, deletion, or paste operation in any SQL file, the `DocumentChanged` event is triggered, which is then converted by the IDE kernel into an `ASTChangeEvent` and pushed to this listener for further processing.

[0066] Furthermore, the method also includes:

[0067] The IDE syntax context awareness module uses the IDE's internal API to access the abstract syntax tree node stream, parses the operation structure of DML statements including SELECT, INSERT, UPDATE, and DELETE according to preset traversal rules, restores the field alias mapping relationship, realizes the symbol expansion from u.name to users.user_name, and outputs a standardized set of operation object information.

[0068] In the aforementioned method for real-time identification and automatic correction of sensitive data operations in a data-driven IDE, step 2, in response to the syntax change event, invokes the IDE syntax context awareness module to obtain the complete abstract syntax tree and symbol resolution table from within the IDE. It then performs millisecond-level lexical and syntactic parsing on the captured SQL statements, extracting structured operation actions, target data tables, and lists of involved data fields. Specifically, the IDE syntax context awareness module utilizes the IDE's internal API to access the abstract syntax tree node stream, parses the operation structure of DML statements such as SELECT, INSERT, UPDATE, and DELETE according to preset traversal rules, restores field alias mapping relationships, implements symbol expansion such as from u.name to users.user_name, and outputs a standardized set of operation object information. This module first extracts the range of changed line numbers from the event payload, locates the root node of the affected syntax subtree, avoids full re-parsing of the entire document, and thus controls the single parsing time to within 5 milliseconds. Subsequently, a depth-first traversal strategy is employed to recursively visit each AST node, identifying top-level statement types such as PsiSelectStatement and PsiInsertStatement, and then delving down to leaf nodes such as PsiColumnReference and PsiTableReference. For each field reference node, the module queries the IDE's built-in symbol resolution service, PsiResolveHelper, to obtain the final bound real database column name, the table name, and the database instance identifier. During this process, the module handles complex alias chains effectively; for example, in the statement `SELECT u.name AS full_name FROM usersu JOIN profiles p ON u.id = p.user_id`, it accurately traces `full_name` back to `users.name`. All parsing results are encapsulated into a structured data object, containing the operation type value field: SELECT / INSERT / UPDATE / DELETE, the target table list format: `[schema.table]`, the field reference list format: `[table.column -> alias]`, and the statement scope context, such as whether it is within a subquery, CTE block, or view definition.

[0069] Furthermore, the method also includes:

[0070] When performing tag queries, the sensitive data stream analysis module adopts a two-level caching mechanism. The first level is a local memory cache that stores frequently accessed sensitive field tags, and the second level is a distributed remote service interface that connects to the enterprise's unified data catalog platform, supporting dynamic updates to the sensitive asset list.

[0071] In the aforementioned method for real-time identification and automatic correction of sensitive data operations based on a data-driven IDE, step 3 involves using the structured data field list as query input to call the sensitive data flow analysis module. This module compares the symbol type information maintained within the IDE with the enterprise-level sensitive data knowledge base to identify whether each field falls under the category of sensitive data and labels its corresponding sensitivity level and Chinese semantic name. Specifically, when performing tag queries, the sensitive data flow analysis module employs a two-level caching mechanism to improve matching efficiency. The first level is a local memory cache storing frequently accessed sensitive field tags. The second level is a distributed remote service interface that connects to the enterprise's unified data catalog platform, supporting dynamic updates to the sensitive asset list and ensuring that the tag system is synchronized with organizational policies. The local cache uses an Least Recently Used (LRU) eviction policy with a maximum capacity of 10,000 records. Each record includes a fully qualified field name (e.g., prod_db.users.phone_number), a sensitivity level integer value (1-5), a Chinese description (e.g., mobile phone number), a data category (e.g., PII-Contact), and a last update timestamp. When a new field query request is received, the module first performs a hash lookup in the local cache. If a match is found, the cached result is returned directly. If no match is found, a gRPC request is constructed and sent to the SensitiveDataLookup endpoint of the enterprise data catalog service via a TLS encrypted channel. This remote service receives the field tuple and performs exact matching or regular expression pattern matching in its distributed database. It also supports custom regular expressions uploaded by the administrator, such as... `_ssn$` matches all fields ending with `_ss` and returns the result along with the TTL (Time-To-Live) value. The module writes the new result to the local cache and sets an expiration callback. This two-level mechanism ensures sub-millisecond response times in over 95% of regular query scenarios, while also guaranteeing the global consistency and timeliness of the sensitive asset list.

[0072] Furthermore, the method also includes:

[0073] The strategy matching logic makes adaptive judgments based on a predefined multidimensional decision matrix. The dimensions of the multidimensional decision matrix include the sensitivity level value range, the current logged-in user role category, and the environment identifier of the current database instance.

[0074] The rule engine calculates a unique matching disposal strategy code.

[0075] In the aforementioned method for real-time identification and automatic correction of sensitive data operations based on a data-driven IDE, step 4 involves executing a strategy matching logic based on the identification results. This logic combines the current user's development role, runtime environment attributes, and the sensitivity level of the fields to determine the appropriate handling strategy type and generate a strategy matching output containing the risk location, handling requirements, and corresponding security function templates. Specifically, the strategy matching process is based on a predefined multidimensional decision matrix for adaptive judgment. The dimensions of this multidimensional decision matrix include the sensitivity level range, the current logged-in user's role category, and the environment identifier of the current database instance. A unique matching handling strategy code is calculated using a rule engine to achieve differentiated response control. The strategy decision matrix is ​​stored in JSON format in the strategy center management backend and synchronized to the client plugin in real time via a WebSocket long connection. Each row of the matrix defines a strategy rule, including a condition part and an action part. The condition part consists of three fields: sensitivity_level_range (e.g., [3, 5]), user_role (e.g., ["developer", "dba"]), and environment_tag (e.g., ["prod", "pre-prod"]. The action section specifies the strategy_code, such as "BLOCK", "WARN", or "AUDIT", and the associated security_function_template, such as "mask({column_name})". After receiving the sensitive field identification results, the policy matching engine first extracts the current user's role information from the IDE session context, obtains the environment tag of the database instance pointed to by the current SQL connection through the integrated enterprise LDAP / SSO system. This tag is preset by the administrator during connection configuration, such as "prod-db-01" being marked as "prod". Subsequently, the engine traverses all rule rows in the decision matrix, searching for the first rule that simultaneously satisfies the following conditions: the sensitivity level falls within the specified range, the user role is within the permission list, and the environment tag matches. Once a match is found, the policy code is locked. For example, when the sensitivity level is greater than or equal to 3 and the environment is a production instance, the matching policy is set to forced blocking mode. In this case, the generated risk warning has the highest severity level, preventing code saving or execution until the correction is completed. When the sensitivity level is 2 and the user role is a tester, the matching policy is set to mild check mode, only recording in the issue panel without interrupting the editing process. The policy matching output is a structured object containing the absolute character offset of each risk field, the policy code, the security function template string, and the risk severity level ERROR / WARNING / INFO.

[0076] Furthermore, the method also includes:

[0077] When the sensitivity level is greater than or equal to 3 and the environment is a production instance, the matching strategy is set to forced blocking mode to prevent code saving or execution.

[0078] When the sensitivity level is 2 and the user role is a tester, the matching strategy is set to mild inspection mode, which only records issues in the issue panel without interrupting the editing process.

[0079] In the aforementioned method for real-time identification and automatic correction of sensitive data operations in a data-driven IDE, step 5 involves calling the IDE's native marker injection module. Based on the strategy matching output, visual markers are applied to risky sensitive fields in the code editing interface. These markers include a warning icon next to the line number and a wavy line hint below the field, with hover information to display risk details and actionable correction suggestions. Specifically, the IDE's native marker injection module calls the IDE documentation annotation model interface to create temporary diagnostic markers, rendering red or yellow wavy line graphic elements in the editor view layer. Red indicates error-level risks requiring immediate handling, while yellow indicates warning-level risks that can be addressed later. A circular warning dot is added to the line number area, allowing users to click and jump to the first risk location. This module registers a custom LocalInspectionTool through the com.intellij.codeInsight.daemon.DaemonCodeAnalyzer service, making it part of the IDE's built-in code inspection system. After the strategy matching output is generated, the module creates a ProblemDescriptor object for each risk field, specifying its text range start and end character offsets, problem description message, severity level, and a QuickFix implementation class. The IDE framework automatically converts this description into visual elements: a wavy line of the corresponding color is drawn below the code, and a circular icon of the corresponding color is rendered in the line number sidebar. When the user hovers the mouse over the mark, the IDE pops up an information box, the content of which is filled by the message field of the ProblemDescriptor. The hover information box bound to the mark includes the original field name, the sensitivity level numeric identifier, the Chinese description name, the data category label, and the name of the recommended security handling function. The user can directly trigger the subsequent automated replacement process by clicking the Apply Correction button. This Apply Correction button is provided by the QuickFix implementation class, and its click event handler is pre-bound to the entry point of the syntax-aware code correction module.

[0080] Furthermore, the method also includes:

[0081] The IDE native tag injection module calls the IDE document annotation model interface to create temporary diagnostic tags, which render red or yellow wavy line graphic elements in the editor view layer. Red represents error-level risk, and yellow represents warning-level risk. Circular warning dots are added to the line number area, which can be clicked to jump to the first risk location.

[0082] In the aforementioned method for real-time identification and automatic correction of sensitive data operations based on a data-driven IDE, step 6, when the user triggers a one-click correction command, activates the syntax-aware code correction module, parses the security function template, replaces the original field reference, automatically encapsulates the plaintext sensitive field into a de-identified or encrypted function call, completes the compliant reconstruction of the SQL statement, and ensures that the new statement conforms to the IDE's syntax validation rules. Specifically, the syntax-aware code correction module performs context compatibility verification before performing the replacement, analyzes the positional characteristics of the expression containing the target field, and determines whether it is in an aggregate function, grouping condition, or join predicate. If a contextual conflict exists, automatic replacement is paused and manual intervention is prompted for evaluation. This module first obtains the PsiElement reference of the field to be corrected and its associated security function template from the QuickFix context. Then, it traverses the AST upwards to check the parent node type of the field node. If the parent node is a PsiFunctionCallExpression such as COUNT(u.name), PsiGroupByClause, or PsiJoinCondition, it is considered a high-risk context. This is because directly wrapping a masked function in such a location could lead to semantic errors, such as COUNT(mask(u.name)) altering the counting logic. In this case, the module does not perform automatic replacement but displays a notification in the editor status bar: "Field detected in aggregation / grouping context. Automatic correction may cause logical errors. Please adjust manually." If the context verification passes, the replacement phase begins. The secure function template is defined using a parameterized placeholder format, such as mask({column_name}) or replace({column_name}, ' ', 3) During the actual replacement, {column_name} is dynamically replaced with the actual reference path of the current field, preserving the original alias and table prefix structure, ensuring that the generated statement is syntactically correct and semantically unchanged. The replacement operation is performed through the IDE's PsiElement.replace() method, which takes a newly constructed PsiFunctionCallExpression node as input, whose function name is mask, and whose parameter is the original field's PsiReferenceExpression. This operation is entirely completed within the IDE's PSIProgram Structure Interface abstraction layer, ensuring the integrity and consistency of the syntax tree and avoiding syntax errors that may be introduced by direct string replacement.

[0083] Furthermore, the method also includes:

[0084] The hover information box contains the original field name, sensitivity level numeric identifier, Chinese description name, data category label, and recommended security processing function name. Users can trigger the automated replacement process directly by clicking the Apply Correction button.

[0085] In the aforementioned method for real-time identification and automatic correction of sensitive data operations in a data-driven IDE, step 7 involves writing the corrected SQL statement back to the editing buffer, clearing the original risk markers, updating the code status to compliant, and synchronizing the operation record to the backend audit log system, forming a complete behavior traceability chain. Specifically, the corrected SQL statement is written to the source code buffer via the IDE's standard document editing interface, triggering a new round of syntax parsing and marker cleanup. All old risk markers are actively destroyed, and a structured audit event is pushed to the backend log center, including a timestamp, user ID, original statement hash value, correction type, and final statement summary. Since the replacement operation in step 6 is completed through the PSI interface, the IDE kernel automatically converts it into a character sequence change in the underlying document and triggers the DocumentChanged event. This event will reactivate the security event listener module, but since there are no plaintext sensitive fields in the corrected statement, subsequent identification and marking processes will not generate new risk warnings. At the same time, the IDE's marker management system automatically cleans up all old ProblemDescriptors associated with the corrected text range, achieving immediate marker removal. Upon completion of the correction operation, the system immediately constructs an audit log event. The payload includes: a timestamp in ISO8601 format, the user's unique ID assigned by the enterprise unified identity authentication system, the SHA-256 hash of the original SQL statement for deduplication and tracing, the correction type (e.g., AUTO_MASK), a 200-character digest of the corrected statement, and a list of sensitive fields involved. This event is sent to the designated API endpoint of the enterprise SIEM security information and event management system via an asynchronous, non-blocking HTTP POST request, ensuring no impact on the IDE's main thread performance. This audit chain provides the security team with complete operational evidence, which can be used for compliance reviews, behavioral analysis, and accountability.

[0086] Furthermore, the method also includes:

[0087] Before performing the replacement, the syntax-aware code correction module performs context compatibility verification, analyzes the positional characteristics of the expression containing the target field, and determines whether it is in an aggregate function, grouping condition, or concatenation predicate. If there is a contextual conflict, the automatic replacement is paused and a manual intervention evaluation is prompted.

[0088] The security function template is defined using a parameterized placeholder format. During actual replacement, {column_name} is dynamically replaced with the actual reference path of the current field, while preserving the original alias and table prefix structure.

[0089] Furthermore, the method also includes:

[0090] All functional modules are encapsulated as plug-in components that can run in mainstream data development IDEs. The plug-ins are developed in Java and packaged into JAR format files. After installation, they are automatically injected into the IDE's core class loading path and are initialized and registered during the IDE process startup phase.

[0091] The policy center management backend supports administrators in configuring sensitivity level classification standards, defining role-environment-policy mapping relationship tables, uploading custom regular expression recognition patterns, and distributing updates to all connected client plugins in real time.

[0092] A performance threshold monitoring mechanism is set up so that when syntax parsing and tag injection operations continuously occupy CPU time for more than a preset duration, the system automatically degrades to a low-frequency polling mode.

[0093] To support the stable operation of the aforementioned core methods, this invention also includes several key auxiliary technical features. All functional modules are encapsulated as plug-in components that can run in mainstream data development IDEs. These plug-ins are developed in Java and packaged as JAR files. After installation, they are automatically injected into the IDE's core class loading path and initialized during the IDE process startup phase, allowing them to run independently without external dependencies. The plug-in conforms to the IntelliJ Platform Plugin SDK specification, declaring necessary extension points and service dependencies to ensure seamless deployment in compatible IDEs such as DataGrip and IntelliJ IDEA Ultimate. Furthermore, a policy center management backend is established, supporting administrators in configuring sensitivity level classification standards, defining role-environment-policy mapping tables, and uploading custom regular expression recognition patterns through a graphical interface. It can also distribute updates to all connected client plug-ins in real time, achieving consistent policy control across the entire organization. The policy center adopts a microservice architecture, providing a RESTful API for client queries and subscriptions. Its web console is built on React, supporting visual drag-and-drop editing of policy rules and version history rollback. To ensure a smooth development experience, a performance threshold monitoring mechanism is also set up in the IDE resource usage monitoring module. When syntax parsing and tag injection operations continuously consume more than 50 milliseconds of CPU time, it automatically degrades to a low-frequency polling mode to avoid editor lag caused by complex SQL statements. This monitoring module periodically samples the main thread's CPU time through the java.lang.management.ThreadMXBean interface. Once it detects that the increment within three consecutive sampling intervals exceeds the threshold, it triggers a degradation switch, switching the event listener's processing mode from real-time event-driven to a timed scan every 500 milliseconds. It automatically switches back to high-performance mode after the system load returns to normal.

[0094] A data development engineer writes a SQL statement in a data development IDE. As follows:

[0095] Data development engineer Zhang San needs to retrieve the names and phone numbers of people aged 20-30 from the user table for data analysis; however, obtaining user consent is required to retrieve user names and phone numbers for data analysis.

[0096] He needs to write the following SQL code in the data development editor IDE, for example: Figure 2 As shown;

[0097] After the data development engineer finishes writing the SQL code, the security event listener of the data development IDE will automatically retrieve the SQL code and execute the IDE's syntax context awareness module to parse the SQL into independent lexical units, as follows:

[0098] Input: The SQL code written by the data development engineer in the previous step. `SELECT user_name,phone_number FROM users where age>20 and age<30` Output after parsing by the syntax parser:

[0099] SELECT (keyword), user_name (identifier), (delimiter), phone_number (identifier), FROM (keyword), users (identifier), where (keyword), age (identifier), > (identifier), 20 (number), and (keyword), age (identifier), < (identifier), 30 (number);

[0100] Data object extraction is used to extract key identifier information from the lexical units parsed by the parser. This information is then organized into a structured list of data objects. The IDE's syntax context awareness module is then executed to organize the syntax into structured data objects. These objects serve as input for the next step of identifying sensitive data. The input and output for this step are as follows:

[0101] enter:

[0102] SELECT (keyword), user_name (identifier), (delimiter), phone_number (identifier), FROM (keyword), users (identifier), where (keyword), age (identifier), > (identifier), 20 (number), and (keyword), age (identifier), < (identifier), 30 (number);

[0103] Output:

[0104] {

[0105] Action: "select"

[0106] "Operation Object Table": "users",

[0107] "Operation Object Information": ["user_name", "phone_number", "age"]

[0108] };

[0109] The sensitive data tag query module, which is responsible for analyzing sensitive data streams, performs a process to identify and tag sensitive data within the data objects. This process involves matching the data object information output in the previous step against a sensitive data knowledge base, matching the content of records in the knowledge base, and finally, identifying and tagging sensitive data within the data objects. An example implementation is shown below:

[0110] Sensitive data tag query

[0111] Based on the data object information output in the previous step, call the sensitive data knowledge base query interface to obtain the sensitivity level of the data object:

[0112] enter:

[0113] {

[0114] Action: "select"

[0115] "Operation Object Table": "users",

[0116] "Operation Object Information": ["user_name", "phone_number", "age"]

[0117] Call the sensitive data knowledge base query API interface;

[0118] Output:

[0119] {

[0120] "Action":"select",

[0121] "Recognition Result": [

[0122] {

[0123] "Operation Object Table": "users",

[0124] "Operation field": "user_name",

[0125] "Sensitive?": true,

[0126] Sensitivity level: 2,

[0127] "Field Chinese Name": "PII-Name"

[0128] },

[0129] {

[0130] "Operation Object Table": "users",

[0131] "Operation field": "phone_number",

[0132] "Sensitive?": true,

[0133] Sensitivity Level: 4

[0134] Field Name (in Chinese): "PII-Mobile Number"

[0135] },

[0136] {

[0137] "Operation Object Table": "users",

[0138] "Operation field": "age",

[0139] "Sensitive?": false,

[0140] Sensitivity level: 0,

[0141] Field Description (in Chinese): "PII-Age"

[0142] }, ]

[0144] };

[0145] The sensitive data knowledge base records the sensitivity level of all data objects, including the field name, its English name, whether it is sensitive, and its sensitivity level. (Example follows) Figure 3 As shown;

[0146] In the strategy matching process, we adopt a relatively intelligent matching strategy that can be aware of context information. First, we establish the matching relationship between strategy types and adaptive matching, as shown in Table 1;

[0147] Table 1 Matching Relationship between Strategy Type and Adaptation

[0148]

[0149] Secondly, based on the matching relationship between the strategy type and the adaptive approach, the strategy handling method for this operation is given in the sensitive data flow analysis module, including the handling strategy content and strategy code, providing input for subsequent one-click repair operations.

[0150] enter:

[0151] {

[0152] "Action":"select",

[0153] "Recognition Result": [

[0154] {

[0155] "Operation Object Table": "users",

[0156] "Operation Role": "Developer",

[0157] "Operation field": "user_name",

[0158] "Sensitive?": true,

[0159] Sensitivity level: 2,

[0160] "Field Chinese Name": "PII-Name"

[0161] },

[0162] {

[0163] "Operation Object Table": "users",

[0164] "Operation Role": "Developer",

[0165] "Operation field": "phone_number",

[0166] "Sensitive?": true,

[0167] Sensitivity Level: 4

[0168] Field Name (in Chinese): "PII-Mobile Number"

[0169] },

[0170] {

[0171] "Operation Object Table": "users",

[0172] "Operation Role": "Developer",

[0173] "Operation field": "age",

[0174] "Sensitive?": false,

[0175] Sensitivity level: 0,

[0176] Field Description (in Chinese): "PII-Age"

[0177] }, ]

[0179] }

[0180] Output:

[0181] {

[0182] "Strategy matching result": "Highly sensitive fields were queried directly".

[0183] "risk_location": {

[0184] "Number of rows": 1,

[0185] "Sensitive field": user_name,

[0186] "Sensitive field location": 7-14,

[0187] "Sensitive field": phone_number,

[0188] "Sensitive field location": 15-27,

[0189] },

[0190] "Processing Requirement_user_name": "Decryption",

[0191] "Processing Request_user_ID": "10003",

[0192] "Processing function": "replace({column_name})",

[0193] "Processing Requirement_phone_number": "Encryption",

[0194] "Processing function": "mask({column_name})",

[0195] };

[0196] Using risk warnings and suggested corrective actions, the IDE's native tag injection module is executed, returning the results of the previous strategy matching step to the IDE interface. This is then visually displayed to data developers, alerting them to potential data security risks in their SQL code. An example is shown below:

[0197] enter:

[0198] {

[0199] "Strategy matching result": "Highly sensitive fields were queried directly".

[0200] "risk_location": {

[0201] "Number of rows": 1,

[0202] "Sensitive field": user_name,

[0203] "Sensitive field location": 7-14,

[0204] "Sensitive field": phone_number,

[0205] "Sensitive field location": 15-27,

[0206] },

[0207] "Processing Requirement_user_name": "Decryption",

[0208] "Processing function": "replace({column_name})",

[0209] "Processing Requirement_phone_number": "Encryption",

[0210] Processing function: "mask({column_name})"

[0211] };

[0212] Output: By calling the front-end interface of the data development IDE, a visual tooltip is created in the SQL writing interface. A dashed warning line is added below sensitive fields, and the row number of the sensitive data is marked with a red dot to the left of the sensitive field. When developers hover their mouse over the dashed line of the sensitive field, a warning message about the sensitive information is displayed, along with suggestions for clicking to correct it, such as... Figure 4 As shown;

[0213] The one-click correction feature allows data developers to automatically replace sensitive data fields with SQL statements containing secure handling functions by clicking the "Click to Correct" option. When a data developer clicks "Click to Correct," the data development IDE automatically executes the syntax-aware code correction module, replacing the text in the SQL statement according to the input field information and correcting the secure functions. An example is shown below:

[0214] enter:

[0215] {

[0216] "Strategy matching result": "Highly sensitive fields were queried directly".

[0217] "risk_location": {

[0218] "Number of rows": 1,

[0219] "Sensitive field": user_name,

[0220] "Sensitive field location": 7-14,

[0221] "Sensitive field": phone_number,

[0222] "Sensitive field location": 15-27,

[0223] },

[0224] "Processing Requirement_user_name": "Decryption",

[0225] "Processing function": "replace({user_name})",

[0226] "Processing Requirement_phone_number": "Encryption",

[0227] Processing function: "mask({column_name})"

[0228] };

[0229] Output:

[0230] {

[0231] "Processing function": "replace({column_name})",

[0232] Processing function: "mask({phone_number})"

[0233] }

[0234] Interface effect as follows Figure 5 As shown;

[0235] After the replacement was completed, the SQL code developed by the data development engineer was processed in full accordance with the data security handling strategy, and the next step of execution was carried out, thus ending the data development task.

[0236] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces, or indirect coupling or communication connection between apparatuses or units, and may be electrical, mechanical, or other forms.

[0237] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated units described above can be implemented in hardware or as software functional units. The above are merely embodiments of this application and do not limit the patent scope of this application. Any equivalent structural or procedural transformations made based on the description and drawings of this application, or direct or indirect applications in other related technical fields, are similarly included within the patent protection scope of this application.

[0238] The specific embodiments of the invention have been described in detail above, but they are only examples, and this application is not limited to the specific embodiments described above. For those skilled in the art, any equivalent modifications or substitutions to the invention are also within the scope of this application. Therefore, all equivalent changes, modifications, and improvements made without departing from the spirit and principles of this application should be covered within the scope of this application.

Claims

1. A method for real-time identification and automatic correction of sensitive data operations based on a data development IDE, characterized in that... This includes the following steps: Step 1: When the data development integrated development environment starts, register the security event listener module with the IDE's internal syntax event bus through the plugin registration interface to continuously subscribe to and capture the syntax change events generated by the SQL statements entered or modified by the developer in the editor; Step 2: In response to the syntax change event, the IDE syntax context awareness module is invoked to obtain the complete abstract syntax tree and symbol resolution table from within the IDE, and the captured SQL statement is subjected to lexical and syntactic analysis to extract a structured list of data fields; The IDE syntax context awareness module uses the IDE's internal API to access the abstract syntax tree node stream, parses the operation structure of DML statements including SELECT, INSERT, UPDATE, and DELETE according to preset traversal rules, restores the field alias mapping relationship, realizes the symbol expansion from u.name to users.user_name, and outputs a standardized set of operation object information. Step 3: Use the structured data field list as the query input, call the sensitive data flow analysis module, and match and compare it with the symbol type information maintained internally by the IDE and the enterprise-level sensitive data knowledge base to identify whether each field belongs to the category of sensitive data, and mark the corresponding sensitivity level and Chinese semantic name; Step 4: Execute the strategy matching logic based on the identification results. Take into account the current user's development role, runtime environment attributes, and the sensitivity level of the fields to determine the type of handling strategy to be triggered and generate strategy matching output. Step 5: Call the IDE's native tag injection module, match the output according to the strategy, apply visual tags to sensitive fields with risks in the code editing interface, and bind hover information to display risk details and executable correction suggestions; Step 6: When the user triggers the one-click correction command, the syntax-aware code correction module is activated, the security function template is parsed and the original field reference is replaced, and the plaintext sensitive fields are automatically encapsulated into the de-identified or encrypted function call, completing the compliance reconstruction of the SQL statement and ensuring that the new statement conforms to the IDE syntax validation rules. Step 7: Write the corrected SQL statement back to the editing buffer, clear the original risk markers, update the code status to compliant, and synchronize the operation record to the backend audit log system to obtain the behavior traceability chain; In step 4, based on the identification results, the strategy matching logic is executed. Taking into account the current user's development role, runtime environment attributes, and the sensitivity level of the fields, the table is consulted to determine the type of handling strategy to be triggered, and a strategy matching output containing the risk location, handling requirements, and corresponding security function template is generated. The strategy matching output is based on a predefined multidimensional decision matrix for adaptive judgment. The dimensions of the multidimensional decision matrix include the sensitivity level value range, the current logged-in user role category, and the environment identifier of the current connected database instance. The rule engine calculates a unique matching handling strategy code to achieve differentiated response control. The multidimensional decision matrix is ​​stored in the strategy center management backend in JSON format and synchronized to the client plugin in real time via a WebSocket long connection. Each row of the matrix defines a strategy rule, including a condition part and an action part. After receiving the sensitive field identification results, the strategy matching engine extracts the current user's role information from the IDE session context. By integrating the enterprise's information and the environment label of the database instance pointed to by the current SQL connection, which is preset by the administrator during connection configuration, the engine traverses all rule rows of the decision matrix to find the first rule that simultaneously satisfies the following conditions: the sensitivity level falls within the specified range, the user role is within the permission list, and the environment label matches. Once a match is found, the policy code is locked. The policy matching output is a structured object containing the absolute character offset of each risk field, the policy code, the security function template string, and the risk severity level.

2. The method for real-time identification and automatic correction of sensitive data operations based on a data development IDE according to claim 1, characterized in that, Also includes: The security event listener module is implemented in Java through the UDF extension mechanism provided by the IDE. During the registration process, it requests listening permissions for the core syntax events ASTChangeEvent and SymbolResolutionCompleteEvent in order to obtain the complete semantic analysis intermediate representation generated by the compiler front end. The list of data fields includes the operation action and the target data table; The strategy matching output includes the risk location, processing requirements, and corresponding security function template; The visual markers include a warning icon next to the line number and a wavy line prompt below the field.

3. The method for real-time identification and automatic correction of sensitive data operations based on a data development IDE according to claim 2, characterized in that, Also includes: When the sensitivity level is greater than or equal to 3 and the environment is a production instance, the matching strategy is set to forced blocking mode to prevent code saving or execution. When the sensitivity level is 2 and the user role is a tester, the matching strategy is set to mild inspection mode, which only records issues in the issue panel without interrupting the editing process.

4. The method for real-time identification and automatic correction of sensitive data operations based on a data development IDE according to claim 1, characterized in that, Also includes: The IDE native tag injection module calls the IDE document annotation model interface to create temporary diagnostic tags, which render red or yellow wavy line graphic elements in the editor view layer. Red represents error-level risk, and yellow represents warning-level risk. Circular warning dots are added to the line number area, which can be clicked to jump to the first risk location.

5. The method for real-time identification and automatic correction of sensitive data operations based on a data development IDE according to claim 1, characterized in that, Also includes: The hover information box contains the original field name, sensitivity level numeric identifier, Chinese description name, data category label, and recommended security processing function name. Users can trigger the automated replacement process directly by clicking the Apply Correction button.

6. The method for real-time identification and automatic correction of sensitive data operations based on a data development IDE according to claim 1, characterized in that, Also includes: Before performing the replacement, the syntax-aware code correction module performs context compatibility verification, analyzes the positional characteristics of the expression containing the target field, and determines whether it is in an aggregate function, grouping condition, or concatenation predicate. If there is a contextual conflict, the automatic replacement is paused and a manual intervention evaluation is prompted. The security function template is defined using a parameterized placeholder format. During actual replacement, {column_name} is dynamically replaced with the actual reference path of the current field, while preserving the original alias and table prefix structure.

7. The method for real-time identification and automatic correction of sensitive data operations based on a data development IDE according to claim 1, characterized in that, Also includes: All functional modules are encapsulated as plug-in components that can run in mainstream data development IDEs. The plug-ins are developed in Java and packaged into JAR format files. After installation, they are automatically injected into the IDE's core class loading path and are initialized and registered during the IDE process startup phase. The policy center management backend supports administrators in configuring sensitivity level classification standards, defining role-environment-policy mapping relationship tables, uploading custom regular expression recognition patterns, and distributing updates to all connected client plugins in real time. A performance threshold monitoring mechanism is set up so that when syntax parsing and tag injection operations continuously occupy CPU time for more than a preset duration, the system automatically degrades to a low-frequency polling mode.

Images