CN117708813B - A security detection method and system for software development environment - Google Patents

Abstract

The present invention discloses a security detection method and system for a software development environment, including: blacklist screening of code editor Visual Studio Code plug-ins and browser plug-ins to be detected; static extraction of code behavior of plug-ins not in the blacklist, and use of abstract syntax tree combined with regular expression matching to obtain API call sequences in the code; modeling of malicious plug-in behavior using feature engineering, and static detection of the maliciousness of plug-ins using random forest classifiers; and further classification of plug-ins determined to be malicious using hierarchical classifiers to obtain specific malicious categories. The present invention also provides a system for implementing the above method, which can perform online analysis and local scanning of browser plug-ins and code editor plug-ins in the development environment, and realizes comprehensive security detection of the two types of plug-ins. The present invention can effectively identify and accurately classify malicious behaviors of plug-ins, and provide more comprehensive security protection for software developers.

Description

A security detection method and system for software development environment

Technical Field

The present invention relates to a network security technology, and in particular to a security detection method and system for a software development environment.

Background technique

As the software development ecosystem continues to expand, developer tool plug-ins are increasingly used by developers, and the development environment is becoming more and more complex, making it difficult to ensure the security of the development environment. Attackers can use malicious third-party plug-ins introduced into the software development environment to steal sensitive data in the development environment, resulting in data leakage, and may also cause the developed program to be injected with malicious code, posing a huge security risk. Therefore, detecting malicious plug-ins in the developer's current development environment will help provide security for developers in the development tool link.

In the prior art, there is no method and system for comprehensive scanning and detection of code editor plug-ins and browser plug-ins in the development environment. In terms of browser plug-in security detection, Cisco's Duo Security released CRXcavator, an automated Chrome extension security assessment tool. Users can log in to this platform and retrieve the extension name or extension ID of the Chrome browser extension to obtain the risk index and analysis report of the specified extension. However, there are the following disadvantages: users can only search based on the extension name and ID, and cannot perform online analysis on plug-ins that have not been detected; the platform is highly restricted and cannot detect plug-ins on other platforms; it cannot detect the security of plug-ins in the developer's local environment and cannot provide security for the developer's environment. In terms of malicious JavaScript code detection, Aurore Fass et al. proposed a modular static JavaScript detection system JStap, which uses code control flow and data flow information to expand on the basis of lexical-based and abstract syntax tree-based detection methods, but this detection method can only classify code into malicious and benign, and cannot achieve further accurate classification of specific malicious behaviors of the code.

Summary of the invention

In view of this, the purpose of the present invention is to provide a security detection method and system for a software development environment, which can perform security analysis on the code editor Visual Studio Code (VSCode) plug-in and browser plug-in used by developers; through the combination of abstract syntax tree (AST) and regular expression, API call sequence can be accurately extracted; by modeling the plug-in behavior, the model can efficiently detect malicious plug-ins; through a hierarchical classifier from API to sensitive behavior to malicious plug-in category, multi-classification and accurate detection of malicious plug-ins is achieved, and the specific category of malicious plug-ins can be identified; browser plug-ins and code editor plug-ins in the software development environment can be analyzed online and scanned locally, realizing comprehensive security detection of the two types of plug-ins, and providing security protection for developers.

In order to achieve the above object, the present invention is implemented by the following technical solutions:

A first aspect of the present invention provides a method for detecting the security of a software development environment, comprising the following steps:

S100: For the VSCode plug-in and Web browser plug-in to be detected, blacklist screening is performed to determine whether they are known malicious plug-ins;

S200: For the plug-ins in S100 that are not in the malicious plug-in blacklist, perform static code behavior extraction, and efficiently obtain the API call sequence in the code by using the abstract syntax tree combined with regular expression matching;

S300: Based on the API call sequence extracted in step S200, the malicious plug-in behavior is modeled through feature engineering, and the maliciousness of the plug-in is statically detected using a random forest classifier to classify the plug-in into malicious or benign.

S400: For the plug-in output as malicious in S300, the API call sequence is mapped to specific sensitive behaviors through a hierarchical classifier, and then the malicious plug-in is classified according to the sequence of these behaviors to obtain a malicious plug-in category.

Preferably, in S100, the blacklist-based malicious plug-in detection step specifically includes:

S110: Collecting recognized malicious plug-in data from the Internet, integrating the malicious plug-in information detected and verified by the detection process of the present invention, building a malicious plug-in blacklist, and regularly synchronizing the latest malicious plug-in information to ensure the comprehensiveness and timeliness of the blacklist content;

S120: Use the blacklist constructed in step S110 to query the unique identifier (ID) of the plug-in to be detected. If the ID exists in the blacklist, the plug-in is marked as a malicious plug-in.

Preferably, in S200, the step of statically extracting the plug-in code behavior specifically includes:

S210: first try to parse the source code using an abstract syntax tree, and obtain an API call sequence by traversing the generated abstract syntax tree;

S220: If the generation of the abstract syntax tree fails, regular matching is enabled as a backup solution. First, all sensitive API calls in the source code are identified, and then the API calls are sorted using a specific algorithm.

Preferably, the step of obtaining the API call sequence by using the abstract syntax tree specifically includes:

S211: Use a syntax parser to parse the source code into an abstract syntax tree;

S212: The abstract syntax tree generated by the hierarchical traversal is obtained by obtaining a custom function declaration subtree and a remaining code subtree, and queues them respectively;

S213: Declare a subtree queue for the custom function, perform dequeue operations on it accordingly, and use pre-order traversal to obtain sensitive API calls from the dequeued subtree. If there are calls to custom functions within the custom function and it has been traversed, insert its API call sequence into the API call sequence of the called function; if the called custom function has not been updated, re-queue the subtree. For custom functions whose API call sequence has been obtained, mark them as updated, and this process continues until the API call sequence of all custom functions has been updated;

S214: Dequeue the remaining code subtree queues in turn, and traverse the dequeued subtrees in pre-order to obtain sensitive API calls. If the current node traversed is a call of a custom function, insert the ordered API call sequence of the custom function into the source file API call sequence from the end;

S215: Repeat S213 and S214 until the custom function declaration subtree queue and the remaining code subtree queue are empty, and output the API call sequence.

Preferably, the step of obtaining the API call sequence by using regular matching specifically includes:

S221: Match the text range of the function definition block by using regular matching;

S222: Identify all sensitive API calls in the source file, and sort them according to the relative positions of the texts of the API calls using selection sorting;

S223: adding the API call in the function definition block to the function call sequence corresponding to the user-defined function;

S224: recursively updating the API call sequence of the user-defined function by inserting the sorted API call sequence of the function called in its definition block into its own API call sequence until all the user-defined functions are updated;

S225: removing all API calls located in the function definition block in the API call sequence of the source file;

S226: Identify the call of the custom function in the source file, and insert its API call sequence into the API call sequence of the source file according to its call position.

Preferably, in S300, the static detection step of maliciousness of the plug-in specifically includes:

S310: Based on the analysis of the malicious plug-in sample, a behavior sequence feature is defined for determining whether the plug-in has suspicious behavior. Each feature is an ordered combination of multiple behaviors and represents a specific sensitive behavior.

S320: Mapping the API call sequence extracted in S200 into a behavior sequence feature vector;

S330: Send the feature vector to the trained random forest classifier for prediction. The random forest consists of multiple decision trees, which each evaluates the feature vector and decides the final classification result by voting.

Preferably, the training method of the random forest classifier is:

S331: A dataset was constructed, which includes benign and malicious samples;

S332: Using static analysis methods, extract defined behavior sequence features from the data set to form a behavior feature matrix;

S333: Divide the entire data set into a training set and a test set in a ratio of 8:2 for model training and evaluation;

S334: By randomly sampling the training data set, a decision tree is constructed for each sampled feature set, and each tree is split by selecting the best feature to improve the node purity;

S335: Using a grid search method to traverse the key parameters of the random forest model, including the number of classifiers and the depth of the decision tree, to select the optimal model parameters;

S336: Evaluate the performance of the model on the test set and save the best performing model for future prediction tasks.

The present invention also provides a security detection system for a software development environment, comprising:

User interaction and security situation module: used to provide an interactive interface to search, upload plug-ins to be tested or scan locally installed plug-ins, and display the security status, test results and historical test records of the development environment;

Plugin information acquisition module: used to automatically collect plugin source code on the plugin market or platform to provide a data basis for security analysis;

Client local development environment security detection module: used to run on the user side, automatically scan the specified plug-in installation path, and obtain the VSCode plug-in and browser plug-in installed in the local development environment;

Plugin malicious static detection module: used to extract API call sequences by using abstract syntax trees combined with regular expression matching, and use random forest models to determine the maliciousness of plugins;

Plug-in malicious behavior determination module: used to determine the category of malicious plug-ins. For plug-ins that are initially determined to be malicious, this module uses a hierarchical classifier to map the API call sequence to specific sensitive behaviors, and then classifies the malicious plug-ins according to the order of these behaviors to obtain the malicious plug-in category;

User management module: used to process user registration, login and permission verification, ensuring secure access to personalized security status and historical detection data;

Data storage module: used to store all data, including plug-in information, test results, user configuration and system logs, to ensure data security and integrity.

Compared with the prior art, the beneficial effects of the present invention are as follows: by comprehensively utilizing static code analysis, machine learning classification and hierarchical behavior classification technology, the present invention provides a comprehensive and accurate development environment security detection method. Compared with the prior art, it can more effectively identify malicious plug-ins and realize multi-classification and accurate detection of malicious behavior categories, providing more comprehensive security protection for developers' code editors and browsers.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG1 is an overall flow chart of a first embodiment of the present invention;

2 is a flow chart of obtaining an API call sequence by using an abstract syntax tree in the first embodiment of the present invention;

3 is a flow chart of obtaining an API call sequence by using regular expression matching in the first embodiment of the present invention;

FIG4 is a system structure diagram of a second embodiment of the present invention;

FIG. 5 is a system flow chart of the second embodiment of the present invention.

Detailed ways

The specific implementation of the present invention is further described in detail below in conjunction with the accompanying drawings and specific implementations. The following examples or drawings are used to illustrate the present invention, but are not used to limit the scope of the present invention.

Embodiment 1:

A method for detecting the security of a software development environment, as shown in FIG1 , comprises the following steps:

S100: For the VSCode plug-in and Web browser plug-in to be detected, blacklist screening is performed to determine whether they are known malicious plug-ins.

In one embodiment, the S100 includes the following steps:

S110: Collecting recognized malicious plug-in data from the Internet, integrating the malicious plug-in information detected and verified by the detection process of the present invention, building a malicious plug-in blacklist, and regularly synchronizing the latest malicious plug-in information to ensure the comprehensiveness and timeliness of the blacklist content.

The sources of Internet malicious plug-in data collection include samples publicly disclosed by well-known security companies Snyk, Kaspersky and Threatmon. Compared with the existing solutions, this embodiment not only collects data from multiple aspects on the Internet, but also adds malicious plug-in data detected and confirmed during the VSCode and browser plug-in detection process of this embodiment to the publicly disclosed data on the Internet, which can better solve the problems of incomplete coverage, narrow description angle, insufficient description content and untimely data update of a single data source.

S120: Using the blacklist constructed in step S110, query the unique identifier (ID) of the plug-in to be detected. If the ID exists in the blacklist, the plug-in is marked as a malicious plug-in.

S200: For the plug-ins in S100 that are not in the malicious plug-in blacklist, perform static code behavior extraction, and efficiently obtain the API call sequence in the code by using the abstract syntax tree combined with regular expression matching.

Specifically, the strategy of "abstract syntax tree as the main method and regular expression matching as the auxiliary method" is adopted in this embodiment to make full use of the advantages of abstract syntax tree in performing precise syntax analysis and identifying sensitive API calls. Due to the diversity of JavaScript syntax and the inherent limitations of parsing tools, when conventional syntactic analysis encounters obstacles, regular expression matching is used as an effective supplement to make up for the shortcomings of abstract syntax tree in parsing certain complex grammatical structures. Compared with the prior art, the method of extracting API call sequences in this embodiment ensures wide compatibility with various coding styles and patterns, can handle continuous iterations and recursion, and further enhances the analysis capabilities of nested and complex function structures.

In one embodiment, the S200 includes the following steps:

S210: First, try to parse the source code using an abstract syntax tree, and obtain the API call sequence by traversing the generated abstract syntax tree.

In the process of traversing the abstract syntax tree, considering that the API call nodes in the function declaration block will not be executed at the location where they are declared, the subtrees are divided into two categories when parsing the abstract syntax tree: one subtree specifically represents the custom function declaration block, and the remaining subtrees are classified as the second subtree. The API call sequence obtained by traversing the second subtree represents the API call sequence of the code under actual execution. For the processing of custom functions, the custom function subtree is traversed in the same traversal order as the second subtree, the ordered API call sequence of the custom function is updated, and inserted into the sorted API call sequence when it is called.

Referring to FIG. 2 , in one embodiment, the method of obtaining an API call sequence using an abstract syntax tree includes the following steps:

S211: Use a syntax parser to parse the source code into an abstract syntax tree.

Specifically, the syntax parser is Esprima, a popular, high-performance ECMAScript parser.

S212: The abstract syntax tree generated by the hierarchical traversal obtains the custom function declaration subtree and the remaining code subtree, and queues them respectively.

S213: declare a subtree queue for the custom function, perform dequeue operations on it in turn, and use pre-order traversal to traverse the dequeued subtree to obtain sensitive API calls; if there are calls to custom functions within the custom function and it has been traversed, insert its API call sequence into the API call sequence of the called function; if the called custom function has not been updated, re-queue the subtree; for the custom function whose API call sequence has been obtained, mark it as updated, and this process continues until the API call sequence of all custom functions has been updated.

S214: Dequeue the remaining code subtree queues in turn, and traverse the dequeued subtrees in pre-order to obtain sensitive API calls. If the current node traversed is a call of a custom function, insert the ordered API call sequence of the custom function into the source file API call sequence from the back.

S215: Repeat S213 and S214 until the custom function declaration subtree queue and the remaining code subtree queue are empty, and output the API call sequence.

S220: If the generation of the abstract syntax tree fails, regular matching is enabled as a backup solution. First, all sensitive API calls in the source code are identified, and then the API calls are sorted using a specific algorithm.

Referring to FIG. 3 , in one embodiment, the method of obtaining an API call sequence by using regular expression matching includes the following steps:

S221: Match the text range of the function definition block using a regular matching method.

S222: Identify all sensitive API calls in the source file, and sort them according to the relative positions of the texts of the API calls using selection sorting.

S223: Add the API call in the function definition block to the function call sequence corresponding to the user-defined function.

S224: recursively update the API call sequence of the user-defined function by inserting the sorted API call sequence of the function called in its definition block into its own API call sequence until all user-defined functions are updated.

S225: Remove all API calls located in the function definition block from the API call sequence of the source file.

S226: Identify the call of the custom function in the source file, and insert its API call sequence into the API call sequence of the source file according to its call position.

S300: Based on the API call sequence extracted in step S200, the malicious plug-in behavior is modeled through feature engineering, and the maliciousness of the plug-in is statically detected using a random forest classifier, and the plug-in is classified into malicious and benign.

In the actual production environment, the proportion of malicious plug-ins is extremely low. Therefore, static detection can be used to make preliminary malicious judgments on the plug-ins and quickly exclude most normal plug-ins, which can reduce a lot of resource consumption and detection delays and improve detection efficiency.

In one embodiment, the static detection of plugin maliciousness includes the following steps:

S310: Based on the analysis of malicious plug-in samples, a behavior sequence feature is defined for determining whether the plug-in has suspicious behavior. Each feature is an ordered combination of multiple behaviors and represents a specific sensitive behavior.

For example, a feasible behavior sequence feature includes: sending sensitive information, querying system environment variables, downloading content and executing, writing files and executing, reading file content and executing, reading files and dynamically executing code, modifying file permissions and creating processes, identifying operating system platforms, modifying the data flow of system command execution results, executing system commands, and performing sensitive file operations. Each behavior sequence feature is a combination of multiple behaviors. For example, the behavior sequence of sending sensitive information includes two behaviors: first, accessing sensitive information, and then sending network requests.

S320: Map the API call sequence extracted in S200 into a behavior sequence feature vector.

S330: Send the feature vector to the trained random forest classifier for prediction. The random forest consists of multiple decision trees, which each evaluates the feature vector and decides the final classification result by voting.

Preferably, the training method of the random forest classifier is:

S331: A dataset was constructed, which contains both benign and malicious samples.

Specifically, a feasible method for constructing a dataset is to select malicious samples from the malicious plug-in information disclosed by well-known security companies Snyk, Kaspersky, and Threatmon, and select samples with large downloads and high user ratings from the official plug-in market rankings as benign samples.

S332: Using static analysis methods, defined behavior sequence features are extracted from the data set to form a behavior feature matrix.

S333: Divide the entire dataset into training set and test set in a ratio of 8:2 to facilitate model training and evaluation.

S334: By randomly sampling the training data set, a decision tree is constructed for each sampled feature set, and each tree is split by selecting the best feature to improve the node purity.

S335: A grid search method is used to traverse the key parameters of the random forest model, including the number of classifiers and the depth of the decision tree, to select the optimal model parameters.

S336: Evaluate the performance of the model on the test set and save the best performing model for future prediction tasks.

Specifically, in this embodiment, the model file is saved in the format of Joblib.

S400: For the plug-in output as malicious in S300, the API call sequence is mapped to specific sensitive behaviors through a hierarchical classifier, and then the malicious plug-in is classified according to the sequence of these behaviors to obtain a malicious plug-in category.

Specifically, the hierarchical classifier has three layers, from top to bottom, namely malicious plug-in category, sensitive behavior category and sensitive API.

For the malicious plug-in category, through the study of existing malicious plug-in reports and manual analysis of malicious samples, a feasible malicious plug-in behavior classification is: sensitive information theft, sensitive file operation, malicious command execution, code injection, ad injection, and browser hijacking.

The behavior of malicious plug-ins is composed of a series of sensitive behaviors. This embodiment associates the category of malicious plug-ins with the corresponding sensitive behavior sequence. For example, the sensitive information theft category follows the behavior sequence of "first access sensitive information, then send it over the network". A feasible sensitive behavior category is defined as: network sending, network downloading, file reading, file deletion, file modification, file creation, code execution, system command execution, external program execution, process information, system information acquisition, and sensitive file operation.

The realization of sensitive behaviors is inseparable from API calls. This embodiment associates sensitive behavior sequences with sensitive API call sequences. A feasible sensitive API definition method is to use the APIs collected in existing research and combine them with the analysis of malicious samples to define APIs that can be used for malicious purposes.

Embodiment 2:

A security detection system for a software development environment, as shown in FIG4 , includes the following modules:

User interaction and security situation module: used to provide an interactive interface to search, upload plug-ins to be tested or scan locally installed plug-ins, and display the security status, test results and historical test records of the development environment.

Plug-in information acquisition module: used to automatically collect plug-in source code on the plug-in market or platform to provide a data basis for security analysis.

Client local development environment security detection module: used to run on the user side, automatically scan the specified plug-in installation path, and obtain the VSCode plug-in and browser plug-in installed in the local development environment.

Plugin malicious static detection module: used to extract API call sequences by using abstract syntax trees combined with regular expression matching, and use random forest models to determine the maliciousness of plugins.

Plug-in malicious behavior determination module: used to determine the category of malicious plug-ins. For plug-ins that are initially determined to be malicious, this module uses a hierarchical classifier to map the API call sequence to specific sensitive behaviors, and then classifies the malicious plug-ins according to the order of these behaviors to obtain the malicious plug-in category.

User management module: used to process user registration, login and permission verification, ensuring secure access to personalized security status and historical detection data.

Data storage module: used to store all data, including plug-in information, test results, user configuration and system logs, to ensure data security and integrity.

The flow chart of the use of this system is shown in Figure 5, which has the following steps:

Step 1: The user logs in to the detection website homepage and selects the detection method. For example, the user can select the input box to search for plug-ins, upload plug-in compressed packages, or scan local plug-ins.

Step 2: Execute corresponding processing according to the detection method selected by the user.

Step 2.1: If the user chooses to search for a plug-in in the input box, the database will be queried based on the plug-in name or plug-in URL entered. If the plug-in already exists in the database, the plug-in information saved in the database will be directly output. If the plug-in does not exist in the database, the plug-in compressed package will be downloaded through a web crawler and the next step will be entered.

Step 2.2: If the user chooses to upload a plug-in compressed package, enter the plug-in compressed package into the next step.

Step 2.3: If the user chooses to scan local plug-ins, the user downloads the local scanning program, performs a local environment plug-in scan, and queries whether the scanned plug-in exists in the database. If it already exists in the database, the plug-in information saved in the database is directly output. If it does not exist in the database, the plug-in compression package is entered into the next step.

Step 3: For the input plug-in compressed package, the plug-in malicious static detection module is used to preliminarily classify the plug-in into malicious and benign, and the plug-in preliminarily classified as malicious is input to the next step.

Step 4: For the plug-ins that are initially classified as malicious, the plug-in malicious behavior determination module is used to classify the malicious plug-ins into sensitive information theft, sensitive file operation, malicious command execution, code injection, ad injection, and browser hijacking.

Step 5: Display the test results to the user and store them in the database.

It should be noted that the system specifically implements the detection method described in detail in Example 1 and integrates it into the automated process, thereby improving the detection efficiency and user interactivity. In addition, the design of the system allows for flexible expansion and updating to adapt to new security threats and plug-in features.

Those skilled in the art should be aware that the embodiments described in the specification are all preferred embodiments and should not be regarded as excluding other embodiments. Those skilled in the art may modify the actions and processes involved in the present embodiment. Any modifications within the spirit and scope of the present invention should be included in the scope of protection of the claims attached to the present invention.

Claims (5)

1. A method for detecting the security of a software development environment, comprising the following steps: S100: For the Visual Studio Code plug-in and Web browser plug-in to be detected, blacklist screening is performed to determine whether they are known malicious plug-ins; S200: For the plug-ins in S100 that are not in the malicious plug-in blacklist, perform static code behavior extraction, and efficiently obtain the API call sequence in the code by using the abstract syntax tree combined with regular expression matching; The S200 includes the following steps: S210: first try to parse the source code using an abstract syntax tree, and obtain the API call sequence by traversing the generated abstract syntax tree; S220: If the generation of the abstract syntax tree fails, regular matching is enabled as a backup solution, first identifying all sensitive API calls in the source code, and then sorting the API calls using a specific algorithm; The S210 includes the following steps: S211: Use a syntax parser to parse the source code into an abstract syntax tree; S212: The abstract syntax tree generated by the hierarchical traversal is obtained to obtain the custom function declaration subtree and the remaining code subtree, and they are queued respectively; S213: Declare a subtree queue for the custom function, perform dequeue operations on it in turn, and use pre-order traversal to obtain sensitive API calls from the dequeued subtrees; if there are calls to custom functions in the custom function and the traversal has been completed, insert its API call sequence into the API call sequence of the called function; if the called custom function has not been updated, re-queue the subtree; for the custom function whose API call sequence has been obtained, mark it as updated, and this process continues until the API call sequence of all custom functions has been updated; S214: Dequeue the remaining code subtree queues in turn, and traverse the dequeued subtrees in pre-order to obtain sensitive API calls. If the current node traversed is a call of a custom function, insert the ordered API call sequence of the custom function into the source file API call sequence from the end; S215: repeat S213 and S214 until the custom function declaration subtree queue and the remaining code subtree queue are empty, and output the API call sequence; The S220 includes the following steps: S221: Match the text range of the function definition block by using regular matching; S222: Identify all sensitive API calls in the source file, and sort them according to the relative positions of the texts of the API calls using selection sorting; S223: adding the API call in the function definition block to the function call sequence corresponding to the user-defined function; S224: recursively updating the API call sequence of the user-defined function by inserting the sorted API call sequence of the function called in its definition block into its own API call sequence until all the user-defined functions are updated; S225: removing all API calls located in the function definition block in the API call sequence of the source file; S226: Identify the call of the custom function in the source file, and insert its API call sequence into the API call sequence of the source file according to its call position; S300: Based on the API call sequence extracted in step S200, the malicious plug-in behavior is modeled through feature engineering, and the maliciousness of the plug-in is statically detected using a random forest classifier to classify the plug-in into malicious or benign. S400: For the plug-in output as malicious in S300, the API call sequence is mapped to specific sensitive behaviors through a hierarchical classifier, and then the malicious plug-in is classified according to the sequence of these behaviors to obtain a malicious plug-in category. 2. The method for detecting the security of a software development environment according to claim 1, wherein S100 comprises the following steps: S110: Collecting recognized malicious plug-in data from the Internet, integrating malicious plug-in information detected and verified through the detection process, building a malicious plug-in blacklist, and regularly synchronizing the latest malicious plug-in information to ensure the comprehensiveness and timeliness of the blacklist content; S120: Use the blacklist constructed in step S110 to query the unique identifier ID of the plug-in to be detected. If the ID exists in the blacklist, the plug-in is marked as a malicious plug-in. 3. The method for detecting the security of a software development environment according to claim 1, wherein S300 comprises the following steps: S310: Based on the analysis of the malicious plug-in sample, a behavior sequence feature is defined for determining whether the plug-in has suspicious behavior, where each feature is an ordered combination of multiple behaviors and represents a specific sensitive behavior; S320: Mapping the API call sequence extracted in S200 into a behavior sequence feature vector; S330: Send the feature vector to the trained random forest classifier for prediction. The random forest consists of multiple decision trees, which each evaluates the feature vector and decides the final classification result by voting. 4. The method according to claim 3, characterized in that the training method of the random forest classifier comprises the following steps: S331: A dataset was constructed, which includes benign and malicious samples; S332: Using static analysis methods, extract defined behavior sequence features from the data set to form a behavior feature matrix; S333: Divide the entire dataset into training set and test set in a ratio of 8:2 to facilitate model training and evaluation; S334: By randomly sampling the training data set, a decision tree is constructed for each sampled feature set, and each tree is split by selecting the best feature to improve the node purity; S335: Using a grid search method to traverse the key parameters of the random forest model, including the number of classifiers and the depth of the decision tree, to select the optimal model parameters; S336: Evaluate the performance of the model on the test set and save the best performing model for future prediction tasks. 5. A security detection system for a software development environment, used to implement the security detection method for a software development environment according to any one of claims 1 to 4, comprising: User interaction and security situation module: used to provide an interactive interface to search, upload plug-ins to be tested or scan locally installed plug-ins, and display the security status, test results and historical test records of the development environment; Plugin information acquisition module: used to automatically collect plugin source code on the plugin market or platform to provide a data basis for security analysis; Client local development environment security detection module: used to run on the user side, automatically scan the specified plug-in installation path, and obtain the Visual Studio Code plug-in and browser plug-in installed in the local development environment; Plugin malicious static detection module: used to extract API call sequences by using abstract syntax trees combined with regular expression matching, and use random forest models to determine the maliciousness of plugins; Plug-in malicious behavior determination module: used to determine the category of malicious plug-ins. For plug-ins that are initially determined to be malicious, this module uses a hierarchical classifier to map the API call sequence to specific sensitive behaviors, and then classifies the malicious plug-ins according to the order of these behaviors to obtain the malicious plug-in category; User management module: used to process user registration, login and permission verification, ensuring secure access to personalized security status and historical detection data; Data storage module: used to store all data, including plug-in information, test results, user configuration and system logs, to ensure data security and integrity.