Sensitive log identification method and device, equipment and storage medium

Abstract

The invention discloses a sensitive log identification method and device, equipment and a storage medium, and the method comprises the steps: traversing a source code file, and obtaining log information in the source code file; performing keyword matching and semantic analysis on the log information, and identifying sensitive information in the log information; and extracting position information of the sensitive information in the source code file, associating the sensitive information with the corresponding position information, and outputting structured data. According to the method, log information analysis is directly carried out on the source code level, so that the timeliness and accuracy of sensitive information identification are effectively improved.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of information security, and in particular to a sensitive log identification method and device, equipment and a storage medium. BACKGROUND

[0002] In the process of software development and operation, log information generated by the system is crucial for debugging programs and monitoring running status. However, sensitive information such as user name, ID number, contact information, and email address may be contained in the log, which may cause data security and compliance problems if directly output. Therefore, sensitive information identification and management of log content has become an important part of information security system construction.

[0003] In the prior art, a scheme for detecting sensitive information based on runtime logs is proposed, that is, after the application program is deployed to the production environment and the actual log is output, the log text is scanned and identified by rule matching or machine learning model. Although this method can act on the actual output content, its detection behavior lags behind the code deployment stage, and the problem needs to be repaired through version iteration after it is found, which has a long cycle and cannot realize risk pre-control in the development stage. A detection method based on static code analysis is also proposed, which can identify some hard-coded sensitive information or specific interface calls in the coding stage, but the existing method usually lacks deep parsing ability for the context of parameters in log printing statements, and it is difficult to cover complex object structures, generic collections, class inheritance, and third-party dependencies, resulting in inaccurate semantic judgment of log output content, high missed detection rate, and difficulty in effectively supporting comprehensive log security management. SUMMARY

[0004] The main purpose of the present application is to provide a sensitive log identification method, device, equipment and storage medium, which aims to solve the technical problems of lag and high missed detection rate of existing sensitive log detection methods.

[0005] To achieve the above purpose, the present application provides a sensitive log identification method, which comprises the following steps:

[0006] Traverse the source code file to obtain log information in the source code file;

[0007] Perform keyword matching and semantic analysis on the log information to identify sensitive information in the log information;

[0008] Extract the location information of the sensitive information in the source code file, associate the sensitive information with the corresponding location information, and output as structured data.

[0009] In an embodiment, the step of traversing the source code file to obtain the log information in the source code file comprises:

[0010] traversing the source code file to identify log statements in the source code file;

[0011] traversing log parameters of the log statements and parsing parameter context information of the log parameters.

[0012] In an embodiment, the log information includes log statements and corresponding parameter context information, and the step of performing keyword matching and semantic analysis on the log information to identify sensitive information in the log information includes:

[0013] analyzing, by using a rule engine, whether the log statements and corresponding parameter context information hit sensitive information, and marking a hit result, to obtain a first analysis result;

[0014] performing model semantic analysis on first log information that does not hit the sensitive information to obtain a second analysis result;

[0015] determining sensitive information in the log information based on the first analysis result and the second analysis result.

[0016] In an embodiment, the step of analyzing, by using a rule engine, whether the log statements and corresponding parameter context information hit sensitive information and marking a hit result, to obtain a first analysis result includes:

[0017] traversing each log statement to analyze whether static text, parameter name, method name, and entity class field information of the log statement hit a preset sensitive word library, and generating a hit result;

[0018] summarizing and deduplicating the hit result to generate the first analysis result.

[0019] In an embodiment, the step of performing model semantic analysis on first log information that does not hit the sensitive information to obtain a second analysis result includes:

[0020] extracting log information marked as not hitting from the first analysis result as first log information;

[0021] filling log statements and corresponding parameter context information of the first log information into a preset template to generate a to-be-identified code prompt word;

[0022] combining a preset system prompt word and a user prompt word to form a large language model input request body, wherein the user prompt word includes a preset task definition prompt word, an analysis step prompt word, a sensitive information prompt word, an output rule prompt word, and the to-be-identified code prompt word.

[0023] In an embodiment, the step of performing model semantic analysis on the first log information that does not hit the sensitive information to obtain a second analysis result comprises:

[0024] submitting the request body to the large language model, and the large language model establishes an analysis role and a task based on the system prompt word and the task definition prompt word;

[0025] receiving a response returned by the large language model, wherein the response is that the large language model analyzes the to-be-recognized code prompt word according to the analysis step prompt word and the sensitive information prompt word, and generates the second analysis result according to the output rule prompt word.

[0026] In an embodiment, the step of the large language model analyzing the to-be-recognized code prompt word according to the analysis step prompt word and the sensitive information prompt word, and generating the second analysis result according to the output rule prompt word comprises:

[0027] analyzing the function and semantics of a log statement in the first log information to determine whether it is possible to output sensitive information;

[0028] If it is determined that sensitive information may be output, the static text and dynamic parameter object name in the log statement are matched with the sensitive information prompt word;

[0029] If the matching is unsuccessful, code semantic analysis is performed on the first log information, and based on the analysis result, log parameters in the first log information that do not output sensitive values are filtered;

[0030] analyzing whether the variable name, annotation value, and annotation content of the entity class field corresponding to the remaining log parameters in the first log information contain the sensitive information prompt word, and generating the second analysis result according to the output rule prompt word.

[0031] In addition, to achieve the above-mentioned purpose, the present application also provides a sensitive log identification device, the sensitive log identification device comprises:

[0032] a log acquisition module configured to traverse a source code file and acquire log information in the source code file;

[0033] a sensitive identification module configured to perform keyword matching and semantic analysis on the log information, and identify sensitive information in the log information;

[0034] an output module configured to extract position information of the sensitive information in the source code file, associate the sensitive information with the corresponding position information, and output as structured data.

[0035] In addition, to achieve the above object, the application further provides a terminal device, comprising a memory, a processor, and a sensitive log identification program stored in the memory and executable on the processor, wherein the sensitive log identification program, when executed by the processor, implements the steps of the sensitive log identification method.

[0036] In addition, to achieve the above object, the application further provides a computer readable storage medium, wherein the computer readable storage medium stores a sensitive log identification program, and the sensitive log identification program, when executed by a processor, implements the steps of the sensitive log identification method.

[0037] The one or more technical solutions provided by the application have at least the following technical effects:

[0038] The application traverses the source code file to obtain log information, realizes early identification of potential sensitive information leakage risk in the code writing stage, overcomes the detection lag problem caused by the traditional scheme relying on runtime log output, and further adopts the combination of keyword matching and semantic analysis to cooperatively analyze the log information, adopts keyword matching to have efficient matching effect of the conventional sensitive mode, adopts the semantic analysis mode to cover the scene that is difficult to process through fixed rules, such as unconventional naming and complex object structure, and the double analysis mechanism expands the breadth and depth of the detection range, thereby effectively reducing the overall missed detection rate. In addition, the sensitive information identified is associated with the accurate position thereof in the source code and output as structured data, and the analysis result is directly converted into executable repair instructions, thereby improving the efficiency of the developer in locating and repairing problems. BRIEF DESCRIPTION OF DRAWINGS

[0039] Figure 1 The figure is a flowchart of the first embodiment of the sensitive log identification method of the application;

[0040] Figure 2 The figure is a flowchart of the second embodiment of the sensitive log identification method of the application;

[0041] Figure 3 The figure is a flowchart of the third embodiment of the sensitive log identification method of the application;

[0042] Figure 4 The figure is a flowchart of the fourth embodiment of the sensitive log identification method of the application;

[0043] Figure 5 The figure is a flowchart of the fifth embodiment of the sensitive log identification method of the application;

[0044] Figure 6 The figure is a flowchart of the sixth embodiment of the sensitive log identification method of the application;

[0045] Figure 7 A module structure diagram of a sensitive log identification device in an embodiment of the present application is shown in FIG. 1.

[0046] Figure 8 A device structure diagram of a hardware running environment involved in a sensitive log identification method in an embodiment of the present application is shown in FIG. 2.

[0047] The implementation, functional features and advantages of the present application will be further described with reference to the embodiments and the accompanying drawings. DETAILED DESCRIPTION

[0048] It should be understood that the specific embodiments described herein are merely intended to explain the present application and not to limit the present application.

[0049] The main technical solution of the present application is as follows: traversing a source code file to obtain log information in the source code file; performing keyword matching and semantic analysis on the log information to identify sensitive information in the log information; extracting position information of the sensitive information in the source code file, associating the sensitive information with the corresponding position information, and outputting the sensitive information as structured data.

[0050] The present application actually considers that log information generated in the code execution process plays an important role in debugging and monitoring the running state of the program. With the acceleration of enterprise digital transformation, the leakage risk of sensitive information such as user name, email, ID number, phone number, etc. in code logs is increasingly prominent. Improper output of sensitive logs in the code may lead to data leakage, compliance risk and other problems. Therefore, it is very important to detect whether the log contains sensitive information and then perform code log output governance to avoid information leakage.

[0051] In the prior art, some schemes detect sensitive information based on runtime logs. For example, a rule-based log sensitive information desensitization and highlighting method matches and detects the original log through defined sensitive rules to realize log desensitization and highlighting functions. A scheme based on a convolutional neural network model is used to identify the sensitive data starting position and sensitive information category in real-time log data of a transaction system. The above schemes need to be performed after the code is released to the production environment and the log is output, which leads to a long repair cycle and a lag in repair. Further, a software source code privacy detection method based on static detection is proposed to realize analysis of the privacy processing logic of the hard-coded privacy information, the interface for obtaining user privacy information, and the user input interface in the source code. Although this scheme can realize static code identification and privacy leakage problem discovery, it does not cover the privacy analysis of code log printing.

[0052] Based on this, the present application proposes a sensitive log identification method, device, equipment and storage medium.

[0053] Specifically, the following are the detailed steps of the first embodiment of the sensitive log identification method of the present application:

[0054] Referring to Figure 1 , Figure 1 The flowchart of the first embodiment of the sensitive log identification method of the present application. In this embodiment, the sensitive log identification method comprises steps S1001-S1003:

[0055] Step S1001, traversing the source code file to obtain the log information in the source code file;

[0056] Step S1002, keyword matching and semantic analysis are performed on the log information to identify sensitive information in the log information;

[0057] Step S1003, extracting the location information of the sensitive information in the source code file, associating the sensitive information with the corresponding location information, and outputting as structured data.

[0058] It should be noted that the log information is not the actual log text printed by the program at runtime, but the code elements and their context related to log printing behavior extracted from the source code through static analysis technology. This specifically includes log printing statements themselves and parameter context information obtained by parsing abstract syntax trees.

[0059] First, the source code is scanned and parsed to build an internal dataset containing all potential log output points and their rich context. Then, two-stage analysis is performed on the dataset: first, a rule engine is used for high-speed keyword matching based on a sensitive word library to quickly identify sensitive information that conforms to conventional naming patterns; then, a large language model is used to perform deep semantic understanding on complex cases that are not matched by the rules to identify unconventional naming or implicit sensitive data. Finally, the sensitive information is accurately bound with the specific code location parsed in step S1001, and output as machine-readable structured data (such as JSON or Excel format), thereby converting the analysis results into work orders that can directly guide repair actions.

[0060] Exemplarily, a piece of code is analyzed as: log.info("Process completed,user:{}", currentUser.getDTO()). First, the log statement is parsed, and it is further parsed that the UserDTO class returned by the currentUser.getDTO() method contains a String idCard field. Then, keyword matching is performed by using the rule engine, and no "ID card" keyword is hit in the parsed log template and parameter name; but in semantic analysis, the large language model identifies the idCard field in the UserDTO class, and determines that the log may output the sensitive information of the ID card number. Finally, a record is generated, which clearly indicates that in a certain source code file at a specific line, the log statement has the risk of "ID card hit".

[0061] In the embodiment of the present application, all analysis processes are completed based on the source code in the coding stage, without waiting for the program to run to generate logs, thereby fundamentally solving the lag problem of traditional runtime detection and making security left shift a reality. Secondly, the rule engine ensures efficient processing of regular patterns, while the semantic analysis capability of the large language model effectively covers complex context and irregular naming scenarios, and this combination mechanism greatly reduces the missed detection rate. Finally, since the output structured data is directly associated with the code line, developers can quickly locate and fix the problem, greatly improving the governance efficiency.

[0062] Further, with reference to Figure 2 , Figure 2 is a flowchart of a second embodiment of the sensitive log recognition method of the present application. In this embodiment, the step S1001 includes steps S2001-S2002:

[0063] Step S2001, traversing the source code file to identify the log statement in the source code file;

[0064] Step S2002, traversing the log parameters of the log statement and parsing the parameter context information of the log parameters.

[0065] Specifically, by recursively traversing the Java source files in the project, and using the parsing library javaparser-symbol-solver-core to build each file into an Abstract Syntax Tree (AST), all log statements are located and extracted by identifying the method name of the method call expression in the AST. For each log statement, further traverse each log parameter it contains. Referring to Table 1, Table 1 shows the following log parameter types: StringLiteralExpr, NameExpr, MethodCallExpr, and BinaryExpr. Different parsing strategies are implemented for different types of parameter expressions.

[0066] For StringLiteralExpr, the string literal does not need to be further parsed, and is directly saved for subsequent sensitive information identification.

[0067] For NameExpr, the object name of the name expression is stored, and the declaration statement of the object. For the class definition of the object, it is processed in multiple cases: if it is a JDK / third-party package object, the class definition usually does not contain business information, and no parsing is performed. If it is a one-party package object, the class definition of the object is parsed through the AST tree. If it is a two-party package object, it cannot be directly obtained through the AST data, and the class definition source code is obtained through CFR package decompilation. If it is a generic object, first determine whether the specific type is a one-party package or a two-party package type, and if so, process it according to the one-party package or two-party package type. In the parsing process, determine whether the class has a parent class, and if so, further parse the definition of the parent class.

[0068] For MethodCallExpr, since it is a method call, the method call contains a name expression, a method name, and method parameters. The method name is directly saved for subsequent use, and the name expression is recursively parsed using NameExpr. The method parameters may be one of the four log parameters in Table 1, and are also recursively parsed.

[0069] For BinaryExpr, the plus sign connected multiple expressions may be one of the four log parameters in Table 1, and are also recursively parsed.

[0070]

[0071] Table 1

[0072] Further, an object list is used to store the parsing results of the above log parameters. Each object in the object list corresponds to a log statement and its parameter context information. The class attribute information of the object includes: package path, class name, line number, log print statement source code, and log parameter context information object list.

[0073] The class attribute information of the log parameter context information object includes the following contents: a string constant value in the log parameter, a log parameter object name, entity class definitions in different cases of the log parameter (a class in a one-party package, a class in a two-party package, a parent class in a class inheritance case, and a business-related entity class defined in a List and Map generic), a declaration of the log parameter object, and a method name when the log parameter is a method call.

[0074] It should be noted that the technical problem that the sensitivity accuracy is insufficient when the log parameter object is a non-Java basic data type can be solved by traversing the log parameters of the log statement and analyzing the parameter context information of the log parameters according to the embodiments of the present application. Specifically, when the log parameter is a complex object, the potential sensitive information of the object is hidden in the field definition of the internal structure of the object, rather than directly reflected on the surface code of the log statement. For example, for the log statement log.info("User info:{}", user), it cannot be determined from the statement itself whether the user object will output the identity card number, mobile phone number, or other sensitive fields. The present solution exposes the structured information in the object to the subsequent analysis engine by deeply analyzing the type definition, class inheritance relationship, generic information, and all fields (including field name, annotation value, and annotation content) of the user parameter. This enables the system to identify potential risks based on the field name, serialization annotation, or field annotation (such as / / identity card number), thereby achieving accurate sensitive information judgment in the complex object serialization output scenario, overcoming the limitations of surface matching based on log templates and variable names, and improving the depth and accuracy of the analysis.

[0075] According to the embodiments of the present application, the complete data type definition associated with the log parameter is restored at the code level through static analysis (including field name, annotation, and annotation). This enables the system to accurately identify potential risks even if a sensitive field is deliberately avoided in the log template or variable name, and to discover the real semantic association by analyzing the metadata of the class to which the field belongs, thereby effectively reducing the missed detection caused by complex code structure or irregular naming.

[0076] Further, referring to Figure 3 , Figure 3 is a flowchart of the third embodiment of the sensitive log identification method of the present application. In this embodiment, the log information includes log statements and corresponding parameter context information, and the step S1002 includes steps S3001-S3003.

[0077] In step S3001, a rule engine is used to analyze whether the log statement and the corresponding parameter context information hit sensitive information, and the hit result is marked to obtain a first analysis result.

[0078] Step S3002, model semantic analysis is performed on the first log information that does not hit the sensitive information, to obtain a second analysis result.

[0079] Step S3003, based on the first analysis result and the second analysis result, the sensitive information in the log information is determined.

[0080] First, based on a predefined sensitive word library, the static text, parameter name, method name, and entity class field information associated with the parameter of the log statement are quickly matched and scanned by using a rule engine, and the log information matched with the sensitive keywords in the sensitive word library is marked as a hit, and the log information that is not matched is marked as a miss, to obtain a first analysis result. Subsequently, the remaining log information that is marked as a miss, i.e., the first log information, is subjected to deep processing by a large language model. The large language model performs context-aware semantic understanding on the functional semantics of the log statement and the deep structure of the parameter object according to a preset prompt word template that includes task definition, analysis steps, sensitive information categories, and output format, so as to identify sensitive information output risks that cannot be covered by the rule, such as irregular naming or complex logic, and generate a second analysis result. Finally, the quick matching result of the rule engine and the deep semantic analysis result of the large language model are summarized and fused, so as to comprehensively determine a final sensitive information set that needs to be alarmed.

[0081] In the embodiments of the present application, the rule engine serves as a first high-speed filter and handles most cases with obvious patterns, thereby reducing the number of calls to the large language model that consumes more computing resources and guaranteeing the overall performance and scalability of the solution. The large language model as a second intelligent filter, on the other hand, takes advantage of its strong semantic understanding and logical reasoning capabilities to make up for the lack of flexibility of the rule engine based on a fixed word library, and can effectively deal with complex business logic in the code, irregular variable naming, and sensitive fields hidden through object nesting, thereby significantly improving the recognition accuracy and coverage in complex scenarios.

[0082] Further, with reference to Figure 4 , Figure 4 is a flowchart of a fourth embodiment of the sensitive log identification method of the present application. In this embodiment, the step S3001 includes steps S4001-S4002:

[0083] Step S4001, each log statement is traversed, and whether the static text, parameter name, method name, and entity class field information of the log statement hit a preset sensitive word library is analyzed, and a hit result is generated;

[0084] Step S4002, the hit result is summarized and deduplicated to generate the first analysis result.

[0085] Specifically, each log statement parsed from the source code is traversed, and the information in multiple dimensions thereof is checked one by one: static text in the log statement is analyzed to check whether it contains keywords defined in the sensitive word library; at the same time, variable names in log parameters, method names in method call expressions, and entity class field definitions obtained through parameter context information are extracted, the entity class field definitions including field names, serialization annotation values, and field annotation contents, and the above strings are uniformly converted to lowercase and matched with keywords in the sensitive word library that are also converted to lowercase. For example, for the static text "user name", the parameter name "userName", the method name "getEmail", and the field "cardNo" of the entity class User and its annotations, it is respectively determined whether they hit the corresponding "name", "email", "card number" and the like in the sensitive word library, and the hit results of each dimension are recorded in real time.

[0086] The repeated hit sensitive information types for the same log statement are merged and de-duplicated to generate a clear and non-redundant first analysis result.

[0087] In the embodiments of the present application, by scanning multiple key context dimensions such as log templates, parameter names, method names, and entity fields, the naming conventions and semantic associations formed in development practice are fully utilized to quickly and in parallel complete the coverage of common sensitive patterns. This efficient and accurate rule matching process lays a solid foundation for subsequent deep analysis of large language models and ensures that the entire recognition scheme can still maintain a low false positive rate and a low false negative rate when processing large amounts of code at high speed.

[0088] Further, with reference to Figure 5 , Figure 5 is a flowchart of the fifth embodiment of the sensitive log recognition method of the present application. In this embodiment, steps S3002 are preceded by steps S5001-S5003:

[0089] Step S5001: extracting log information marked as a miss from the first analysis result as first log information;

[0090] Step S5002: filling the log statement and the corresponding parameter context information of the first log information into a preset template to generate a to-be-recognized code prompt word;

[0091] Step S5003: combining a preset system prompt word and a user prompt word to form a large language model input request body, wherein the user prompt word includes a preset task definition prompt word, an analysis step prompt word, a sensitive information prompt word, an output rule prompt word, and the to-be-recognized code prompt word.

[0092] Specifically, the first analysis result is screened to extract all first log information marked as a miss sensitive information, and for each first log information, a structured information filling operation is performed: the specific log statement source code and parameter context information are filled in according to the pre-designed format template, thereby generating a content complete, format standard to be recognized code prompt word.

[0093] For example, the preset template is:

[0094] Please analyze the following log statement and its parameter definition:

[0095] The log printing statement is: {}

[0096] The definition of the parameter {} is: {}

[0097] The type of the parameter {} is: {} ...

[0099] The definition of the parameter {} is: {}

[0100] The type of the parameter {} is: {}

[0101] Further, the preset system prompt word and the user prompt word, the user prompt word includes: task definition prompt word, analysis step prompt word, sensitive information definition prompt word, output rule prompt word, to-be-recognized code prompt word.

[0102] Exemplarily, the system role prompt word is: you are a Java code security review expert; the task definition prompt word is defined as: strictly analyze the log printing statement in the code according to the following rules to avoid log leakage risk. The output rule prompt word is: the output format when hit is: `type + hit`, multiple sensitive information type hits are separated by a comma, such as: `card number hit, mobile phone number hit`, no hit, output no. Pay special attention: prohibit interpretation analysis process, only return result. The sensitive information definition prompt word is defined as: card number, ID card, mobile phone number, fixed phone number, email, name, address.

[0103] Further, the prompt word assembly is performed, the system prompt word defining the system role and behavior specification of the large language model is combined with the user prompt word including the specific analysis task, step, sensitive information definition, output format requirement and the aforementioned to-be-recognized code prompt word, to form a complete input request body conforming to the large language model interface calling specification.

[0104] The embodiment of the application combines the preset system prompt word and the user prompt word to form a large language model input request body, encapsulates the analysis task, background knowledge, to-be-analyzed data and output requirement clearly and unambiguously in the request body, which is equivalent to setting a strict analysis "pipeline" for the large language model. The output behavior of the large language model is effectively constrained, the analysis process is controllable, the result format is uniform, and the problems such as unpredictable output result and difficulty in integrating into subsequent automatic process caused by free play of the model or unclear input instruction are avoided.

[0105] Further, with reference to Figure 6 , Figure 6 The flowchart of the sixth embodiment of the sensitive log identification method of the application is shown. In this embodiment, the step S3002 includes steps S6001-S6002:

[0106] Step S6001, submitting the request body to the large language model, and the large language model establishes an analysis role and task based on the system prompt word and the task definition prompt word;

[0107] Specifically, the request body is submitted to the large language model, and the large language model establishes an analysis role and task based on the system prompt word and the task definition prompt word. After receiving the request body, the large language model parses the system prompt word and the task definition prompt word therein. The role identity and professional field background of the model are set by the system prompt word, so that the subsequent reasoning and judgment can be based on the professional perspective of code security. The task definition prompt word defines the specific problem to be solved in this interaction, the core principle to be followed and the boundary range of analysis.

[0108] Step S6002, receiving the response returned by the large language model, wherein the response is the second analysis result generated by the large language model according to the analysis step prompt word and the sensitive information prompt word, and the output rule prompt word is analyzed on the to-be-identified code prompt word.

[0109] The step of the large language model analyzing the to-be-identified code prompt word according to the analysis step prompt word and the sensitive information prompt word, and generating the second analysis result according to the output rule prompt word includes steps S6003-S6006:

[0110] Step S6003, analyzing the function and semantics of the log statement in the first log information, and judging whether it is possible to output sensitive information;

[0111] Step S6004, if it is judged that sensitive information may be output, matching the static text and dynamic parameter object name in the log statement with the sensitive information prompt word;

[0112] Step S6005, if the matching is not successful, code semantic analysis is performed on the first log information, and log parameters in the first log information that do not output sensitive values are filtered based on the analysis result;

[0113] Step S6006, whether the variable name, annotation value and annotation content of the entity class field corresponding to the remaining log parameters in the first log information contain the sensitive information prompt word is analyzed, and the second analysis result is generated according to the output rule prompt word.

[0114] Specifically, through the established network connection of the large language model API interface, the HTTP response returned is received, and the text content is parsed from the response body as the original response data. The text content is the output of the internal processing chain of the large language model, which starts from the analysis of the "analysis step prompt word" in the request body by the model.

[0115] First, the large language model understands the actual role of the log statement described by the code prompt word to be recognized in the business logic, and evaluates whether there is a possibility of outputting user real data, thereby completing the preliminary risk classification. If it is determined that there is a potential risk, perform: if it is judged that sensitive information may be output, match the static text and dynamic parameter object name in the log statement with the sensitive information prompt word, associate the semantic understanding of the log template static text and dynamic parameter object name generated internally with the categories defined in the "sensitive information prompt word", and complete a semantic matching attempt. If no explicit association is found in this matching, perform: if the matching is not successful, code semantic analysis is performed on the first log information, and log parameters in the first log information that do not output sensitive values are filtered based on the analysis result, based on its understanding of the programming language semantics, identify and filter out those log parameters that only output metadata (such as collection size, object state identifier) rather than specific business data values, and exclude them from the object of this deep analysis. Finally, whether the variable name, annotation value and annotation content of the entity class field corresponding to the remaining log parameters in the first log information contain the sensitive information prompt word is analyzed, and the second analysis result is generated according to the output rule prompt word, focusing on the remaining log parameters after filtering, systematically retrieving the definition of the corresponding entity class field, and comparing the variable name, naming in serialization annotation and text description in code annotation of these fields one by one to see if they intersect with the sensitive information prompt word, and according to the format specified in the "output rule prompt word", the analysis conclusion is organized into a standard second analysis result text.

[0116] Exemplarily, assuming that the first log information to be analyzed corresponds to a log statement: log.debug("Processing data for client:{},action:{}", c, act), where the type of parameter c is Client class, and the type of act is String. The large language model will understand that the function of this statement is to record the operation process of "processing data for a client", which involves outputting client information (c) and operation type (act). Since the client information may contain sensitive data such as identity, the model determines that there is a potential risk of outputting sensitive information in this statement. Then the model matches "client" in the static text "Processing data for client" in the log template with the sensitive information prompt word, and identifies that it is related to the "user" category. At the same time, the dynamic parameter object names "c" and "act" are matched, where "c" as a short name for the client object may be associated with the "user" category, and "act" as the action type has no obvious sensitive association. Although this matching suggests the potential risk of the "user" category, it does not explicitly hit specific sensitive information types such as identity card, mobile phone number, etc., so the matching result is not enough to directly conclude. Then, the large language model performs code semantic analysis on the log parameters to filter non-sensitive output. For this statement, the model will analyze the semantics of the parameter act and identify that it is likely to be a string variable representing the operation type (such as "login", "update"), which only outputs the action identifier but not the specific user business data, so it is determined as not outputting sensitive values and is filtered. For parameter c, it is determined to be an object reference, which may output specific field values after serialization, so it is retained as a deep analysis object. Finally, focus on the deep analysis of the Client class corresponding to the remaining parameter c. Retrieve the field information of the Client class, find that it contains the field private String idNumber, which directly hits the "identity card" category in the sensitive information prompt word; at the same time, find that the field is equipped with the annotation @JsonProperty("id_card"), and the annotation value id_card is also directly associated with the identity card information; in addition, if there is / / customer identity card number or the like in the field annotation, it will also be identified as a hit. Finally, according to the output rule prompt word, the second analysis result text "identity card hit" is generated by combining these deep analysis evidences.

[0117] The embodiments of the present application preconfigure system roles and tasks, build a professional analysis context for the model, ensure the normativity and professionalism of the analysis starting point, and effectively constrain the reasoning direction of the model through clear role positioning to avoid irrelevant output deviating from the core task. The pre-defined analysis step prompt words simulate the review logic of human experts, and through multi-level and multi-dimensional cross verification, potential risks hidden in complex object structures or unconventional naming can be found, guiding the model to gradually deepen from overall function judgment to field-level inspection to reduce the missed detection rate in complex scenarios. Furthermore, the parameter filtering mechanism based on code semantics can intelligently distinguish between parameters that output business data and parameters that only output metadata (such as status, quantity), avoiding invalid deep analysis of the latter, improving the accuracy of analysis and reducing false positives.

[0118] In addition, with reference to Figure 7 The present application also provides a sensitive log identification device, which comprises:

[0119] A log acquisition module 10 is configured to traverse a source code file and acquire log information in the source code file.

[0120] A sensitive identification module 20 is configured to perform keyword matching and semantic analysis on the log information and identify sensitive information in the log information.

[0121] An output module 30 is configured to extract position information of the sensitive information in the source code file, associate the sensitive information with the corresponding position information, and output the sensitive information as structured data.

[0122] The sensitive log identification device provided by the present application adopts the sensitive log identification method in the above embodiments, aiming to solve the technical problems of existing sensitive log detection methods, such as lag and high missed detection rate. Compared with the prior art, the sensitive log identification device provided by the present application has the same beneficial effects as the sensitive log identification method provided by the above embodiments, and other technical features in the sensitive log identification device are the same as the features disclosed in the above embodiments, which will not be repeated here.

[0123] The present application provides a sensitive log identification device, which comprises at least one processor and a memory in communication connection with the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform the sensitive log identification method in Embodiment I.

[0124] The sensitive log identification device in this application embodiment may include, but is not limited to, mobile terminals such as mobile phones, laptops, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Description), PMPs (Portable Media Players), vehicle terminals (such as vehicle navigation terminals), and fixed terminals such as digital TVs and desktop computers. Figure 8 The sensitive log identification device shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0125] like Figure 8 As shown, the sensitive log identification device may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to a program stored in the read-only memory 1002 or a program loaded from the storage device 1003 into the random access memory 1004. The random access memory 1004 also stores various programs and data required for the operation of the sensitive log identification device. The processing unit 1001, the read-only memory 1002, and the random access memory 1004 are interconnected via a bus 1005. An input / output interface 1006 is also connected to the bus. Typically, the following systems can be connected to the input / output interface 1006: input devices 1007 including, for example, a touch screen, touchpad, keyboard, mouse, image sensor, microphone, accelerometer, gyroscope, etc.; output devices 1008 including, for example, a liquid crystal display (LCD), speaker, vibrator, etc.; storage devices 1003 including, for example, magnetic tape, hard disk, etc.; and communication devices 1009. Communication device 1009 allows the sensitive log identification device to communicate wirelessly or wiredly with other devices to exchange data. While the figures show sensitive log identification devices with various systems, it should be understood that implementation or possession of all the systems shown is not required. More or fewer systems may be implemented alternatively.

[0126] In particular, according to the embodiments disclosed in the present application, the process described above with reference to the flowchart can be implemented as a computer software program. For example, the embodiments disclosed in the present application include a computer program product comprising a computer program carried on a computer readable medium, the computer program containing program codes for executing the method shown in the flowchart. In such embodiments, the computer program can be downloaded and installed from a network through a communication device, or installed from the storage device 1003, or installed from the read-only memory 1002. When the computer program is executed by the processing device 1001, the above-mentioned functions defined in the method of the embodiments disclosed in the present application are executed.

[0127] The sensitive log identification device provided by the present application adopts the sensitive log identification method in the above-mentioned embodiments, and aims to solve the technical problems of existing sensitive log detection methods, such as lag and high missing detection rate. Compared with the prior art, the sensitive log identification device provided by the present application has the same beneficial effects as the sensitive log identification method provided by the above-mentioned embodiments, and other technical features in the sensitive log identification device are the same as the features disclosed in the previous embodiment method, which will not be repeated here.

[0128] It should be understood that various parts of the present application can be realized by hardware, software, firmware or a combination thereof. In the description of the above-mentioned embodiments, specific features, structures, materials or characteristics can be combined in any one or more embodiments or examples in a suitable manner.

[0129] The above is merely specific embodiments of the present application, but the protection scope of the present application is not limited thereto, and any person skilled in the art can easily think of changes or replacements within the technical scope disclosed in the present application, which should be covered within the protection scope of the present application. Therefore, the protection scope of the present application should be subject to the protection scope of the claims.

[0130] The present application provides a computer readable storage medium having stored thereon computer readable program instructions (i.e. computer program) for executing the sensitive log identification method in the above-mentioned embodiments.

[0131] The computer readable storage medium provided in the present application may, for example, be a U disk, but is not limited to an electric, magnetic, optical, electromagnetic, infrared, or semiconductor system or device, or any combination of the above. More specific examples of the computer readable storage medium can include, but are not limited to, an electric connection with one or more conductive wires, a portable computer disk, a hard disk, a random access memory (RAM), a read only memory (ROM), an erasable programmable read only memory (EPROM or flash memory), an optical fiber, a portable compact disk read only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. In the present embodiment, 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 or device. The program code contained on the computer readable storage medium can be transmitted in any suitable medium, including but not limited to an electric wire, an optical cable, an RF (Radio Frequency), and the like, or any suitable combination of the above.

[0132] The above computer readable storage medium can be contained in the sensitive log identification device, or can exist separately without being assembled into the sensitive log identification device.

[0133] Computer program code for carrying out operations of the present application can be written in one or more programming languages or combinations of languages including object oriented programming languages such as Java, Smalltalk, C++ or conventional procedural programming languages such as the "C" programming language or similar programming languages. The program code can execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer can be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection can be made to an external computer (for example, through the Internet using an Internet Service Provider).

[0134] The computer readable program instructions can also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable apparatus or other device to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide processes for implementing the functions / acts specified in the flowchart and / or block diagram block or blocks.

[0135] The modules involved in the embodiments of the present application can be implemented in software or hardware. In some cases, the name of the module does not constitute a limitation on the module itself.

[0136] The computer readable storage medium provided by the present application is a computer readable storage medium, which stores computer readable program instructions (i.e. computer program) for executing the sensitive log identification method described above, and aims to solve the technical problems of existing sensitive log detection methods, such as lag and high missing rate. Compared with the prior art, the computer readable storage medium provided by the present application has the same beneficial effects as the sensitive log identification method provided by the above embodiments, and will not be described here.

[0137] The present application also provides a computer program product, comprising a computer program, which, when executed by a processor, implements the steps of the sensitive log identification method as described above.

[0138] The computer program product provided by the present application aims to solve the technical problems of existing sensitive log detection methods, such as lag and high missing rate. Compared with the prior art, the computer program product provided by the present application has the same beneficial effects as the sensitive log identification method provided by the above embodiments, and will not be described here.

[0139] It should be noted that, in this document, the terms "comprises", "comprising", or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but can also include other elements not expressly listed or inherent to such process, method, article, or apparatus. An element proceeded by "comprises a" does not, without more constraints, exclude the presence of additional identical elements in the process, method, article, or apparatus that comprises the element.

[0140] The above-mentioned sequence numbers of embodiments of the present application are only for description, and do not represent advantages or disadvantages of the embodiments.

[0141] Those skilled in the art can clearly understand the above-mentioned embodiment methods from the description of the above embodiments, which can be realized by software and necessary general hardware platforms, of course, can also be realized by hardware, but in many cases, the former is a better embodiment. Based on such understanding, the technical solutions of the present application can be embodied in the form of a software product, which is stored in a storage medium (such as a ROM / RAM, a magnetic disk, or an optical disk) and includes a plurality of instructions for causing a terminal device (which can be a mobile phone, a computer, a server, a controlled terminal, or a network device) to execute the method of each embodiment of the present application.

[0142] The above is only a preferred embodiment of the present application, and does not limit the patent scope of the present application, and any equivalent structure or equivalent process transformation using the content of the specification and drawings, or direct or indirect application in other related technical fields, are also included in the patent protection scope of the present application.

Claims

1. A method for identifying sensitive logs, characterized in that, The sensitive log identification method includes: Traverse the source code files and obtain the log information from the source code files; Perform keyword matching and semantic analysis on the log information to identify sensitive information in the log information; Extract the location information of the sensitive information in the source code file, associate the sensitive information with the corresponding location information, and output it as structured data.

2. The sensitive log identification method as described in claim 1, characterized in that, The step of traversing the source code file and obtaining the log information in the source code file includes: Traverse the source code file and identify the log statements in the source code file; Iterate through the log parameters of the log statement and parse the parameter context information of the log parameters.

3. The sensitive log identification method as described in claim 1, characterized in that, The log information includes log statements and corresponding parameter context information. The step of performing keyword matching and semantic analysis on the log information to identify sensitive information in the log information includes: The rule engine is used to analyze whether the log statements and their corresponding parameter context information contain sensitive information, and the results of the hits are marked to obtain the first analysis result; A second analysis result is obtained by performing model semantic analysis on the first log information that did not hit the sensitive information. Based on the first and second analysis results, sensitive information in the log information is determined.

4. The sensitive log identification method as described in claim 3, characterized in that, The step of using a rule engine to analyze the log statements and corresponding parameter context information to determine whether they contain sensitive information and marking them to obtain the first analysis result includes: Iterate through each log statement, analyze whether the static text, parameter names, method names, and entity class field information of the log statement match the preset sensitive word library, and generate the match result; The hit results are summarized and deduplicated to generate the first analysis result.

5. The sensitive log identification method as described in claim 3, characterized in that, Before the step of performing model semantic analysis on the first log information that did not match the sensitive information to obtain the second analysis result, the following steps are included: Extract the log information marked as a miss from the first analysis result, and use it as the first log information; Fill the log statements and corresponding parameter context information of the first log information into a preset template to generate code prompt words to be recognized; The preset system prompts and user prompts are combined to form a large language model input request body. The user prompts include preset task definition prompts, analysis step prompts, sensitive information prompts, output rule prompts, and the code to be identified prompts.

6. The sensitive log identification method as described in claim 5, characterized in that, The step of performing model semantic analysis on the first log information that did not match the sensitive information to obtain the second analysis result includes: Submit the request body to the large language model, which establishes the analysis role and task based on the system prompt words and task definition prompt words; The system receives a response from the large language model, wherein the response is the second analysis result generated by the large language model based on the analysis step prompts and sensitive information prompts for the code to be identified, and according to the output rule prompts.

7. The sensitive log identification method as described in claim 6, characterized in that, The steps of the large language model analyzing the code prompt words to be identified according to the analysis step prompt words and sensitive information prompt words, and generating the second analysis result according to the output rule prompt words include: Analyze the function and semantics of the log statements in the first log information to determine whether they may output sensitive information. If it is determined that sensitive information may be output, then the static text and dynamic parameter object name in the log statement are matched with the sensitive information prompt words; If no match is found, code semantic analysis is performed on the first log information, and log parameters in the first log information that do not output sensitive values ​​are filtered based on the analysis results. Analyze whether the variable names, annotation values, and comment content of the entity class fields corresponding to the remaining log parameters in the first log information contain the sensitive information prompt words, and generate the second analysis result based on the output rule prompt words.

8. A sensitive log identification device, characterized in that, The device includes: The log acquisition module is used to traverse the source code files and obtain the log information in the source code files; The sensitive information identification module is used to perform keyword matching and semantic analysis on the log information to identify sensitive information in the log information; The output module is used to extract the location information of the sensitive information in the source code file, associate the sensitive information with the corresponding location information, and output it as structured data.

9. A sensitive log identification device, characterized in that, The device includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the sensitive log identification method as described in any one of claims 1 to 7.

10. A storage medium, characterized in that, The storage medium is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by a processor, it implements the steps of the sensitive log identification method as described in any one of claims 1 to 7.

Images