A vulnerability detection orchestration method and system based on artificial intelligence and historical penetration testing knowledge

Abstract

The embodiment of the application provides a vulnerability detection arrangement method and system based on artificial intelligence and historical penetration testing knowledge, the method comprises the following steps: receiving a historical report, preprocessing the historical report to form a standardized desensitization text; knowledge extraction is carried out on the standardized desensitization text in the cloud, and the standardized desensitization text is converted into a vulnerability instance; the quality evaluation of the vulnerability instance is carried out, the same kind is aggregated, and the vulnerability instance is converted into a knowledge baseline; real-time project information is obtained locally, combined with the knowledge baseline, a declarative detection suggestion is generated in the cloud and fed back to the local; the declarative detection suggestion is compiled into an execution plan in the local, and a plan step is generated; combined with artificial intelligence, the plan step or dialogue intention reasoning is converted into a tool calling sequence in the local tool menu; based on the tool calling sequence, detection is carried out, and the detection result is desensitized and returned to the cloud for baseline matching, forming a security detection task closed loop.

Description

Technical Field

[0001] This invention relates to the field of data processing technology, and in particular to a vulnerability detection orchestration method and system based on artificial intelligence and historical penetration testing knowledge. Background Technology

[0002] Enterprise security teams have accumulated a large number of penetration test reports, vulnerability notifications, and remediation records over time. These materials contain knowledge such as vulnerability names, affected interfaces, request methods, preconditions, verification steps, evidence, and remediation suggestions, but are usually scattered across heterogeneous media such as DOCX, DOC, PDF, Excel, HTML, Markdown, or text. On the other hand, actual testing occurs on the local terminals of security testers, involving authorized domains, test accounts, test objects, access credentials, and business data, which should not be directly handed over to the cloud for free access.

[0003] Currently, existing technologies for processing the aforementioned data typically fall into two disjointed categories: one treats historical reports merely as full-text search or statistical data, failing to generate executable and verifiable knowledge; the other directly maps scanning templates or vulnerability numbers to local plugins, which, while capable of automatic execution, are prone to misexecution due to number reuse, version drift, target mismatch, or tampering with cloud input. For business security issues such as object-level privilege escalation, export privilege escalation, and file download privilege escalation, general-purpose scanners can easily achieve coverage through batch enumeration or large-scale requests, failing to meet the low-risk, minimal-request, and explicit authorization requirements of production environments. Summary of the Invention

[0004] To address the problems existing in the prior art, embodiments of the present invention provide a vulnerability detection orchestration method and system based on artificial intelligence and historical penetration testing knowledge.

[0005] Firstly, embodiments of this specification provide a vulnerability detection orchestration method based on artificial intelligence and historical penetration testing knowledge, the method comprising:

[0006] Receive historical reports, preprocess the historical reports to form standardized desensitized text, the preprocessing includes content deduplication, controlled format parsing, and sensitive information replacement;

[0007] Knowledge extraction is performed on the standardized de-identified text in the cloud, and the standardized de-identified text is converted into vulnerability instances;

[0008] The vulnerability instances are evaluated for quality, and the results of the quality evaluation are aggregated into similar instances and transformed into a knowledge baseline.

[0009] Obtain local real-time project information, and based on the real-time project information and knowledge baseline, generate declarative detection suggestions in the cloud and feed them back to the local machine;

[0010] The declarative detection recommendations are compiled into an execution plan locally, and the plan steps are generated after multidimensional consistency verification and asset binding.

[0011] By combining artificial intelligence, the planned steps or dialogue intent reasoning are transformed into a tool call sequence within the local tools menu;

[0012] The detection is performed based on the sequence called by the tool, and the detection results are anonymized and sent back to the cloud for baseline matching, forming a closed loop for the security detection task.

[0013] Secondly, embodiments of this specification provide a vulnerability detection orchestration system based on artificial intelligence and historical penetration testing knowledge, the system comprising:

[0014] The report access module is used to receive historical reports, preprocess the historical reports to form standardized desensitized text, and the preprocessing includes content deduplication, controlled format parsing, and sensitive information replacement.

[0015] The knowledge extraction module is used to extract knowledge from the standardized de-identified text in the cloud and convert the standardized de-identified text into vulnerability instances.

[0016] The knowledge quality module is used to evaluate the quality of the vulnerability instances, aggregate similar instances based on the quality evaluation results, and transform them into knowledge baselines.

[0017] The baseline publishing module is used to obtain local real-time project information, and based on the real-time project information and the knowledge baseline, generate declarative detection suggestions in the cloud and feed them back to the local system.

[0018] The plan compilation module is used to compile the declarative detection suggestions into an execution plan locally, and generate plan steps after multidimensional consistency verification and asset binding;

[0019] The reasoning module is used to combine artificial intelligence to convert the planned steps or dialogue intent reasoning into a tool call sequence within the local tools menu;

[0020] The detection module is used to perform detection based on the tool's call sequence, and to anonymize the detection results and send them back to the cloud for baseline matching, thus forming a closed loop for the security detection task.

[0021] Thirdly, embodiments of this specification provide an electronic device, including a processor and a memory;

[0022] The processor is connected to the memory;

[0023] The memory is used to store executable program code;

[0024] The processor runs a program corresponding to the executable program code stored in the memory to perform the methods described in one or more embodiments.

[0025] Fourthly, embodiments of this specification provide a non-transitory computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the steps of the aforementioned vulnerability detection orchestration method based on artificial intelligence and historical penetration testing knowledge.

[0026] In view of the above, the beneficial effects of the technical solutions provided by some embodiments of this specification include at least the following:

[0027] In one or more embodiments of this specification, historical reports are received, preprocessed to form standardized de-identified text; knowledge extraction is performed on the standardized de-identified text in the cloud, and the standardized de-identified text is converted into vulnerability instances; quality evaluation is performed on the vulnerability instances and similar aggregation is performed to convert them into knowledge baselines; local real-time project information is obtained, and combined with the knowledge baseline, declarative detection suggestions are generated in the cloud and fed back to the local machine; the declarative detection suggestions are compiled into an execution plan locally, generating plan steps; combined with artificial intelligence, the plan steps or dialogue intent reasoning are converted into tool call sequences within the local tool menu; detection is executed based on the tool call sequence, and the detection results are de-identified and sent back to the cloud for baseline matching, forming a closed loop of security detection task. This embodiment transforms heterogeneous, unstructured historical reports into structured instances and aggregates them into versioned baselines, thereby converting documentation into executable detection capabilities. It also avoids erroneous executions caused by vulnerability number reuse, version drift, and target mismatches through cloud-based semantic matching and local multi-dimensional consistency verification. Furthermore, by treating cloud output as suggestions and compiling a local plan, it ensures that detection actions only execute verified and securely controllable steps. Finally, it minimizes requests and requires explicit authorization to complete business security verification by embedding low-risk detectors and controlled AI orchestration. Finally, through multi-layered execution protection and local de-identification and feedback, it forms a closed-loop security detection system where sensitive data remains locally and is fully traceable. Attached Figure Description

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

[0029] Figure 1This is a flowchart illustrating a vulnerability detection orchestration method based on artificial intelligence and historical penetration testing knowledge, provided in one embodiment of this specification.

[0030] Figure 2 This is a schematic diagram of an AI security tool menu dynamically generated based on a capability registry, provided in one embodiment of this specification.

[0031] Figure 3 This is a schematic diagram illustrating AI performing inference feedback and re-inference according to one embodiment of this specification.

[0032] Figure 4 This is a schematic diagram of the structure of a vulnerability detection orchestration system based on artificial intelligence and historical penetration testing knowledge, provided in one embodiment of this specification.

[0033] Figure 5 This is a schematic diagram of the structure of an electronic device provided in one embodiment of this specification. Detailed Implementation

[0034] The subject matter described herein will now be discussed with reference to exemplary embodiments. It should be understood that these embodiments are discussed merely to enable those skilled in the art to better understand and implement the subject matter described herein, and are not intended to limit the scope, applicability, or examples set forth in the claims. The function and arrangement of the elements discussed may be changed without departing from the scope of this specification. Various processes or components may be omitted, substituted, or added as needed in the various examples. For example, the described methods may be performed in a different order than described, and steps may be added, omitted, or combined. Furthermore, features described in some examples may be combined in other examples.

[0035] As used herein, the term "comprising" and its variations are open terms meaning "including but not limited to". The term "based on" means "at least partially based on". The terms "one embodiment" and "an embodiment" mean "at least one embodiment". The term "another embodiment" means "at least one other embodiment". The terms "first", "second", etc., may refer to different or the same objects. Other definitions, whether explicit or implicit, may be included below. Unless explicitly indicated by the context, the definition of a term shall remain consistent throughout the specification.

[0036] Please see Figure 1 , Figure 1 This document illustrates an overall flowchart of a vulnerability detection orchestration method based on artificial intelligence and historical penetration testing knowledge, as provided in an embodiment of this specification.

[0037] like Figure 1As shown, this vulnerability detection orchestration method based on artificial intelligence and historical penetration testing knowledge includes at least the following steps:

[0038] Step S102: Receive historical reports, preprocess the historical reports to form standardized desensitized text, the preprocessing includes content deduplication, controlled format parsing, and sensitive information replacement.

[0039] Specifically, historical reports, including but not limited to penetration test reports, vulnerability notifications, remediation records, and their attachments, are received at a secure access point in the cloud. Upon receiving the data, preprocessing steps are performed. These steps include, but are not limited to, content deduplication, controlled format parsing, and sensitive information replacement. Content deduplication can be based on the summary information of the file content to identify duplicates, preventing the same report from being repeatedly included in the knowledge base due to filename, storage location, or slight format changes, thus ensuring the basic purity of subsequent knowledge aggregation. During batch import of directories, the system identifies identical files based on the file content summary and skips duplicates; when a single document is created or uploaded, the content summary is recorded for traceability. When the file content changes, a new summary is generated and processed as new input. The controlled format parsing step includes, for files identified as being imported for the first time, the system selects the appropriate parser based on the file type. For Word reports, the parsing process strictly follows the internal order of the document to read paragraphs and tables, maintaining the original narrative logic and ensuring that the contextual relationship between multi-paragraph verification steps, request / response fragments, and their descriptions is not disrupted. For PDF, HTML, Markdown, Excel, and other formats, the corresponding parsers are used to restore the text and table structure. During parsing, the system performs controlled processing of embedded attachments, conversion of legacy documents, and optional image text recognition. Each extended processing step has resource limits, such as the number of attachments, expansion levels, image size, recognition time, and total processing time. Once the budget is exceeded, the system will stop expanding and mark that part as "restricted and unparsed," preventing abnormal or maliciously crafted reports from causing the parsing process to consume resources indefinitely.

[0040] The sensitive information replacement steps include hiding the target source, authentication information, passwords and keys, personal identification and contact information, internal addresses, and local file paths, and abstracting query parameter values ​​of identifier types; interface paths, HTTP methods, and parameter names are preserved. For example, the target source can be replaced with a placeholder, and the object identifier in the query parameters can be replaced with an identifier placeholder value. The current implementation does not automatically rewrite all numbers or universally unique identifiers in the interface path into semantic path variables.

[0041] Furthermore, after preprocessing, the system retains the parsed chapter data and segments the normalized text into processing segments with overlapping intervals based on length; source tags generated from embedded attachments and image text recognition are retained along with the text. During the knowledge extraction stage, duplicate findings in adjacent segments are merged, and source locations are saved when the model can recognize them. The segments themselves do not require the addition of independent file summaries and paragraph order fields, thus maintaining consistency with the current data structure.

[0042] Step S104: Extract knowledge from the standardized de-identified text in the cloud and convert the standardized de-identified text into vulnerability instances.

[0043] Specifically, the standardized and de-identified text output from the above steps can be extracted using the knowledge extraction module in the cloud. The system first determines whether the current task enables artificial intelligence (AI) services. If enabled, the cloud-based AI is invoked to independently analyze each text segment. When analyzing each segment, the AI ​​returns results according to preset structured field requirements, including but not limited to vulnerability type, applicable system, business module, affected location, request method, parameter name, preconditions, verification steps, judgment criteria, and false alarm prompts. The identification of AI-affected locations employs strict test context filtering: the system only detects addresses or request lines clearly intended for testing or attack, such as request examples containing HTTP methods, paths, and parameters. Announcement links, patch addresses, local file paths, or example placeholder content are not considered detection targets. This avoids incorrectly converting reference links in the report into objects for subsequent automated detection. Furthermore, whether AI services are enabled is adjusted in real-time based on the system's processing resources, business requirements, and whether the data carries a strict AI service identifier.

[0044] During the extraction process, the system also performs abstract replacements on the real host address and specific business object values. For example, "https: / / target.example.com / api / order / 10086" in the original report is replaced with "https: / / <host>In the request body, the real user ID, order number, etc., are replaced with semantic placeholders in the string " / api / order / {orderId}". This secondary replacement of sensitive information further ensures that the knowledge retains only reusable path shapes, HTTP methods, and parameter names, without carrying any specific environmental information. This prevents sensitive data leakage and enables the knowledge to be transferred across targets.

[0045] Furthermore, if the AI ​​service becomes unavailable, fails to launch, or the current task does not have AI enabled, the system will revert to the local rule extraction mode. The non-AI rules within the cloud-based knowledge extraction module identify vulnerable paragraphs and common fields using regular expressions, keyword matching, and document structure features. For example, they locate headings such as "Vulnerability Name," "Request Method," and "Verification Steps," and extract their subsequent content. While the accuracy of rule extraction is typically lower than AI, it ensures that the process remains uninterrupted even when AI is unavailable, still producing basically usable vulnerability instances.

[0046] After extraction and abstraction, the system enriches the knowledge of each vulnerability instance. This enrichment process automatically adds stable vulnerability semantics, component types, version information, applicable authentication requirements, and more specific verification conditions based on the extracted request lines, parameters, and business modules. For example, if the original report only states "unauthorized access to the order interface," the enrichment module might categorize it as "missing object-level permissions" based on the request method and response example, and add the required test account roles and resource conditions. After knowledge enrichment, each vulnerability instance possesses a relatively complete set of structured fields.

[0047] Step S106: Perform a quality assessment on the vulnerability instances, aggregate similar instances based on the quality assessment results, and transform them into a knowledge baseline.

[0048] Specifically, the quality assessment module in the cloud can be used to evaluate the quality of vulnerability instances. This quality assessment can include the following checks: whether the vulnerability name is clear and specific, rather than template text or vague descriptions such as "risk exists" or "needs to be fixed"; whether key attachments are missing, for example, if the report mentions screenshots or attachments as evidence but could not be extracted due to parsing limitations, resulting in incomplete verification evidence; whether target information is present, i.e., whether it includes identifiable affected locations, request methods, parameter names, etc.; and whether verifiable verification evidence is available, i.e., whether the verification steps, judgment criteria, and evidence descriptions are clear enough for other testers to reproduce the verification process based on the record. Based on the results of the above checks, the system marks each result as "quality met" or "low quality." Low-quality records will not proceed to the recommended process in subsequent steps, but will still be retained in the knowledge base with the reason for non-compliance, for later manual review or data supplementation.

[0049] Furthermore, for vulnerability instances that meet the quality standards, the system enters the aggregation phase. Aggregation groups vulnerability instances from different reports that are essentially the same into a unified vulnerability pattern. The basis for aggregation may include, but is not limited to, vulnerability semantics, aliases, and similarity relationships. Stable vulnerability semantics refers to the abstraction at the root cause or type level of the vulnerability, such as "object-level permission deficiency," "functional permission deficiency," and "file download privilege escalation." Aliases refer to different naming methods for the same vulnerability in different reports. Similarity relationships are calculated based on features such as path shape, business module, and parameter structure. Through aggregation, the details that differ from specific environments in multiple instances are stripped away, retaining the common characteristics of the vulnerability pattern, such as typical path shapes, request methods, key parameter names, common verification conditions, and common false alarm prompts. For example, two reports describing "order query interface can be accessed without authorization" and "horizontal privilege escalation to view other people's order details" respectively may be aggregated into the same pattern "object-level permission deficiency - order query," retaining abstract paths such as / api / order / {orderId} and GET methods within the pattern.

[0050] After aggregating vulnerability instances, the system checks if they meet the release criteria. If they do, the pattern becomes an automatically recommended baseline. Release criteria include: a valid status and historical instances. A valid status means the pattern has not been marked as obsolete, not covered by a patch statement, or disabled for any other reason; historical instances ensure the pattern originates from real reports and is not fabricated. Once these release criteria are met, the pattern is released as a versioned baseline. Upon release, the system assigns a version number to the pattern and writes the aggregated complete knowledge to the baseline repository. When new instances are subsequently aggregated, causing changes to the pattern's content, the system increments the version number. This ensures that each recommendation can be traced back to a specific knowledge version, avoiding inconsistent recommendation results at different times due to changes in knowledge content.

[0051] Step S108: Obtain local real-time project information; based on the real-time project information and in conjunction with the knowledge baseline, generate declarative detection suggestions in the cloud and feed them back to the local machine.

[0052] Specifically, the local client obtains real-time local project information, including the current target and local assets. This includes system type, business modules, functional characteristics, a complete list of interfaces (anonymized to path shapes and parameter names, excluding actual object values), and a local capability directory, and uploads this information to the cloud. This allows the cloud to understand the real-time project status (i.e., what the current target looks like and what detection capabilities the client possesses, but it does not know any credentials or specific resource IDs).

[0053] On one hand, the processing flow for structural paths is as follows: First, the cloud performs a hard screening based on knowledge status, quality, system type, and client capabilities, and then excludes unsuitable items based on the shape of the interface path, request method, and target binding relationship. Subsequently, the candidate items are scored and ranked based on business modules, historical priority, capability matching, and binding status. The interface list is used to bind historical path templates to currently existing targets, and will not generate interfaces that do not exist locally out of thin air. Functional features can be uploaded with project information, but currently they are mainly used as contextual information and do not constitute independent hard screening conditions.

[0054] For each successfully bound candidate detection item, the cloud can generate a declarative detection suggestion. This suggestion can be a structured detection recipe, containing the following fixed fields: knowledge source and version (tracing back to the knowledge baseline published in step S106), the type of local capability to be used (such as an object-level permission detector), required inputs and preconditions (e.g., requiring two test accounts and their respective pre-built resources), recommended verification steps (described in semantic steps, not the original request), success criteria, common false alarm scenarios, allowed HTTP methods, and maximum request volume (security budget). The cloud only considers read-based methods (such as GET) as automatically compatible; verification content involving data modification (POST / PUT / DELETE, etc.) or batch enumeration will be forcibly downgraded to manual processing and will not be included in the executable part of the automatic suggestion.

[0055] Furthermore, the cloud-based system sorts all candidate suggestions, taking into account factors such as knowledge quality, historical priority, system type and business module compatibility, successful binding to the current target interface, and client capability. The sorted, structured plan path is then returned to the client.

[0056] On the other hand, the dialogue path is relatively lightweight. At the dialogue entry point, the frontend sends the project identifier and dialogue history of the local real-time project information to the backend task, and can optionally pass in the system type, business module, and historical knowledge identifier, but does not automatically add the complete list of project interfaces to the context of each round. When the AI ​​deems historical experience necessary, it will invoke the baseline recommendation capability to query cloud knowledge according to the system type, business module, and functional characteristics given in the dialogue. The content returned by this path includes applicable vulnerability types, priority, inspection points, and local capability hints, but does not include precise binding information to specific interfaces. Therefore, the dialogue path is mainly used to help testers choose the detection direction or understand the typical verification approach for a certain type of vulnerability; when precise interface binding is required, the system will prompt to switch to the structured plan path.

[0057] The two paths share the following principles: cloud output is always a "declarative suggestion," never directly triggering any local execution; all suggestions come with security budgets and method restrictions; real accounts, resource IDs, and authentication information remain locally and are bound in subsequent steps during the local compilation phase. This transforms abstract versioning knowledge into locally verifiable detection candidates relevant to the current goal, providing a specification basis for the next rigorous compilation and planning steps.

[0058] Step S110: The declarative detection suggestions are compiled into an execution plan locally. After multidimensional consistency verification and asset binding, the plan steps are generated.

[0059] Specifically, after receiving declarative detection suggestions from the cloud, the local client cannot execute them directly. Instead, it needs to enter the local compilation module. The compilation module checks the format compatibility of the suggestions, confirming that their structure conforms to the specifications defined by the local plan parser, and that the fields are complete and of the correct type. If the format is incompatible or contains unparseable content, the suggestion is marked as an exception and will not proceed to the next step.

[0060] If the format check passes, the system proceeds to the multidimensional consistency verification phase. The verification includes the following key dimensions:

[0061] 1. Consistency between vulnerability semantics, detection capabilities, and executors. The system confirms that the vulnerability semantics corresponding to the knowledge number referenced in the recommendation are consistent with the semantic type of a certain detection capability in the local registry, and that the capability matches the executor (self-developed detector or external adapter) specified in the recommendation. The knowledge number is only used for tracing the source and cannot be directly used as the basis for selecting the detector to prevent erroneous execution due to number reuse or mapping errors. Capability versions must also be compatible to ensure that the currently registered detector version can implement the verification logic required by the recommendation.

[0062] Second, the existence verification of the target interface. The system compares the suggested target interface path shape, request method, and parameter names with the local interface list to confirm that the target does indeed exist in the system under test. If the suggested interface path cannot be found in the local list, or the path shape does not match, the suggestion cannot form an executable step and is marked as "target does not exist".

[0063] Third, a dual permission check for request methods. The system verifies whether the HTTP methods allowed in the recommendation are simultaneously permitted by both parties: first, the methods declared in the cloud recommendation itself (usually read-based methods); and second, the permitted methods configured in the project's authorization policy. If neither party allows them, the recommendation cannot be executed automatically.

[0064] Fourth, a sufficiency check of the requested budget and resources. The system calculates the number of requests required to execute the suggestion and compares it with the project's "single task request limit" and the number of remaining available requests for the task. If the budget is insufficient, the suggestion is marked as "insufficient budget" and either processed manually or skipped.

[0065] After verifying the above dimensions, the compilation module records the target interface, allowed methods, detection capabilities, executor, request budget, and required local asset types in the planning steps, such as test accounts, provisioned resources, or path parameters. The actual values ​​of account credentials, resource identifiers, and path parameters are not written into the compiled planning steps; testers submit these values ​​locally when starting the task, and the execution engine then parses and verifies their sufficiency, target matching relationships, and project authorization scope. Real authentication information, object values, and path parameters are never uploaded to the cloud.

[0066] Based on the verification and binding results, the compilation module will suggest categorizing the following into three types:

[0067] Executable plan steps: Format, semantics, capabilities, executors, objectives, methods, and budget conditions are all satisfied. Each step has a stable step identifier; this identifier is generated based on capabilities, knowledge baseline, objective identifier, and compilation order, or it can be inherited from cloud-based verification identifiers, with upstream content summaries retained separately for traceability. The actual values ​​of account, resource, and path parameters are not included in the step identifier calculation. The tester's confirmation record is the selected set of step identifiers; during task execution, the system re-executes the asset, scope, method, and budget verification plan for the currently submitted binding values.

[0068] Manual or Skipped Items: Items that can only be handled manually, lack local capabilities or objectives, have insufficient budgets, or lack necessary test assets are marked as not automatically executable and displayed as either manual or skipped items, allowing testers to decide on subsequent actions.

[0069] Fatal Block: A suggestion is deemed a fatal block if semantic conflicts, dangerous behavior, or incompatible formats exist. For example, the suggested verification logic may conflict with prohibited actions in the project, the combined parameters may trigger write operations, or the capabilities may be severely mismatched with the executor. When a fatal block exists, the system will not execute the remaining steps in the current plan by default, requiring testers to reselect a clearly defined safe subset to avoid executing with defects.

[0070] After compilation, the executable plan steps are presented to testers in a structured plan format. Testers select and confirm the steps to be executed, and the system records the set of confirmed step identifiers. Once confirmed, the structured task is executed directly by the local execution engine in the order of the steps, without requiring artificial intelligence to reselect targets or resources. When the currently running binding values ​​change, the execution entry point will be re-verified, but new step identifiers will not be automatically generated or existing step confirmations will not be revoked simply because of changes in binding values. Dialogue tasks, on the other hand, are orchestrated by a separate artificial intelligence tool.

[0071] Step S112: In conjunction with artificial intelligence, the planned steps or dialogue intent reasoning are converted into a tool call sequence within the local tools menu.

[0072] Specifically, the system dynamically generates a menu of security tools for fixed purposes on the local client, including but not limited to unauthorized access, object-level permissions, function-level permissions, file download permissions, data export permissions, sensitive field return, management or debugging entry exposure, security response headers, interface rate limiting sampling, setting session authorization scope, and querying historical baselines. Each type of self-developed detector uses an identifier in the local registry as a discrete tool item; the parameters adopt a fixed structure, which may include fields such as target address, endpoint, account, and resource, and accept structure, authorization scope, and security policy verification at the execution entry point.

[0073] Additionally, a diagram illustrating the AI ​​security tool menu dynamically generated based on the capability registry is shown below. Figure 2 As shown, in Figure 2 The documentation explicitly states that the Security Tools menu module does not delegate underlying network capabilities to artificial intelligence as is. Instead, it generates a set of fixed-purpose optional tools based on the detectors and allowed adapters already registered with the current client. The identifiers for self-developed detectors are derived from the registry; external tools only expose pre-allowed tags, scan modes, rates, and port profiles. Tools that are not installed or configured will explicitly return "unavailable."

[0074] Artificial intelligence (AI) can only invoke registered detectors or allowed adapters; it cannot provide arbitrary command lines, raw HTTP request methods, or request bodies, nor can it bypass the execution entry point to expand the project's authorized scope. AI can fill in structured target, endpoint, account, and resource parameters allowed by the tool mode; the execution entry point will still be restricted based on domain name or IP range, request method, request budget, and the adapter's tags, mode, rate, duration, and port file whitelist. Adding new detection capabilities requires prior local registration and capability description.

[0075] For conversational tasks involving user interaction, the AI ​​selects one or more tools from the tool menu and provides structured parameters based on the current conversation history, project authorization policies, and user intent. Parameters may include target addresses, endpoints, accounts, and resource data supported by the tool mode, but must be validated through project domain or IP authorization scope, allowed methods, request budget, and adapter whitelist. The AI ​​cannot directly submit raw HTTP methods, request bodies, or arbitrary command lines.

[0076] After receiving the AI's tool selections, the system orchestrator executes the selected tools one by one. The execution process does not involve the AI ​​directly initiating network requests; instead, it is handled by the local detection engine or external adapter according to its inherent capabilities. After each tool execution, the system adds the completion status (success, failure, blocked), the number of discoveries (e.g., how many vulnerabilities were discovered), and an error summary as a tool message to the dialogue context, requesting the AI ​​to make a decision again. Based on this feedback, the AI ​​decides whether to continue calling the next tool, switch detection tools, or end the current task and provide a summary. This "inference-tool-re-inference" loop can be configured with a maximum number of inferences and tool calls to prevent infinite loops. Even without automatic limits by default, users can still terminate the background task using the stop function.

[0077] The diagram illustrating AI's reasoning, feedback, and further reasoning can be shown as follows: Figure 3 As shown, in Figure 3 The document clearly states that the AI ​​first selects one or more tools from the security tools menu and provides structured parameters; the system executes each tool sequentially, providing feedback on completion status, number of findings, and error summaries to the AI; based on this, the AI ​​decides whether to continue, adjust tools, or terminate. When the AI ​​no longer selects a tool, the system outputs a summary of this round. The project has implemented configurable control over the number of inferences and tool calls; even without automatic limits by default, users can still terminate background tasks using the stop function.

[0078] For structured tasks (structured paths in step S108), the planned steps have already determined the step identifiers, target interfaces, detection capabilities, executors, and required asset types. After the front-end submits the step identifiers and local binding values ​​selected and confirmed by the testers, the local execution engine directly assigns the corresponding detectors according to the planned order, and continues, skips, or blocks subsequent steps based on the execution status of each step; artificial intelligence does not participate in the step mapping or supplementary tool selection for structured plans. The account, resource, and path parameters bound at runtime still need to be checked locally in the plan.

[0079] Regarding the execution of dialogue tasks, the system runs the tasks in a background process, while the front end receives inference text, tool progress, and vulnerability discovery events in real time. Only one active dialogue task is allowed per project at any given time to avoid state chaos caused by concurrent operations. When the user clicks "stop," the desktop core terminates the detection engine and its child processes; discoveries already written to the result database via events before stopping are retained and will not be rolled back. The current dialogue path is not paused at the tool level for confirmation, but hard restrictions such as authorization scope, prohibited actions, request budget, tags, modes, rates, durations, and port files remain in effect, sharing the same underlying security mechanism as the structured path. While maintaining AI intelligent scheduling capabilities, the system confines all execution actions within the security boundaries of locally registered detectors and controlled adapters. The AI's output is not raw network traffic, but a sequence of tool calls verified by a whitelist.

[0080] Step S114: Detection is performed based on the tool's call sequence, and the detection results are de-identified and sent back to the cloud for baseline matching, forming a closed loop for the security detection task.

[0081] Specifically, the structured plan performs multi-layered checks at the execution entry point and within the engine, including basic objectives, permitted methods, single-task request limits, prohibited actions, selected step confirmation status, capabilities, detectors, target interfaces, test assets, path parameters, and step budgets. The dialog path does not perform plan step confirmation checks, but shares project authorization scope, prohibited actions, request budgets, and adapter whitelist restrictions with the structured path.

[0082] In addition, the system converts the output of self-developed detectors and external adapters into a unified vulnerability discovery format. Local discovery records for structured plans include appended vulnerability semantics, capability identifiers, target methods, affected parameters, knowledge sources, plan identifiers, and step identifiers. When imported to the cloud, core matching fields are written to the scan discovery record, while the complete anonymized input context is retained in the scan import record for tracing the source of local plans and steps.

[0083] When the dialog mode directly invokes the detector, there are no structured planning steps; therefore, only the actual context of the path is recorded. All vulnerability evidence invokes a local desensitizer during result construction to hide the target source, query parameter values ​​for identifier types, authentication information, passwords and keys, personal identification and contact information, internal addresses, and local file paths, while retaining the interface path and sensitive type labels. The current implementation does not uniformly abstract all object numbers in the interface path. Sensitive field detection only reports the types of sensitive information found and does not return the actual value plan.

[0084] Furthermore, when cloud-based categorization is required, the client converts locally anonymized findings into cloud-acceptable scan records, sequentially completing result import, baseline matching, and matching result querying. The cloud associates findings with historical knowledge baselines based on rules, aliases, and similarity relationships, and can generate manual review tasks. The current project's report page integrates local findings and cloud matching results, without relying on a separate, yet-to-be-implemented, cloud reporting interface. In this way, detection results not only remain in local records but can also be used to verify the effectiveness and coverage of the knowledge baseline, providing feedback for subsequent knowledge optimization.

[0085] The system records missing capabilities, non-existent targets, insufficient budget, unconfirmed requests, user rejections, detection anomalies, and security policy blocking during the compilation and execution of the plan. Operations such as project creation, target configuration, plan generation, task execution, scope changes, task blocking, and cloud interactions are all written to local audit logs, forming a complete operation trajectory. After task completion, testers can view evidence in the results center, check the local findings and cloud matching conclusions on the report page, and supplement test assets, modify authorized scopes, or regenerate plans based on the reasons for coverage gaps, forming the next round of controlled testing. Through these steps, multi-layered protection at the execution layer, anonymization and state management at the result layer, matching feedback at the cloud layer, and traceability at the audit layer are integrated, completing a full process from historical report knowledge construction to local secure execution and ultimately forming a closed-loop feedback loop.

[0086] In this embodiment, a vulnerability detection orchestration method based on artificial intelligence and historical penetration testing knowledge includes: receiving historical reports; preprocessing the historical reports to form standardized de-identified text; extracting knowledge from the standardized de-identified text in the cloud and converting it into vulnerability instances; performing quality evaluation on the vulnerability instances and aggregating them into similar instances to convert them into knowledge baselines; acquiring local real-time project information and, in conjunction with the knowledge baselines, generating declarative detection suggestions in the cloud and feeding them back to the local machine; compiling the declarative detection suggestions into an execution plan locally and generating plan steps; combining artificial intelligence, converting the plan steps or dialogue intent reasoning into a tool call sequence within the local tool menu; executing detection based on the tool call sequence, and de-identifying the detection results and sending them back to the cloud for baseline matching, forming a closed loop for the security detection task. This embodiment transforms heterogeneous, unstructured historical reports into structured instances and aggregates them into versioned baselines, thereby converting documentation into executable detection capabilities. It also avoids erroneous executions caused by vulnerability number reuse, version drift, and target mismatches through cloud-based semantic matching and local multi-dimensional consistency verification. Furthermore, by treating cloud output as suggestions and compiling a local plan, it ensures that detection actions only execute verified and securely controllable steps. Finally, it minimizes requests and requires explicit authorization to complete business security verification by embedding low-risk detectors and controlled AI orchestration. Finally, through multi-layered execution protection and local de-identification and feedback, it forms a closed-loop security detection system where sensitive data remains locally and is fully traceable.

[0087] Please refer to the following. Figure 4 , Figure 4 This diagram illustrates the structure of a vulnerability detection orchestration system based on artificial intelligence and historical penetration testing knowledge, as provided in an embodiment of this specification. It should be noted that... Figure 4 The vulnerability detection orchestration system shown, based on artificial intelligence and historical penetration testing knowledge, is used to execute this specification. Figure 1 The methods shown in the embodiments are illustrated for ease of explanation, showing only the parts related to the embodiments of this specification. For specific technical details not disclosed, please refer to this specification. Figure 1 The example shown.

[0088] like Figure 4 As shown, this vulnerability detection orchestration system based on artificial intelligence and historical penetration testing knowledge can include at least:

[0089] The report access module S402 is used to receive historical reports, preprocess the historical reports to form standardized desensitized text, and the preprocessing includes content deduplication, controlled format parsing, and sensitive information replacement.

[0090] The knowledge extraction module S404 is used to extract knowledge from the standardized de-identified text in the cloud and convert the standardized de-identified text into vulnerability instances.

[0091] The knowledge quality module S406 is used to perform quality evaluation on the vulnerability instances, aggregate similar instances based on the quality evaluation results, and transform them into knowledge baselines.

[0092] The baseline publishing module S408 is used to obtain local real-time project information, and based on the real-time project information and the knowledge baseline, generate declarative detection suggestions in the cloud and feed them back to the local machine.

[0093] The plan compilation module S410 is used to compile the declarative detection suggestions into an execution plan locally, and generate plan steps after multidimensional consistency verification and asset binding;

[0094] The reasoning module S412 is used to combine artificial intelligence to convert the planned steps or dialogue intent reasoning into a tool call sequence within the local tool menu;

[0095] The detection module S414 is used to perform detection based on the tool's call sequence, and to de-identify the detection results and send them back to the cloud for baseline matching, thus forming a closed loop for the security detection task.

[0096] Those skilled in the art will clearly understand that the technical solutions of the embodiments in this specification can be implemented by means of software and / or hardware. In this specification, "unit" and "module" refer to software and / or hardware that can independently complete or cooperate with other components to complete a specific function, wherein the hardware may be, for example, a field-programmable gate array (FPGA), an integrated circuit (IC), etc.

[0097] Each processing unit and / or module in the embodiments of this specification can be implemented by an analog circuit that implements the functions described in the embodiments of this specification, or by software that executes the functions described in the embodiments of this specification.

[0098] See Figure 5 It shows a schematic diagram of the structure of an electronic device according to an embodiment of this specification, which can be used to implement... Figure 1 The method in the illustrated embodiment. (As shown) Figure 5 As shown, the electronic device 500 may include: at least one central processing unit 501, at least one network interface 504, user interface 503, memory 505, and at least one communication bus 502.

[0099] The communication bus 502 is used to enable communication between these components.

[0100] The user interface 503 may include a display screen and a camera. Optionally, the user interface 503 may also include a standard wired interface and a wireless interface.

[0101] The network interface 504 may optionally include a standard wired interface or a wireless interface (such as a Wi-Fi interface).

[0102] The processor 501 may include one or more processing cores. The processor 501 connects to various parts within the electronic device 500 using various interfaces and lines, and performs various functions and processes data by running or executing instructions, programs, code sets, or instruction sets stored in the memory 505, and by calling data stored in the memory 505. Optionally, the processor 501 may be implemented using at least one hardware form of Digital Signal Processing (DSP), Field-Programmable Gate Array (FPGA), or Programmable Logic Array (PLA). The processor 501 may integrate one or a combination of several of the following: a Central Processing Unit (CPU), a Graphics Processing Unit (GPU), and a modem. The CPU primarily handles the operating system, user interface, and applications; the GPU is responsible for rendering and drawing the content required for display; and the modem handles wireless communication. It is understood that the modem may also not be integrated into the processor 501 and may be implemented as a separate chip.

[0103] The memory 505 may include random access memory (RAM) or read-only memory. Optionally, the memory 505 may include a non-transitory computer-readable storage medium. The memory 505 can be used to store instructions, programs, code, code sets, or instruction sets. The memory 505 may include a program storage area and a data storage area, wherein the program storage area may store instructions for implementing an operating system, instructions for at least one function (such as touch function, sound playback function, image playback function, etc.), instructions for implementing the above-described method embodiments, etc.; the data storage area may store data involved in the above-described method embodiments, etc. Optionally, the memory 505 may also be at least one storage system located remotely from the aforementioned processor 501. Figure 5 As shown, the memory 505, which serves as a computer storage medium, may include an operating system, a network communication module, a user interface module, and program instructions.

[0104] exist Figure 5 In the illustrated electronic device 500, the user interface 503 is mainly used to provide an input interface for the user and to acquire user input data; while the processor 501 can be used to call the image-based interactive application stored in the memory 505 and specifically perform the following operations:

[0105] Receive historical reports, preprocess the historical reports to form standardized desensitized text, the preprocessing includes content deduplication, controlled format parsing, and sensitive information replacement;

[0106] Knowledge extraction is performed on the standardized de-identified text in the cloud, and the standardized de-identified text is converted into vulnerability instances;

[0107] The vulnerability instances are evaluated for quality, and the results of the quality evaluation are aggregated into similar instances and transformed into a knowledge baseline.

[0108] Obtain local real-time project information, and based on the real-time project information and knowledge baseline, generate declarative detection suggestions in the cloud and feed them back to the local machine;

[0109] The declarative detection recommendations are compiled into an execution plan locally, and the plan steps are generated after multidimensional consistency verification and asset binding.

[0110] By combining artificial intelligence, the planned steps or dialogue intent reasoning are transformed into a tool call sequence within the local tools menu;

[0111] The detection is performed based on the sequence called by the tool, and the detection results are anonymized and sent back to the cloud for baseline matching, forming a closed loop for the security detection task.

[0112] As an optional embodiment of this specification, the preprocessing includes:

[0113] Duplicate files are identified based on the content summary of the historical reports, and a parser is selected for the first detected file according to its file type;

[0114] Sensitive information is replaced in the parsed text, replacing real parameters and personal information with abstract placeholders, which retain the path shape, HTTP method, and parameter name;

[0115] The replaced text is segmented, and a source identifier is appended to each segment.

[0116] As an optional embodiment of this specification, the step of extracting knowledge from the standardized de-identified text in the cloud and converting the standardized de-identified text into vulnerability instances includes:

[0117] Artificial intelligence is used to independently analyze each segment of the standardized de-identified text and merge vulnerabilities found repeatedly in adjacent segments;

[0118] When analyzing each segment independently, the artificial intelligence only identifies addresses or request lines with test context and performs secondary replacement on the extracted real parameters and personal information;

[0119] The extracted fragments after the second replacement are enriched with knowledge to generate vulnerability instances. The knowledge enrichment includes supplementing stable vulnerability semantics, component types, version information, authentication requirements, and verification conditions.

[0120] As an optional embodiment of this specification, the method further includes:

[0121] When the aforementioned artificial intelligence is not enabled, it reverts to the local rule mode in the cloud, and identifies the vulnerable segments and common fields of each segment through cloud rules.

[0122] As an optional embodiment of this specification, the step of obtaining local real-time project information and, based on the real-time project information and in conjunction with a knowledge baseline, generating declarative detection suggestions in the cloud and feeding them back to the local machine includes:

[0123] The feedback path to the local machine includes a structured path and a dialogue path;

[0124] The feedback path of the structured path includes:

[0125] The local client obtains local real-time project information and submits it to the cloud. The cloud excludes inapplicable knowledge baselines based on the real-time project information and binds the data attributes of the real-time project information to the current interface.

[0126] For each successfully bound candidate detection item, a structured detection suggestion is generated, and the structured detection suggestions are sorted and fed back to the local client;

[0127] The feedback path of the dialogue path includes:

[0128] The system queries cloud-based knowledge based on the real-time project information and returns declarative recommendations applicable locally, in conjunction with the knowledge baseline.

[0129] As an optional embodiment of this specification, the step of combining artificial intelligence to convert the planned steps or dialogue intent reasoning into a tool call sequence within the local tools menu includes:

[0130] Dynamically generate a security tool menu based on the local registry and adapter whitelist;

[0131] The artificial intelligence selects a tool from the security tools menu and provides structured parameters, which are limited to the range defined by the security tools menu;

[0132] The orchestrator executes the selected tool, feeds back the tool execution structure to the artificial intelligence, and obtains the execution feedback from the artificial intelligence;

[0133] For the structured path, the artificial intelligence maps each step to the corresponding detector tool call in the order of the planned steps;

[0134] For the aforementioned dialogue path, the artificial intelligence selects and invokes the corresponding detector tool based on the dialogue history.

[0135] As an optional embodiment of this specification, the desensitization process includes:

[0136] The detection results are converted into a unified vulnerability discovery format and local desensitization is performed during the construction process. The desensitized objects include the target host, object number, authentication information, password and key, internal address, and local file path, while retaining the path shape, sensitive type labels, and verification relationships.

[0137] Furthermore, the sensitive field detection only reports the types of sensitive information found, without returning the actual values.

[0138] This specification also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the above-described method. The computer-readable storage medium may include, but is not limited to, any type of disk, including floppy disks, optical disks, DVDs, CD-ROMs, microdrives, as well as magneto-optical disks, ROMs, RAMs, EPROMs, EEPROMs, DRAMs, VRAMs, flash memory devices, magnetic cards or optical cards, nanosystems (including molecular memory ICs), or any type of medium or device suitable for storing instructions and / or data.

[0139] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that this specification is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this specification. Furthermore, those skilled in the art should also understand that the embodiments described in this specification are preferred embodiments, and the actions and modules involved are not necessarily essential to this specification.

[0140] In the above embodiments, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions in other embodiments.

[0141] In the embodiments provided in this specification, it should be understood that the disclosed system can be implemented in other ways. For example, the system embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some service interface; the indirect coupling or communication connection between systems or units may be electrical or other forms.

[0142] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0143] Furthermore, the functional units in the various embodiments of this specification can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0144] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage device (CMD). Based on this understanding, the technical solution of this specification, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a memory and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this specification. The aforementioned memory includes various media capable of storing program code, such as USB flash drives, read-only memory (ROM), random access memory (RAM), portable hard drives, magnetic disks, or optical disks.

[0145] Those skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be implemented by a program instructing related hardware. The program can be stored in a computer-readable storage medium, which may include: a flash drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk, etc.

[0146] The foregoing has described specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired result. In some embodiments, multitasking and parallel processing are possible or may be advantageous.< / host>

Claims

1. A vulnerability detection orchestration method based on artificial intelligence and historical penetration testing knowledge, characterized in that, The method includes: Receive historical reports, preprocess the historical reports to form standardized desensitized text, the preprocessing includes content deduplication, controlled format parsing, and sensitive information replacement; Knowledge extraction is performed on the standardized de-identified text in the cloud, and the standardized de-identified text is converted into vulnerability instances; The vulnerability instances are evaluated for quality, and the results of the quality evaluation are aggregated into similar instances and transformed into a knowledge baseline. Obtain local real-time project information, and based on the real-time project information and knowledge baseline, generate declarative detection suggestions in the cloud and feed them back to the local machine; The declarative detection recommendations are compiled into an execution plan locally, and the plan steps are generated after multidimensional consistency verification and asset binding. By combining artificial intelligence, the planned steps or dialogue intent reasoning are transformed into a tool call sequence within the local tools menu; The detection is performed based on the sequence called by the tool, and the detection results are anonymized and sent back to the cloud for baseline matching, forming a closed loop for the security detection task.

2. The vulnerability detection orchestration method based on artificial intelligence and historical penetration testing knowledge according to claim 1, characterized in that, The preprocessing includes: Duplicate files are identified based on the content summary of the historical reports, and a parser is selected for the files to be processed according to their file types; Sensitive information is replaced in the parsed text, replacing real parameters and personal information with abstract placeholders, which retain the interface path, HTTP method and parameter name; The replaced text is segmented, and a source identifier is appended to each segment.

3. The vulnerability detection orchestration method based on artificial intelligence and historical penetration testing knowledge according to claim 2, characterized in that, The process of extracting knowledge from the standardized and de-identified text in the cloud and converting the standardized and de-identified text into vulnerability instances includes... Artificial intelligence is used to independently analyze each segment of the standardized de-identified text and merge vulnerabilities found repeatedly in adjacent segments; When analyzing each segment independently, the artificial intelligence only identifies addresses or request lines with test context and performs secondary replacement on the extracted real parameters and personal information; The extracted fragments after the second replacement are enriched with knowledge to generate vulnerability instances. The knowledge enrichment includes supplementing stable vulnerability semantics, component types, version information, authentication requirements, and verification conditions.

4. The vulnerability detection orchestration method based on artificial intelligence and historical penetration testing knowledge according to claim 3, characterized in that, The method further includes: When the aforementioned artificial intelligence is not enabled, it reverts to the local rule mode in the cloud, and identifies the vulnerable segments and common fields of each segment through cloud rules.

5. The vulnerability detection orchestration method based on artificial intelligence and historical penetration testing knowledge according to claim 1, characterized in that, The process of acquiring local real-time project information, and based on this real-time project information and a knowledge baseline, generating declarative detection suggestions in the cloud and feeding them back to the local system, includes: The feedback path to the local machine includes a structured path and a dialogue path; The feedback path of the structured path includes: The local client obtains local real-time project information and submits it to the cloud. The cloud excludes inapplicable knowledge baselines based on the real-time project information and binds the data attributes of the real-time project information to the current interface. For each successfully bound candidate detection item, a structured detection suggestion is generated, and the structured detection suggestions are sorted and fed back to the local client; The feedback path of the dialogue path includes: The system queries cloud-based knowledge based on the real-time project information and returns declarative recommendations applicable locally, in conjunction with the knowledge baseline.

6. The vulnerability detection orchestration method based on artificial intelligence and historical penetration testing knowledge according to claim 5, characterized in that, The integration of artificial intelligence, within the local tools menu, transforms the planned steps or dialogue intent reasoning into a tool call sequence, including: Dynamically generate a security tool menu based on the local registry and adapter whitelist; The artificial intelligence selects a tool from the security tools menu and provides structured parameters, which are limited to the range defined by the security tools menu; The orchestrator executes the selected tool, feeds back the tool execution structure to the artificial intelligence, and obtains the execution feedback from the artificial intelligence; For the structured path, the local execution engine maps each step directly to the corresponding registered detector and executes the plan according to the confirmed sequence of planned steps; For the aforementioned dialogue path, the artificial intelligence selects and invokes the corresponding detector tool based on the dialogue history.

7. The vulnerability detection orchestration method based on artificial intelligence and historical penetration testing knowledge according to claim 1, characterized in that, The desensitization process includes: The detection results are converted into a unified vulnerability discovery format and local desensitization is performed during construction. The desensitized objects include the target source, query parameter values ​​of identifier types, authentication information, passwords and keys, personal identity and contact information, internal addresses and local file paths, while retaining interface paths, sensitive type tags and verification relationships. Furthermore, the sensitive field detection only reports the types of sensitive information found, without returning the actual values.

8. A vulnerability detection orchestration system based on artificial intelligence and historical penetration testing knowledge, characterized in that, The system includes: The report access module is used to receive historical reports, preprocess the historical reports to form standardized desensitized text, and the preprocessing includes content deduplication, controlled format parsing, and sensitive information replacement. The knowledge extraction module is used to extract knowledge from the standardized de-identified text in the cloud and convert the standardized de-identified text into vulnerability instances. The knowledge quality module is used to evaluate the quality of the vulnerability instances, aggregate similar instances based on the quality evaluation results, and transform them into knowledge baselines. The baseline publishing module is used to obtain local real-time project information, and based on the real-time project information and the knowledge baseline, generate declarative detection suggestions in the cloud and feed them back to the local system. The plan compilation module is used to compile the declarative detection suggestions into an execution plan locally, and generate plan steps after multidimensional consistency verification and asset binding; The reasoning module is used to combine artificial intelligence to convert the planned steps or dialogue intent reasoning into a tool call sequence within the local tools menu; The detection module is used to perform detection based on the tool's call sequence, and to anonymize the detection results and send them back to the cloud for baseline matching, thus forming a closed loop for the security detection task.

9. An electronic device, comprising a processor and a memory; The processor is connected to the memory; The memory is used to store executable program code; The processor runs a program corresponding to the executable program code stored in the memory to perform the method as described in any one of claims 1-7.

10. A computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the method as described in any one of claims 1-7.

Images