An automated penetration testing method, device and medium based on expression language and high concurrency scanning

Abstract

The application discloses an automatic penetration testing method and device based on expression language and high-concurrency scanning and a medium, and mainly relates to the technical field of penetration testing, and aims to solve the problems of long time consumption, multiple combination tools depending on fragmentation, and lack of flexibility of vulnerability detection rule engine in the prior art. The application comprises the following steps: constructing a front-end and back-end separated system architecture; a back-end service layer delivers task metadata to a message queue; an external network module and an internal network module of a penetration testing engine subscribe or poll a database from the message queue to obtain tasks; the external network module replaces POC template variables with actual parameter values in an execution context, generates a structured request and sends it in parallel, performs normalization processing after receiving a response, executes a precompiled CEL expression in a restricted sandbox and calls a custom function in a preset function library to obtain a vulnerability verification result; and a dynamically scalable pool of the internal network module sequentially obtains subtasks from a local bounded job queue to execute and obtain a vulnerability verification result.

Description

Technical Field

[0001] This application relates to the field of automated penetration testing technology, and in particular to an automated penetration testing method, device and medium based on expression language and high-concurrency scanning. Background Technology

[0002] With the deepening of digital transformation, the Internet, the Internet of Things (IoT), and cloud computing technologies are being widely applied, leading to a surge in cyberattacks characterized by high frequency, complex methods, and significant destructiveness. Cybersecurity is no longer merely a technical issue but has become a strategic core issue concerning economic development, social stability, and national security. Against this backdrop, the industry urgently needs forward-looking, user-friendly, and comprehensive solutions to effectively address increasingly complex cyber threats.

[0003] However, existing penetration testing tools have several limitations. First, traditional scanning tools lag behind in concurrent processing capabilities, resulting in slow scanning speeds and long processing times when facing large-scale internal network assets, failing to meet the demands of modern penetration testing for efficient response. Second, existing tools often rely on fragmented combinations to complete tasks such as scanning, vulnerability verification, and report generation. Inconsistent data formats and poor interoperability between different tools lead to cumbersome workflows and difficulties in information integration. Third, vulnerability detection rule engines are often hard-coded or complexly configured, lacking flexibility. When facing new vulnerabilities or specific business logic, they require waiting for vendor updates or complex secondary development, resulting in long response cycles and high barriers to entry. Finally, most tools rely primarily on command-line interfaces, lacking a unified and intuitive graphical user interface, requiring high technical skills from users and hindering their promotion and application. Summary of the Invention

[0004] This application provides an automated penetration testing method, device, and medium based on expression language and high-concurrency scanning to solve four core problems in the prior art: low scanning efficiency, lagging rule updates, fragmented toolchains, and security vulnerabilities in the execution environment. It provides a penetration testing technical solution that can dynamically define detection logic, support high-concurrency scheduling, automate the entire process, and has a secure execution environment.

[0005] Firstly, an automated penetration testing method based on expression language and high-concurrency scanning, the method comprising:

[0006] Construct a system architecture that separates the front-end and back-end; the system architecture includes a front-end view layer, a back-end service layer, and a penetration testing engine, and the penetration testing engine includes an external network module and an internal network module;

[0007] The front-end view layer submits the scanning task and parameter file to the back-end service layer. After receiving the task and parameter file, it writes the task metadata to the database and simultaneously delivers the task metadata to the message queue.

[0008] The penetration testing engine's external network module and internal network module subscribe to or poll the database to retrieve tasks. After retrieving a task, they load preset auxiliary data and generate an execution context. The target network segment in the execution context is divided into several sub-network blocks according to a dynamic sharding strategy. Based on the list of high-risk ports in the execution context, the preset high-risk ports involved in the sub-network blocks are preferentially placed into the local bounded job queue. The auxiliary data includes historical scan records, service or application fingerprint information, historical vulnerability detection results, and port risk level information in the asset database. This data is used to enrich the target's attribute information and provide a basis for subsequent task priority allocation and scanning strategy selection.

[0009] The external network module generates structured requests based on the actual parameter values ​​in the execution context and sends them concurrently. After receiving the response, it executes the pre-compiled CEL expression corresponding to the response in a restricted sandbox to obtain the vulnerability verification result. The internal network module retrieves subtasks from the local bounded job queue in sequence and executes them to obtain the vulnerability verification result.

[0010] The backend service layer preprocesses the vulnerability verification results returned by the external network module and the internal network module; the standardized results after preprocessing are pushed to the frontend view layer for real-time display.

[0011] In one implementation of this application, a front-end and back-end separated system architecture is constructed, specifically including:

[0012] The front-end view layer is built on Vue + TypeScript, configuring a task creation panel, project management, real-time log and result display modules, integrating a WebSocket / SSE client to receive real-time progress, and interacting with the back-end service layer through HTTP requests;

[0013] The backend service layer is built using the FastAPI framework, which provides RESTful API interfaces to receive tasks and parameter files from the frontend view layer. Pydantic is used for parameter validation, and unique records of tasks are generated and written to the database. Tasks are delivered to message queues as needed to support distributed scheduling. Asynchronous database operations are implemented using SQLAlchemyORM.

[0014] A penetration testing engine was created. The external network module is based on Python combined with CEL expressions, extending custom functions and building a restricted sandbox to execute vulnerability judgment logic. The internal network module is built with a daemon process in Golang, and a Goroutine pool and channel communication architecture are set up. The Work-Stealing algorithm and connection reuse strategy are incorporated. Dynamic sharding + high-risk port priority + Work-Stealing scheduling are adopted. In actual tests, the scanning time of tens of thousands of IPs was reduced by more than 50%.

[0015] In one implementation of this application, the front-end view layer submits a scanning task and parameter file to the back-end service layer. After receiving the task and parameter file, it writes the task metadata to the database and simultaneously posts the task metadata to a message queue. Specifically, this includes:

[0016] The scanning task and parameter file are obtained through the task configuration panel and file upload entry provided by the front-end view layer. The scanning task and parameter file are then submitted to the back-end service layer by calling the back-end interface via an HTTP request.

[0017] After receiving the request, the backend interface performs field format validation and semantic validation on the input data; after the field format validation and semantic validation are successful, it automatically completes the timestamp conversion and parameter completion.

[0018] A unique task_id is generated, and standardized task metadata is constructed based on the verified data. The metadata includes the task_id, user configuration parameters in the scanning task, verification completion information, initial task status, and creation timestamp. The verification completion information is automatically supplemented by filling in missing or incomplete fields after verifying the legality of the scanning task parameters submitted by the user. It includes a standardized representation of the target address range, default port or port policy, scanning policy parameters, and task priority, etc., which explain the verification completion information.

[0019] The backend service layer performs asynchronous database operations and writes normalized metadata into the Task table;

[0020] Depending on the system's operating mode, the backend service layer synchronously or asynchronously delivers task metadata to the message queue and configures consumption parameters;

[0021] The backend service layer returns the task_id and initial task status to the frontend view layer in a non-blocking manner.

[0022] In one implementation of this application, the external network module and internal network module of the penetration testing engine subscribe to or poll tasks from a message queue or a database. After receiving a task, they load preset auxiliary data and generate an execution context. The auxiliary data includes historical scan records, service or application fingerprint information, historical vulnerability detection results, and port risk level information from the asset database. This data is used to enrich the target's attribute information and provide a basis for subsequent task priority allocation and scanning strategy selection. The target network segment in the execution context is divided into several sub-network blocks according to a dynamic sharding strategy. Based on the list of high-risk ports in the execution context, the preset high-risk ports involved in the sub-network blocks are preferentially placed into the local bounded job queue. Specifically, this includes:

[0023] Configure two types of nodes in the penetration testing engine execution layer: Python workers for the external network module and Golang daemons for the internal network module;

[0024] After a node receives a task, it retrieves the target's historical port liveness records and last scan time from the asset database; loads the service application fingerprint template from the fingerprint database; extracts vulnerability hit and false alarm records from the historical results database; and merges external intelligence with blacklists and whitelists.

[0025] Expand and filter the target set, remove blacklisted IPs, retain preset high-activity targets according to historical liveness status, and merge target metadata; filter out a suitable POC rule list based on fingerprint and port information; extract a preset high-risk port list from vulnerability hit and false alarm records from the historical results database; inject task execution constraints to form an execution context; among them, task execution constraints include dynamic sharding strategies;

[0026] Extract the target network segment, dynamic sharding strategy, and preset high-risk port list from the execution context; divide the target network segment into several sub-network blocks according to the dynamic sharding strategy; for each sub-network block, extract the detection requirements involving preset high-risk ports, generate preset high-priority subtasks, and push them to the front end of the local bounded job queue; after the subtasks are enqueued, synchronously write the metadata to the database.

[0027] In one implementation of this application, the external network module generates structured requests based on the actual parameter values ​​in the execution context and sends them concurrently. After receiving the response, it executes the pre-compiled CEL expression corresponding to the response in a restricted sandbox to obtain the vulnerability verification result, specifically including:

[0028] The external network module, based on the execution context, calls the scanning engine to dynamically replace the variables marked with double curly braces in the POC template;

[0029] After the variable substitution is complete, the engine converts the template into a structured request JSON.

[0030] Initiates concurrent HTTP requests with a built-in automatic retry mechanism;

[0031] After receiving the server response, it is standardized into a PocResponse model object; the model object contains the response status code, response header dictionary, response body plaintext, and request time field;

[0032] Recursively convert the type of the PocResponse model object and its nested structure, and parse the nested data into types supported by CEL;

[0033] Within a pre-defined restricted sandbox, pre-compiled CEL expressions are loaded, a centrally registered custom function library is called, and vulnerability assessment logic is executed.

[0034] If the CEL expression evaluates to True, the vulnerability record containing task_id, subtask_id, POC name, target network segment, and response evidence will be persisted to the database via the interface.

[0035] If the evaluation result is False, save the missing record and trigger an optional retry.

[0036] In one implementation of this application, the intranet module sequentially retrieves subtasks from the local bounded job queue for execution to obtain vulnerability verification results, specifically including:

[0037] The intranet module retrieves subtasks from the local bounded job queue according to the principle of high priority.

[0038] The number of coroutines is automatically adjusted by monitoring CPU utilization and task queue length, and a work-stealing algorithm is used for task extraction.

[0039] After the coroutine retrieves the subtask, it performs port probing.

[0040] After a successful port probe, an application-layer fingerprint is collected, and the corresponding plug-in vulnerability detection is dynamically triggered based on the port and fingerprint matching results.

[0041] If a subnet fails to probe for a predetermined number of consecutive times, a local circuit breaker is triggered, and exponential backoff retry is performed on the failed task.

[0042] The scan results are processed in a streaming manner; if a vulnerability is detected, a result containing task_id / subtask_id, target IP, port, vulnerability type, and verification evidence is generated and asynchronously written to the Vulnerability table in the database; at the same time, the scan rate and error rate indicators are reported to the monitoring system in real time, and the results are synchronously transmitted back.

[0043] In one implementation of this application, the backend service layer preprocesses the vulnerability verification results returned by the external network module and the internal network module; the preprocessed standardized results are pushed to the frontend view layer for real-time display, specifically including:

[0044] The backend service layer continuously consumes the vulnerability verification results returned by the external network module and the internal network module;

[0045] Group by task_id and target IP, filter duplicate port liveness records and vulnerability verification results to obtain preprocessed standardized results;

[0046] The preprocessed standardized results are pushed proactively as a standardized result package via the WebSocket / SSE protocol. The front-end Vue+TypeScript application receives the package and updates the real-time log panel and vulnerability list. For non-real-time query requirements, the back-end provides a paginated query interface via REST API.

[0047] The backend service layer is triggered upon task completion, generating a report based on preprocessed standardized data. The report uses a pre-set template and supports exporting to PDF / HTML format, while automatically saving the report generation log.

[0048] In one implementation of this application, after constructing a front-end and back-end separated system architecture, the method further includes:

[0049] Deploy a relational database and execute the initial DDL script to establish the core data table structure. The core data table structure includes: Task table records the main task metadata, SubTask stores dynamically generated subnet scanning units, Asset stores the identified asset information, Vulnerability stores the vulnerability verification results, Fingerprint records application layer fingerprint features, QueueCursor maintains the message queue consumption position, and User manages user permissions.

[0050] Create task distribution streams, result collection streams, and event notification streams, and configure dead-letter queues to handle exception messages;

[0051] The monitoring system uses a combination of Prometheus and Grafana. Exporters are deployed to collect node metrics, and alarm rules are configured to monitor scan rate, error rate, and system load. The Grafana dashboard visualizes the number of concurrent threads, task backlog, and vulnerability statistics, and thresholds are set to trigger alarms.

[0052] Initialize the centralized function registry and CEL type registry, and preload the default function libraries for port detection, fingerprinting, and vulnerability verification into the execution environment.

[0053] Secondly, this application provides an automated penetration testing device based on expression language and high-concurrency scanning, the device comprising:

[0054] processor;

[0055] And memory, on which executable code is stored, which, when executed, causes the processor to perform an automated penetration testing method based on expression language and high-concurrency scanning, as described above.

[0056] Thirdly, this application provides a non-volatile computer storage medium storing computer instructions, which, when executed, implement an automated penetration testing method based on expression language and high-concurrency scanning as described above.

[0057] As can be seen from the above technical solutions, this application has the following advantages:

[0058] By constructing a front-end and back-end separated system architecture, the front-end view layer, back-end service layer, and penetration testing engine are decoupled, achieving decoupling between task processing and user interaction. The penetration testing engine employs a dynamic sharding strategy to divide the target network segment into several sub-network blocks, and prioritizes critical ports by combining a pre-set high-risk port list. Through a local bounded job queue and a dynamically scalable coroutine pool mechanism, tasks are evenly distributed in a multi-core environment. This design effectively solves the bottleneck of traditional tools in concurrent processing, enabling rapid response to large-scale internal network scanning needs, significantly reducing scanning time, and meeting the high-efficiency response requirements of modern penetration testing.

[0059] Enhance system flexibility and scalability, and simplify vulnerability detection rule management. The penetration testing engine employs Expression Language (CEL) and pre-compiled CEL expressions, combined with custom functions from a pre-defined function library, to perform vulnerability verification within a restricted sandbox. This design allows users to dynamically define detection logic by writing expressions, eliminating the need for hard-coded rules or complex configurations. When faced with new vulnerabilities or specific business logic, users can directly adjust detection strategies through expressions, without waiting for vendor updates or secondary development, significantly lowering the technical barrier and shortening the response cycle. Simultaneously, the external network module generates structured requests by replacing POC template variables, further enhancing the flexibility and adaptability of detection.

[0060] The system optimizes operational processes and user experience, achieving end-to-end automation and visualization. The front-end view layer provides a unified graphical user interface, while the back-end service layer uses message queues and databases to standardize task metadata management, ensuring seamless integration of scanning, vulnerability verification, and report generation. Results processing employs a streaming aggregation mechanism, combined with standardized preprocessing and real-time display, reducing the complexity of information integration. Simultaneously, the system supports exporting reports using pre-defined templates, simplifying the operational process. This design not only reduces user reliance on the command-line interface but also enhances the usability and promotional value of penetration testing through an intuitive interface and automated processes. Attached Figure Description

[0061] To more clearly illustrate the technical solution of the present invention, the accompanying drawings used in the description will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0062] Figure 1 This is a flowchart of an automated penetration testing method based on expression language and high-concurrency scanning provided in an embodiment of this application.

[0063] Figure 2 This is a schematic diagram of the internal structure of an automated penetration testing device based on expression language and high-concurrency scanning, provided in an embodiment of this application. Detailed Implementation

[0064] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0065] Those skilled in the art should understand that the embodiments described below are merely preferred embodiments of this disclosure and do not imply that this disclosure can only be implemented through these preferred embodiments. These preferred embodiments are merely used to explain the technical principles of this disclosure and are not intended to limit the scope of protection of this disclosure. Based on the preferred embodiments provided by this disclosure, all other embodiments obtained by those skilled in the art without creative effort should still fall within the scope of protection of this disclosure.

[0066] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0067] The technical solutions proposed in the embodiments of this application will be described in detail below with reference to the accompanying drawings.

[0068] The example provides an automated penetration testing method based on expression language and high-concurrency scanning, such as... Figure 1 As shown in the embodiments of this application, the method mainly includes the following steps:

[0069] Step 110: Construct a system architecture that separates the front-end and back-end.

[0070] The system architecture includes a front-end view layer, a back-end service layer, and a penetration testing engine, which includes an external network module and an internal network module.

[0071] In some embodiments, a front-end and back-end separated system architecture is constructed, specifically including:

[0072] The front-end view layer is built using Vue and TypeScript, configuring a task creation panel, project management, real-time logs and result display modules. It integrates a WebSocket / SSE client to receive real-time progress and interacts with the back-end service layer via HTTP requests. (In the single-page application built with Vue and TypeScript, in addition to the basic modules, a URL / path management module is developed to support batch import of target URLs and path brute-force configuration; the task creation panel provides fine-grained parameter configuration items (such as target CIDR / IP list input boxes, port detection range selection (all ports / common ports), POC rule list checkboxes, execution priority (high / medium / low) settings), and supports parameter file (.r.txt) upload and preview functions; in addition to receiving progress, the WebSocket / SSE client can also receive vulnerability hit notifications in real time, triggering front-end pop-up reminders to improve user experience efficiency).

[0073] The backend service layer is built using the FastAPI framework, providing RESTful API interfaces to receive tasks and parameter files from the frontend view layer. Pydantic is used for parameter validation, generating unique records for each task and writing them to the database. Tasks are then delivered to message queues on demand, supporting distributed scheduling. SQLAlchemyORM is used for asynchronous database operations. (In addition to the basic RESTful API, the core interfaces defined in the FastAPI framework include: POST / tasks (submit tasks), GET / tasks / {id} (query task details), and GET / projects (project list). After receiving task data, the interfaces perform dual validation of "format + semantics" using Pydantic / JSON Schema (e.g., validating the target IP format and matching the POC list with the target type), while automatically performing timestamp conversion (converting local frontend time to UTC) and parameter completion (adding a default value of 300s when no timeout is specified). Message queue delivery is handled differently according to system mode: in distributed mode, complete task metadata is delivered; in single-machine mode, a job pointer pointing to the database record is delivered, and idempotent parameters are configured (queue claim timeout 30s, task retention period 72h) to avoid duplicate consumption.)

[0074] A penetration testing engine was created. The external network module, based on Python and CEL expressions, extends custom functions and constructs a restricted sandbox to execute vulnerability detection logic (the Python-based POC scanning engine is encapsulated in poc_exploit.py, supporting dynamic template variable replacement (e.g., concatenating addresses with {{target + ":" + str(port)}}), and providing gen-req (intelligently generating Burp Suite-compatible debuggable structured requests) and replay (accurately replaying the original request and comparing response differences) interfaces). The CEL expression execution layer preloads a unified type mapping (e.g., converting nested JSON in the HTTP response body to CEL-supported MapType, and converting response status codes to IntType). Custom function libraries cover string processing (e.g., str_decode()), encryption / decoding (e.g., base64_decode()), and HTTP response parsing (e.g., extract_response_body()), and all functions are injected through a centralized registry and executed within a restricted sandbox (prohibiting arbitrary I / O and system calls). The internal network module uses Golang to build a daemon process, establishes a Goroutine pool and Channel communication architecture, and integrates Work-Stealing. The algorithm and connection reuse strategy (the Goroutine pool of the Golang daemon supports dynamic scaling (expanding when CPU utilization exceeds 70% and shrinking when it is below 30%), and integrates three core optimization strategies: dynamic timeout control (adjusting the threshold according to the intranet latency, such as setting the timeout to 500ms for latency <10ms), token-bucket rate limiting (10 requests per second by default), and failure backoff retry (interval of 2s / 4s / 8s, up to 3 times); port detection is implemented with dual-mode support through the WrapperTcpWithTimeout() interface, using the standard three-way handshake for ordinary targets (to ensure accuracy), and using the rawSYN mode for high-concurrency scenarios (combined with passive packet capture to confirm the connection status), and reducing handshake overhead through connection reuse (address pool + LRU cache + heartbeat maintenance).

[0075] Deploy the relational database PostgreSQL and execute the initial DDL script to establish the core data table structure. The core data table structure includes: Task table records the main task metadata, SubTask stores dynamically generated subnet scanning units, Asset stores the identified asset information, Vulnerability stores the vulnerability verification results, Fingerprint records application layer fingerprint features, QueueCursor maintains the message queue consumption position, and User manages user permissions.

[0076] Create task distribution streams, result collection streams, and event notification streams, and configure dead-letter queues to handle exception messages;

[0077] The monitoring system uses a combination of Prometheus and Grafana. Exporters are deployed to collect node metrics, and alarm rules are configured to monitor scan rate, error rate, and system load. The Grafana dashboard visualizes the number of concurrent threads, task backlog, and vulnerability statistics, and thresholds are set to trigger alarms.

[0078] Initialize the centralized function registry and CEL type registry, and preload the default function libraries for port detection, fingerprinting, and vulnerability verification into the execution environment.

[0079] To elaborate further, during the system deployment phase, this application will complete the construction and initialization of the infrastructure based on pre-configured environment parameters (database connection string, message queue address, monitoring and alarm configuration, certificate and reverse proxy information, etc.): deploying a relational database (e.g., PostgreSQL) and executing initial DDL table creation (Task, SubTask, Asset, Vulnerability, Fingerprint, QueueCursor, User, etc.), deploying a message queue (e.g., RedisStreams / RabbitMQ / Kafka) and creating necessary topics / streams, deploying a monitoring and alarm stack (Prometheus + Grafana) and configuring basic dashboards and alarm rules, while initializing a centralized function registry and a CEL type registry and preloading the default custom function library into the execution environment; after deployment, it will produce usable DB / Queue / monitoring endpoints and basic configuration files (config.yml), and define static parameters such as idempotent consumption strategy, queue claim timeout, and task retention period in the configuration, providing stable operational support and tunable static constraints for subsequent steps.

[0080] Step 120: The front-end view layer submits the scanning task and parameter file to the back-end service layer. After receiving the task and parameter file, it writes the task metadata to the database and simultaneously delivers the task metadata to the message queue.

[0081] It should be noted that this step can be specifically described as follows:

[0082] The front-end view layer provides a task configuration panel and file upload entry; the scan task and parameter file are obtained, and the back-end FastAPI RESTful interface is called via HTTP request to submit the scan task and parameter file to the back-end service layer.

[0083] After receiving a request, the FastAPI interface performs field format and semantic validation on the input data using Pydantic / JSON Schema; after successful field format and semantic validation, it automatically completes timestamp conversion and parameter completion.

[0084] A unique task_id is generated using UUID, and standardized task metadata is constructed based on the verified data. The metadata includes the task_id, user configuration parameters in the scan task, verification completion information, initial task status, and creation timestamp.

[0085] The backend service layer performs asynchronous database operations through SQLAlchemyORM and writes normalized metadata into the Task table;

[0086] Depending on the system's operating mode, the backend service layer synchronously or asynchronously delivers task metadata to the message queue and configures consumption parameters;

[0087] The backend service layer returns the task_id and initial task status to the frontend view layer in a non-blocking manner, allowing the frontend view layer to query the task progress via the subsequent GET / tasks / {task_id} interface.

[0088] It should be further explained that all intermediate results generated during execution are written back to the message queue or database with task_id / subtask_id. The backend uses subtask_id as the smallest aggregation unit for deduplication, MapIPToPorts aggregation, and progress summarization. The execution context lifecycle and the returned results are used for task-level progress updates, breakpoint recovery, partial circuit breaker decisions, and report generation. This ensures that step four is not only a bridge for task distribution, but also that subsequent operations such as vulnerability scanning requests, CEL determination, port probing, and protocol identification all use the same execution context as input and achieve end-to-end traceability and output summarization through task_id and subtask_id. The verification and completion information is information automatically supplemented by missing or incomplete fields after validating the legality of the scan task parameters submitted by the user. This includes the normalized representation of the target address range, the default port or port policy, scan policy parameters, and task priority, etc., explaining the verification and completion information.

[0089] Step 130: The external network module and internal network module of the penetration testing engine subscribe to or poll the database from the message queue to obtain tasks. After obtaining the tasks, they load preset auxiliary data and generate an execution context. The auxiliary data includes historical scan records, service or application fingerprint information, historical vulnerability detection results, and port risk level information in the asset library. This data is used to enrich the target's attribute information and provide a basis for subsequent task priority division and scanning strategy selection. The target network segment in the execution context is divided into several sub-network blocks according to a dynamic sharding strategy. Based on the list of high-risk ports in the execution context, the preset high-risk ports involved in the sub-network blocks are preferentially placed into the local bounded job queue.

[0090] It should be noted that two types of nodes are configured in the penetration testing engine execution layer: Python workers for the external network module and Golang daemons for the internal network module; in a distributed scenario, the system subscribes to RedisStreams / RabbitMQ message queues, while in a single-machine scenario, it polls the database.

[0091] After a node receives a task, it loads auxiliary data in batches using the task target description as an index: retrieves the target's historical port liveness records and last scan time from the asset database; loads service / application fingerprint templates from the fingerprint database; extracts vulnerability hit and false alarm records from the historical results database; and merges external intelligence with blacklists and whitelists.

[0092] Expand and filter the target set, remove blacklisted IPs, and prioritize high-activity targets based on their historical liveness status; then merge the target metadata; next, filter out a suitable list of POC rules based on fingerprint and port information; extract a list of preset high-risk ports from the vulnerability hit and false alarm records in the historical results database; finally, inject task execution constraints to form an execution context; among them, task execution constraints include dynamic sharding strategies.

[0093] Extract the target network segment, dynamic sharding strategy, and preset high-risk port list from the execution context; divide the target network segment into several sub-network blocks according to the dynamic sharding strategy; for each sub-network block, prioritize the extraction of detection requirements involving preset high-risk ports, generate preset high-priority subtasks, and push them to the front end of the local bounded job queue; ordinary port subtasks are subsequently added to the local bounded job queue; after the subtasks are enqueued, the metadata is synchronously written to the database, and all operations carry task_id / subtask_id.

[0094] Step 140: The external network module generates structured requests based on the actual parameter values ​​in the execution context and sends them concurrently. After receiving the response, it executes the pre-compiled CEL expression corresponding to the response in the restricted sandbox to obtain the vulnerability verification result. The internal network module retrieves subtasks from the local bounded job queue in sequence and executes them to obtain the vulnerability verification result.

[0095] It should be noted that the external network module replaces the POC template variables with the actual parameter values ​​in the execution context, generates structured requests and sends them concurrently. After receiving the response, it performs normalization processing, mapping the response to a type recognizable by CEL. Within a restricted sandbox, it executes pre-compiled CEL expressions and calls custom functions from a pre-defined function library to obtain vulnerability verification results, specifically including:

[0096] The external network module Python worker, based on the execution context, calls the POC scanning engine encapsulated in poc_exploit.py to dynamically replace variables marked with double curly braces in the POC template; the replacement process supports embedded CEL expressions.

[0097] After the variable replacement is completed, the engine converts the template into a structured request JSON through the gen-req interface, which includes the original request text, the parsed parameter mapping, and the security detection identifier;

[0098] It uses httpx.AsyncClient to initiate concurrent HTTP requests and has a built-in automatic retry mechanism;

[0099] After receiving the server response, it is standardized into a PocResponse model object, which includes the response status code, response header dictionary, response body plaintext, and request time field.

[0100] Recursively convert the PocResponse model and its nested structure to parse nested data into types supported by CEL and automatically perform type inference.

[0101] Within a pre-defined restricted sandbox, pre-compiled CEL expressions are loaded, a centrally registered custom function library is called, and vulnerability assessment logic is executed.

[0102] If the CEL expression evaluates to True, the vulnerability record containing task_id, subtask_id, POC name, target network segment and response evidence will be persisted to the database through the create_vuln_result interface;

[0103] If the evaluation result is False, save the missing record and trigger an optional retry.

[0104] The internal network module's dynamically scalable pool sequentially retrieves subtasks from the local bounded job queue for execution, scans the subtasks, and obtains vulnerability verification results, specifically including:

[0105] The Golang daemon of the intranet module is based on a dynamically scalable Goroutine pool, and retrieves subtasks from the local bounded job queue according to the principle of high priority.

[0106] Meanwhile, the pool automatically adjusts the number of coroutines by monitoring CPU utilization and task queue length, and uses a work-stealing algorithm to allow idle coroutines to steal tasks from busy coroutines, thereby achieving load balancing in a multi-core environment.

[0107] After the coroutine retrieves the subtask, it calls the unified encapsulated WrapperTcpWithTimeout() interface to perform port probing. The interface supports two modes under context management: standard three-way handshake for ordinary targets and rawSYN mode for high-concurrency scenarios. It also enables connection reuse strategy and automatically adjusts the timeout threshold based on the target network latency according to the dynamic timeout control algorithm.

[0108] After a successful port probe, an application layer fingerprint is collected, and the corresponding plug-in vulnerability detection is dynamically triggered based on the port and fingerprint matching results. During the detection process, the token-bucket rate is limited to prevent single-target probe overload, while the protocol's preset specific verification logic is executed.

[0109] Use segmented locks instead of global locks; use a lock-free concurrent queue based on CAS for result return; use sync / atomic atomic operations for critical write operations;

[0110] If five consecutive probe failures are detected in a subnet, a local circuit breaker is triggered, and exponential backoff retry is performed on the failed tasks.

[0111] The scan results are processed in a streaming manner; if a vulnerability is detected, a result containing task_id / subtask_id, target IP, port, vulnerability type, and verification evidence is generated and asynchronously written to the Vulnerability table in the database; the liveness records of ordinary ports are stored in the database in batches; at the same time, the scan rate and error rate indicators are reported to the monitoring system in real time, and the results are synchronously transmitted back.

[0112] Further, the external network module can be specifically described as follows:

[0113] After receiving the vulnerability scanning execution context from the external network, the external execution node uses the POC scanning engine encapsulated in poc_exploit.py as its core. First, it performs intelligent parameter processing on the POC templates and variables in the context: template variables are represented in double curly braces (such as {{target}}), and are replaced by the actual parameter values ​​by the template engine at runtime. The replacement process can embed CEL expressions for evaluation, so that parameters can be dynamically generated according to the context and support variable mutation.

[0114] At the gen-req interface, the engine converts the replaced template into a structured request JSON (containing the original request text, parsed parameter mappings, and security detection identifiers), and then sends the request concurrently via httpx.AsyncClient (with a built-in automatic retry mechanism, retrying a maximum of 3 times by default). Each response is normalized into a PocResponse model object (containing fields such as status_code, headers, body, rtt, and convenient access methods).

[0115] The response enters the external network judgment pipeline: First, the response and its nested structure (JSON, XML, etc.) undergo recursive type conversion, mapping them to CEL-recognizable Map / List types and automatically performing type inference. Here, type inference ensures the correct execution of the CEL expression and transforms the response structure into a usable reference for subsequent judgment, evidence extraction, and result aggregation. Subsequently, in the phased CEL evaluation process of environment initialization, expression compilation, and optimization, the pre-compiled CEL expression is executed within a restricted sandbox, and centralized registered custom functions (such as decoding, regular expression matching, fingerprint extraction, etc.) are called. When the CEL evaluation is True, the system persists the vulnerability record containing task_id, subtask_id, POC name, target network segment, and evidence into the database through backend interfaces such as create_vuln_result. If the CEL evaluation is False, the non-hit record is saved, optional retry or backup POC is triggered, and running indicators are recorded to support subsequent retesting and false positive analysis. At the same time, intermediate data such as the original request, response snapshot, and CEL execution log are written to the audit log for reproduction and analysis.

[0116] To facilitate manual verification and debugging, the system also provides gen-req (intelligent request generator) and replay (replay request) interfaces: the former dynamically constructs the detection payload according to the POC template and target parameters and returns a structured request that can be debugged in tools such as Burp Suite; the latter accurately reconstructs and sends the original request, records the complete interaction (response time, status code, header, body, etc.) and supports intelligent response comparison to highlight the key differences between the two responses.

[0117] The above process takes the execution context as input and outputs information such as vulnerability records, audit logs, and verifiable requests, as well as request / replay data that facilitates verification. The backend then aggregates and pushes this data to the presentation layer.

[0118] Further, the intranet module can be specifically described as follows:

[0119] After receiving the execution context related to the intranet vulnerability scan from step four, the Golang daemon acts as an independent high-performance execution unit to process the intranet task: First, based on the target CIDR, port policy, and priority rules in the execution context, it calls the task generator to divide the target network segment into several sub-network blocks according to the dynamic sharding strategy, and puts high-risk ports into the priority queue based on historical response rates and vulnerability distribution. Then, the generated sub-tasks are pushed into the local bounded job queue.

[0120] The scheduling layer is centered around a dynamically scalable Goroutine pool. It automatically adjusts the pool size by monitoring CPU / load and employs a work-stealing mechanism to balance task distribution in multi-core environments. Global concurrency is jointly controlled by a token-bucket and a bounded queue, along with a subnet adaptive concurrency strategy to prevent overload in a single area. Port probing is performed within the coroutine using a unified encapsulated network call interface, WrapperTcpWithTimeout(). This interface supports standard three-way handshake detection and optional rawSYN mode (combined with passive packet capture to confirm SYN-ACK / RST) under context / timeout management, autonomously balancing accuracy and speed. Upon successful connection, application-layer fingerprinting or subsequent vulnerability verification is immediately performed. Frequently accessed targets utilize a connection reuse strategy (address pool + LRU cache + heartbeat maintenance), while abnormal connections are automatically removed. To ensure long-term high-concurrency stability, the scheduling layer triggers a partial circuit breaker and dynamically reduces the dispatch frequency of that segment when it detects consecutive subnet failures or a high error rate. It also employs exponential backoff timeout and retry strategies to reduce invalid attempts. Results processing employs streaming aggregation: probe events are first written to a memory buffer and controlled by backpressure; MapIPToPorts() merges port records by IP; BloomFilter is used for incremental deduplication; important assets are persisted in real time; and ordinary records are asynchronously written to disk in batches. When encountering common service ports, AddScan() is used to dynamically trigger plug-in vulnerability detection (parallel brute-force, protocol parsing, or secondary verification).

[0121] To avoid data inconsistency caused by concurrent contention, the system employs multi-level concurrency control: the global lock is split into segmented locks to reduce blocking; the result channel uses a lock-free concurrent queue based on CAS; and critical write operations use memory barriers and sync / atomic atomic operations to ensure visibility and execution order. All subtasks and probe events carry task_id / subtask_id for idempotent consumption, breakpoint resumption, and progress reporting by the backend. Performance metrics (scan rate, concurrency, error rate) are reported to the monitoring system in real time for alerting and automatic scaling, thus achieving a highly efficient, stable, and controllable large-scale intranet scan execution chain.

[0122] Step 150: The backend service layer preprocesses the vulnerability verification results returned by the external network module and the internal network module; the standardized results after preprocessing are pushed to the frontend view layer for real-time display.

[0123] Specifically, the backend service layer continuously consumes the vulnerability verification results returned by the external network module and the internal network module;

[0124] Group by task_id and target IP, merge port vulnerability association data using MapIPToPorts(), use BloomFilter to perform incremental deduplication, filter duplicate port liveness records and vulnerability verification results, and obtain preprocessed standardized results;

[0125] The preprocessed standardized results are pushed proactively as a standardized result package via the WebSocket / SSE protocol. The front-end Vue+TypeScript application receives the package and updates the real-time log panel and vulnerability list. For non-real-time query requirements, the back-end provides a paginated query interface via REST API.

[0126] The backend service layer is triggered upon task completion, generating a report based on preprocessed standardized data. The report uses a pre-set template and supports exporting to PDF / HTML format, while automatically saving the report generation log.

[0127] As can be seen from the above description, this application adopts a front-end and back-end separation architecture design to improve the system's scalability, maintainability, and ease of operation.

[0128] The system's external network uses the CEL engine to perform expression parsing and rule calculation, supporting custom functions and cross-system data adaptation. The backend relies on FastAPI to provide external interfaces, task scheduling, and data management. The internal network scanning uses a Golang coroutine pool and multi-level optimization algorithms to handle large-scale concurrent tasks, combined with dynamic timeout control, connection reuse, and resource contention avoidance mechanisms to ensure low latency, high throughput, and stable operation.

[0129] Regarding data flow, the system receives data from tasks and configuration files submitted by the front end, asset repositories, external fingerprints, or real-time probe results. After a task is created, FastAPI parses, validates, and standardizes the input, and writes the task record to the database or posts it to a message queue, where it is retrieved and processed by the corresponding execution modules (external CEL path and internal Golang path). The external path loads the HTTP response, fingerprint, and metadata as typed parameters, performs lexical / syntactic parsing, AST generation, and type validation in CEL, and calls a centrally registered custom function in a restricted sandbox to complete the judgment. The judgment result is persisted through the backend. The internal path uses the Golang daemon to concurrently perform port probing and protocol identification based on a coroutine pool. Scan events are sent back to the backend via a lock-free queue or streaming pipeline. The backend aggregates, deduplicates, and hierarchically persists the results and pushes the standardized data to the front end for display.

[0130] To ensure the controllability and tunability of the above operation process, the system predefines configuration items at the component level, including a unified data model and table structure, type registration and JSON / Schema mapping, centralized function registrar and permission signature, sandbox resource quotas and timeout limits, message queues and channel buffering strategies, coroutine pool scaling and Work-Stealing parameters, sharding / priority rules, connection pool strategies (LRU / heartbeat / anomaly removal), and deduplication / persistence strategies. These static configurations work together with the dynamic processing flow to enable the system to gradually transform raw inputs into structured judgments and visual reports in complex internal and external network environments, thereby achieving an automated closed loop of scanning, vulnerability verification, rule management, and result processing.

[0131] The above are method embodiments of this application. Based on the same inventive concept, this application also provides a target identification data processing device for unmanned aerial vehicle (UAV) inspection. Figure 2 As shown, the device includes: a processor; and a memory storing executable code thereon, which, when executed, causes the processor to perform a target identification data processing method for UAV inspection as described in the above embodiments.

[0132] Specifically, the server-side architecture is a front-end / back-end separated system. This architecture includes a front-end view layer, a back-end service layer, and a penetration testing engine. The penetration testing engine includes an external network module and an internal network module. The front-end view layer submits scanning tasks and parameter files to the back-end service layer. After receiving the tasks and parameter files, it writes the task metadata to the database and simultaneously posts the task metadata to a message queue. The external network module and the internal network module of the penetration testing engine subscribe to or poll the database from the message queue to retrieve tasks. After retrieving a task, they load preset auxiliary data and generate an execution context. The target network segment in the execution context is then segmented according to a dynamic sharding strategy. The system is divided into several sub-blocks. Based on the list of high-risk ports in the execution context, the preset high-risk ports involved in the sub-blocks are preferentially placed into the local bounded job queue. The external network module generates structured requests based on the actual parameter values ​​in the execution context and sends them concurrently. After receiving the response, it executes the pre-compiled CEL expression corresponding to the response in a restricted sandbox to obtain the vulnerability verification result. The internal network module retrieves subtasks from the local bounded job queue in sequence and executes them to obtain the vulnerability verification result. The backend service layer preprocesses the vulnerability verification results returned by the external network module and the internal network module. The preprocessed standardized results are pushed to the front-end view layer for real-time display.

[0133] As described above, the front-end and back-end architecture of this system not only achieves a concise and user-friendly front-end page that facilitates understanding and operation for evaluators, but also simplifies the overall system structure. The near-natural language characteristics of the Python language itself also help developers quickly understand the system's code architecture and carry out secondary development or functional expansion, thus enabling the sustainable development of the system.

[0134] Regarding external network vulnerabilities, this system's external network scanner boasts several advantages: it employs an expression-based dynamic rule-based judgment mechanism, enabling flexible loading and updating of detection logic at runtime, thus quickly adapting to new vulnerabilities and variants; combining templated parameters and context evaluation, the detection payload can be dynamically generated based on the target environment, improving the rule coverage and applicability; it achieves automated nested type conversion and unified representation for complex structured data such as HTTP responses, allowing rules to directly apply to multi-layered data such as JSON / XML without manual preprocessing; through the combination of asynchronous request scheduling and pre-compiled judgment units, it significantly improves concurrent processing capabilities and judgment throughput, meeting the needs of large-scale external network probing; it also provides request generation and replay capabilities for easy debugging and reproduction, supporting accurate verification of suspicious hits; and at runtime, it ensures security and traceability through a restricted execution environment and audit logs, thereby achieving a balance between flexibility, scalability, performance, and compliance.

[0135] In handling intranet vulnerabilities, the source code of the intranet scanner, written in Go, can easily achieve high concurrency and low overhead for scanning tasks. Its small size and high system compatibility enable it to adapt to various intranet environments.

[0136] In addition, embodiments of this application also provide a non-volatile computer storage medium storing executable instructions, which, when executed, implement an automated penetration testing method based on expression language and high-concurrency scanning as described above.

[0137] The above description of the disclosed embodiments enables those skilled in the art to make or use the invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the invention. Therefore, the invention is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. An automated penetration testing method based on expression language and high-concurrency scanning, characterized in that, The method includes: Construct a system architecture that separates the front-end and back-end; the system architecture includes a front-end view layer, a back-end service layer, and a penetration testing engine, and the penetration testing engine includes an external network module and an internal network module; The front-end view layer submits the scanning task and parameter file to the back-end service layer. After receiving the task and parameter file, it writes the task metadata to the database and simultaneously delivers the task metadata to the message queue. The external network module and internal network module of the penetration testing engine subscribe to or poll the database to obtain tasks from the message queue. After obtaining the tasks, they load the preset auxiliary data and generate the execution context. The target network segment in the execution context is divided into several sub-network blocks according to the dynamic sharding strategy. Based on the list of high-risk ports in the execution context, the preset high-risk ports involved in the sub-network blocks are preferentially placed into the local bounded job queue. Configure two types of nodes in the penetration testing engine execution layer: Python workers for the external network module and Golang daemons for the internal network module; After a node receives a task, it retrieves the target's historical port liveness records and last scan time from the asset database; loads the service application fingerprint template from the fingerprint database; extracts vulnerability hit and false alarm records from the historical results database; and merges external intelligence with blacklists and whitelists. Expand and filter the target set, remove blacklisted IPs, retain preset high-activity targets according to historical liveness status, and merge target metadata; filter out a suitable POC rule list based on fingerprint and port information; extract a preset high-risk port list from vulnerability hit and false alarm records from the historical results database; inject task execution constraints to form an execution context; among them, task execution constraints include dynamic sharding strategies; Extract the target network segment, dynamic sharding strategy, and preset high-risk port list from the execution context; divide the target network segment into several sub-network blocks according to the dynamic sharding strategy; for each sub-network block, extract the detection requirements involving preset high-risk ports, generate preset high-priority subtasks, and push them to the front end of the local bounded job queue; after the subtasks are enqueued, synchronously write the metadata to the database. The external network module generates structured requests based on the actual parameter values ​​in the execution context and sends them concurrently. After receiving the response, it executes the pre-compiled CEL expression corresponding to the response in a restricted sandbox to obtain the vulnerability verification result. The internal network module retrieves subtasks from the local bounded job queue in sequence and executes them to obtain the vulnerability verification result. The external network module, based on the execution context, calls the scanning engine to dynamically replace the variables marked with double curly braces in the POC template; After the variable substitution is complete, the engine converts the template into a structured request JSON; Initiates concurrent HTTP requests with a built-in automatic retry mechanism; After receiving the server response, it is standardized into a PocResponse model object; the model object contains the response status code, response header dictionary, response body plaintext, and request time field; Recursively convert the type of the PocResponse model object and its nested structure to parse the nested data into types supported by CEL; Within a pre-defined restricted sandbox, pre-compiled CEL expressions are loaded, a centrally registered custom function library is called, and vulnerability assessment logic is executed. If the CEL expression evaluates to True, the vulnerability record containing task_id, subtask_id, POC name, target network segment and response evidence will be persisted to the database through the interface; If the evaluation result is False, save the non-hit record and trigger an optional retry; The backend service layer preprocesses the vulnerability verification results returned by the external network module and the internal network module; the standardized results after preprocessing are pushed to the frontend view layer for real-time display. The construction of the front-end and back-end separated system architecture specifically includes: The front-end view layer is built on Vue + TypeScript, configuring a task creation panel, project management, real-time log and result display modules, integrating a WebSocket / SSE client to receive real-time progress, and interacting with the back-end service layer through HTTP requests; The backend service layer is built using the FastAPI framework, which provides RESTful API interfaces to receive tasks and parameter files from the frontend view layer. Pydantic is used for parameter validation, and unique records of tasks are generated and written to the database. Tasks are delivered to message queues as needed to support distributed scheduling. Asynchronous database operations are implemented using SQLAlchemyORM. A penetration testing engine was created, in which the external network module is based on Python combined with CEL expressions, extending custom functions and constructing restricted sandbox execution vulnerability judgment logic; the internal network module is built with a daemon process in Golang, setting up a Goroutine pool and channel communication architecture, and integrating Work-St e Aling algorithm and connection reuse strategy.

2. The automated penetration testing method based on expression language and high-concurrency scanning according to claim 1, characterized in that, The front-end view layer submits the scanning task and parameter file to the back-end service layer. After receiving the task and parameter file, it writes the task metadata to the database and simultaneously posts the task metadata to the message queue. Specifically, this includes: The scanning task and parameter file are obtained through the task configuration panel and file upload entry provided by the front-end view layer. The scanning task and parameter file are then submitted to the back-end service layer by calling the back-end interface via an HTTP request. After receiving the request, the backend interface performs field format validation and semantic validation on the input data; after the field format validation and semantic validation are successful, it automatically completes the timestamp conversion and parameter completion. Generate a unique task_id and construct normalized task metadata based on the verified data; the metadata includes task_id, user configuration parameters in the scan task, verification completion information, task initial status, and creation timestamp; The backend service layer performs asynchronous database operations and writes normalized metadata into the Task table; Depending on the system's operating mode, the backend service layer synchronously or asynchronously delivers task metadata to the message queue and configures consumption parameters; The backend service layer returns the task_id and initial task status to the frontend view layer in a non-blocking manner.

3. The automated penetration testing method based on expression language and high-concurrency scanning according to claim 1, characterized in that, The intranet module retrieves subtasks from the local bounded job queue sequentially for execution, obtaining vulnerability verification results, specifically including: The intranet module retrieves subtasks from the local bounded job queue according to the principle of high priority. The number of coroutines is automatically adjusted by monitoring CPU utilization and task queue length, and a work-stealing algorithm is used for task extraction. After the coroutine retrieves the subtask, it performs port probing. After a successful port probe, an application-layer fingerprint is collected, and the corresponding plug-in vulnerability detection is dynamically triggered based on the port and fingerprint matching results. If a subnet fails to probe for a set number of consecutive times, a local circuit breaker is triggered, and the failed task is retried exponentially. The scan results are processed in a streaming manner; if a vulnerability is detected, a result containing task_id / subtask_id, target IP, port, vulnerability type, and verification evidence is generated and asynchronously written to the Vulnerability table in the database; at the same time, the scan rate and error rate indicators are reported to the monitoring system in real time, and the results are synchronously transmitted back.

4. The automated penetration testing method based on expression language and high-concurrency scanning according to claim 1, characterized in that, The backend service layer preprocesses the vulnerability verification results returned by the external network module and the internal network module; The preprocessed, standardized results are pushed to the front-end view layer for real-time display, specifically including: The backend service layer continuously consumes the vulnerability verification results returned by the external network module and the internal network module; Group by task_id and target IP, filter duplicate port liveness records and vulnerability verification results to obtain preprocessed standardized results; The preprocessed standardized results are pushed proactively as a standardized result package via the WebSocket / SSE protocol. The front-end Vue+TypeScript application receives the package and updates the real-time log panel and vulnerability list. For non-real-time query requirements, the back-end provides a paginated query interface via REST API. The backend service layer is triggered upon task completion, generating a report based on preprocessed standardized data. The report uses a pre-set template and supports exporting to PDF / HTML format, while automatically saving the report generation log.

5. The automated penetration testing method based on expression language and high-concurrency scanning according to claim 1, characterized in that, After constructing a front-end and back-end separated system architecture, the method further includes: Deploy a relational database and execute the initial DDL script to establish the core data table structure. The core data table structure includes the Task table, which records the main task metadata; the SubTask table, which stores dynamically generated subnet scanning units; the Asset table, which stores the identified asset information; the Vulnerability table, which stores the vulnerability verification results; the Fingerprint table, which records the application layer fingerprint characteristics; the QueueCursor table, which maintains the message queue consumption position; and the User table, which manages user permissions. Create task distribution streams, result collection streams, and event notification streams, and configure dead-letter queues to handle exception messages; The monitoring system uses a combination of Prometheus and Grafana. Exporters are deployed to collect node metrics, and alarm rules are configured to monitor scan rate, error rate, and system load. The Grafana dashboard visualizes the number of concurrent threads, task backlog, and vulnerability statistics, and thresholds are set to trigger alarms. Initialize the centralized function registry and CEL type registry, and preload the default function libraries for port detection, fingerprinting, and vulnerability verification into the execution environment.

6. An automated penetration testing device based on expression language and high-concurrency scanning, characterized in that, The device includes: processor; And a memory storing executable code, which, when executed, causes the processor to perform an automated penetration testing method based on expression language and high-concurrency scanning as described in any one of claims 1-5.

7. A non-volatile computer storage medium, characterized in that, It stores computer instructions, which, when executed, implement an automated penetration testing method based on expression language and high-concurrency scanning as described in any one of claims 1-5.

Images