NPM malicious software package detection method based on behavior analysis and matching of graph model

Abstract

The invention belongs to the technical field of software engineering, and particularly relates to an NPM malicious software package detection method based on behavior analysis and matching of a graph model. The method comprises the following steps: constructing a program suspicious behavior graph by utilizing a static analysis technology; collecting NPM malicious software packages from a plurality of information sources as a data set; in the off-line stage, a program suspicious behavior graph is constructed for an existing malicious software package, and a malicious behavior graph is obtained in a manual clipping mode; in the deployment stage, a to-be-detected NPM software package is input, an installation script contained in a configuration file of the to-be-detected NPM software package is analyzed firstly, whether malicious behaviors exist or not is recognized, then obfuscation detection is conducted on a code file, and program suspicious behavior graphs under the three stages of installation, import and operation are generated for the software package not containing obfuscation codes; and the malicious behavior graph is matched with a known malicious behavior graph generated in an offline stage, so that malicious behavior detection is realized. The method provided by the invention can help to detect the NPM malicious software package and reduce the harm caused by malicious codes.

Description

Technical Field

[0001] The present invention belongs to the technical field of software engineering, and in particular relates to a method for detecting NPM malware packages. Background Art

[0002] Open source software refers to software whose source code is open and allows users to freely use, modify and distribute it. By reusing existing code, developers do not need to write code from scratch, which significantly reduces the cost of software development, accelerates innovation, and improves code transparency and security. These advantages have led to the widespread adoption of open source software around the world. According to the Open Source Security and Risk Analysis Report released by Synopsys in 2024[1], 96% of code bases contain open source software. At the same time, the open source community witnessed 301 million contributions to open source software on GitHub by developers in 2023[2], indicating that the influence and importance of open source software are growing day by day. However, with the popularity and widespread use of open source software, security issues in the open source software supply chain have become increasingly prominent. As more companies and developers rely on open source components, attackers are increasingly turning their attention to the supply chain and attempting to launch attacks by attacking the open source software supply chain. This trend has exacerbated security risks and posed a major threat to the open source software ecosystem[3][5][6][7]. Ladisa et al.[4] proposed a classification method for open source software supply chain attacks, which provides an important reference for understanding and preventing these threats. Among supply chain security risks, malware package poisoning is a common attack method. These malware packages may disguise themselves as legitimate software, inducing developers or enterprises to inadvertently integrate them into applications, thereby causing security issues. Recently, researchers have discovered that two widely used package management repositories, NPM and PyPI, are full of malware packages[8][9]

[10]

[11]

[12]

[13] , posing a security threat to many downstream applications. According to a Sonatype report[6], more than 245,000 malware packages were discovered in 2023 alone, which is twice the total number of malware packages discovered in all previous years since 2019.

[0003] In the face of this type of software package poisoning attack, automated malware package detection tools are particularly important, especially NPM, which is currently the largest Node.JS package management and distribution center with more than two million software packages. Therefore, effective malware package detection is crucial. There are many automated malware package detection tools. Duan et al.

[14] used static analysis and dynamic analysis for software packages and combined heuristic rules for detection. This rule-based method is simple and efficient, but it is prone to high false positive rates. Ohm et al.

[15] used an unsupervised learning method to analyze the AST representation of malware packages using the Markov clustering algorithm and generated signatures for each cluster to detect new software packages. Sejfia et al.

[16] proposed a malware package detection tool AMALFI based on supervised learning. By extracting metadata features and source code features of software packages, classifiers are trained to detect new software packages. The learning-based method converts the code into discrete feature representations, which to a certain extent loses the order of behavior when the malicious code is executed. Zhang et al.

[17] constructed natural language sequences to describe the behavior of malware packages through feature extraction, natural language description, and function call graph generation, and used the Bert model for classification. Zahan et al.

[17] used prompt engineering to detect malware packages, but due to the high cost of using ChatGPT, large-scale detection is difficult to achieve. In summary, current detection tools have the following shortcomings: (1) Existing tools cannot fully model malicious behavior, which involves not only sensitive API calls, but also the control flow and data dependencies between these API calls. (2) Existing methods rely on manual calibration to collect sensitive APIs, and the collection of third-party dependencies is not sufficient. (3) Existing tools require a lot of manpower in actual use due to high false positive rates and lack of detailed output information (such as the specific location of the malicious code). Summary of the invention

[0004] The purpose of the present invention is to provide a method for detecting NPM malware packages with high efficiency and low consumption, thereby effectively detecting malware packages and reducing the harm caused by malicious codes.

[0005] The NPM malware package detection method provided by the present invention includes an offline stage and a deployment stage; the deployment stage is divided into three stages: installation, import and operation; the present invention first uses static analysis technology to construct a program behavior graph with sensitive APIs as nodes and data dependencies and control flows as edges, wherein sensitive APIs are automatically identified through a large model; then information about NPM malware packages is collected from multiple information sources to form a data set;

[0006] In the offline stage, for the existing malware packages, a suspicious behavior graph of the program is constructed, and the malicious behavior graph is obtained by manual cutting;

[0007] In the deployment phase, the NPM software package to be detected is input, and the installation script contained in its configuration file is first analyzed to identify whether there is malicious behavior, and the entry of the execution file in the installation phase and the import phase is determined; then, the code file is obfuscated and detected, and for the software package that does not contain obfuscated code, suspicious behavior graphs of the program in the three phases of installation, import and operation are generated respectively, and matched with the known malicious behavior graphs generated in the offline phase to detect malicious behavior;

[0008] For specific malicious behaviors that match, based on dynamic analysis, the API hooking method is used to obtain the parameter content of the specified API, and combined with the API type, it is handed over to the big model for further malicious behavior judgment.

[0009] The specific steps are as follows:

[0010] (I) Static analysis technology is used to construct a suspicious program behavior graph with sensitive APIs as nodes and data dependencies and control flows as edges. The identification of sensitive APIs is obtained by automatic identification and classification of the large model.

[0011] Through static analysis tools, given the execution entry of a program, a behavior graph of the program is generated; based on the behavior graph, sensitive APIs are identified and located. These APIs can be divided into built-in APIs and third-party APIs according to their types; then, based on the identified sensitive APIs, a suspicious behavior graph of the program is constructed. In the suspicious behavior graph, each node corresponds to a sensitive API, and the edges in the graph represent the control flow and data dependency between APIs.

[0012] It includes the following sub-steps:

[0013] (1) Based on the static analysis tool Joern

[19] , the control flow information and data dependency contained in the code are analyzed. The control flow information is represented by a control flow graph (CFG), and the data dependency is represented by a data dependency graph (DDG).

[0014] (2) Given an execution entry, traverse the control flow graph to simulate the execution process of the program and generate a program behavior graph (PBG). During the traversal process, add the nodes encountered to the program behavior graph, and add corresponding edges to the behavior graph based on the edge information in the original control flow graph and the data dependency graph. In particular, during the traversal process, four types of nodes are mainly analyzed and processed, including:

[0015] Import node (import or require): The import statement is used to import modules. When encountering this type of node, analyze the type of the imported module, classify it as a built-in module, a third-party module, or a local module, and record the corresponding alias.

[0016] Function Call Node: A function call statement refers to a call to a declared function. When such a node is encountered, the corresponding called function is located according to the call graph (CG). Next, based on the data dependency graph, it is determined whether there is a data dependency related to the function call parameters. If such a dependency exists, the function call node is connected to the called function node through a data dependency edge; if not, they are connected using a control flow edge.

[0017] API Call Node: An API call statement refers to calling an API provided by a built-in module or a third-party dependency. Each API call node can be classified as sensitive or non-sensitive. To identify sensitive built-in APIs, we obtain the official documentation of the API and pre-set the corresponding sensitive behavior types, such as file reading, network requests, etc., and then use the big model to classify the official description of the API to identify sensitive APIs. For sensitive third-party APIs, we analyze the source code and API comments, and also use the big model for classification to identify sensitive APIs. For sensitive APIs, the corresponding return value type will also be recorded to assist in the analysis of the API calls involved in the return value.

[0018] Assignment node: For assignment statements, first analyze the type of the expression on the right side. If the expression on the right side is an API call, further analyze the behavior category and return value type of the API call, and bind this information to the object on the left side of the assignment.

[0019] (3) Based on the sensitive APIs identified and located and their edge relationships in the program behavior graph, the program’s suspicious behavior graph (SBG) is extracted and constructed. In the graph, each node corresponds to an identified sensitive API, and the edges in the graph represent the control flow relationships and data dependencies between APIs.

[0020] (ii) Collect information about NPM malware packages from multiple information sources as a dataset.

[0021] Collect software packages related to the NPM ecosystem from public malware package datasets; collect security intelligence related to the NPM ecosystem from well-known security blogs and obtain corresponding software packages.

[0022] It includes the following sub-steps:

[0023] (1) We collect malware packages from the public malware package datasets Backstabber's knife collection

[11] and MalOSS

[14] , and filter out malware packages related to the NPM ecosystem.

[0024] (2) Collect well-known security websites, such as Sonatype, Fortinet, Hacker News, etc., and obtain security intelligence information related to the NPM ecosystem from the blogs of these websites, including: package name, version number, release date. Based on this information, collect the malware packages that have been removed from the local NPM repository cache.

[0025] (III) In the offline stage, a suspicious behavior graph of the program is constructed for the existing malware package, and the malicious behavior graph is obtained by manual cutting; the specific process is as follows:

[0026] First, prepare the dataset required to generate the malicious behavior graph:

[0027] Use the NPM malware packages collected in step (2) as a dataset for generating malicious behavior graphs;

[0028] Use the method in step (1) to generate corresponding suspicious behavior graphs for these malware packages;

[0029] The suspicious behavior graph may contain sensitive APIs that are not related to malicious behavior. Therefore, these irrelevant API nodes are removed through artificial trimming to obtain the final malicious behavior graph.

[0030] (IV) In the deployment phase, input the NPM software package to be detected, first analyze the installation script contained in the configuration file in the software package, determine the entry of the execution file in the installation phase and the import phase, and identify whether there is malicious behavior. Next, perform obfuscation detection on the code file; for software packages that do not contain obfuscated code, generate suspicious behavior graphs of the program from the three stages of installation, import, and operation, and match them with known malicious behavior graphs to detect malicious behavior. For malicious behaviors that are partially matched, the API hooking method is adopted. Through dynamic analysis, the parameter content of the specified API is extracted from the execution log. The parameter content is combined with the API type and handed over to the large model for further malicious behavior judgment. Specifically includes the following sub-steps:

[0031] (1) Take the NPM software package to be detected as the input of this step, process the installation script in the configuration file package.json in the software package, and specifically analyze the scripts in the three fields of preinstall, install, and postinstall. Analyze the executable file entry of the software package in the installation and import stages based on regular expressions, and use a large model to judge the script to detect whether there is malicious behavior in the script.

[0032] (2) Malicious code usually uses obfuscation to hide its malicious behavior. In the current step, the obfuscated code is detected. The features of obfuscation detection are composed of the semantic information and syntactic features of the code. The semantic information features include the number of code lines, the number of blank characters, the number of obfuscated identifiers, etc. The syntactic features are extracted based on the AST sequence and n-grams model. The detection process is based on the trained binary classifier, and the model used is random forest.

[0033] (3) If the software package does not contain obfuscated code, use the method in step (1) to generate a suspicious behavior graph of the program from the three stages of installation, import, and operation for the software package that does not contain obfuscated code. Match the suspicious behavior graph with the malicious behavior graph obtained in step (3) to detect malicious behavior.

[0034] (4) In order to reduce the false alarm rate, additional analysis is performed on some malicious behaviors detected in step (3). The API types to be analyzed include file reading and writing, command execution, executable file operation, and dynamic function generation. Custom code is inserted before the API to be analyzed to obtain its actual parameters. Based on dynamic analysis, the specified parameter content is extracted from the execution log. Then, these actual operation parameters are combined with the API type and submitted to the large model for judgment, so as to further determine whether there is malicious behavior.

[0035] The technical features and performance advantages of the present invention mainly include:

[0036] By using static analysis technology to construct a program behavior graph, with sensitive APIs as nodes and data dependencies and control flows as edges, global modeling of program behavior is achieved, making the analysis more accurate and fine-grained. The large model automatically identifies and classifies sensitive APIs, significantly reducing the workload of manual collection and annotation. In the deployment phase, program behavior analysis is subdivided into three stages: installation, import, and operation. It can fully cover all execution links of the software package, detect potential malicious behaviors, and ensure the comprehensiveness of detection. In addition, special detection is carried out on the obfuscation of the code, and the obfuscation features are used for binary classification processing to expand the detection range of malicious code. API hooking technology and dynamic analysis are used to obtain the operating parameters of the API in real time, further confirm the existence of malicious behavior, and effectively reduce the false alarm rate. The present invention can not only detect and identify malicious behavior and its type, but also accurately locate the location of malicious code, thereby greatly improving the efficiency of manual inspection.

[0037] The present invention mainly constructs program behavior based on static analysis, and further verifies specific situations that are prone to false positives through dynamic analysis. Compared with methods that rely on pure dynamic analysis, the present invention is better in terms of resource usage and performance overhead. BRIEF DESCRIPTION OF THE DRAWINGS

[0038] Figure 1 The figure is a flowchart of the NPM malware package detection method based on the behavior analysis and matching of the graph model of the present invention.

[0039] Figure 2 Schematic diagram of the conversion from program behavior graph to suspicious behavior graph. DETAILED DESCRIPTION

[0040] The following is a process of determining whether a given NPM package contains malicious code. Figure 1 , as follows:

[0041] (1) After inputting the NPM software package to be detected, the configuration file package.json in the software package is first processed, and the installation scripts in the three fields of preinstall, install, and postinstall are specifically analyzed. The execution file entry of the software package in the installation and import stages is analyzed through regular expressions, and the script is judged using a large model to determine whether the script has malicious behavior. The prompt words used to determine whether the script is malicious are as shown in Table 1 below:

[0042] Table 1

[0043]

[0044] (2) Perform obfuscation detection on the code. The obfuscation detection features are composed of the semantic information and syntactic features of the code. The semantic information features include the number of code lines, the number of blank characters, the number of obfuscated identifiers, etc. The syntactic features are extracted based on the AST sequence and n-grams model. The detection process is based on the trained binary classifier, and the model used is the random forest. If obfuscation is detected, it is considered that malicious code has been detected.

[0045] (3) If the software package does not contain obfuscated code, generate a suspicious program behavior graph corresponding to the installation, import, and runtime of the software package. The sample code snippet in the software package to be detected is shown in Appendix 1. Generate a corresponding program behavior graph for the code, identify and locate sensitive APIs, and construct a suspicious program behavior graph based on the sensitive APIs identified and located and their edge relationships in the program behavior graph. Figure 2 , the left side of the figure shows the program behavior graph corresponding to the code sample, and the right side shows the conversion of the program behavior graph to the sensitive behavior graph. The blue edges represent the control flow relationship (i.e., the logical execution order). For example, in the left figure, http.get points to fs.createWriteStream through the control flow, then points to flemished.on, and finally connects to fs.chmod and child_process.exec. The red edges represent data dependencies. For example, the data of flemished.on in the left figure depends on http.get, while the data of neroli.write depends on fs.createWriteStream. In the suspicious behavior graph, only nodes related to sensitive APIs are retained. The edge type in the suspicious behavior graph is derived based on the combination of control flow and data dependency in the program behavior graph. By utilizing the transitivity of the edge type, the relationship between these APIs is intuitively represented. After the suspicious behavior graph is converted, the suspicious behavior graph is matched with the known malicious behavior graph to detect possible malicious behaviors.

[0046] (4) For malicious behavior graphs that are partially matched, additional analysis is required. By inserting custom code before the API to be analyzed, the parameters of its actual runtime are obtained. The code is shown in Appendix 2. Line 10 shows the code for API hooking, which is used to capture the specific parameter values ​​of the function in actual operation. Subsequently, based on dynamic analysis, the specified parameter content is extracted from the execution log, and these parameters are combined with the API type and handed over to the large model for judgment to further determine whether there is malicious behavior. The prompt words used for sensitive file reading analysis are shown in Table 2 below.

[0047]

[0048] Through the above four steps, malicious behavior detection can be performed on the software package to be detected, and the specific location of the malicious code in the file can be located. This detection tool can effectively identify NPM malware packages, reduce the required manpower, and reduce the potential harm caused by malicious code to downstream software.

[0049] (5) The experimental data set consists of the collected open source malware packages and the top 5000 NPM non-malware packages with high download volume, among which the malware packages include 244 unobfuscated malware packages and 120 obfuscated malware packages. The experiment adopts ten-fold cross validation as the evaluation method, and uses precision, recall and F1 value as evaluation indicators. The experiment compares 4 NPM malware package detection tools. The specific results are shown in Table 3 below, among which SpiderScan is the tool corresponding to the present invention.

[0050] tool Accuracy Recall F1 value GuardDog 57.1％ 59.9％ 58.5％ SAP 95.4％ 48.7％ 64.2％ AMALFI 73.1％ 72.9％ 72.8％ CEREBRO 88.1％ 80.7％ 84.2％ SpiderScan 96.5％ 89.7％ 92.9％ .

[0051] The tool corresponding to the present invention achieved the highest F1 value, which was 8.7% to 34.4% higher than other tools, fully demonstrating its superiority in NPM malware package detection.

[0052] Attachment 1, sample code snippet of the software package to be tested

[0053]

[0054] Attachment 2, API hook code

[0055]

[0056] References

[0057] [1].Synopsys.2024.Open Source Security and Risk AnalysisReport.Retrieved May 20,2024fromhttps: / / www.synopsys.com / software-integrity / open-source-security-risk-analysis-report.

[0058] [2].GitHub Inc.2023.The state of open source and rise of AI in2023.Retrieved May 20,2024

[0059] from https: / / github.blog / 2023-11-08-the-state-of-open-source-and-ai / .

[0060] [3].Yacong Gu,Lingyun Ying,Yingyuan Pu,Xiao Hu,Huajun Chai,RuiminWang,Xing Gao,andHaixin Duan.2023.Investigating package related securitythreats in software registries.InProceedings of the IEEE Symposium onSecurity and Privacy.1578-1595.

[0061] [4].Piergiorgio Ladisa,Henrik Plate,Matias Martinez,and OlivierBarais.2023.Sok:Taxonomy ofattacks on open-source software supply chains.InProceedings of the IEEE Symposium onSecurity and Privacy.1509-1526.

[0062] [5].OpenSSF.2023.2023 OpenSSF Annual Report.Retrieved May 20,2024fromhttps: / / openssf.org / download-the-2023-openssf-annual-report /

[0063] [6].Sonatype.2023.State of the Software Supply Chain.Retrieved May20,2024 fromhttps: / / www.sonatype.com / state-of-the-software-supply-chain / introduction

[0064] [7].Xinyuan Wang.2021.On the feasibility of detecting software supplychain attacks.InProceedings of the IEEE Military CommunicationsConference.458-463.

[0065] [8].Fortinet.2023.Malicious Packages Hidden in NPM.Retrieved May 20,2024 fromhttps: / / www.fortinet.com / blog / threat-research / malicious-packages-hiddin-in-npm

[0066] [9].Wenbo Guo,Zhengzi Xu,Chengwei Liu,Cheng Huang,Yong Fang,and YangLiu.2023.AnEmpirical Study of Malicious Code In PyPI Ecosystem.In Proceedingsof the 38th IEEE / ACMInternational Conference on Automated SoftwareEngineering.166-177.

[0067]

[10] .The Hacker News.2023.116 Malware Packages Found on PyPIRepository InfectingWindows and Linux Systems.Retrieved May 20,2024fromhttps: / / thehackernews.com / 2023 / 12 / 116-malware-packages-found-on-pypi.html

[0068]

[11] .Marc Ohm,Henrik Plate,Arnold Sykosch,and MichaelMeier.2020.Backstabber’s knifecollection:A review of open source softwaresupply chain attacks.In Proceedings of the 17thInternational Conference onDetection of Intrusions and Malware,and Vulnerability Assessment.23-43.

[0070]

[12] .Ruturaj K Vaidya,Lorenzo De Carli,Drew Davidson,and VaibhavRastogi.2019.Securityissues in language based software ecosystems.arXivpreprint arXiv:1903.02613(2019).

[0071]

[13] .Xiaoyan Zhou,Feiran Liang,Zhaojie Xie,Yang Lan,Wenjia Niu,Jiqiang Liu,HainingWang,and Qiang Li.2024.A Large-scale Fine-grained Analysisof Packages in Open-SourceSoftware Ecosystems.arXiv preprint arXiv:2404.11467(2024).

[0072]

[14] .Ruian Duan,Omar Alrawi,Ranjita Pai Kasturi,Ryan Elder,BrendanSaltaformaggio,andWenke Lee.2020.Towards measuring supply chain attacks onpackage managers for interpretedlanguages.In Proceedings of the 28th AnnualNetwork and Distributed System SecuritySymposium.

[0073]

[15] .Marc Ohm,Lukas Kempf,Felix Boes,and Michael Meier.2022.TowardsDetection ofMalicious Software Packages Through Code Reuse by MalevolentActors.Gesellschaft fürInformatik,Bonn.

[0074]

[16] .Adriana Sejfia and Max 2022.Practical automated detectionof malicious npmpackages.In Proceedings of the 44th International Conferenceon Software Engineering.1681-1692.

[0076]

[17] .Junan Zhang,Kaifeng Huang,Bihuan Chen,Chong Wang,Zhenhao Tian,and Xin Peng.

[0077] 2023.Malicious Package Detection in NPM and PyPI using a Single Modelof MaliciousBehavior Sequence.arXiv preprint arXiv:2309.02637(2023).

[0078]

[18] .Nusrat Zahan,Philipp Burckhardt,Mikola Lysenko,FerossAboukhadijeh,and LaurieWilliams.2024.Shifting the Lens:Detecting Malware innpm Ecosystem with Large LanguageModels.arXiv preprint arXiv:2403.12196(2024).

[0079]

[19] .Joern.2019.Joern-The Bug Hunter’s Workbench.Retrieved May 20,2024 fromhttps: / / joern.io / 。

Claims

1. A method for detecting NPM malware packages based on behavioral analysis and matching of a graph model, including an offline phase and a deployment phase; the deployment phase is divided into three phases: installation, import, and operation; the characteristics are: First, we use static analysis technology to build a program behavior graph with sensitive APIs as nodes and data dependencies and control flows as edges. Sensitive APIs are automatically identified through a large model. Then, we collect information about NPM malware packages from multiple information sources to form a data set. In the offline stage, for the existing malware packages, a suspicious behavior graph of the program is constructed, and the malicious behavior graph is obtained by manual cutting; In the deployment phase, the NPM software package to be detected is input, and the installation script contained in its configuration file is first analyzed to identify whether there is malicious behavior, and the entry of the execution file in the installation phase and the import phase is determined; then, the code file is obfuscated and detected, and for the software package that does not contain obfuscated code, suspicious behavior graphs of the program in the three phases of installation, import and operation are generated respectively, and matched with the known malicious behavior graphs generated in the offline phase to detect malicious behavior; For specific malicious behaviors that match, based on dynamic analysis, the API hook method is used to obtain the parameter content of the specified API, and combined with the API type, it is handed over to the big model for further malicious behavior judgment; The specific steps are as follows: (1) Static analysis technology is used to construct a suspicious program behavior graph with sensitive APIs as nodes and data dependencies and control flows as edges. The identification of sensitive APIs is obtained by automatic identification and classification by a large model; Using static analysis tools, given the execution entry of a program, a behavior graph of the program is generated. Based on the behavior graph, sensitive APIs are identified and located. These APIs can be divided into built-in APIs and third-party APIs according to their types. Next, based on the identified sensitive APIs, a suspicious behavior graph of the program is constructed. In the suspicious behavior graph, each node corresponds to a sensitive API, and the edges in the graph represent the control flow and data dependency between APIs. (ii) Collecting information about NPM malware packages from multiple information sources as a dataset; Specifically, we collect software packages related to the NPM ecosystem from public malware package datasets; collect security intelligence related to the NPM ecosystem from well-known security blogs, and obtain corresponding software packages; (3) In the offline stage, a suspicious behavior graph of the program is constructed for the existing malware package, and the malicious behavior graph is obtained by manual cutting; (IV) In the deployment phase, the NPM software package to be detected is input, and the installation script contained in the configuration file of the software package is first analyzed to determine the entry of the executable file in the installation phase and the import phase, and identify whether there is malicious behavior therein; then, the code file is obfuscated for detection; for software packages that do not contain obfuscated code, a suspicious behavior graph of the program is generated from the three phases of installation, import, and operation, and it is matched with the known malicious behavior graph to detect malicious behavior; for malicious behaviors that are partially matched, the API hooking method is used to extract the parameter content of the specified API from the execution log through dynamic analysis; the parameter content is combined with the API type and handed over to the large model for further malicious behavior judgment.

2. The NPM malware package detection method according to claim 1, characterized in that: Step (1) specifically includes the following sub-steps: (1) Based on the static analysis tool Joern, the control flow information and data dependency contained in the code are analyzed; the control flow information is represented in the form of a control flow graph (CFG), and the data dependency is represented in the form of a data dependency graph (DDG); (2) Given an execution entry, traverse the control flow graph to simulate the execution process of the program and generate the program's behavior graph (PBG). During the traversal process, add the encountered nodes to the program's behavior graph and add corresponding edges to the behavior graph based on the edge information in the original control flow graph and the data dependency graph; (3) Based on the identified and located sensitive APIs and their edge relationships in the program behavior graph, the suspicious behavior graph (SBG) of the program is extracted and constructed. In the SBG, each node corresponds to an identified sensitive API, and the edges represent the control flow relationships and data dependencies between APIs.

3. The NPM malware package detection method according to claim 2, characterized in that: Sub-step (2) of step (1) mainly analyzes and processes four types of nodes, including: Import node: The import statement is used to import modules. When encountering this type of node, analyze the type of the imported module, classify it as a built-in module, a third-party module, or a local module, and record the corresponding alias; Function call node: A function call statement refers to a call to a declared function. When such a node is encountered, the corresponding called function is located according to the call graph (CG). Then, based on the data dependency graph, it is determined whether there is a data dependency related to the function call parameters. If such a dependency exists, the function call node is connected to the called function node through a data dependency edge. If not, they are connected using a control flow edge. API call node: API call statement refers to calling the API provided by built-in modules or third-party dependencies; each API call node is divided into two categories: sensitive or non-sensitive; for identifying sensitive built-in APIs, obtain the official documentation of the API, pre-set the corresponding sensitive behavior type, and then use the big model to classify the official description of the API to identify sensitive APIs; for sensitive third-party APIs, analyze the source code and API comments, and also use the big model to classify, so as to achieve identification of sensitive APIs; for sensitive APIs, the corresponding return value type will also be recorded to assist in the analysis of the API calls involved in the return value; Assignment node: For assignment statements, first analyze the type of the expression on the right side; if the expression on the right side is an API call, further analyze the behavior category and return value type of the API call, and bind this information to the object on the left side of the assignment.

4. The NPM malware package detection method according to claim 3, characterized in that: Step (ii) specifically includes the following sub-steps: (1) Collect malware packages from the public malware package datasets Backstabber's knife collection and MalOSS, and filter out malware packages related to the NPM ecosystem; (2) Collect well-known security websites and obtain security intelligence information related to the NPM ecosystem from the blogs of these websites, including: package name, version number, and release date; based on this information, collect malware packages that have been removed from the local NPM repository cache.

5. The NPM malware package detection method according to claim 4, characterized in that: The specific process of step (three) is as follows: First, prepare the dataset required to generate the malicious behavior graph: Use the NPM malware packages collected in step (2) as a dataset for generating malicious behavior graphs; Use the method in step (1) to generate corresponding suspicious behavior graphs for these malware packages; The suspicious behavior graph may contain sensitive APIs that are not related to malicious behavior. Therefore, these irrelevant API nodes are removed through artificial trimming to obtain the final malicious behavior graph.

6. The NPM malware package detection method according to claim 5, characterized in that: Step (iv) specifically includes the following sub-steps: (1) Take the NPM software package to be detected as input, process the installation script in the configuration file package.json in the software package, and specifically analyze the scripts in the three fields of preinstall, install, and postinstall; analyze the executable file entry of the software package in the installation and import stages based on regular expressions, and use a large model to judge the script to detect whether there is malicious behavior in the script; (2) Malicious code usually uses obfuscation to hide its malicious behavior. In the current step, the obfuscated code is detected. The features of obfuscation detection are composed of the semantic information and syntactic features of the code, where the semantic information features include the number of code lines, the number of blank characters, and the number of obfuscated identifiers. The syntactic features are extracted based on AST sequences and n-grams models. The detection process is based on the trained binary classifier, and the model used is random forest. (3) If the software package does not contain obfuscated code, use the method in step (1) to generate a suspicious behavior graph of the program from the three stages of installation, import, and operation for the software package that does not contain obfuscated code; match the suspicious behavior graph with the malicious behavior graph obtained in step (3) to detect malicious behavior; (4) Perform additional analysis on some of the malicious behaviors detected in step (3), where the API types to be analyzed include file reading and writing, command execution, executable file running, and dynamic function generation; Insert custom code before the API to be analyzed to obtain its actual parameters, and extract the specified parameter content from the execution log based on dynamic analysis; These actual operating parameters are then combined with the API type and submitted to the big model for judgment to further determine whether there is malicious behavior.

Images