System security threat monitoring method and system

Abstract

The invention relates to the technical field of security threat monitoring, in particular to a system security threat monitoring method and system. Comprising the following steps: S1, converting a source code project file and an application program into corresponding intermediate language files; s2, performing static analysis on the intermediate language file based on a static program slicing method of an improved system dependency graph (SDG); s3, carrying out visual statistics and display on an analysis result, and accurately identifying a line number in the source code; s4, generating a corresponding analysis report to display the influenced component and the security dynamic state thereof, and detecting detailed information and influence range of the vulnerability; existing static program analysis is improved, whether codes conform to related regulation and national standard coding specifications or not can be found, by improving a static program slicing method based on a system dependency graph SDG, time complexity is remarkably reduced, universality is enhanced by adopting an intermediate language file so as to adapt to various programming languages, and the method has the advantages of being high in practicability and easy to popularize. And wider support is provided for static analysis.

Description

Technical Field

[0001] The present invention relates to the technical field of security threat monitoring, and in particular to a system security threat monitoring method and system. Background Art

[0002] Supply chain attacks are an emerging threat against software developers and suppliers. Compared with traditional attack methods, supply chain threats have the characteristics of low attack cost, wide attack surface, serious impact, and strong concealment. According to Gartner's forecast, by 2025, 45% of enterprises and organizations around the world will face software supply chain attacks, which will increase three times compared to 2021. This poses a serious threat to information technology facilities and IT facilities in the national economy and people's livelihood industries. Supply chain security has become a crucial link in the threat confrontation. It is worth noting that supply chain attacks not only originate from external third-party components, but also may have design defects or backdoors in the planning and design stages. It is difficult to fundamentally eliminate vulnerabilities and mitigate threats by relying solely on traditional vulnerability analysis and online compliance checks.

[0003] In view of this, a system security threat monitoring method, system, medium and processor are needed. Summary of the invention

[0004] In view of the problem that it is difficult to fundamentally eliminate vulnerabilities and reduce threats by relying on traditional vulnerability analysis and online compliance checks in the existing technology, the present invention provides a system security threat monitoring method, system, medium and processor, which can perform static testing of code during the software development stage and before going online to ensure that security gaps are repaired in a timely manner. Through static code analysis, national and industry code development specifications can be implemented, guiding R&D personnel to develop good habits during the coding process, avoiding the production of defective code, and thus ensuring that the code meets compliance standards. The specific technical solution is as follows:

[0005] In order to solve the above technical problems, the present invention provides the following technical solutions, a system security threat monitoring method, comprising:

[0006] S1: Convert source code project files and application programs into corresponding intermediate language files;

[0007] S2: Static analysis of intermediate language files based on the static program slicing method based on the improved system dependency graph SDG;

[0008] S3: Visualize and display the analysis results, and accurately identify the line numbers in the source code;

[0009] S4: Generate a corresponding analysis report to display the affected components and their security dynamics, the details of the detected vulnerabilities, and the scope of impact;

[0010] The existing static program analysis has been improved. It can not only find out whether the code complies with relevant industry regulations and national standard coding specifications, but also significantly reduce the time complexity by improving the static program slicing method based on the system dependency graph SDG. The use of intermediate language files has enhanced the versatility to adapt to multiple programming languages ​​and provide broader support for static analysis.

[0011] As a preferred solution of a system security threat monitoring method described in the present invention, the static program slicing method based on the improved system dependency graph SDG includes the following summary edge acquisition steps:

[0012] S21: Find all programs that directly or indirectly call process D and form a first program set;

[0013] S22: Find out the programs directly or indirectly called by process D and form a second program set;

[0014] S23: Take out the program directly or indirectly called by process D from CG;

[0015] S24: Slice the formal-out nodes of the extracted program in-process to obtain information of the formal-in nodes corresponding to each formal-out node;

[0016] S25: Obtaining a binary relationship between an actual-out node and an actual-in node at a call point in the program according to the above corresponding information;

[0017] S26: Take out procedure D and the programs that directly or indirectly call procedure D from CG in sequence, and return to step 24 until all the programs in the program set are taken out;

[0018] S27: construct summary edges from actual-in nodes to actual-out nodes based on all obtained binary relationships;

[0019] This algorithm is incremental and only considers the programs related to the slicing standard, which narrows the slicing scope and reduces unnecessary workload.

[0020] As a preferred solution of the system security threat monitoring method described in the present invention, the monitoring method is used in the testing stage before research and development and launch.

[0021] As a preferred solution of the system security threat monitoring method described in the present invention, the intermediate language file is an LLVM bitcode file.

[0022] As a preferred solution of a system security threat monitoring method described in the present invention, the system dependency graph SDG is an extension of the intra-process dependency graph PDG, which includes the intra-process dependency graph PDG of each process in the system and a set of dependency points and dependency edges for describing the control flow and data flow transfer between processes.

[0023] As a preferred solution of a system security threat monitoring method described in the present invention, each node of the intra-process dependency graph PDG has an input set IN and an output set OUT; the calculation formula between the input set IN and the output set OUT is as follows:

[0024] OUT(s)=(IN(s)-KILL(s))∪GEN(s)

[0025] Among them, KILL(s) is the failure set, which is the set of definition information that will definitely fail after statement s; GEN(s) is the generation set, which is the set of definition information that can be generated at statement s.

[0026] As a preferred solution of the system security threat monitoring method described in the present invention, it provides rectification suggestions based on CWE vulnerability numbers, that is, risk assessment and repair suggestions.

[0027] As a preferred solution of the system security threat monitoring system described in the present invention, it includes:

[0028] A conversion module, which is used to convert source code engineering files and application programs into corresponding intermediate language files;

[0029] An analysis module, which is used to perform static analysis on the intermediate language file based on a static program slicing method based on an improved system dependency graph SDG;

[0030] The display module is used to visualize and display the analysis results and accurately identify the line numbers in the source code;

[0031] The reporting module is used to generate corresponding analysis reports to display the affected components and their security dynamics, the details of the detected vulnerabilities and the scope of impact;

[0032] The existing static program analysis has been improved. It can not only find out whether the code complies with relevant industry regulations and national standard coding specifications, but also significantly reduce the time complexity by improving the static program slicing method based on the system dependency graph SDG. The use of intermediate language files has enhanced the versatility to adapt to multiple programming languages ​​and provide broader support for static analysis.

[0033] A computer device comprises a memory and a processor, wherein the memory stores a computer program, and wherein the processor implements the steps of any one of the methods for monitoring system security threats when executing the computer program.

[0034] A computer-readable storage medium having a computer program stored thereon, characterized in that when the computer program is executed by a processor, the steps of any one of the methods for monitoring system security threats are implemented.

[0035] The beneficial effects of the present invention are as follows: By deeply integrating source code development, software security testing, and software security operations, the security checkpoints are moved forward, and the cost of vulnerability repair is reduced to cope with the growing and increasingly complex supply chain threats. This method will cover the entire life cycle of the software, check from the source, and reduce the risk of threat spread caused by introducing devices with security defects and threats into the core business network. By effectively preventing the introduction of vulnerabilities during the development process, the overall security of the business network is improved to better cope with supply chain threats. BRIEF DESCRIPTION OF THE DRAWINGS

[0036] In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the accompanying drawings required for use in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other accompanying drawings can be obtained based on these accompanying drawings without paying creative work.

[0037] Figure 1 A flowchart of a system security threat monitoring method provided by an embodiment of the present invention.

[0038] Figure 2 A schematic diagram of the CalcSummEdge algorithm flow of a system security threat monitoring method provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0039] In order to make the above-mentioned purposes, features and advantages of the present invention more obvious and easy to understand, the specific implementation methods of the present invention are described in detail below in conjunction with the drawings of the specification. Obviously, the described embodiments are part of the embodiments of the present invention, but not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary persons in the art without creative work should fall within the scope of protection of the present invention.

[0040] Embodiment 1, as Figure 1 The figure shows a flow chart of a system security threat monitoring method, which includes the following steps:

[0041] S1: During the R&D and pre-launch testing phase, source code engineering files, applications, code snippets, compilation processes, and binary applications are converted into corresponding LLVM bitcode (language) files to facilitate subsequent static program slicing analysis of the program. The implementation object of the slicing analysis algorithm is LLVM bitcode, which has strong versatility and is conducive to the subsequent development of slicing. With the help of LLVM bitcode, multiple front-end language programs can be sliced ​​to meet the needs of static analysis of multiple languages.

[0042] S2: Based on the static program slicing method of the improved system dependency graph SDG, the LLVM bitcode file is statically analyzed and deeply mined to discover potential 0day vulnerabilities in the power information system, ensuring that potential security issues are discovered and fixed in the early stages of development and testing, thereby improving the security and stability of the entire power information system.

[0043] Specifically, the dependency graph includes a program dependency graph (PDG) and a system dependency graph (SDG).

[0044] In static analysis, a program dependency graph (PDG) is used to describe a process within a function, where the nodes of the graph represent statements and control predicate expressions, and the edges in the graph include control dependency edges and data dependency edges. Control dependency edges are control conditions that statements and expressions depend on for execution, and the source nodes of control dependency edges can only be entry nodes or predicate nodes; data dependency edges represent data flows between statements or expressions. In addition, each program dependency graph also contains an entry node (Entry) representing the entry of the process and an exit node (Exit) representing the exit of the process. Each node in the PDG has an input set (IN) and an output set (OUT), where the input set IN(s) records the set of definition information that can reach statement s, and the output set OUT(s) records the set of definition information that can be propagated downward after passing through statement s. The input set IN of a node is the union of all its direct predecessor output sets OUT, and the output set OUT is the result of excluding definitions that are no longer visible on the basis of the input set IN and adding new definition information. The relationship between the input set IN and the output set OUT can be expressed by the following data flow equation:

[0045]

[0046] OUT(s)=(IN(s)-KILL(s))∪GEN(s) (2)

[0047] Among them, the failure set KILL(s) is the set of definition information that will definitely fail after s, and the generation set GEN(s) is the set of definition information that can be generated at point s. At the beginning of the iteration, the output set of the process entry node Entry is set to:

[0048] OUT(Entry)={(Entry,x)x∈DEF(Entry)}.

[0049] The input sets and output sets of other nodes are set to empty. When the input sets and output sets of each node no longer change, the iteration converges and the calculation terminates.

[0050] Program slicing within a procedure can be achieved through graph reachability analysis on the program dependency graph. As long as the graph is traversed in the opposite direction of the dependency edge, the final slicing result can be obtained. The statements contained in the slice are the dependency graph nodes covered during the graph traversal process. The specific program dependency graph (PDG) slicing algorithm program is as follows:

[0051] Input: PDG, Slice Standard o >

[0052] Output: Slice

[0053] Initialization: Slice = Ф, W = {s o};

[0054] algorithm:

[0055]

[0056] Take an element s from W;

[0057] Slice = Slice U {s};

[0058] for each edge in PDG<s',s> do

[0059] W = WU{s'};

[0060] Deleting an edge from a PDG<s',s> ;

[0061] endfor

[0062] Until W = Ф;

[0063] end

[0064] ​Dependencies in sequential programs are transitive. Program slicing is essentially tracing statements related to the slicing criteria. Program slicing within a process can be achieved through graph reachability analysis on the program dependency graph. As long as the graph is traversed in the opposite direction of the dependency edge, the final slicing result can be obtained. The statements contained in the slice are the dependency graph nodes covered during the graph traversal process.

[0065] For the system dependency graph (SDG), the system dependency graph is an extension of the intra-procedural dependency graph. It contains the program dependency graph PDG of each procedure in the system and a set of dependency points and dependency edges used to describe the control flow and data flow transfer between procedures. Compared with the intra-procedural dependency graph, the system dependency graph SDG adds five types of nodes: call-site nodes, formal-in nodes, formal-out nodes, actual-in nodes, and actual-out nodes. The call-site node describes the call statement. The control dependency edge from the call-site node to the entry of the called procedure represents the control flow transfer from the calling procedure to the called procedure. This set of dependency edges is also called call edges. Each procedure corresponds to a set of formal-in and formal-out nodes, which represent the input parameters and output parameters respectively. Their control depends on the entry node of the procedure. In addition to the call-site node, each call also corresponds to a set of actual-in and actual-out nodes, which describe the actual parameters corresponding to the formal parameters respectively. Their control depends on the corresponding call-site call point. Compared with the intra-procedural dependency graph, the system dependency graph SDG adds three types of edges: call edge, parameter-in / out edge, and summary edge. There is a call edge between the call-site node and the entry node of its corresponding callee. There are two types of dependency edges representing parameter passing between the formal-in and formal-out nodes and the actual-in and actual-out nodes. The parameter-in edge connects the actual-in and formal-in nodes, while the parameter-out edge connects the formal-out and actual-out nodes. These two edges describe the value transfer between the actual parameters and formal parameters of the procedure. The system dependency graph SDG also contains transitive dependency edges (summary edges, summary edges) from the actual-in node to the actual-out node. These summary edges express the external dependency characteristics of a call without the need to understand the relevant statements in the called procedure.

[0066] The initial SDG only contains the PDGs of several intra-procedural programs. The algorithm completes the construction of the SDG by continuously adding inter-procedural dependency points and dependency edges. Among them, the most critical issue is how to obtain the summary edge. The specific system dependency graph (SDG) slicing algorithm is as follows:

[0067] Input: a set of multiple PDGs W, a call graph (CG), a slicing standard <so>

[0068] Output: SDG

[0069] Begin

[0070] for each PDG∈W do / / The initial SDG contains only a few PDGs

[0071] Add formal-in / out nodes to the entry node entry;

[0072] for each call site ∈ PDG do

[0073] Add call-site, actual-in / out and other nodes;

[0074] Add the call edge to SDG according to CG;

[0075] According to the correspondence between actual parameters and formal parameters, add the corresponding parameter-in / out edges to SDG;

[0076] endfor

[0077] endfor

[0078] Calculate summary edges according to a certain algorithm;

[0079] Add the summaries to the SDGs based on the calculation results;

[0080] end

[0081] Static program slicing considers all possible inputs of the program, and the analysis is more comprehensive and the cost is lower. Currently, the most popular static program slicing method is program slicing based on dependency graphs. It mainly constructs a dependency graph and then traverses the dependency graph twice to obtain the program slicing results. Among them, the most important step is to obtain the process summary edge (i.e., summary edge). The summary edge can be constructed using the feature subgraph method or the IFDS algorithm. The feature subgraph method first constructs a connection grammar to establish a model of the process call structure, then establishes an auxiliary feature subgraph for each program to describe the dependency relationship between process parameters, and finally introduces the data dependency between the feature subgraph parameters corresponding to the program at the call point of each program. The IFDS algorithm is used to construct summary edges. The algorithm needs to construct a hypergraph of the inter-procedural program, use the edge set PathEdge to store ordinary edges, and use the set SummaryEdge to store summary edges. The edges in the hypergraph are continuously analyzed, and PathEdge and SummaryEdge are updated until all edges are analyzed. Currently, the fastest way to obtain summary edges is the IFDS (Interprocedural Finite Distributive Subset) algorithm, which obtains summary edges by obtaining four flow functions of nodes. However, since it needs to build a hypergraph of interprocedural programs, the algorithm process is relatively complicated.

[0082] Therefore, the present application also proposes another static program slicing method based on the improved system dependency graph SDG, and proposes a simpler method for constructing summary edges, namely the CalcSummEdge algorithm, to reduce the time complexity of program slicing based on the dependency graph. The main improvements are: (1) Improved static program slicing based on the system dependency graph SDG; (2) A new program slicing method for inter-procedural information flow.

[0083] In a specific implementation, in the static program slicing method based on the improved system dependency graph SDG, the call related to the process P includes the following summary edge acquisition steps:

[0084] First, based on the existing system dependency graph (without adding transitive dependency edges), each formal-out node of process P is sliced ​​within the process;

[0085] Get the formal-in nodes that they depend on;

[0086] According to the correspondence between formal-in / out and actual-in / out nodes, we can obtain the dependency of actual-out on actual-in at the calling point of process P.

[0087] Construct a transitive dependency edge from actual-in to actual-out.

[0088] Since the efficiency of slice analysis is affected by SummaryEdge edges, the focus needs to be on optimizing the calculation of this part. Considering that the calculation of the summary edge of process P may be affected by the calculation of the summary edge of the module called by P, from a global perspective, the solution of the summary edge corresponding to each process is an iterative process. When all the called summary edges are stable, the calculation terminates.

[0089] After optimizing the SummaryEdge calculation, the specific algorithm CalcSummEdge program is as follows:

[0090] Algorithm (CalcSummEdge)

[0091] Input: SDG, CG, slicing standard without summary edges <so>(so is a statement in program P)

[0092] Output: summary edge set

[0093] declare S caller is the set of directly or indirectly calling process P;

[0094] S callee The set of programs that are directly or indirectly called by process P;

[0095] S proc is a collection of programs;

[0096] Initialization: S caller =S callee =S proc ={P};

[0097]

[0098]

[0099] like Figure 2 The figure below is a flowchart showing the execution process of the CalcSummEdge algorithm. There are 8 process programs AH, and the arrows in the figure represent the calling relationship. Assuming that the slicing standard is a statement in D, the steps are as follows:

[0100] Lines 1-4 find all assemblies {A, B, C} that call D directly or indirectly;

[0101] Lines 5-8 find out the assembly {E, F} that D calls directly or indirectly;

[0102] Line 9 calls the SummEdge(Sproc) procedure.

[0103] SummEdge (Sproc) program first iteration:

[0104] Line 11 retrieves programs E and F from CG;

[0105] Lines 13-24 perform intra-procedural slicing on the formal-out nodes of programs E and F, obtain the formal-in corresponding to each formal-out node, and update SummForm;

[0106] Lines 25-27 use the SummForm information to obtain the binary relationship between actual-out and actual-in at the call point in D and update SummAct;

[0107] The second iteration of the SummEdge (Sproc) procedure;

[0108] Line 11 retrieves program D from CG;

[0109] Lines 13-24 perform in-proc slicing on formal-out in D and update SummForm;

[0110] Lines 25-27 use the SummForm information to obtain the binary relationship between actual-out and actual-in at the call point in C and update SummAct;

[0111] The third iteration of the SummEdge (Sproc) program obtains the binary relationship between actual-out and actual-in at the call points in A and B, and updates SummAct;

[0112] In the fourth iteration of the SummEdge(Sproc) program, the set Sproc is empty, the loop stops, and the algorithm terminates.

[0113] The algorithm does not do any processing on programs G and H. This algorithm is incremental and only considers programs related to the slicing standard. Compared with the feature subgraph and IFDS algorithms, its advantage is that it narrows the slicing range and reduces unnecessary workload.

[0114] Therefore, in the static program slicing method based on the improved system dependency graph SDG, the call related to the process D includes the following summary edge acquisition steps:

[0115] S21: Find all programs that directly or indirectly call process D and form a first program set; the first program set includes all programs that directly or indirectly call process D;

[0116] S22: Find out the programs directly or indirectly called by process D and form a second program set; the second program set includes all the programs directly or indirectly called by process D;

[0117] S23: Take out the program directly or indirectly called by process D from CG;

[0118] S24: Slice the formal-out nodes of the extracted program in-process to obtain information of the formal-in nodes corresponding to each formal-out node;

[0119] S25: Obtaining a binary relationship between an actual-out node and an actual-in node at a call point in the program according to the above corresponding information;

[0120] S26: Take out procedure D and the programs that directly or indirectly call procedure D from CG in sequence, and return to step 24 until all the programs in the program set are taken out;

[0121] S27: Construct a transitive dependency edge from actual-in to actual-out.

[0122] Furthermore, the in-depth exploration of static analysis of source code engineering and applications refers to risk detection and analysis of code snippets, compilation processes, and binary applications, and the use of multiple analysis methods such as data flow analysis, taint propagation analysis, symbolic execution, pattern matching, and semantic analysis for cross-analysis, so as to effectively improve the visibility of unsafe and malicious components in the software, prevent n-day vulnerabilities from being introduced into the system on the development side, and reduce the workload of security personnel. At the same time, it can also effectively improve the component information and vulnerability information in software assets on the regulatory side, which is a key step in effectively managing software supply chain security. At the same time, semantic analysis capabilities can detect the use of unsafe APIs and incorrect configuration information, thereby defending against some 0-day vulnerabilities.

[0123] Furthermore, the risk detection and analysis of code snippets refers to self-identification of project engineering types and automatic selection of the most appropriate analysis engine from a variety of analysis engines for analysis. The types of analysis engines cover the source code engineering of most mainstream languages, including more than 10 languages ​​such as NodeJS, Java, Python, JavaScript, PHP, C#, Ruby, Go, Flutter, Kotlin, Rust, and Erlang. Then, the code is statically analyzed, using advanced semantic analysis, symbolic execution, data flow analysis, taint propagation analysis and other technologies, which can quickly identify defective code and 0day in the source code and provide repair suggestions. At the same time, the analysis engine is deeply integrated with the package manager, has comprehensive open source component information, and can provide repair suggestions, such as one-click repair capabilities for NodeJS, Java, and Python. The analysis engine can timely prevent and prevent such malicious code from being introduced into the project and put on the shelf for use by analyzing and discovering malicious components in the product.

[0124] Furthermore, the risk detection and analysis of the compilation process and binary applications includes analyzing binary files compiled from C / C++, Golang, and Java to discover unsafe third-party components.

[0125] Furthermore, the risk detection and analysis of binary applications mainly refers to static analysis of online power information system applications, and accurate data flow analysis can be performed without source code.

[0126] S2: Visualize and display the analysis results, accurately identify the line numbers in the source code, generate detailed reports and documents that comply with international standards, and provide rectification suggestions based on the CWE vulnerability number, that is, risk assessment and repair suggestions.

[0127] Furthermore, the analysis results are visualized and statistically analyzed, including providing a path tracking diagram and path tracking table of the vulnerability, gradually presenting the process of vulnerability introduction, assisting R&D personnel and security personnel in auditing and troubleshooting the code, effectively helping developers understand the causes of vulnerabilities, and assisting the ability of manual marking to achieve the troubleshooting of false positive vulnerabilities, thereby further manually evaluating the authenticity and severity of the vulnerability, so as to better repair source code vulnerabilities. Provide domestic and foreign coding standards to help R&D personnel follow code specifications during the coding process. At the same time, it can also graphically and continuously check various dependencies and changes in software assets, effectively reducing the difficulty of component vulnerability troubleshooting.

[0128] The following common vulnerabilities can be detected, covering the common vulnerabilities of CWE (Common Weakness Enumeration) and 0WASP (0pen Web Application Security Project): XSS (cross-site scripting), SQL injection, CSRF (cross-site request forgery), incorrect configuration, server-side forgery, hard-coded passwords, XPath injection, LPAD injection, XML entity injection, file inclusion vulnerability, code injection, command injection, information leakage, insecure random function, unverified jump, deserialization vulnerability, abandoned function, logical error, illegal pointer reference, memory out of bounds, multiple release, insecure function, insecure encryption, WebShell (a code execution environment in the form of web page files).

[0129] S3: Generate a corresponding analysis report to display the affected components and their security dynamics, the details of the detected vulnerabilities and the scope of impact, project information display, etc. Furthermore, the analysis report is a document that complies with international standards, including a software bill of materials summary, a risk vulnerability summary, and a licensing information summary. Furthermore, the software bill of materials is already an internationally recognized methodology. Through a static snapshot of the executable body, it can effectively improve the visibility of vulnerabilities and the ability to manage licenses, help to do bilateral verification, and is a key means to deal with software supply chain threats.

[0130] The analysis report supports multiple report export formats, including SARIF, json, word format reports, excel format reports, etc.

[0131] Since the codes in the power information system are complex and diverse, involving various types of hardware equipment, the security of the code itself is also a very important part of the supply chain security. It is necessary to study whether the code in the power grid complies with the relevant industry regulations and national standard coding specifications, and to discover potential 0day risks in the code. Through improved pointer analysis and improved program slicing analysis, the accuracy can be improved while effectively reducing the analyzer overhead. Finally, a set of static code analyzers including semantic analysis, symbolic execution, and data flow analysis is formed, which supports multiple common languages ​​and also supports integration with IDE plug-ins to ensure that R&D personnel can improve the code while developing.

[0132] Embodiment 2, a system security threat monitoring system, applied to the system security threat monitoring method described above, comprises:

[0133] A conversion module, which is used to convert source code engineering files and application programs into corresponding intermediate language files;

[0134] An analysis module, which is used to perform static analysis on the intermediate language file based on a static program slicing method based on an improved system dependency graph SDG;

[0135] The display module is used to visualize and display the analysis results and accurately identify the line numbers in the source code;

[0136] The reporting module is used to generate corresponding analysis reports to display the affected components and their security dynamics, the details of the detected vulnerabilities and the scope of impact;

[0137] The existing static program analysis has been improved. It can not only find out whether the code complies with relevant industry regulations and national standard coding specifications, but also significantly reduce the time complexity by improving the static program slicing method based on the system dependency graph SDG. The use of intermediate language files has enhanced the versatility to adapt to multiple programming languages ​​and provide broader support for static analysis.

[0138] Embodiment 3, a computer-readable storage medium includes a stored program, wherein when the program is executed, the device where the computer-readable storage medium is located is controlled to execute the above-mentioned system security threat monitoring method.

[0139] Embodiment 4, a processor, the processor is used to run a program, wherein the system security threat monitoring method described above is executed when the program is running.

[0140] The present application discloses a system security threat monitoring method, comprising: S1: converting source code engineering files and application programs into corresponding intermediate language files; S2: statically analyzing the intermediate language files based on a static program slicing method based on an improved system dependency graph SDG; S3: visually counting and displaying the analysis results, accurately identifying the line numbers in the source code; S4: generating a corresponding analysis report to display the affected components and their security dynamics, detailed information of detected vulnerabilities and the scope of impact; the existing static program analysis is improved, which can not only find out whether the code complies with relevant industry regulations and national standard coding specifications, but also significantly reduce the time complexity by improving the static program slicing method based on the system dependency graph SDG, and enhance the versatility by using intermediate language files to adapt to multiple programming languages, so as to provide more extensive support for static analysis.

[0141] Those of ordinary skill in the art will appreciate that the units of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of the two. In order to clearly illustrate the interchangeability of hardware and software, the composition of each example has been generally described in terms of function in the above description. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of the present invention.

[0142] In the embodiments provided by the present invention, it should be understood that the division of units is only a logical function division, and there may be other division methods in actual implementation, for example, multiple units can be combined into one unit, one unit can be split into multiple units, or some features can be ignored, etc.

[0143] In addition, each functional unit in each embodiment of the present invention may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit. The above-mentioned integrated unit may be implemented in the form of hardware or in the form of software functional units.

[0144] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or all or part of the technical solution can be embodied in the form of a software product, which is stored in a storage medium and includes several instructions for a computer device (which can be a personal computer, a server or a network device, etc.) to perform all or part of the steps of the method described in each embodiment of the present invention. The aforementioned storage medium includes: U disk, read-only memory (ROM, Read-0nlyMemory), random access memory (RAM, RandomAccessMemory), mobile hard disk, magnetic disk or optical disk, etc., which can store program code.

[0145] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, rather than to limit it. Although the present invention has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or replace some or all of the technical features therein by equivalents. These modifications or replacements do not make the essence of the corresponding technical solutions deviate from the scope of the technical solutions of the embodiments of the present invention, and they should all be included in the scope of the claims and specification of the present invention.< / so> < / so>

Claims

1. A system security threat monitoring method, characterized in that: include: Convert source code project files and application programs into corresponding intermediate language files; Based on the static program slicing method of the improved system dependency graph SDG, the intermediate language file is statically analyzed; Visualize and display the analysis results, and accurately identify the line numbers in the source code; Generate a corresponding analysis report to display the affected components and their security dynamics, detailed information of detected vulnerabilities, and the scope of impact.

2. A system security threat monitoring method as claimed in claim 1, characterized in that: The static program slicing method based on the improved system dependency graph SDG includes: Find all programs that directly or indirectly call procedure D and form the first program set; Find out the programs called directly or indirectly by process D and form a second program set; Remove the programs directly or indirectly called by process D from CG; Perform intra-process slicing on the formal-out nodes of the extracted program to obtain the information of the formal-in nodes corresponding to each formal-out node; According to the corresponding information, the binary relationship between the actual-out node and the actual-in node at the call point in the program is obtained; Sequentially take out procedure D and the programs that directly or indirectly call procedure D from CG, and perform intra-procedural slicing on the formal-out nodes of the taken out programs until all the programs in the program set are taken out; Construct summary edges from actual-in nodes to actual-out nodes based on all obtained binary relationships.

3. A system security threat monitoring method as claimed in claim 1, characterized in that: The monitoring method is used in the research and development and pre-launch testing stages.

4. A system security threat monitoring method as claimed in claim 1, characterized in that: The intermediate language file is an LLVM bitcode file.

5. A system security threat monitoring method as claimed in claim 1, characterized in that: The system dependency graph SDG is an extension of the intra-process dependency graph PDG, and includes the intra-process dependency graph PDG of each process in the system and a set of dependency points and dependency edges for describing the control flow and data flow transfer between processes.

6. A system security threat monitoring method as claimed in claim 5, characterized in that: Each node of the intra-process dependency graph PDG has an input set IN and an output set OUT; The calculation formula between the input set IN and the output set OUT is as follows: OUT(s)=(IN(s)-KILL(s))∪GEN(s) Among them, KILL(s) is the failure set, which is the set of definition information that will definitely fail after statement s; GEN(s) is the generation set, which is the set of definition information that can be generated at statement s.

7. A system security threat monitoring method as claimed in claim 1, characterized in that: The following steps are also included: Provides correction suggestions based on CWE vulnerability numbers, that is, risk assessment and repair suggestions.

8. A system security threat monitoring system, characterized in that: The system security threat monitoring method applied to any one of claims 1 to 7 comprises: A conversion module, which is used to convert source code engineering files and application programs into corresponding intermediate language files; An analysis module, which is used to perform static analysis on the intermediate language file based on a static program slicing method based on an improved system dependency graph SDG; The display module is used to visualize and display the analysis results and accurately identify the line numbers in the source code; The report module is used to generate corresponding analysis reports to display the affected components and their security dynamics, the details of the detected vulnerabilities and the scope of impact.

9. A computer-readable storage medium, characterized in that: The computer-readable storage medium includes a stored program, wherein when the program is executed, the device where the computer-readable storage medium is located is controlled to execute the system security threat monitoring method according to any one of claims 1 to 7.

10. A processor, characterized in that: The processor is used to run a program, wherein the program, when running, executes the system security threat monitoring method described in any one of claims 1 to 7.

Images