Adaptive scanning path planning method and device for ai software supply chain

Abstract

The application belongs to the technical field of software supply chain security detection and is used for solving the problem that the prior art cannot introduce dynamic feedback based on actual execution results in the scanning scheduling process, so that the scanner capability evaluation and project risk demand estimation can be continuously corrected as the scanning experience accumulates, specifically an adaptive scanning path planning method and device for an AI software supply chain, comprising: acquiring an original feature vector of a target project; calculating the scheduling matching degree of each scanner; dynamically determining an overlap penalty coefficient according to the scheduling matching degree and a global stability index, and based on the overlap penalty coefficient and the maximum capability overlap degree of each scanner and the selected set, iteratively performing marginal gain greedy selection to obtain a final scanner combination; the application constructs a deviation feedback loop between the actual detection rate and the scheduling matching degree, so that the capability confidence coefficient of the scanner can be corrected gradually according to the historical scanning results.

Description

Technical Field

[0001] This invention belongs to the field of software supply chain security detection technology, specifically an adaptive scanning path planning method and device for AI software supply chain. Background Technology

[0002] In AI software supply chain security testing, a common practice is to first attach capability tags to the scanner, indicating which vulnerability types it supports and which artifact formats it adapts to, and then use global historical detection rates or static matching degrees for combined scheduling; the model is usually called separately outside of scanning, on the premise that the tags can reflect the actual detection effectiveness.

[0003] However, the dependency structures, model file formats, and code calling patterns of different AI projects vary significantly, which may lead to discrepancies between the actual detection performance of the same scanner on different projects and its static capability labels. For example, a scanner labeled as supporting "Pickle deserialization detection" may only cover specific attack patterns, but fail to capture the actual deserialization call chain. Existing scheduling lacks a closed loop that uses the actual detection rate as feedback during execution to correct the scanner's capability confidence. Scanners with inflated labels will be continuously selected with high priority, and will be repeatedly called by multiple projects. Although there will be detection results each time, the scheduling weight will not be reduced, forming a "false belief - reselection - false belief again" lock. In addition, existing technologies lack a mechanism to reverse-calibrate the project risk requirement vector based on the actual detected vulnerabilities, making it difficult for the initial feature mapping rules to evolve on their own once they are set.

[0004] Therefore, how to introduce dynamic feedback based on actual execution results during the scanning scheduling process, so that scanner capability assessment and project risk requirement estimation can be continuously corrected as scanning experience accumulates, has become an urgent technical problem to be solved. Summary of the Invention

[0005] The purpose of this invention is to provide an adaptive scanning path planning method and apparatus for the AI ​​software supply chain, which solves the problem that existing technologies cannot introduce dynamic feedback based on actual execution results during the scanning scheduling process, so that scanner capability assessment and project risk requirement estimation can be continuously corrected as scanning experience is accumulated. The technical problem to be solved by the present invention is: how to provide an adaptive scanning path planning method and device for the AI ​​software supply chain that can introduce dynamic feedback based on actual execution results during the scanning scheduling process, so that scanner capability assessment and project risk requirement estimation can be continuously corrected with the accumulation of scanning experience.

[0006] The objective of this invention can be achieved through the following technical solutions: An adaptive scanning path planning method for the AI ​​software supply chain includes: Obtain the original feature vector of the target project and generate a project risk requirement vector based on it. The dimension of the project risk requirement vector is aligned with the capability dimension of the scanner. Obtain the static capability vector, capability confidence coefficient, and utility history of each scanner in the candidate scanner set; Based on the project risk demand vector, static capability vector, capability confidence coefficient, and utility history, calculate the scheduling matching degree of each scanner; Obtain the set of required scanners and the global stability index. Dynamically determine the overlap penalty coefficient based on the global stability index. Iteratively perform a greedy selection based on the scheduling matching degree, the overlap penalty coefficient, and the maximum capability overlap between each scanner and the selected set to obtain the final scanner combination. The final scanner combination is invoked to perform a scan and obtain the actual detection rate. Based on the deviation between the actual detection rate and the scheduling matching degree, update the capability confidence coefficient and utility history, and update the global stability index according to the fluctuation of multiple deviations.

[0007] The present invention has the following beneficial effects: 1. Construct a deviation loop between the actual detection rate and the scheduling matching degree, and adjust the capability confidence coefficient according to historical results; if a scanner performs better than expected in multitasking, the coefficient will rise and the matching degree will increase accordingly; if the performance is poor, it will be lowered; negative feedback pulls the decision towards the true detection capability, avoiding long-term misselection caused by static labels being too high or too low. 2. By introducing a global stability index to dynamically adjust the overlap penalty coefficient, the marginal gain greedy selection forces the selection of scanners with complementary capabilities to increase exploration when the system is unstable, and weakens the penalty to concentrate the use of high-matching scanners when the system is stable. The system uses the sample variance of the bias sequence as a stability measure. When the variance increases, the overlap penalty coefficient automatically increases, and when the variance approaches zero, the coefficient decreases, thereby adaptively balancing exploration and utilization without relying on human intervention. 3. Rule Evolution: Based on the actual vulnerabilities detected, feature mapping rules are generated or refined in reverse. Risk triggering conditions missing in the initial rule table are automatically filled in during scanning practice. If a vulnerability is detected but a certain risk dimension is below the coverage threshold, the system extracts triggering conditions from the original features, generates candidate rules, and makes them effective after passing multiple confidence counts. The rule table can be self-expanding, reducing manual maintenance. 4. The synergistic effect of the above three mechanisms enables the system's resource allocation efficiency to approach the optimal level successively. After multiple scanning tasks, the convergence of the capability confidence coefficient allows high detection rate scanners to obtain higher scheduling priority, the adjustment of the global stability index makes the overlap penalty coefficient tend to a lower value in the stable state, and the rule evolution makes the feature mapping tend to be complete. Under the constraint of limited computing resources, the system converges the number of high-risk vulnerabilities detected per unit time to near the upper limit that the scanner set can reach, while controlling the resource consumption of invalid scanning tasks below the preset threshold. Attached Figure Description

[0008] 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 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.

[0009] Figure 1 This is the main flowchart of the method in Embodiment 1 of the present invention; Figure 2 This is a sub-flowchart of step S6 in Embodiment 1 of the present invention; Figure 3 This is a system block diagram of Embodiment 2 of the present invention. Detailed Implementation

[0010] The technical solution of the present invention will be clearly and completely described below with reference to the embodiments. 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.

[0011] In AI software supply chain security testing, a common approach is to first label scanners with their capabilities and then use static matching scores or global historical detection rates for combined scheduling. This assumes that the labels reflect the actual utility, and that the scheduling model and scanning execution are separated. However, the dependencies, model file formats, and calling methods vary greatly across different projects, leading to biases between the actual detection and static labels of the same scanner in different projects. For example, labeling a scanner as supporting Pickle deserialization detection may only cover a few known attacks and fail to capture the actual call chain.

[0012] When such biases occur, the existing scheduling mechanism lacks a closed-loop path to correct the scanner's capability confidence using the actual detection rate fed back during the scanning process. As a result, if a scanner is continuously assigned a high priority due to an inflated capability label, the system will repeatedly select that scanner in subsequent projects. Although actual detection results can be obtained after each execution, the scheduling model cannot adjust its scheduling weight accordingly, resulting in a "false confidence - reselection - false confidence again" lock-in effect. At the same time, there is also a lack of a mechanism to reverse-calibrate the project risk requirement vector based on the actual detected vulnerabilities, making it difficult for the initial feature mapping rules to evolve on their own once set.

[0013] For example, in a project containing Pickle format model files, the system relies on preset rules to set the Pickle deserialization risk intensity to 1.0 and forcibly selects the corresponding specialized scanner. If the scanner fails to detect a new type of deserialization vulnerability, due to the lack of feedback loop, the system cannot know whether the selection is effective or ineffective, and will repeat the same scheduling decision when encountering similar projects in the future. If there is overlap in capabilities among multiple scanners, the system may still select a large number of redundant scanners when resources are scarce due to the lack of dynamic adjustment of overlap penalties, thus crowding out coverage of other risk categories. The above defects together cause the deviation between scheduling decisions and actual scanning effectiveness to not be automatically converged, and after long-term operation, the system's resource allocation efficiency may actually be lower than that of the static configuration scheme.

[0014] If the above problems are not addressed, the system will continue to rely on initial static capability labels and historical global statistics, making it unable to adapt to changes in the actual performance of the scanner or the emergence of new vulnerability patterns. Adaptive scanning path planning will degenerate into an open-loop, non-self-correcting fixed strategy, losing its "adaptive" nature in response to dynamic environments, and affecting the overall detection efficiency and resource utilization of AI software supply chain security testing.

[0015] Example 1: As Figure 1-2 As shown, the adaptive scanning path planning method for the AI ​​software supply chain includes: Step S1: Obtain the original feature vector of the target project and generate a project risk requirement vector based on it. The dimension of the project risk requirement vector is aligned with the capability dimension of the scanner. Before executing step S1, this embodiment pre-constructs a feature mapping rule table to convert the original feature vector into a project risk requirement vector. This rule table is stored in an SQLite database and contains six fields: rule ID, trigger condition expression, output dimension, output strength value, status (effective or draft), and confidence count. The trigger condition expression uses Boolean operation syntax within a security sandbox, allowing access only to fields in the original feature vector and basic logical operations. The initial entries in the rule table are configured by the system administrator based on common AI supply chain risk patterns. For example, the trigger condition for rule R_pickle_1 is "there is an entry in model_artifacts with format equal to pickle", the output dimension is "r_pickle", and the output strength value is 1.0. The trigger condition for rule R_cve_1 is always true, the output dimension is "r_cve", and the output strength value is determined by the formula... Calculation, where The maximum depth of the dependency tree. This is the ratio of the project's average vulnerability density to the global average density. This mapping rule table supports dynamic evolution, and new effective rules can be added to it based on subsequent scan feedback, but initially it only contains the above-mentioned preset rules.

[0016] This embodiment pre-sets the following parameters, the values ​​of which are determined based on engineering experience or offline statistics. In actual deployment, they can be recalibrated according to the specific environment: =10 -8 Used to prevent extremely small positive numbers with a denominator of zero; it is used uniformly in division operations such as static matching degree and historical correction factor. α=0.1: The learning rate for updating the capability confidence coefficient, which controls the adjustment of the confidence coefficient by a single bias, and the value ranges from 0 to 1; =0.5: Expected maximum deviation, dimensionless, used to normalize the deviation value so that the adjustment amount tends to 0 when the absolute value of the deviation is close to 0.5; Rule evolution coverage threshold: The value is 0.5. When the intensity of a certain risk dimension in the project risk requirement vector is lower than this threshold and a corresponding vulnerability is detected, candidate rule generation is triggered. Rule draft activation threshold: The value is 3. When a draft rule is hit by the same condition a total of 3 times, its status changes from "draft" to "effective". Minimum number of samples for global stability update: 3. The sample variance is calculated and the global stability index S is updated only when the number of deviation values ​​in the global deviation list reaches 3. Preset upper limit of variance =0.1: Dimensionless, used in the global stability index calculation formula, its value is based on the 90th percentile of the deviation value distribution in the offline analysis of historical scanning tasks; Resource limits: These include the maximum number of CPU cores and the maximum amount of memory, which are specified by the system configuration file. In this example, we assume that the maximum number of CPU cores is 2 and the maximum amount of memory is 4GB.

[0017] Of the parameters mentioned above, α The coverage threshold, activation threshold, minimum number of samples, and upper limit of variance are all globally fixed values; the resource limit can be dynamically adjusted according to the actual environment; the specific calculations in the embodiments are all based on the above preset values.

[0018] Step S1 is specifically divided into two sub-stages: obtaining the original feature vector and generating the project risk requirement vector based on the rule table.

[0019] The original feature vector is obtained by parsing the file structure of the target project. The system first recursively scans the project root directory, collecting dependency description files (such as requirements.txt, pyproject.toml, package.json) and AI artifact files (with extensions such as .pkl, .pt, .bin, .safetensors, .gguf, etc.). For dependency description files, the system calls the corresponding ecosystem's parsing tools (using pipdeptree--json in Python and npm ls--json in JavaScript) to generate a dependency tree, from which three features are extracted: component type distribution vector, dependency depth feature value, and historical vulnerability density. The component type distribution vector is calculated by: statistically analyzing the proportion of AI framework dependency packages (package names containing torch, tensorflow, transformers, or onnx) to the total number of dependency packages, and the proportion of Pickle, SafeTensors, and GGUF formats in the model files, ultimately obtaining a four-dimensional vector. Depth-dependent features include maximum depth. (Longest path from root node to leaf node), average depth (Arithmetic mean of all node depths) and the number of nodes with a depth greater than 5; historical vulnerability density characteristics are obtained by querying the local vulnerability knowledge base (SQLite table cve_records): for each dependency package, the number of its CVE entries is retrieved, summed, and then divided by the total number of dependency packages to obtain the average density. Then divide by the preset global average density =0.5 to obtain the relative multiple For model files, the system not only checks the extension but also reads the 8-byte magic number at the beginning of each file to confirm the true serialization format and prevent extension spoofing. For files confirmed to be in Pickle format, the system uses the Unpickler safe parser, which overrides the find_class method, to extract class name strings (such as torch._utils._rebuild_tensor_v2) from the file and records whether they contain dangerous classes (such as _reduce_, os.system). In addition, the system uses the Python standard library ast to traverse the abstract syntax tree of all .py files, detects the existence of torch.load or pickle.load calls, and stores the detection results as boolean values ​​in the source_calls.has_pickle_load field of the original feature vector.

[0020] Assuming a specific target project, what is the maximum depth of its dependency tree? =4, average depth =2.3, number of high-depth nodes is 2; there are 10 dependency packages in total, including 2 AI frameworks (PyTorch and transformers), the total number of historical CVEs is 8, and the average density is =0.8, multiple of the global mean =1.6; The model file contains a model.bin file, the magic number is identified as Pickle format, security analysis found that the class name contains torch.\_utils.\_rebuild\_tensor\_v2 but no dangerous classes were found; source code scanning found torch.load calls; therefore, the original feature vectors This can be expressed as: =0.2, =0.1; =4, =2.3, =0.8, =1.6; model\_artifacts[0].format="pickle", model\_artifacts[0].dangerous\_classes is empty; source\_calls.has\_pickle\_load=true.

[0021] Next, the system generates a project risk requirement vector based on the original feature vector and the feature mapping rule table. The dimensions of the project risk requirement vector are aligned with the dimensions of the scanner capabilities. In this embodiment, six dimensions are preset: (Pickle deserialization risk) (Backdoor risk in the model) (CVE vulnerability risk) (PyTorch Ecosystem Strength) (TensorFlow Ecosystem Strength) (License risk). The rule table is executed in ascending order of rule ID, and the condition expression for each rule is based on... The fields in the code are subjected to Boolean operations. If the result is true, the value of the corresponding dimension is set as the output strength value of the rule (the later executed rule can overwrite the previous value). For the example project above: the condition "there is an entry with format equal to pickle in model_artifacts" of rule R_pickle_1 is true, therefore... Set to 1.0; rule R_cve_1 is always true, calculate the output intensity value. Therefore =0.44; the condition of rule R_pytorch " If ">0 and there exists a dependency package whose package name contains 'torch'" is true, output the following: =0.8; other dimensions ( , , Since there are no matching rules, the default value of 0.1 is retained; the final project risk requirement vector is obtained. =[1.0, 0.1, 0.44, 0.8, 0.1, 0.1]; Simultaneously, the system records the mapping_trace, indicating the source of each dimension's value, for example... This comes from rule R_pickle_1, triggered by the presence of a pickle entry in model_artifacts. From rule R_cve_1, the calculation formula uses =4 and =1.6; This mapping_trace will be used in subsequent feedback steps to determine whether a new mapping rule needs to be generated.

[0022] It's worth noting that some fields in the original feature vector were not used by any rules during this generation process. For example, the list of dangerous class names in `source_calls.has_pickle_load` and `model_artifacts` are retained in the original feature vector for use in subsequent steps. If a future scan detects a Pickle deserialization vulnerability, and the current... If it's already at version 1.0, then rule evolution won't be triggered; but if If the value is low (e.g., only the default 0.1 due to missing rules), the system will combine the source_calls.has_pickle_load fields to generate new candidate rules; the output of step S1 is the project risk requirement vector. The corresponding mapping_trace provides input for subsequent calculation of scheduling matching degree.

[0023] Step S2: Obtain the static capability vector, capability confidence coefficient, and utility history of each scanner in the candidate scanner set;

[0024] Before executing step S2, the system has pre-built a static capability profile for each callable scanner; this profile is not declared by the scanner itself, but rather filled in by the administrator during registration based on the scanner's technical documentation and test results; static capability vector The dimensions and the aforementioned project risk requirement vector The dimensions are fully aligned; in this embodiment, the vector length is 6, corresponding sequentially to… , , , , , There are six risk dimensions; each component in the vector takes only 0 or 1 as its value, with 1 indicating that the scanner has the ability to detect risks in the corresponding dimension. For example, a scanner named PickleScan has its capability vector set to [1, 0, 0, 0, 0, 0], indicating that it only covers Pickle deserialization risks. The capability vector of a general SCA tool, DependencyChecker, is [0, 0, 1, 0, 0, 0]. A vulnerability scanner for the PyTorch ecosystem, PyTorchVulnScanner, might be set to [0, 0, 1, 1, 0, 0]. Once registered, the static capability vector does not change automatically unless the administrator manually updates the scanner version.

[0025] For each scanner, the system maintains two dynamic data points at runtime: capability confidence coefficient. and utility history list The initial value of the capability confidence coefficient is uniformly set to 0.5. The physical meaning of this coefficient is: the degree of confidence the system has in the capability represented by "1" in the static capability vector that it is truly effective in the current project. A value of 0.5 indicates that the initial state is neither biased towards trust nor doubt, and will be adjusted subsequently through scanning feedback. Utility history record. It is a first-in, first-out queue that can store a maximum of 100 records, with each record being a quaternion. , where label is the task feature label (string). The static matching degree calculated during that scheduling process. The actual detection rate for this scan is represented by t, where t is the Unix timestamp. These records are used to calculate the history correction factor. To facilitate fast retrieval, the system also maintains a Redis-based inverted index, where the key is the task feature tag and the value is a list of pointers to entries with the same tag in the history of each scanner.

[0026] Taking the example project in step S1 as an example, the task feature label generated by this project is "pickle_true_depth_mid_pytorch"; three scanners have been registered in the system: PickleScan (static capability vector [1, 0, 0, 0, 0, 0], confidence coefficient 0.5, empty history), DependencyChecker ([0, 0, 1, 0, 0, 0], confidence coefficient 0.5, empty history), and PyTorchVulnScanner ([0, 0, 1, 1, 0, 0], confidence coefficient 0.5, empty history); in step S2, the system reads this information from the scanner profile storage module (in this embodiment, a Redis hash table is used, with the key name scanner:dynamic:{scanner_id}) to construct a candidate scanner set; it should be emphasized that the candidate scanner set is also filtered by preconditions; the preconditions are stored in each scanner registration The `precondition` field of the information is in the format of a logical expression. For example, the `precondition` of PickleScan is "exists('*.pkl')". The system checks whether a .pkl file exists in the project's root directory. For the example project, model.bin exists, so the condition is met and PickleScan enters the candidate set. The `precondition` of DependencyChecker is "exists('requirements.txt')". The example project has this file and also enters the candidate set. The `precondition` of PyTorchVulnScanner, in addition to requiring the existence of requirements.txt, also requires that PyTorch be detected by the dependency package name. The example project meets this requirement and also enters the candidate set. If the precondition of a scanner is not met, it is directly removed from the candidate set and does not participate in the subsequent scheduling matching degree calculation.

[0027] The utility history is empty during the initial system runtime; as scanning tasks are executed, after each scan, the first feedback loop appends a new record to the corresponding scanner based on the deviation between the actual detection rate and the scheduling match. In the middle; when the number of records exceeds 100, remove the record with the oldest timestamp; step S2 is only responsible for reading these stored data and does not involve write operations; the system uses a global lock to ensure that each read is accurate. This is a complete copy after the most recent update; it is worth noting that the algorithm for generating task feature labels must be strictly consistent with the rules used in step S1, namely, based on the existence of a Pickle model file, the dependency depth level (depth ≤2 is low, 3 to 5 is medium, and ≥6 is high), and the name of the detected AI framework (in this embodiment, only pytorch, tensorflow, and other values ​​are distinguished). For the example project, the maximum dependency depth is 4, which belongs to the medium level (mid), so the label is determined as "pickle_true_depth_mid_pytorch"; this label will be used in the subsequent step S3 to filter matches from the history.

[0028] Step S3: Calculate the scheduling matching degree of each scanner based on the project risk demand vector, static capability vector, capability confidence coefficient, and utility history. Step S3 receives the project risk requirement vector output from step S1. Step S2 reads the static capability vectors of each scanner. Confidence coefficient of capability and utility history list Simultaneously, it receives the feature label L of the current task ("pickle_true_depth_mid_pytorch" in this embodiment); the core of this step lies in integrating the static matching degree, historical performance correction, and confidence degree into a scheduling matching degree. This serves as the basis for subsequent greedy choices.

[0029] For each scanner j in the candidate scanner set, if the scanner's static capability vector All components are 0, indicating that the scanner does not cover any predefined risk dimensions, its scheduling match degree is directly set to 0.05 (lower limit), and it does not participate in the calculation of subsequent historical correction factors; this type of scanner obtains a very low selection probability solely based on the lower limit of the scheduling match degree, and is used for exploratory scheduling; the system checks before calculation If the value is 0, skip the cosine similarity calculation and directly set it. =0; otherwise, calculate its static matching degree. Static matching degree is defined as the static capability vector. Project Risk Requirements Vector The cosine similarity, i.e. ; in =10 -8It is a very small positive number, used to prevent the denominator from being zero; because Each component in the equation is either 0 or 1, and its norm is... equal ; obtained in step S1 Taking [1.0, 0.1, 0.44, 0.8, 0.1, 0.1] as an example, this relates to the static capability vector of the scanner PickleScan. =[1, 0, 0, 0, 0, 0], numerator is 1.0, denominator is ≈1.365, therefore ≈0.732; for DependencyChecker, its =[0,0,1,0,0,0], numerator is 0.44, denominator is =1.365, ≈0.322; for PyTorchVulnScanner, =[0, 0, 1, 1, 0, 0], numerator is 0.44 + 0.8 = 1.24, denominator is ≈1.930, ≈0.642.

[0030] Next, the historical correction factor is calculated. The system retrieves the utility history of scanner j. The process involves filtering out all entries whose task feature labels are exactly the same as the current label L; let the number of filtered entries be K; if K≥3, then calculate the actual detection rate among these entries. arithmetic mean and static matching degree The arithmetic mean of the static matching degree values ​​(i.e., the values ​​at which the records were stored). The historical correction factor is defined as follows: ; in The values ​​are the same as above, used to avoid the denominator. A division-by-zero error occurs when the value is zero (in real-world scenarios, the average static matching degree may be zero, for example, when the scanner capability vector and the project requirement vector have no intersection); this formula restricts the correction factor to the range of 0.7 to 1.3 to avoid excessive impact from a single extreme result; if K < 3, then let =1.0 indicates that no correction will be made when there is a lack of sufficient historical data.

[0031] For example, suppose PickleScan has performed four scans in the past, with the feature label "pickle_true_depth_mid_pytorch" for three of them. The static matching degrees in the corresponding records are 0.72, 0.74, and 0.70, respectively, and the actual detection rates are 0.80, 0.82, and 0.75, respectively. =0.72, =0.79, the ratio 0.79 / 0.72≈1.097, falls within the range of 0.7 to 1.3, therefore =1.097; If a scanner has never executed a task for the current tag type, then =1.0.

[0032] Obtain static matching degree Confidence coefficient of capability (Dynamic data read from step S2) and historical correction factors Afterwards, scheduling matching degree Defined as the product of the three, and further truncated to between 0.05 and 1.0: ; The lower bound of 0.05 ensures that even if a scanner's evaluation value is extremely low across all dimensions, there is still a tiny probability that it will be considered in subsequent steps, providing the system with basic exploratory capabilities; continuing with the example above: PickleScan's... The initial value was 0.5. ≈0.732, =1.097, then the product is 0.732×0.5×1.097≈0.401, truncated. =0.401; If, after multiple feedbacks, the confidence coefficient of PickleScan is increased to 0.9, the scheduling match rate will rise to approximately 0.722, significantly increasing its likelihood of being selected; For DependencyChecker, which lacks historical data, let its... =0.5, =0.322, =1.0, then =0.161; PyTorchVulnScanner =0.642, if its confidence coefficient is also 0.5 and there is no historical correction, then =0.321.

[0033] The system performs the above calculations sequentially for each scanner in the candidate set and outputs the scheduling matching degree for each scanner. This value quantitatively characterizes the expected applicability of the scanner to the project under the joint constraints of current project characteristics, scanner static capabilities, historical performance accumulation, and confidence level. After step S3 is completed, these scheduling matching degrees will serve as inputs for the greedy selection of marginal gain in step S4. It is worth noting that the scheduling matching degree is not a static indicator; it will dynamically evolve with the update of confidence coefficients and the growth of historical records caused by each scan feedback, thereby enabling the system's scheduling decisions to gradually converge to scanners with higher actual performance.

[0034] Step S4: Obtain the set of required scanners and the global stability index. Dynamically determine the overlap penalty coefficient based on the global stability index. Iteratively perform a greedy selection based on the marginal gain, based on the scheduling matching degree, the overlap penalty coefficient, and the maximum capability overlap between each scanner and the selected set, to obtain the final scanner combination. The system also maintains a separate mandatory scanner rule engine, used to force the execution of specific scanners based on high-risk signals in the original feature vector. The rule set of this engine is stored in a JSON file, with each rule containing a trigger condition expression and a corresponding list of scanner identifiers. The trigger condition expression uses the same syntax as the feature mapping rule table, but the rule engine only outputs the scanner set and does not modify the risk requirement vector. Initial rules are configured by the administrator; for example, rule R_mandatory_1's trigger condition is "the existence of an entry with format equal to pickle in model_artifacts", and the corresponding scanner is "PickleScan"; rule R_mandatory_2's trigger condition is "source_calls.has_pickle_load==true", and the corresponding scanner is "PickleDeepScan". Before executing step S4, the system inputs the original feature vector into the rule engine, evaluates all rules in order, and merges the matched scanners after deduplication to obtain the set of required scanners M. If the preconditions of any scanner in M ​​are not met (for example, PickleScan requires the existence of a .pkl file but it does not actually exist), the system reports an error and terminates the scheduling to avoid invalid scanning.

[0035] Step S4 receives the scheduling matching degree of each candidate scanner calculated in step S3. Simultaneously, the system retrieves the mandatory scanner set M from the rule engine and reads the current global stability index S from the global storage (in this embodiment, S is initially set to 0.5). The mandatory scanner set is forcibly specified by the rule engine based on high-risk signals in the original feature vector. For example, if the original feature vector of the example project in step S1 contains a Pickle format model file, then rule R_pickle_1 is triggered, forcibly adding PickleScan to M. If multiple rules are effective simultaneously, M may contain multiple scanners. The system first checks whether the total resource requirements of all scanners in M ​​exceed the available resource limit (CPU core limit). Memory limit If the limit is exceeded, an error message will be displayed and the system will exit, requiring manual intervention to adjust the rules or resource quotas. This embodiment assumes... PickleScan consumes 1 CPU core and 1GB of memory, while the available resources are 2 CPU cores and 4GB of memory, so it passes.

[0036] Next, the overlap penalty coefficient is dynamically determined. This coefficient is negatively correlated with the global stability index S, and is defined as follows: ; The global stability index S is calculated by the feedback loop in step S6 based on the variance of the most recent 20 deviation values, and its value ranges from 0 to 1. Negatively correlated with S: The smaller S is (the more unstable the system). The larger the value, the higher the weight of the overlap penalty term in the marginal gain, thereby inhibiting the selection of scanners that overlap with the capabilities of the already selected set, and forcing an increase in combinatorial diversity to promote exploration; in this embodiment, the current S=0.5, then =0.3×0.5=0.15.

[0037] The greedy selection process maintains two sets: the selected set A, initially the mandatory selection set M; and the candidate set C, initially all scanners that meet the preconditions and have not been forcibly selected. In the example of step S2, the candidate set... The system also needs to record the resources consumed. , The initial value is the sum of the resource consumption of each scanner in M; then the iteration begins.

[0038] In each iteration, for each candidate scanner Calculate its maximum capability overlap with the selected set A. Capability overlap is based on static capability vectors. The Jaccard similarity definition; let the set of static capability vectors of existing scanners in A be . ,but ; Where i traverses each dimension of the capability vector; when the denominator is zero (i.e., both vectors have empty non-zero dimensions), the Jaccard similarity is defined as 0; if A is empty (in this embodiment, A at least contains the required scanner, so it is not empty), then =0; For this example, the selected set Its static capability vector is [1, 0, 0, 0, 0, 0]; the vector of the candidate DependencyChecker is [0, 0, 1, 0, 0, 0]. The intersection dimension is empty, and the union dimension is two dimensions: the 0th dimension and the 2nd dimension. =0 / 2=0; the candidate PyTorchVulnScanner vector is [0, 0, 1, 1, 0, 0], which has no intersection with PickleScan, and the union dimension is the 0th, 2nd, and 3rd dimensions, for a total of 3. =0; therefore, the overlap between the two candidates is 0.

[0039] Next, calculate the marginal gain. ;because The marginal gain is directly equal to the scheduling matching degree; in step S3, the marginal gain is calculated. =0.161, =0.321, therefore =0.161, =0.321; Select the scanner with the largest and positive marginal gain, namely PyTorchVulnScanner (gain 0.321>0); Check if its resource requirements (assuming 0.8 CPU cores and 2GB memory) are less than or equal to the remaining resources. =2-1=1 core, =4-1=3GB, meeting the condition; add the scanner to A, remove it from C, and update. =1 + 0.8 = 1.8 cores =1+2=3GB.

[0040] Proceed to the next iteration; at this point, only DependencyChecker remains in C; recalculate its relationship with the selected set. The maximum capability overlap; the Jaccard similarity with PickleScan is still 0; compared with the vector [0,0,1,1,0,0] of PyTorchVulnScanner, the vector [0,0,1,0,0,0] of DependencyChecker has an intersection dimension of the second dimension (CVE vulnerability), and a union dimension of the second and third dimensions, for a total of two, with Jaccard=0.5; take the maximum value. =0.5; marginal gain =0.161-0.15×0.5=0.161-0.075=0.086, still positive; resource check: remaining CPU is 2-1.8=0.2 cores, remaining memory is 4-3=1GB; the resource requirements of DependencyChecker are assumed to be 0.5 CPU cores and 1GB memory. The CPU requirement 0.5>0.2, the resources are insufficient, so the scanner cannot be selected; the system removes it from C (cannot be added due to insufficient resources); at this time C is empty, and the iteration terminates.

[0041] Final Scanner Combination Step S4 outputs the combination and the scheduling matching degree of each selected scanner (used for subsequent step S5 to execute the scan and step S6 to provide feedback); if the marginal gain of all candidates is negative in a certain iteration, the algorithm terminates early and no additional scanners are selected, only the required set is retained; if resources are insufficient and the remaining candidates cannot be added, the algorithm also stops immediately; this greedy algorithm ensures that, without exceeding the resource limit, each iteration selects the scanner that makes the largest marginal contribution to the current selected set, and achieves stability adaptation through a dynamic overlap penalty coefficient.

[0042] Step S5: Call the final scanner combination to perform the scan and obtain the actual detection rate; Step S5 receives the final scanner combination output from step S4. The system executes scanning tasks sequentially or concurrently according to the resource consumption order of each scanner in the combination (in this embodiment, they are arranged from high to low according to scheduling matching degree, with PyTorchVulnScan first and PickleScan last). For the sake of simplicity, this embodiment adopts a serial execution mode, but in actual deployment, the remaining resources can be used for parallel execution.

[0043] For each scanner, the system constructs the actual command based on the command-line template in its registration information. The template for PickleScan is `{exec_path}scan--pickle-only{project_dir}-o{output_file}`, where `{exec_path}` is replaced with the executable file path of the scanner, `{project_dir}` is replaced with the root directory of the target project, and `{output_file}` is replaced with a temporary file path, such as ` / tmp / PickleScan_1703123456.json`. The system creates a child process to execute the command and sets the timeout to three times the `avg_time_sec` field in the scanner's registration information (i.e., the timeout for each scanner is set to three times the average timeout in its registration information, to avoid a single scanner blocking the scheduling process for an extended period). If the average timeout for PickleScan is 10 seconds, the timeout is set to 30 seconds. If the child process does not complete within the timeout period, the system forcibly terminates the process, marks the scan result as a failure, and resets the scanner's actual detection rate. Set it to 0.

[0044] If the scan is completed successfully, the system reads the output JSON file; the JSON format is pre-defined by each scanner and contains at least one array of `vulnerabilities`, with each element containing the fields `file`, `line`, `vuln_type`, and `severity`.

[0045] The number of vulnerabilities was obtained after system analysis. Next, the actual detection rate of the scanner is calculated. The formula is ; The value of D is determined based on the counting unit specified during scanner registration. The physical meaning of D differs between different scanners, but this does not affect subsequent independent feedback. This counting unit is specified by the administrator during scanner registration and stored in the `count_unit` field. For PickleScan, `count_unit` is `pickle_file_count`. The system extracts the number of Pickle model files from the original feature vector in step S1. In this embodiment, only one `model.bin` file is recognized as Pickle format, so D=1. If PickleScan detects a vulnerability, then... =1 / 1=1.0; if not detected, then it is 0.

[0046] It is important to note that different scanners may use different counting units (e.g., number of files, number of packages, number of code files), which leads to differences in the unit of measurement of the actual detection rate among different scanners. However, since the actual detection rate of each scanner is only used to update the scanner's own capability confidence coefficient and is not compared horizontally between different scanners, the inconsistency of the denominator unit will not affect the system's feedback logic. The confidence coefficient of each scanner evolves independently, and its update depends only on the scanner's own historical deviation sequence.

[0047] For PyTorchVulnScanner, its `count_unit` is `dep_pkg_count` (total number of dependency packages). In step S1, the total number of dependency packages for this project is counted as 10, so D=10; assuming that PyTorchVulnScanner detects 2 PyTorch-related CVE vulnerabilities after scanning, then... =2 / 10=0.2; If the counting unit of a scanner is `source_file_count` (number of source files), the system needs to count the number of all `.py`, `.js`, etc. source files under the project before scanning, and use this as the denominator; if the counting unit is `model_file_count`, then the denominator is the number of all model files (regardless of format). When the denominator is zero, the system sets the actual detection rate to 0 and writes an alarm event to the operation log, including the scanner identifier, project path, and reason for the missing information (e.g., "Pickle model file not detected"). The scan still reports a normal result, and its deviation... A negative value will decrease the confidence coefficient of the capability, thereby reducing the probability that the scanner will be selected in similar projects in the future; for the statistics of source_file_count, the system recursively scans the project directory, collects source code files with extensions of .py, .js, .java, .go, .cpp, and .c, and excludes hidden directories (such as .git, pycache, and node_modules); the statistical result is used as the denominator; if there are no source code files, the denominator is set to 1.

[0048] Another situation needs to be handled: the denominator may be zero; for example, a project may not have a Pickle model file, but PickleScan is selected in step S4 (theoretically, mandatory rules should avoid this situation, but it can still happen due to configuration errors); in this case, the denominator is 0, and the system will... Set it directly to 0 and record the exception in the log.

[0049] During the scan execution, the system simultaneously records the actual execution time and peak memory usage of each scanner (obtained via the operating system API), but this data is only used for monitoring and does not participate in the calculation of this step; the output of step S5 is the actual detection rate of each scanner. And the corresponding vulnerability list (used in the second feedback loop of subsequent step S6); in this embodiment, PickleScan's =1.0, PyTorchVulnScanner =0.2; these values, along with the scheduling match degree calculated in step S3, are also included. Together, these will be used in step S6 to update the capability confidence coefficient and global stability index; it is worth noting that the system still records the results in case of scan timeout or execution failure. =0 and retain the feedback. In this way, the confidence coefficient of the scanner that performs poorly over a long period of time will gradually decrease, thereby reducing the probability of it being selected again.

[0050] Step S6: Based on the deviation between the actual detection rate and the scheduling matching degree, update the capability confidence coefficient and the utility history record, and store the deviation in the historical deviation set. Update the global stability index based on the fluctuation of multiple deviations in the set.

[0051] Step S6 receives the actual detection rate output from step S5. (PickleScan is 1.0, PyTorchVulnScanner is 0.2) and the scheduling matching degree calculated in step S3. (PickleScan is 0.401, PyTorchVulnScanner is 0.321); simultaneously, the current capability confidence coefficient is read from the scanner's dynamic profile storage. =0.5 and =0.5, and their respective utility history records. , (In this embodiment, it is initially empty); the system also maintains a global deviation list B, which is initially empty, to store the deviation values ​​of any scanner in the last 20 scans. .

[0052] For each scanner that has been executed, the system first calculates the deviation value. And limited to the range [-0.5, 0.5]; for PickleScan: =1.0 - 0.401 = 0.599, which exceeds the upper limit of 0.5, therefore =0.5; for PyTorchVulnScanner: =0.2-0.321=-0.121, which is within the interval, therefore =-0.121.

[0053] Update the scanner's utility history; each record contains four fields: task feature label L (in this example, "pickle_true_depth_mid_pytorch"), static matching degree, etc. (Calculated in step S3, PickleScan is 0.732 and PyTorchVulnScanner is 0.642), actual detection rate , timestamp (Unix time in seconds); append this record to the corresponding scanner The tail of the queue; if the queue length exceeds 100, the oldest record at the head of the queue is removed; in this embodiment, it is initially empty, and the length becomes 1 after appending.

[0054] The formula for calculating the adjustment amount is: ; Where α = 0.1 is the learning rate. =0.5 is the preset upper limit of deviation; when When ≤0.5, ;when When the deviation is greater than 0.5 (the absolute value of the actual deviation has been limited to no more than 0.5), Substituting this into the example, PickleScan's... =0.5, Δc=0.2×0.5=0.1, after update =0.5 + 0.1 = 0.6 (still 0.6 after truncation); PyTorchVulnScanner =-0.121, =0.121≤0.5, Δc=0.4×(-0.121)×0.121=-0.00586, after update =0.5-0.00586=0.49414, which becomes 0.494 after limitation; this correction causes the confidence coefficient to increase when the performance exceeds expectations (positive deviation) and decrease when the performance falls short of expectations (negative deviation), and the adjustment magnitude increases monotonically with the absolute value of the deviation.

[0055] After each update, the system will adjust the deviation. The value is added to the global deviation list B. In this embodiment, 0.5 and -0.121 are added to B in sequence. When the length of B reaches the preset upper limit of 20, the oldest deviation value is removed before subsequent additions.

[0056] The global stability metric S is updated after each scan task. The system sets a minimum sample size. =3, meaning that the sample variance is calculated and S is updated only when the number of deviation values ​​n in the global deviation list B is ≥3; if n < 3, S remains unchanged; in this embodiment, n = 2, the update condition is not met, so S remains 0.5; when n reaches 3 in the future, the sample variance is calculated. ; in The arithmetic mean of the deviations in B; then update The denominator 0.1 in the formula is the preset upper limit of variance. The value is determined by setting the 90th percentile of the variance of the deviation sample under typical unstable conditions to 0.1, based on the distribution of deviation values ​​in historical scanning tasks through offline analysis.

[0057] when When S ≥ 0.1, S = 0, indicating that the system is in a highly unstable state; when When S=0, S=1, indicating that the system is completely stable; the updated S in this step will affect the overlap penalty coefficient of subsequent scheduling. The relationship has been defined by step S4.

[0058] After step S6 is completed, the system will update the capability confidence coefficient. =0.6、 =0.494 is written back to Redis, persisting the updated utility history and storing the global stability index S (still 0.5). These updates will directly affect the scheduling matching degree calculation of subsequent projects, forming a complete closed-loop adaptation. It is worth noting that the confidence coefficient of PyTorchVulnScanner decreased from 0.5 to 0.494, which means that its actual detection rate was slightly lower than expected (0.2 vs 0.321), and the system slightly lowered its trust in it. On the other hand, PickleScan's confidence coefficient increased from 0.5 to 0.6 because its actual detection rate was much higher than expected (1.0 vs 0.401), reflecting the positive accumulation of trust due to positive deviation.

[0059] After step S6 is completed, the system executes the second feedback loop, which evolves the feature mapping rule table based on the vulnerability list detected in this scan; this process is independent of the confidence coefficient update in step S6, but uses the same scan results.

[0060] Taking the scan results of this embodiment as an example, PickleScan detected a Pickle deserialization vulnerability, with the vulnerability type being "pickle_deserialization". The system maintains a mapping table from vulnerability type to risk dimension; for example, "pickle_deserialization" maps to the risk dimension. “model_backdoor” maps to For the vulnerabilities detected this time, the target dimension was mapped to... The system retrieves the data stored in step S1. The current intensity value of this dimension is read, with a preset coverage threshold of 0.5; there are two scenarios: Scenario 1: If the current strength value is below 0.5, and the current scan detects a vulnerability corresponding to this dimension, then the generation of a "rule missing" candidate rule will be triggered. Scenario 2: If the current strength value is higher than or equal to 0.5 (e.g., 1.0), but the current scan still detects vulnerabilities corresponding to this dimension, then a "rule refinement" candidate rule generation is triggered. In this case, the generated candidate rule is not a newly created rule, but rather a more stringent constraint is added to the conditional expression of an existing rule; for example, if the original rule only requires "the existence of a Pickle format model file," the refined rule adds "and the source code contains a torch.load call"; the system marks the original rule as "to be replaced" and generates a more stringent draft rule with an initial confidence count of 1. When the same refinement condition is hit multiple times, the original rule is replaced with the refined rule. If the current strength value is greater than or equal to 0.5 and no vulnerability is detected, no evolution will be triggered; In this embodiment =1.0 and a vulnerability was detected, which falls under scenario two. The system then enters the rule refinement process. Since the original rule R_pickle_1 in this embodiment only depends on the file format, while the actual vulnerability is also related to the calling mode, the system generates the refinement condition "format='pickle' exists in model_artifacts and source_calls.has_pickle_load==true", and updates the rule table according to the aforementioned process.

[0061] Suppose another scenario: In the original feature vector of a project, the model file is identified as Pickle format, but the corresponding rule R_pickle_1 does not exist in the feature mapping rule table (e.g., the rule was accidentally deleted or the system is in a cold start state). The default value is 0.1, which is lower than the coverage threshold of 0.5; at this point, the system enters the candidate rule generation process.

[0062] The system starts from the original feature vector To extract triggering conditions and avoid the accumulation of confidence counts for the same candidate rule triggered multiple times in the same project, the system first deduplicates vulnerabilities by risk dimension when processing the vulnerability list. Specifically, a temporary set `DeduplicateRisks` is created, and the risk dimension mapped to each vulnerability is traversed, with the dimension identifier added to the set. Then, subsequent strength checks and rule generation are performed on each unique dimension in the set. Furthermore, each draft rule is only allowed to accumulate a confidence count once in the same project (debouncing is achieved by recording the project ID) to prevent a large number of similar vulnerabilities generated in a single scan from causing the rule to be activated prematurely. Dimension, the predefined trigger condition template is "a Pickle format model file exists and the source code contains torch.load or pickle.load calls"; system check The system checks whether the `model_artifacts` field contains an entry with `format='pickle'` and whether `source_calls.has_pickle_load` is true. If both are true, a candidate trigger condition expression string is generated: "The `model_artifacts` field contains an entry with `format='pickle'` and `source_calls.has_pickle_load==true`". This expression uses the same syntax as the feature mapping rule table in step S1.

[0063] The system queries the feature mapping rule table (SQLite table mapping_rules) to check if a rule exists whose condition field is exactly equal to the string and whose status is 'draft'. If it exists, the confidence count field of that rule is incremented by 1. If it does not exist, a new rule is inserted, with the rule ID automatically generated, condition set to the string, output_dimension set to "r_pickle", output_value set to 1.0, status set to "draft", and confidence set to 1.

[0064] When the accumulated confidence of a draft rule reaches the activation threshold (set to 3 in this example), the system updates its status to "active" and records the activation_time as the current timestamp. Subsequently, for newly submitted scanning tasks, the feature mapping rule table will include this new rule, thus enabling its use in subsequent projects. It can be correctly set to 1.0; if the current project has not yet completed a full scan (for example, there are multiple components to be scanned), the system can add the project back to a high-priority position in the priority queue through the optional backscan interface, and use the new rules to perform incremental supplementary scanning.

[0065] In the actual operation of this embodiment, due to The system is already at version 1.0, which skips rule evolution and does not generate any new rules. This second feedback loop ensures that the feature mapping rule table can expand itself from scanning practice, gradually covering the risk patterns missing in the initial rule table, without the need for continuous manual maintenance. The entire process does not require retraining or service restart, and only triggers a lightweight check and update after each scan.

[0066] The closed-loop scheduling mechanism constructed in Embodiment 1 eliminates the reliance on static capability labels and historical global statistics for scanner selection. Instead, it dynamically adjusts the capability confidence coefficient based on the actual detection rate after each scan, while adaptively adjusting the overlap penalty coefficient using a global stability index. When a scanner consistently outperforms expectations across multiple tasks, its confidence coefficient gradually increases, leading to a higher matching rate in subsequent scheduling. Conversely, if a scanner repeatedly underperforms expectations, its confidence coefficient decreases, reducing its probability of being selected. This negative feedback loop ensures that the deviation between scheduling decisions and actual detection effectiveness is gradually converged, preventing drastic fluctuations caused by a single abnormal task. The global stability index automatically adjusts the trade-off between exploration and exploitation by monitoring the variance of the deviation sequence: when the variance increases, the system intensifies the overlap penalty, forcing the scheduler to select scanners with complementary capabilities to collect more information; when the variance is stable, the penalty is weakened, causing the scheduler to concentrate on the scanners with the best historical performance; the rule evolution mechanism calibrates the feature mapping rule table in reverse based on the actual detected vulnerabilities, gradually refining the originally missing or coarse risk triggering conditions; the entire system can therefore continuously optimize the selection quality of the scanner combination without relying on continuous human intervention, and gradually converge resource allocation to the direction with higher actual risk detection efficiency.

[0067] Example 2: Figure 3 As shown, the adaptive scanning path planning device for the AI ​​software supply chain includes: The feature extraction module is configured to obtain the original feature vector of the target project and generate a project risk requirement vector, with the dimension of the project risk requirement vector aligned with the capability dimension of the scanner. The scanner profile storage module is configured to store the static capability vector, capability confidence coefficient and utility history of each scanner. The scheduling matching calculation module is configured to calculate the scheduling matching degree of each scanner based on the project risk requirement vector and the capability profile of each scanner. The greedy selection module is configured to obtain the set of mandatory scanners and the system's global stability index, dynamically determine the overlap penalty coefficient based on the scheduling matching degree and the global stability index, and select the final scanner combination based on the marginal gain greedy algorithm. The scan execution module is configured to call the final scanner combination to perform the scan and obtain the actual detection rate; The feedback update module is configured to update the scanner's capability confidence coefficient and utility history based on the deviation between the actual detection rate and the scheduling matching degree, and update the global stability index based on the fluctuation of multiple deviations.

[0068] Example 3: A computer device includes a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the program, it implements the adaptive scanning path planning method for the AI ​​software supply chain as described in Example 1. The memory stores a feature mapping rule table, dynamic profile data of scanners (including static capability vectors, capability confidence coefficients, and utility history records), and a global stability index. When the processor runs the program, it reads the above data from the memory and executes steps S1 to S6 sequentially, including: generating a project risk requirement vector based on the original feature vector of the target project; calculating the scheduling matching degree of each scanner; dynamically determining the overlap penalty coefficient based on the global stability index and performing a greedy selection of marginal gain to obtain the final scanner combination; calling the combination to perform scanning and obtaining the actual detection rate; and updating the capability confidence coefficient and the global stability index based on the deviation between the actual detection rate and the scheduling matching degree. This computer device can be a server, workstation, or personal computer and can be deployed in a CI / CD pipeline or an independent security testing platform.

[0069] Example 4: A computer-readable storage medium storing a computer program thereon; when the program is executed by a processor, it implements the adaptive scan path planning method for the AI ​​software supply chain as described in Example 1; the storage medium can be a non-transitory medium such as ROM, RAM, hard disk, optical disk, or USB flash drive; when the program is loaded into the processor of a computer device for execution, the computer device can automatically complete the dynamic optimization of scanner combination, scan path planning, and feedback closed-loop update based on the original feature vector of the target item, thereby continuously optimizing the allocation efficiency of scanning resources without manual intervention.

[0070] In the description of this specification, references to terms such as "an embodiment," "example," "specific example," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of the invention. In this specification, illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples.

[0071] The preferred embodiments of the present invention disclosed above are merely illustrative of the invention. These preferred embodiments do not exhaustively describe all details, nor do they limit the invention to any specific implementation. Clearly, many modifications and variations can be made based on the content of this specification. This specification selects and specifically describes these embodiments to better explain the principles and practical applications of the invention, thereby enabling those skilled in the art to better understand and utilize the invention.

Claims

1. An adaptive scanning path planning method for the AI ​​software supply chain, characterized in that, include: Obtain the original feature vector of the target project and generate a project risk requirement vector based on it. The dimension of the project risk requirement vector is aligned with the capability dimension of the scanner. Obtain the static capability vector, capability confidence coefficient, and utility history of each scanner in the candidate scanner set; Based on the project risk demand vector, the static capability vector, the capability confidence coefficient, and the utility history record, calculate the scheduling matching degree of each scanner; Obtain the set of required scanners and the global stability index. Dynamically determine the overlap penalty coefficient based on the global stability index. Based on the scheduling matching degree, the overlap penalty coefficient, and the maximum capability overlap between each scanner and the selected set, iteratively perform a greedy selection with marginal gain to obtain the final scanner combination. The final scanner combination is invoked to perform a scan and obtain the actual detection rate; Based on the deviation between the actual detection rate and the scheduling matching degree, the capability confidence coefficient and the utility history record are updated, and the deviation is stored in the historical deviation set. The global stability index is updated based on the fluctuation degree of multiple deviations in the set.

2. The adaptive scanning path planning method for AI software supply chain according to claim 1, characterized in that, The original feature vector includes: component type distribution vector, dependency depth feature value, real serialization format identifier of model file, list of dangerous class names embedded in model file, and detection results of dangerous call patterns in source code.

3. The adaptive scanning path planning method for AI software supply chain according to claim 1, characterized in that, The calculation of the scheduling matching degree of each scanner includes: calculating the cosine similarity between the static capability vector and the project risk requirement vector to obtain the static matching degree; filtering historical records that match the current task feature labels from the utility history records; if the number of matching records reaches a threshold, calculating the ratio of the average historical actual detection rate to the average static matching degree as the historical correction factor; and multiplying the static matching degree, capability confidence coefficient and historical correction factor to obtain the scheduling matching degree.

4. The adaptive scanning path planning method for AI software supply chain according to claim 3, characterized in that, The task feature label is generated by combining the following discrete features: whether a Pickle format model file exists, the dependency depth level, and the name of the AI ​​framework detected from the project dependency package, wherein the AI ​​framework name is determined by matching keywords in the dependency package name.

5. The adaptive scanning path planning method for AI software supply chain according to claim 1, characterized in that, The marginal gain greedy selection includes: calculating the overlap penalty coefficient based on the global stability index, which is negatively correlated with the global stability index; calculating the marginal gain of each candidate scanner, which is the product of the scheduling matching degree minus the overlap penalty coefficient and the maximum capacity overlap; selecting the scanner with the positive and largest marginal gain to add to the selected set; repeating until the candidate set is empty or resources are insufficient.

6. The adaptive scanning path planning method for AI software supply chain according to claim 1, characterized in that, The updated capability confidence coefficient includes: calculating the deviation value and limiting it within a preset range; calculating the adjustment amount according to the sign and absolute value of the deviation using a piecewise function, with the adjustment range increasing monotonically with the absolute value of the deviation; and adding the capability confidence coefficient to the adjustment amount and limiting it between preset upper and lower limits.

7. The adaptive scanning path planning method for AI software supply chain according to claim 1, characterized in that, The update of the global stability index includes: maintaining a global list storing the most recent preset number of deviation values; calculating the sample variance of the list; updating the global stability index to 1 minus the ratio of the sample variance to a preset upper limit of variance, and limiting it to between 0 and 1.

8. The adaptive scanning path planning method for AI software supply chain according to claim 1, characterized in that, Also includes: Map vulnerabilities to risk dimensions based on the list of vulnerabilities detected by the scan; If the strength value of this dimension in the project risk requirement vector is lower than the preset coverage threshold, then candidate mapping rules are generated based on the triggering conditions in the original feature vector; when the confidence count of the draft rules with the same triggering conditions reaches the activation threshold, their status is updated to effective.

9. The adaptive scanning path planning method for AI software supply chain according to claim 1, characterized in that, The denominator of the actual detection rate is determined based on the scanner's counting unit: the number of Pickle model files, the total number of dependency packages, the total number of model files, or the number of source code files; the numerator is the number of vulnerabilities detected by the scanner.

10. An adaptive scanning path planning device for the AI ​​software supply chain, characterized in that, include: The feature extraction module is configured to obtain the original feature vector of the target project and generate a project risk requirement vector, wherein the dimension of the project risk requirement vector is aligned with the capability dimension of the scanner. The scanner profile storage module is configured to store the static capability vector, capability confidence coefficient and utility history of each scanner. The scheduling matching calculation module is configured to calculate the scheduling matching degree of each scanner based on the project risk requirement vector and the capability profile of each scanner. The greedy selection module is configured to obtain the set of mandatory scanners and the system's global stability index, dynamically determine the overlap penalty coefficient based on the global stability index, and select the final scanner combination based on the marginal gain greedy algorithm. The scan execution module is configured to call the final scanner combination to perform a scan and obtain the actual detection rate; The feedback update module is configured to update the scanner's capability confidence coefficient and utility history based on the deviation between the actual detection rate and the scheduling matching degree, and update the global stability index based on the fluctuation of multiple deviations.

Images