A software research and development security access control implementation method, device and equipment and storage medium

Abstract

The application discloses a software research and development security access control implementation method, device and equipment and a storage medium. The method comprises the following steps: the function test and the interface test are divided into multiple short period windows; test traffic is captured at the end of each short period window, and the test traffic is subjected to deduplication processing; the deduplicated test traffic is subjected to playback attack test to obtain a test result; the test result is subjected to access control detection at a first security checkpoint to obtain a first security scanning result; when the detection time of the access control detection exceeds a first preset time and the access control detection is not completed, the test result is subjected to access control detection at a second security checkpoint according to a second preset time to obtain a second security scanning result; and the test result, the first security scanning result and the second security scanning result are reported. According to the method, the application with long security test time does not need to block the process, and efficient cooperation of full-process automatic security test and agile delivery is realized.

Description

A software development method, device, equipment, and storage medium for implementing secure access control. Technical Field

[0001] This invention relates to the field of software development technology, and in particular to a method, apparatus, device, and storage medium for implementing secure access control in software development. Background Technology

[0002] In the current software development lifecycle, security testing, especially penetration testing, is typically treated as a separate project and conducted only before major version releases due to its complexity, high level of expertise required, and long processing time. However, with the rise of agile development and the significantly accelerated pace of software version iteration, this traditional, centralized penetration testing model is no longer suitable for the rapid iteration rhythm. Its execution frequency is far lower than the version release frequency, resulting in a large number of iterations not undergoing sufficient security verification before release. Potential security vulnerabilities cannot be identified and patched in a timely manner, leading to ongoing security risks.

[0003] Meanwhile, in continuous integration (CI) and continuous delivery (CD) pipelines designed for rapid delivery, quality gates are typically established as fixed checkpoints. Integrating these into gates is feasible for relatively short-duration tasks such as static code security scanning. However, for more in-depth security testing processes like penetration testing, execution times can easily reach tens of minutes or even hours. Setting these as mandatory bottlenecks in the pipeline would severely disrupt development continuity and efficiency. Developers would have to wait a long time after submitting code to receive the build results and deploy it to the environment for functional verification. Such frequent, long waits would disrupt the development process, contradicting the core principle of agile development: rapid feedback. Summary of the Invention

[0004] The purpose of this invention is to provide a method, apparatus, device, and storage medium for implementing secure access control in software development, aiming to solve the problems of low efficiency in existing security testing processes.

[0005] In a first aspect, embodiments of the present invention provide a method for implementing secure access control in software development, comprising:

[0006] Receive the code to be tested;

[0007] Functional testing and interface testing are broken down into multiple short-cycle windows, and the code to be tested is tested through multiple short-cycle windows;

[0008] At the end of each short-cycle window, capture the test traffic and deduplicate the test traffic.

[0009] The deduplicated test traffic was replayed for attack testing to obtain the test results;

[0010] Set up a first security checkpoint and a second security checkpoint, and set a first preset time and a second preset time for the first security checkpoint and the second security checkpoint respectively; the first preset time is less than the second preset time;

[0011] At the first security checkpoint, the code to be tested is subjected to access control detection to obtain the first security scan result;

[0012] When the access control detection time exceeds the first preset time and the access control detection is not completed, the code to be tested is subjected to access control detection at the second security checkpoint according to the second preset time to obtain the second security scan result;

[0013] The test results, the first security scan results, and the second security scan results shall be reported.

[0014] Secondly, embodiments of the present invention provide a software development security access control implementation device, comprising:

[0015] The receiving unit is used to receive the code to be tested.

[0016] The split unit is used to break down functional tests and interface tests into multiple short-cycle windows, and to test the code to be tested through multiple short-cycle windows;

[0017] The capture unit is used to capture test traffic at the end of each short-cycle window and to deduplicatize the test traffic.

[0018] The test unit is used to perform replay attack tests on the deduplicated test traffic and obtain the test results.

[0019] The setting unit is used to set a first security checkpoint and a second security checkpoint, and to set a first preset time and a second preset time for the first security checkpoint and the second security checkpoint respectively; the first preset time is less than the second preset time.

[0020] The first detection unit is used to perform access control detection on the code to be tested at the first security checkpoint to obtain the first security scan result;

[0021] The second detection unit is used to perform access control detection on the code to be tested at the second security checkpoint according to the second preset time when the access control detection time exceeds the first preset time and the access control detection is not completed, so as to obtain the second security scan result.

[0022] The reporting unit is used to report the test results, the first security scan results, and the second security scan results.

[0023] Thirdly, embodiments of the present invention provide a computer device, which includes a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the software development security access control implementation method described in the first aspect.

[0024] Fourthly, embodiments of the present invention also provide a computer-readable storage medium, wherein the computer-readable storage medium stores a computer program, which, when executed by a processor, implements the software development security access control implementation method described in the first aspect.

[0025] This invention discloses a method, apparatus, device, and storage medium for implementing secure access control in software development. The method includes: receiving code to be tested; dividing functional testing and interface testing into multiple short-cycle windows, and testing the code to be tested through multiple short-cycle windows; capturing test traffic at the end of each short-cycle window and deduplicating the test traffic; performing a replay attack test on the deduplicated test traffic to obtain test results; setting a first security checkpoint and a second security checkpoint, and setting a first preset time and a second preset time for the first security checkpoint and the second security checkpoint respectively; the first preset time is less than the second preset time; performing access control detection on the code to be tested at the first security checkpoint to obtain a first security scan result; when the access control detection time exceeds the first preset time and the access control detection is not completed, performing access control detection on the code to be tested at the second security checkpoint according to the second preset time to obtain a second security scan result; and reporting the test results, the first security scan result, and the second security scan result. This invention utilizes functional test traffic replay to achieve standardized penetration testing, ensuring security coverage for each version. Secondly, by setting a first and final checkpoint with timeout mechanisms, it balances testing depth with delivery speed. This solution allows applications with time-consuming security testing to avoid process blockage, while ensuring quality through the final checkpoint, achieving efficient collaboration between full-process automation of security testing and agile delivery. Embodiments of this invention also provide a software development security access control device, a computer-readable storage medium, and a computer device, all possessing the aforementioned beneficial effects, which will not be elaborated further here. Attached Figure Description

[0026] To more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings used in the following description of the embodiments will be briefly introduced. 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.

[0027] Figure 1 is a flowchart illustrating the implementation method of secure access control in software development;

[0028] Figure 2 is a schematic diagram of the sub-processes of the software development security access control implementation method;

[0029] Figure 3 is a flowchart of the continuous integration and continuous delivery pipeline.

[0030] Figure 4 is a schematic block diagram of a software-developed secure access control implementation device. Detailed Implementation

[0031] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. 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.

[0032] It should be understood that, when used in this specification and the appended claims, the terms “comprising” and “including” indicate the presence of the described features, integrals, steps, operations, elements and / or components, but do not exclude the presence or addition of one or more of its features, integrals, steps, operations, elements, components and / or collections thereof.

[0033] It should also be understood that the terminology used in this specification is for the purpose of describing particular embodiments only and is not intended to limit the invention. As used in this specification and the appended claims, the singular forms “a,” “an,” and “the” are intended to include the plural forms unless the context clearly indicates otherwise.

[0034] It should also be further understood that the term "and / or" as used in this specification and the appended claims refers to any combination of one or more of the relevant listed items and all possible combinations, and includes such combinations.

[0035] Please refer to Figures 1 and 2. This embodiment provides a method for implementing secure access control in software development, including:

[0036] S101: Receive the code to be tested;

[0037] S102: Break down functional testing and interface testing into multiple short-cycle windows, and test the code to be tested through multiple short-cycle windows;

[0038] Specifically, functional testing and interface testing are broken down into multiple short-cycle windows, and the code to be tested is tested through these multiple short-cycle windows, including:

[0039] Obtain all business functions for functional testing and establish a corresponding business function matrix;

[0040] Based on the business function matrix, all business functions are classified from two dimensions: business value and risk level, forming a four-quadrant priority model.

[0041] Based on the four-quadrant priority model, the window execution priority of each business function is determined;

[0042] Based on window execution priority, a core-edge splitting strategy is adopted to decompose each business function into core paths and edge scenarios;

[0043] Build a quick feedback window and an extended verification window;

[0044] The core path is categorized into the rapid feedback window, while edge scenarios are categorized into the extended verification window, forming multiple short-cycle windows. The processing time of the rapid feedback window is shorter than that of the extended verification window.

[0045] Specifically, all business functions of the application under test are acquired, including core functionalities such as user login, order creation, payment processing, and data query. A business function matrix is ​​constructed based on these functionalities, with rows representing function categories and columns representing function attributes, including execution frequency, data dependency, and business criticality. Next, based on the business function matrix, all business functions are categorized from two dimensions: business value and risk level. Business value is assessed through function usage frequency and revenue contribution, while risk level is assessed through historical defect density and security sensitivity, resulting in a four-quadrant priority model: high value / high risk, high value / low risk, low value / high risk, and low value / low risk. According to the four-quadrant priority model, the window execution priority of each business function is determined, with high-value / high-risk functions receiving the highest priority and low-value / low-risk functions receiving the lowest priority. Based on the window execution priority, a core-edge splitting strategy is adopted, decomposing each business function into core paths and edge scenarios. The core path covers the main functional flow and key branches, while the edge scenarios cover exception handling, boundary conditions, and special parameter combinations. Two types of test windows were then constructed: a quick feedback window and an extended verification window. The quick feedback window was configured with a 5-minute execution duration, and the extended verification window with a 15-minute execution duration. Core paths were assigned to the quick feedback window, while edge scenarios were assigned to the extended verification window, forming multiple short-cycle windows. The quick feedback window was executed immediately after each code commit, while the extended verification window was executed centrally during nighttime builds. This ensured that core paths for high-priority functions could be tested and verified within 5 minutes, while comprehensive edge scenario tests were executed within the 15-minute window. The business processing time of the quick feedback window was shorter than that of the extended verification window, achieving optimized allocation of test resources and rapid acquisition of test feedback.

[0046] In some embodiments, a business function matrix is ​​constructed based on these function points, where the matrix rows represent function categories and the columns represent function attributes, including:

[0047] All functionalities of the application under test are collected and categorized according to business domains, including user authentication, transaction processing, data management, report generation, and system configuration. These categories form the rows of a matrix. The columns of the matrix are defined as functional attribute dimensions, including execution frequency, data dependency, business criticality, security sensitivity, and historical defect rate. Execution frequency is determined by analyzing the average daily call count of each function in production environment logs, categorized into high frequency (greater than 1000 times / day), medium frequency (100-1000 times / day), and low frequency (less than 100 times / day). Data dependency is determined by analyzing the number and depth of associations between the function and core data tables, categorized into high dependency (associations with 5 or more core tables), medium dependency (associations with 2-5 core tables), and low dependency (associations with fewer than 2 core tables). Business criticality is assessed based on the degree of impact of the function on business continuity, categorized into critical (function failure leads to business interruption), important (function failure affects some business operations), and general (function failure does not affect core business operations). Security sensitivity is determined based on the data type and permission level processed by the function, categorized as high sensitivity (processing personal identification information and financial data), medium sensitivity (processing business operation data), and low sensitivity (processing publicly available data). Historical defect rate is calculated by analyzing data from the defect management system over the past six months, representing the average number of defects per thousand lines of code for each function. Each cell in the matrix is ​​filled with the evaluation value for the corresponding function category across various attribute dimensions, forming a complete business function matrix and providing a data foundation for subsequent short-term window segmentation. The matrix employs a weighted scoring mechanism, assigning higher weights to business criticality and security sensitivity to ensure that high-value, high-risk functions receive priority in testing resource allocation. The matrix data is updated quarterly or dynamically adjusted when significant changes occur in the application architecture to maintain synchronization with actual business conditions.

[0048] This implementation achieves precise allocation of testing resources through multi-dimensional quantitative evaluation. The matrix structure transforms abstract business value into measurable, concrete indicators, avoiding the uneven resource allocation problems caused by experience or subjective judgment in traditional testing. Systematic evaluation of dimensions such as execution frequency, data dependency, and business criticality ensures that high-risk, high-value functions receive priority testing, significantly improving testing efficiency and issue detection rate. Of particular note is the introduction of the security sensitivity dimension, which directly strengthens the core objective of security access control, ensuring that functions handling sensitive data undergo sufficient security verification.

[0049] In some embodiments, based on a business function matrix, all business functions are classified from two dimensions: business value and risk level. Business value is assessed through function usage frequency and revenue contribution, while risk level is assessed through historical defect density and security sensitivity, forming a four-quadrant priority model including: high value high risk, high value low risk, low value high risk, and low value low risk.

[0050] From the established business function matrix, select the core attributes (matrix column data) used to assess business value and risk level as the basic data source for classification.

[0051] The core attributes of business value assessment include:

[0052] Core objective support level: The degree to which a function contributes to the system's core business objectives;

[0053] User impact scope: The size of the user group affected by the functional failure;

[0054] Operation frequency: The number of times a function is called per unit of time;

[0055] Revenue Relevance: The degree to which a function is directly or indirectly related to revenue.

[0056] The core attributes of risk level include:

[0057] Scope of impact of the fault: Whether the functional failure causes other services to be interrupted;

[0058] Data security sensitivity: Does the data processed by the function contain private / sensitive data (such as mobile phone numbers, payment information);

[0059] Recovery difficulty: The time and resources required to repair the fault;

[0060] Compliance requirements: Whether it complies with industry regulations or internal compliance standards (such as payment compliance in the financial industry).

[0061] Next, to avoid subjectivity in classification, quantifiable assessment indicators, scoring rules, and grading standards need to be developed for business value and risk level respectively. The general standards are shown in Table 1:

[0062] Table 1

[0063]

[0064] Among them, high business value: total score of indicators ≥ 16 points (average score of 4 indicators ≥ 4 points).

[0065] Mid-level business value: Total score of 8-15 points (average score of 2-3.9 points);

[0066] Low business value: Total score of indicators ≤ 7 points (average score ≤ 1.9 points).

[0067] Furthermore, the risk level assessment criteria are shown in Table 2:

[0068] Table 2

[0069]

[0070] High-risk level: Total score of indicators ≥ 16 points (average score of 4 indicators ≥ 4 points).

[0071] Medium risk level: Total score of indicators 8-15 points (average score 2-3.9 points);

[0072] Low risk level: Total score of indicators ≤ 7 points (average score ≤ 1.9 points).

[0073] Subsequently, based on the evaluation criteria, scores were assigned to the four business value indicators and four risk level indicators for each business function, and the scores were entered into the evaluation form.

[0074] Then sum the scores of the four indicators in the business value dimension and the four indicators in the risk level dimension respectively;

[0075] Next, based on the total score and the grading rules, determine the business value level (high / medium / low) and risk level (high / medium / low) of each business function.

[0076] Next, the two-dimensional levels of each business function are added as new columns to the business function matrix, forming a complete mapping data of business functions, attributes, value levels, and risk levels.

[0077] Example: Evaluation process of payment function of an e-commerce system: Business value score: support for core objectives 5 points + scope of user influence 5 points + operation frequency 5 points + revenue relevance 5 points = 20 points, which is considered high business value;

[0078] Risk level score: 5 points for scope of impact of failure + 5 points for data security sensitivity + 5 points for recovery difficulty + 5 points for compliance requirements = 20 points, which is considered a high-risk level;

[0079] Matrix supplementary record: Payment function - high business value - high risk level.

[0080] Then, using business value level as the vertical axis and risk level as the horizontal axis, a four-quadrant model is constructed, mapping each business function to a specific quadrant according to the two-dimensional level, as shown in Table 3:

[0081] Table 3

[0082]

[0083] The mapping operation involves traversing all business functions in the business function matrix, assigning them to the corresponding quadrants based on their recorded dual-dimensional levels, and finally forming a four-quadrant priority distribution table to clarify the list of business functions included in each quadrant.

[0084] In some embodiments, based on window execution priority, a core-edge splitting strategy is adopted to decompose each business function into core paths and edge scenarios, including:

[0085] Based on the window execution priority determined by the four-quadrant priority model, each business function is decomposed into paths. For high-priority functions (quadrants 1 and 2), deep path analysis is used to identify the core execution path of the function through static code analysis and call chain tracing. The core path is defined as the minimum set of functions covering more than 80% of user operation scenarios and containing key business rules. For example, the core path of the user login function includes username and password verification, session creation, and basic permission allocation. Edge scenarios are defined as all branch conditions, exception handling, and boundary cases outside the core path, including invalid credential handling, account locking mechanisms, and multi-factor authentication processes. For medium- and low-priority functions (quadrants 3 and 4), lightweight path analysis is used. The core path only includes the main success scenario, while edge scenarios include all possible failure paths and special condition handling. The identification of the core path uses traffic analysis to assist decision-making. By analyzing the call chain data of the production environment, path nodes with a call frequency exceeding 5% are included in the core path scope. The extraction of edge scenarios uses a decision table method to systematically enumerate all input combinations and state transition possibilities. Strict verification standards are set for core paths, requiring 100% coverage of key business rules and security control points. A risk-oriented sampling strategy is adopted for edge scenarios, maintaining 100% coverage for high-risk edge scenarios (such as handling permission verification failures), while dynamically adjusting the coverage ratio for medium- and low-risk edge scenarios based on historical defect distribution. Path decomposition results are compiled into structured description documents, including path identifiers, preconditions, operation sequences, expected results, and risk levels, providing a clear basis for test case allocation within short-cycle windows. The boundaries between core paths and edge scenarios are reviewed quarterly or dynamically adjusted when user behavior patterns change significantly, ensuring that test coverage remains consistent with actual usage patterns.

[0086] In some embodiments, for high-priority functions (first quadrant and second quadrant), a deep path analysis method is used to identify the core execution path of the function through static code analysis and call chain tracing, including:

[0087] A static code analysis engine is used to perform a full scan of the target function's source code, constructing a control flow graph and identifying all possible execution branches and data dependencies. During static analysis, special attention is paid to business rule implementation points, security control points, and data persistence operations, marking key nodes and decision points. Simultaneously, a call chain tracing proxy is deployed in the test environment using bytecode instrumentation technology to capture the function's execution path data in real test scenarios. The call chain tracing proxy records the entry parameters, return values, execution duration, and exception information for each method call, constructing a complete call sequence graph. The control flow graph generated by static analysis is fused with the call sequence graph obtained from dynamic tracing, calculating the execution frequency weight of each path. The weight calculation formula is: W = 0.6 * static call count + 0.4 * dynamic execution frequency. Based on path weight sorting, accumulation begins from the highest weight path. When the accumulated coverage reaches an 80% threshold, accumulation stops, and the selected path set is defined as the core execution path. For key nodes in the core execution path, their preconditions and postconditions are further analyzed to identify the necessary business rule constraints. In the user login function example, static code analysis identified the password verification algorithm, session generation logic, and permission loading mechanism as key code segments; call chain tracing data showed that username verification, password hash comparison, and session token creation were high-frequency execution nodes; fusion analysis determined that the path containing these nodes was the core execution path. The deep path analysis engine then automatically outputs a structured description of the core execution path, including path ID, coverage percentage, a list of key nodes, and a set of business rule constraints, providing precise path coverage targets for subsequent short-cycle test case design. The deep path analysis process for high-priority functions is automatically triggered after each major code change, ensuring that the core execution path definition remains synchronized with the code implementation.

[0088] In this embodiment, breaking down functional testing and interface testing into multiple short-cycle windows, and testing the code to be tested through multiple short-cycle windows, further includes:

[0089] Collect historical data for the interface to be tested, including the interface importance level and interface call frequency;

[0090] Establish a hierarchical model based on the importance level and frequency of interface calls;

[0091] Each interface is assigned a test priority weight based on a hierarchical model;

[0092] All interfaces to be tested are grouped according to test priority weights to generate multiple interface test groups;

[0093] Assign test cases to each interface test group to form a test case set;

[0094] Calculate the short-cycle window duration for each interface test group based on the number of test cases and the preset time threshold.

[0095] Based on the short-cycle window duration, corresponding short-cycle window parameters are generated for each interface test group, resulting in multiple short-cycle windows. The window parameters include the window start time, window end time, and window sequence.

[0096] Specifically, historical data of the interfaces to be tested are collected from the application monitoring platform and API gateway log system. The historical data includes the importance level of the interface and the frequency of interface calls. The importance level of the interface is calculated by weighting three indicators: business impact, data sensitivity level and system coupling. The frequency of interface calls is based on the production environment statistics of the past 30 days, including the average number of calls per day, the peak number of calls and the call stability coefficient. Next, a hierarchical model is established based on the importance level and call frequency of the interfaces. This hierarchical model adopts a dynamic threshold grading method. After normalizing the importance level and call frequency, the comprehensive score S is calculated as: S = 0.65 * normalized importance level value + 0.35 * normalized call frequency value. Based on the distribution of the comprehensive score, the interfaces are divided into five levels using an equal-frequency binning algorithm: L1 level is for S values ​​between 0.85 and 1.0, L2 level is for S values ​​between 0.70 and 0.84, L3 level is for S values ​​between 0.55 and 0.69, L4 level is for S values ​​between 0.40 and 0.54, and L5 level is for S values ​​between 0.0 and 0.39. The ratio of the number of interfaces in each level is controlled at 2:3:3:1.5:0.5. Based on a hierarchical model, each interface is assigned a test priority weight: L1 layer interfaces have a weight of 1.0, L2 layer interfaces have a weight of 0.85, L3 layer interfaces have a weight of 0.7, L4 layer interfaces have a weight of 0.5, and L5 layer interfaces have a weight of 0.3. Interfaces within the same layer undergo linear interpolation fine-tuning based on their comprehensive scores. Subsequently, all interfaces to be tested are grouped according to their test priority weights. An adaptive clustering algorithm is used to divide the interfaces into 4-8 interface test groups, ensuring that high-weight interfaces are grouped separately, low-weight interfaces are aggregated by business domain, the weight variance of each group does not exceed 0.05, and the business relevance of interfaces within a group is not less than 0.6. Test cases are assigned to each interface test group, forming a test case set. The L1 layer interface group executes 100% security test cases and functional test cases; the L2 layer interface group executes 100% security test cases and 80% functional test cases; the L3 layer interface group executes 80% security test cases and 60% functional test cases; and the L4 and L5 layer interfaces are combined and executed with 60% security test cases and 40% functional test cases. Based on the number of test cases in each interface test group and the preset time threshold, the short-cycle window duration corresponding to each interface test group is calculated. The time threshold is dynamically calculated based on the system resource capacity. The basic formula is: window duration (minutes) = number of test cases / 50 + level adjustment coefficient, where the level adjustment coefficient of L1 is 0, L2 is 0.5, L3 is 1.0, and L4 and L5 are combined into 1.5. The maximum window duration does not exceed 15 minutes.Based on the short-cycle window duration, corresponding short-cycle window parameters are generated for each interface test group, resulting in multiple short-cycle windows. The window parameters include the window start time, window end time, and window sequence. The window sequence is arranged in descending order according to the test priority weight. The window sequence number is 1 for the L1 layer interface group, 2 for the L2 layer, and so on. The window start time is dynamically calculated based on the current load status of the CI / CD pipeline and the estimated completion time of the previous window, ensuring a 20-second environment reset interval between windows. The window end time is equal to the window start time plus the window duration plus a 10-second buffer time. All window parameters are stored in the scheduling configuration database as the basis for the execution of the automated test engine.

[0097] In some embodiments, functional testing and interface testing are broken down into multiple short-cycle windows, and the code to be tested is then tested through multiple short-cycle windows, further comprising:

[0098] Obtain the attack payload template library and business permission configuration data;

[0099] Normal traffic data is captured through short-period windows to generate a basic traffic sample set;

[0100] Perform parameter parsing on the basic traffic sample set to extract nodes with mutable parameters;

[0101] The structured query language injection payload and path traversal payload from the attack payload template library are injected into the mutable parameter node to generate derivative attack traffic;

[0102] Extract request sequence features from the basic traffic sample set and construct a traffic sequence pattern graph;

[0103] Based on the traffic sequence pattern graph, the dependencies of business operations are identified, and the operation path topology is generated.

[0104] Based on the operation path topology and business permission configuration data, construct an unauthorized access test sequence;

[0105] Merge derived attack traffic and unauthorized access test sequences to form an enhanced penetration test case set;

[0106] Update the enhanced penetration test case set to the penetration test case library to generate the updated test case library.

[0107] Specifically, an attack payload template library is loaded from a security knowledge base. This library contains 256 predefined structured query language injection payload templates, 128 path traversal payload templates, and 192 other types of attack payload templates. Simultaneously, business permission configuration data, including role-permission mapping tables, resource access control lists, and sensitive operation whitelists, is obtained from the business system configuration center. The traffic capture agent monitors network communication in real time during each short-cycle window, recording HTTP request methods, URL paths, request headers, request bodies, and response data. Static resource requests and heartbeat detection traffic are filtered out, generating a basic traffic sample set containing valid business interactions. The sample set is stored according to interface ID and business scenario. Deep analysis of the basic traffic sample set is performed, using syntax analysis algorithms to identify JSON, XML, and form data structures. All user-controllable parameter nodes are marked, and a set of mutable parameter nodes is determined based on parameter type, length limits, and format constraints. Each node is labeled with a mutation compatibility tag. The structured query language injection payload and path traversal payload from the attack payload template library are injected into the mutable parameter nodes according to compatibility tags. Integer overflow and boundary value payloads are applied to numerical parameters, and special character encoding and multi-level nested payloads are applied to string parameters. This generates derived attack traffic containing original request and mutated request pairs, with each derived attack traffic tag labeled with payload type and expected abnormal behavior. Next, the time series and state dependencies of requests in the basic traffic sample set are analyzed to extract session identifier transmission patterns, state transition conditions, and key operation pre-requirements. A traffic sequence pattern graph in the form of a directed acyclic graph is constructed, where nodes represent business operations and edges represent operation transition probabilities and dependency strengths. The traffic sequence pattern graph is traversed to identify the set of mandatory pre-operations and key points of privilege escalation, generating a triple operation path topology structure containing operation nodes, transition conditions, and privilege requirements. Combining the operation path topology structure and business permission configuration data, a scenario of low-privilege users performing high-privilege operations is simulated, constructing unauthorized access test sequences including role switching, session hijacking, and privilege boundary breaching. Each sequence is labeled with expected permission verification failure points. Derivative attack traffic and unauthorized access test sequences are weighted and merged according to risk level. High-risk SQL injection payloads and critical business unauthorized access sequences are prioritized for combination, forming an enhanced penetration test case set containing 1500-3000 test cases. Each test case includes execution order, expected response, and risk rating. The test case library update service compares the enhanced penetration test case set with the existing penetration test case library, retaining historically valid test cases, replacing outdated attack patterns, adding new test sequences, and generating a version-controlled updated test case library. Simultaneously, it updates the test case index and metadata tags to ensure the test engine can efficiently retrieve and execute the latest security test cases. The entire process is executed in a resource-isolated test environment. All generated attack traffic undergoes security filtering to ensure it does not cause actual system damage. Traffic data is encrypted and stored, and only necessary test cycles are retained before automatic cleanup.

[0108] This embodiment's method of generating attack cases based on actual business traffic significantly improves the accuracy and effectiveness of testing, avoiding the resource waste caused by a large number of invalid payloads in traditional penetration testing. The dual mechanism of parameter mutation and business sequence analysis not only covers traditional injection vulnerabilities but also effectively identifies privilege escalation risks at the business logic level, forming a defense-in-depth testing system. By using graph structures to model business operation dependencies, the system can understand the permission boundaries and key operation chains in complex business processes, thereby constructing advanced attack paths that conform to actual business scenarios.

[0109] In some embodiments, a deep parsing of the basic traffic sample set is performed, using a syntax analysis algorithm to identify JSON, XML, and form data structures, marking all user-controllable parameter nodes, and determining the set of mutable parameter nodes based on parameter type, length limits, and format constraints, including:

[0110] The process loads HTTP request content from a basic traffic sample set, determines the data format of the HTTP request content, applies a recursive descent algorithm to construct a JSON abstract syntax tree for JSON types, applies a SAX parsing algorithm to construct an XML document object model for XML types, and applies a key-value pair parsing algorithm to construct a parameter mapping structure for form types. The parsing process traverses the constructed data structure, identifying all leaf nodes and attribute values ​​as candidate parameter positions, while simultaneously analyzing validation error information in the server response to help determine the parameter structure boundaries. The user controllability marking process combines request source characteristics, parameter position characteristics, and business context characteristics to mark URL query parameters, request body fields, cookie values, and custom fields in HTTP headers as directly controllable parameters, and indirectly referenced data identifiers as indirectly controllable parameters, excluding uncontrollable parameters such as system-generated timestamps, session tokens, and digital signatures. The mutation compatibility assessment process performs type inference for each user-controllable parameter, determining the parameter type by analyzing the value distribution in historical request samples, including string, numeric, boolean, date, and enumeration types. Simultaneously, the validation rules returned in the server response are extracted to identify parameter length limitations, format constraints, and business rule restrictions, such as string length ranges, numerical boundaries, regular expression patterns, and dependencies between related fields. Based on these characteristics, the mutation compatibility assessment process calculates a mutation capability score for each parameter. The scoring formula is S = 0.4 * type variability + 0.3 * length tolerance + 0.3 * format compatibility, where type variability is calculated based on the acceptable payload range of the parameter type, length tolerance is calculated based on the parameter length fluctuation range in historical requests, and format compatibility is calculated based on the server's tolerance for format errors. When the mutation capability score exceeds a threshold of 0.65, the parameter is included in the mutable parameter node set. Each node in the set is labeled with a mutation strategy, including four types of mutation strategies: character injection, structural disruption, boundary breach, and semantic obfuscation.

[0111] In some embodiments, the time series and state dependencies of requests in the basic traffic sample set are analyzed to extract session identifier transmission patterns, state transition conditions, and key operation prerequisites. A traffic sequence pattern graph in the form of a directed acyclic graph is constructed, where nodes represent business operations and edges represent operation transition probabilities and dependency strengths, including:

[0112] The system loads all request records for the same user session from the basic traffic sample set and sorts them by timestamp to form a request sequence dataset. It then traverses this dataset, identifying cookies (small text files stored in a user's browser), the Authorization header (a key object for identifying session dependencies and simulating attacks in software testing), and session identifiers passed in request parameters. It tracks the transmission path and transformation patterns of session identifiers across different requests, establishing a session identifier transmission pattern, including identifier generation location, transmission method, and expiration conditions. Subsequently, it monitors changes in server response status codes, status identifiers, and business data, combining request parameters to identify key conditions triggering state transitions, such as valid session verification and user permission checks required to transition from login status to order creation status. The pre-requirement mining process uses a sequence pattern mining algorithm to identify pre-requirement patterns for key business operations and calculates operation dependency confidence. For example, a shopping cart creation and order confirmation operation must precede a payment operation; operation sequences with a confidence score exceeding 0.85 are considered strong dependencies. The identified business operations are then abstracted into nodes, including operation types such as login, query, create, modify, and delete. Each node is assigned a unique identifier and an operation feature vector, containing metrics such as operation frequency, average response time, and error rate. Next, the transition frequency between adjacent operations is calculated, and the transition frequency is divided by the total number of occurrences of the source node to obtain the operation transition probability. Simultaneously, the dependency strength value is calculated based on the tightness of state dependencies. The dependency strength is comprehensively calculated based on the number of data dependencies, state consistency requirements, and business rule constraints, with a value ranging from 0.0 to 1.0. Then, a topology sorting algorithm is applied to ensure that the node order conforms to the chronological order and dependency relationship, eliminating circular dependencies. For detected circular dependencies, a time window segmentation strategy is applied to divide long sessions into multiple sub-sessions for processing. Next, similar operation paths are merged, edges with a transition probability below 0.05 are pruned, and weak dependencies with a dependency strength below 0.3 are filtered out, improving the clarity and usability of the graph structure. Subsequently, similar business operations are merged, for example, merging product query operations with different query parameters into a unified product query node, maintaining the integrity of business semantics while reducing graph complexity. The resulting traffic sequence pattern graph is stored in the form of an adjacency list. Each node records the operation type, frequency of occurrence, and business characteristics, while each edge records the transition probability, dependency strength, and set of triggering conditions. Additional metadata for the graph data includes session identifier type, average session length, and critical path set, providing a data foundation for subsequent business dependency analysis. The entire analysis process is executed in memory, using an incremental computation strategy to handle large-scale traffic data, and timeout limits are set to ensure that the graph structure is constructed within a short period window constraint.

[0113] S103: Capture test traffic at the end of each short-cycle window and deduplicate the test traffic;

[0114] In this embodiment, capturing test traffic at the end of each short-cycle window includes:

[0115] Collect data on code change scope, historical failure rate, business priority, and resource availability as multi-dimensional indicators;

[0116] The execution order and resource quota for each short-cycle window are calculated based on multi-dimensional indicators to generate a window execution plan;

[0117] Predictive preloading technology is used to analyze window execution plans and predict the scope of code changes;

[0118] Based on the anticipated scope of code changes, test environment and test data are prepared in advance before code push, and a preload ready signal is generated;

[0119] When a preload ready signal is received, a dedicated resource pool is allocated to each short-cycle window according to the resource quota in the window execution plan;

[0120] The corresponding dedicated resource pool is invoked in the execution order to execute tests within the corresponding code change scope in each short cycle window, and the test traffic generated during the test process is recorded in real time.

[0121] Specifically, the code change scope is obtained from the version control system, historical failure rate data is extracted from the test history database, business priority indicators are obtained from the business requirements management system, and real-time resource availability data is collected from the resource monitoring platform, forming an evaluation indicator set containing four dimensions. Based on these multi-dimensional indicators, the execution order and resource quota for each short-cycle window are calculated. The execution order calculation uses a weighted sorting algorithm, with weights allocated as follows: code change scope impact 0.4, historical failure rate 0.3, business priority 0.2, and resource availability 0.1. Resource quota calculation allocates CPU cores, memory capacity, and network bandwidth based on window priority scores. High-priority windows receive no less than 30% of the total system resources, medium-priority windows receive 15%–25%, and low-priority windows receive no more than 15%. A window execution plan is generated, including the execution sequence number, resource quota details, and estimated execution duration. Predictive preloading technology is used to analyze the window execution plan. A machine learning model identifies the correlation between code change patterns and test requirements, predicting the scope of upcoming code changes with an accuracy rate exceeding 85%. Based on the anticipated scope of code changes, the preload controller initiates an environment preparation process 10 minutes before the code is officially pushed to the test environment. This includes creating container instances, deploying dependent services, injecting test datasets, and configuring network policies. When all preload tasks are completed and the environment health check passes, a preload ready signal is generated, containing the environment ID, dataset version, and resource reservation status. Upon receiving the preload ready signal, the resource allocator allocates independent dedicated resource pools to each short-cycle window according to the resource quota parameters in the window execution plan. Each resource pool contains compute nodes, storage volumes, and network isolation domains, ensuring that tests between windows do not interfere with each other. The execution engine calls the corresponding dedicated resource pools according to the execution order, loads test tasks with the corresponding code change scope within each short-cycle window, starts the traffic capture agent to monitor network communication in real time, and records HTTP request / response pairs, database query statements, external service call data and system logs. The traffic capture agent starts buffer data cleanup 30 seconds before the window ends, and triggers data persistence operation at the end of the window, storing all test traffic generated in this window in a standardized format to the traffic warehouse, and generating traffic metadata including timestamp, window ID, code version number and traffic type label, providing high-quality input data for subsequent security penetration testing.

[0122] Next, the captured test traffic is deduplicated. Specifically, the captured test traffic is analyzed. Key information such as session identifiers and user tokens in each network request in the test traffic is identified and extracted. Based on this information, continuous duplicate requests from the same user session are deduplicated within the session, retaining only the first occurrence of each unique request in that session.

[0123] Next, the URL parameters of each request are standardized and sorted, and dynamic parameter values ​​that do not affect the semantics of security testing are removed. Simultaneously, the JSON or XML data in the HTTP request body is structurally normalized. For normalized requests that are exact matches, they are considered duplicates and only one copy is retained.

[0124] Then, all requests within the entire short period window are further subdivided according to the preset sub-window duration. Within each sub-window, requests with the same normalization characteristics and similar request times are aggregated, and only one representative sample is retained.

[0125] To accurately determine request similarity, a unique fingerprint is generated for each normalized request. This fingerprint integrates the request method, the normalized request path, parameter structure features, and key header information. The system calculates the hash value of this fingerprint and quickly filters out duplicate requests by comparing the hash value with a deduplicated hash set in memory.

[0126] After the above multi-level deduplication process, the system finally outputs a deduplicated and streamlined set of test traffic data for subsequent penetration test playback and analysis.

[0127] S104: Perform a replay attack test on the deduplicated test traffic to obtain the test results;

[0128] In this embodiment, the different application environments vary significantly. Some critical business applications have well-developed environments (development, testing, pre-release, and production), while some internal systems have relatively limited environments (possibly only development and production). Furthermore, penetration testing generates a large amount of dirty data and uncontrollable behavior, which can be highly destructive to less robust systems. Therefore, the measures we take are as follows:

[0129] The penetration test is scheduled to be performed in a non-production environment (testing or development environment).

[0130] Penetration testing is managed through application configuration items, including but not limited to penetration test addresses and on / off flags. When the application environment with the configuration items in effect is deployed, a penetration test task is triggered. The penetration test task ends and the results are displayed when the workflow reaches the penetration test node.

[0131] Furthermore, the deduplicated test traffic data set is read and input into the penetration testing engine. Based on a pre-configured attack rule base, the penetration testing engine automatically replaces and transforms attack payloads on key parameters in the traffic, such as inserting SQL injection probe strings into HTTP request parameters or attempting to tamper with session identifiers in cookie fields.

[0132] Subsequently, the modified attack traffic was replayed onto a pre-prepared test target isolated from the production environment. The replay process simulated the timing and concurrency characteristics of real user requests, while simultaneously recording the target application's response data to each attack request, including HTTP status codes, response content, server error logs, and network latency changes.

[0133] The penetration testing engine analyzes the collected response data in real time, matching it against predefined security vulnerability characteristic rules to identify anomalies. For example, it can detect the presence of SQL injection vulnerabilities by checking if the response contains database error messages, or identify potential logical privilege escalation issues by comparing the response content with expected output.

[0134] Subsequently, all analyzed anomalies were aggregated to generate preliminary vulnerability events. These vulnerability events were then automatically verified and risk-rated, false positives were eliminated, and risk levels were assigned based on vulnerability type, exploitation difficulty, and potential impact.

[0135] Finally, the verified and rated vulnerability information, along with a complete chain of evidence including the original request that triggered the vulnerability, the attack payload, and the application response, is structured into a standard-format test result report. This report serves as the final output of this short-term security test.

[0136] S105: Set a first security checkpoint and a second security checkpoint, and set a first preset time and a second preset time for the first security checkpoint and the second security checkpoint respectively; the first preset time is less than the second preset time;

[0137] In this embodiment, step S104 is not run after step S103. It can run synchronously with step S102 or before step S102, as long as it is ensured that it does not run after step S103.

[0138] In this embodiment, referring to Figure 3, after artifact compilation and unit testing during the continuous integration phase, a security test node is set as the first security checkpoint. A maximum waiting time, such as 10 minutes, is configured for this checkpoint. This time is determined based on the historical average execution time of the static code security scanning tool selected by the team under typical project scale, and also takes into account the development team's maximum tolerance for process interruption.

[0139] Subsequently, at the end of the pipeline, before the application version is approved and ready for deployment to the production environment, a second checkpoint is set up. This checkpoint is responsible for forcibly blocking versions that did not obtain security scan results at the first checkpoint. Simultaneously, a minimum waiting time, such as 30 minutes, is configured for the second checkpoint. This minimum time setting follows the principle of ensuring that the background security testing service has sufficient time to complete a full scan, aiming to avoid bypassing necessary security verification steps due to overly rapid process progression.

[0140] Because of the significant time interval between the first checkpoint timeout and the jump to the second checkpoint, the security scanning service is required to proactively notify the pipeline system of the scan results after completion, regardless of the outcome. Upon receiving the results, the pipeline persistently stores them and clearly displays the scan status, details of discovered vulnerabilities, and their risk levels to the user in the pipeline's graphical interface. This allows development or operations personnel to identify and address issues as early as possible.

[0141] In some embodiments, security testing includes at least four aspects of detection, as shown in Table 4:

[0142] Table 4

[0143]

[0144] The detection tools mentioned above are merely examples; developers can create their own or choose relevant open-source tools. This embodiment does not impose any limitations on these tools. The three security activities performed during the development phase all involve static code scanning. Different security tools are required due to the different test points. These three activities are combined into a single node in the CI / CD pipeline, named Static Code Security Scan. Penetration testing is performed as a separate node during the testing phase.

[0145] S106: At the first security checkpoint, the code to be tested is subjected to access control detection to obtain the first security scan result;

[0146] In this embodiment, access control detection is performed on the code to be tested at the first security checkpoint, and the first security scan result includes:

[0147] The code to be tested is parsed using a non-compiled static analysis engine to generate code structure feature data;

[0148] Hard-coded voucher detection processing is performed on code structure feature data to generate voucher risk index values;

[0149] High-risk function call identification processing is performed on code structure feature data to generate a function call risk map;

[0150] Perform basic injection vulnerability scanning on code structure feature data to generate a candidate set of injection vulnerabilities;

[0151] Aggregate credential risk index values, function call risk graphs, and injection vulnerability candidate sets to construct a preliminary security assessment matrix;

[0152] The first security scan result is generated based on the preliminary security assessment matrix.

[0153] Specifically, lexical analysis is performed on the code under test, converting the code character stream into a token sequence to identify basic syntactic units such as keywords, identifiers, literals, and operators. Based on lexical analysis, syntactic analysis is performed on the code under test, using parsing algorithms to process the token sequence and construct an abstract syntax tree reflecting the hierarchical syntactic structure of the code. This tree structure uses the root node to represent the entire compilation unit, with child nodes representing syntactic elements such as class definitions, method declarations, control flow statements, and expressions. Then, based on the constructed abstract syntax tree, its nodes are traversed to extract code structure feature data. This code structure feature data includes control flow graphs, data dependencies, and function call hierarchies. Next, hard-coded credential detection processing is performed on the code structure feature data, using a combination of regular expression pattern matching and contextual semantic analysis to identify sensitive credentials embedded in the code, such as API keys, passwords, and certificates. Credential risk index values ​​are calculated based on credential type, exposure level, and access permissions, ranging from 0.0 to 10.0; values ​​exceeding a threshold of 3.5 are marked as high-risk. Simultaneously, high-risk function call identification processing is performed on the code structure feature data. Based on a predefined dangerous function knowledge base, functions such as `system`, `exec`, and `eval` that may lead to command injection, as well as insecure encrypted functions and functions with known vulnerabilities, are identified. A function call risk graph containing call chain paths, parameter sources, and risk propagation paths is constructed. Subsequently, basic injection vulnerability scanning is performed on the code structure feature data. Data flow analysis technology is applied to trace the path from user input to sensitive operations, detecting common injection points such as SQL injection, command injection, and XSS, generating a candidate set of injection vulnerabilities containing vulnerability locations, attack vectors, and confidence scores. Next, the credential risk index values, function call risk graph, and injection vulnerability candidate set are integrated, and each risk is normalized and weighted. Hard-coded credentials have a weight of 0.4, high-risk function calls have a weight of 0.35, and injection vulnerabilities have a weight of 0.25. A preliminary security assessment matrix containing risk type distribution, severity statistics, and a list of key files is constructed. Based on the preliminary security assessment matrix, a hierarchical decision-making algorithm is applied. When the number of high-risk items in the matrix exceeds 5 or the highest risk score exceeds 8.0, it is classified as a blocking level; 3-5 high-risk items or a highest score between 6.0 and 8.0 are classified as a warning level; all other cases are classified as pass level. A first security scan result containing a risk summary, a detailed issue list, and remediation suggestions is generated and stored in structured JSON format. A visual report is also generated for developers to view. The entire analysis process is executed in a resource-isolated container to ensure it does not affect other tasks in the pipeline. Low-priority checks are automatically truncated when the analysis times out, ensuring that partial results are returned within the preset maximum waiting time.

[0154] This embodiment directly analyzes the code under test using a static analysis engine without compilation, avoiding the resource consumption and time delays of the complete compilation process, significantly improving analysis efficiency. It is particularly suitable for operation under the strict time constraints of CI / CD pipelines. The multi-dimensional security analysis mechanism simultaneously detects hard-coded credentials, high-risk function calls, and injection vulnerabilities, constructing a defense-in-depth system that effectively compensates for the blind spots of single detection dimensions and improves the comprehensiveness of security coverage. The code structure feature-based analysis method goes beyond simple string matching; by understanding the syntax tree structure and data flow dependencies of the code, it significantly reduces the false positive rate and improves detection accuracy.

[0155] In some embodiments, an incremental abstract syntax tree is constructed through lexical analysis and syntactic analysis to extract code structure feature data. This code structure feature data includes control flow graphs, data dependencies, and function call hierarchies.

[0156] The system receives the code to be tested and converts the source code character stream into a sequence of tokens according to the lexical rules defined by the programming language specification. Each token contains a type identifier, text content, line number, and column number information. C++17 lexical rules are applied to C++ code, Java language specification lexical rules to Java code, and Python 3 lexical rules to Python code. Comments and whitespace characters are identified and skipped. Then, a predictive recursive descent algorithm is used to construct a hierarchical abstract syntax tree (AST) from the token sequence according to the language's BNF grammar specification. An incremental construction strategy reconstructs local subtrees only for modified code areas, maintaining the existing structure of unmodified areas and reducing analysis overhead. AST node types include expression nodes, statement nodes, declaration nodes, and literal nodes. Each node records its precise location range in the source code and its child node relationships. Next, the statement nodes in the AST are traversed, identifying conditional statements, loop statements, and jump statements. Basic blocks are used as nodes, and control transfers are used as edges to construct a directed graph structure. Basic blocks are defined as continuous statement sequences with a single entry and single exit point. Conditional branches create two outgoing edges, loop structures create back edges, and exception handling creates special control paths. Next, using chain analysis algorithms, the declaration and usage positions of variables in the abstract syntax tree are tracked, identifying the definition and usage points of variables, and constructing a data dependency graph. Nodes represent variable operations, and edges represent data flow, distinguishing between three types: true dependency, anti-dependency, and output dependency, while recording dependency strength (single use, multiple uses, and use within a loop). Then, function call expressions in the abstract syntax tree are identified, and a call graph is constructed. Nodes represent function definitions, and edges represent call relationships, recording call frequency, parameter passing methods, and return value usage. Recursive calls are specially marked, and library function calls are standardized. Following this, the control flow graph, data dependencies, and function call hierarchy are unified into a structured data format. The control flow graph is represented by an adjacency matrix, containing basic block identifiers, conditional expressions, and path probabilities; data dependencies are represented by sets of triples, containing variable names, definition positions, and usage positions; and the function call hierarchy is represented by a hierarchical JSON structure, containing function signatures, call depths, and cross-module call markers. Feature data is compressed and optimized, and incremental changes are stored using differential encoding. The entire analysis process is executed in a memory-constrained environment. When dealing with large changes, priority is given to function bodies and critical control paths to ensure feature extraction is completed within a short-term window. Feature data is appended with version identifiers and timestamps to facilitate accurate association of code changes in subsequent security analysis phases.

[0157] In some embodiments, a method combining regular expression pattern matching and contextual semantic analysis is used to identify sensitive credentials such as API keys, passwords, and certificates embedded in the code. The credential risk index value is calculated based on credential type, exposure level, and access permissions, including:

[0158] Load a set of predefined regular expression patterns that cover the format characteristics of common sensitive credentials, such as specific prefix and length combinations of API keys from different cloud service providers, common variable naming patterns for password fields, and fixed start and end markers for certificate files. Then, use these patterns to scan all string constants in the code structure feature data one by one, quickly filtering out an initial set of candidate strings that conform to the characteristics of sensitive credentials in terms of form.

[0159] After obtaining the initial candidate set, contextual semantic analysis is initiated for each candidate string. This analysis process includes examining the code environment in which the string is referenced, such as whether it is assigned to variables or attributes whose names contain keywords such as "key," "token," or "credential." Simultaneously, it analyzes the target function to which the string is passed as a parameter, determining whether it is used for known security-sensitive operations such as authentication, encryption / decryption, database connection, or configuration initialization. By combining the morphological features of regular expression matching with the intent features of contextual semantics, various sensitive credentials such as API keys, database passwords, and encryption certificates embedded in the code can be identified with high accuracy and assigned precise type labels.

[0160] For each confirmed sensitive credential, a quantitative risk assessment process is initiated. This process is calculated based on three core dimensions: First, the inherent risk of the credential type itself is considered, with root certificates or global API keys assigned a high-risk weight, while test environment tokens are assigned a lower weight. Second, the exposure level of the credential is assessed, determining its exposure level based on whether it appears in frontend code, log statements, or publicly available configuration files. Finally, the potential access permissions that could be gained if the credential is leaked are analyzed, such as full control, read / write permissions, or read-only permissions. A pre-defined weighted calculation model is used to synthesize the assessment values ​​from these three dimensions into a single, comparable credential risk index value, which is used for subsequent prioritization and remediation guidance.

[0161] S107: When the access control detection time exceeds the first preset time and the access control detection is not completed, the code to be tested is subjected to access control detection at the second security checkpoint according to the second preset time to obtain the second security scan result;

[0162] In this embodiment, at the second security checkpoint, access control detection is performed on the code to be tested according to a second preset time, and the second security scan result includes:

[0163] Obtain code complexity assessment data, historical vulnerability density assessment data, and business criticality assessment data from the code to be tested to generate deep testing input parameters;

[0164] The depth detection input parameters are fed into the analytic hierarchy process (AHP) for weighted scoring to generate a comprehensive risk score.

[0165] The test depth level and corresponding test duration are determined based on the comprehensive risk score to generate deep test configuration parameters;

[0166] Based on the deep testing configuration parameters, perform deep security testing that combines static data stream tracing, control path exploration, and attack scenario simulation to generate a raw vulnerability discovery set;

[0167] The original vulnerability discovery set is classified into vulnerability levels, and the business impact and remediation difficulty dimensions of the original vulnerability discovery set are expanded to generate a second security scan result.

[0168] Specifically, static analysis is performed on the code under test to calculate cyclomatic complexity, lines of code, and nesting depth, generating code complexity assessment data. A historical defect database is consulted to statistically analyze the number of vulnerabilities and their severity distribution related to the code under test, generating historical vulnerability density assessment data. Based on the business architecture document, the usage frequency, data sensitivity, and business impact of the corresponding functions in the code under test are evaluated, generating business criticality assessment data. The code complexity assessment data, historical vulnerability density assessment data, and business criticality assessment data are aggregated to generate deep testing input parameters. Next, a three-level assessment model is constructed. The first layer is the target layer, i.e., a comprehensive risk score. The second layer is the criteria layer, containing three dimensions: code complexity, historical vulnerability density, and business criticality. The third layer is the solution layer, containing specific indicators for each dimension. The weights of each indicator are calculated using an expert-preset judgment matrix: code complexity has a weight of 0.35, historical vulnerability density has a weight of 0.45, and business criticality has a weight of 0.20. A consistency check is performed to ensure the CR value is less than 0.1, generating a comprehensive risk score ranging from 0 to 10. Based on the comprehensive risk score, the test depth level and corresponding test duration are determined using a segmented mapping strategy: a score of 8.5-10.0 corresponds to depth level 5 with a test duration of 15 minutes; a score of 7.0-8.4 corresponds to depth level 4 with a test duration of 12 minutes; a score of 5.5-6.9 corresponds to depth level 3 with a test duration of 9 minutes; a score of 4.0-5.4 corresponds to depth level 2 with a test duration of 6 minutes; and a score of 0-3.9 corresponds to depth level 1 with a test duration of 3 minutes. This generates depth test configuration parameters, including test tool configuration, timeout parameters, and resource allocation strategies. Subsequently, the depth test configuration parameters are loaded, and three detection technologies are executed in parallel in an isolated sandbox environment: static data flow tracing and analysis to identify sensitive data propagation paths; control path exploration using symbolic execution technology to generate high-coverage test cases; and attack scenario simulation to construct complex attack sequences based on historical attack patterns. The results of these three methods are fused and deduplicated to generate an original vulnerability discovery set, including vulnerability location, attack vector, reproduction steps, and preliminary risk level. The original vulnerability discovery set is then graded according to the CVSS 3.1 standard, while expanding the evaluation to two business dimensions: the business impact dimension considers the degree of impact of vulnerabilities on core business processes, data integrity, and user experience, and the remediation difficulty dimension assesses the scope of code modifications required for vulnerability remediation, test coverage requirements, and deployment complexity. Both dimensions are quantitatively evaluated using a 0-5 point scale, ultimately generating a structured second security scan result, including a vulnerability list, risk heatmap, business impact matrix, and remediation priority ranking. This result is automatically pushed to the CI / CD pipeline decision node as a key basis for whether to release the application version. The entire detection process is strictly controlled within a second preset time range, and in the event of timeout, the complete analysis results of high-risk vulnerabilities are retained first.

[0169] S108: Report the test results, the first security scan results, and the second security scan results.

[0170] Specifically, the test results generated during the testing process, the first security scan result generated at the first security checkpoint, and the second security scan result generated at the second security checkpoint are all collected uniformly. The collection process adopts an asynchronous processing mechanism to ensure that it does not affect the normal test execution flow.

[0171] Next, the collected results data are formatted and converted into a unified JSON data format. Sensitive information is anonymized during formatting, and large datasets are compressed and segmented. Metadata such as timestamps, version identifiers, and pipeline numbers are added to the formatted data.

[0172] The formatted result data is then reported to the central storage system via a secure transmission channel. The transmission process employs an encrypted transmission protocol to ensure data security. The central storage system establishes a multi-level storage architecture based on data type, with hot data stored in a cache and historical data transferred to archive storage.

[0173] Once the results are reported, a notification service is triggered to send a results-ready notification to the relevant users. The notification includes a summary of key metrics and a link to the detailed report. Users can access the test report interface through the security portal, which provides multi-dimensional data filtering and visualization capabilities.

[0174] In some specific implementations, a new version of application A is developed. The interface access path for this application in the test environment is: http: / / t-qa.lepass.cn / qa. After the developers successfully deploy the new version of application A to the test environment through the release pipeline, the system sends a penetration testing task notification to the security service. At this time, the security service creates a new penetration testing task and periodically (every 5 minutes, the interval should not be too long to avoid session expiration) pulls the access logs of application A (http: / / t-qa.lepass.cn / qa) from nginx within that 5-minute interval, deduplicates the requests, and then uses the deduplicated requests as input data for penetration testing security tools (such as Xray) to execute the penetration test. Then, the above process is repeated every 5 minutes until a clear task termination notification is received or the timeout occurs (e.g., more than 7 days). The nginx access log data comes from the version testing (version functional testing, regression testing, interface testing, etc.) conducted by testers in the test environment.

[0175] Once the testers complete the test and report that it passed, the penetration test ends. At this point, the security service stops the scheduled task and merges the test results from all 5-minute intervals between the start and end of the scheduled task, outputting a test report. Simultaneously, the security service compiles the vulnerability data in the report by severity and reports it to the access control service. The access control service determines whether to pass based on preset access control standards. For example, if two critical vulnerabilities were found in this test, and the company / project team requires that no critical vulnerabilities appear in the deployment, then this version will be blocked and will not be allowed to proceed to the next stage of development. Finally, the access control results and report are displayed to the user.

[0176] This embodiment, based on functional / interface test traffic replay, enables a standardized and automated process with 100% application version coverage. Furthermore, using this method, applications with long security execution times can proceed with other pipeline activities without waiting for all security tests to complete. Results are immediately apparent upon scan completion, allowing developers to address security vulnerabilities promptly. The second checkpoint serves as the final quality control measure, preventing non-compliant versions from entering the production environment.

[0177] Please refer to Figure 4. This embodiment provides a software development security access control implementation device 200, including:

[0178] Receiving unit 201 is used to receive the code to be tested;

[0179] The splitting unit 202 is used to split functional tests and interface tests into multiple short-cycle windows, and to test the code to be tested through multiple short-cycle windows;

[0180] The capture unit 203 is used to capture test traffic at the end of each short-cycle window and perform deduplication processing on the test traffic;

[0181] Test unit 204 is used to perform replay attack tests on the deduplicated test traffic and obtain test results;

[0182] Setting unit 205 is used to set a first security checkpoint and a second security checkpoint, and to set a first preset time and a second preset time for the first security checkpoint and the second security checkpoint respectively; the first preset time is less than the second preset time;

[0183] The first detection unit 206 is used to perform access control detection on the code to be tested at the first security checkpoint to obtain the first security scan result;

[0184] The second detection unit 207 is used to perform access control detection on the code to be tested at the second security checkpoint according to the second preset time when the access control detection time exceeds the first preset time and the access control detection is not completed, so as to obtain the second security scan result.

[0185] The reporting unit 208 is used to report the test results, the first security scan results, and the second security scan results.

[0186] Furthermore, the splitting unit 202 includes:

[0187] A matrix building subunit is used to obtain all business functions of the functional test and build a business function matrix corresponding to the business functions.

[0188] The classification subunit is used to classify all business functions based on the business function matrix from two dimensions: business value and risk level, forming a four-quadrant priority model.

[0189] The priority determination subunit is used to determine the window execution priority of each business function based on the four-quadrant priority model.

[0190] The decomposition subunit is used to decompose each business function into core paths and edge scenarios based on the execution priority of the window and adopting a core-edge splitting strategy.

[0191] The window building subunit is used to build the quick feedback window and the extended verification window;

[0192] The sub-unit is used to assign the core path to the fast feedback window and the edge scene to the extended verification window, forming multiple short-cycle windows; wherein the business processing time of the fast feedback window is less than the business processing time of the extended verification window.

[0193] Furthermore, the splitting unit 202 includes:

[0194] The data collection subunit is used to collect historical data of the interface to be tested, including the interface importance level and interface call frequency;

[0195] The model building subunit is used to build a hierarchical model based on the importance level and frequency of interface calls.

[0196] The weight allocation subunit is used to assign a test priority weight to each interface based on the hierarchical model.

[0197] The grouping subunit is used to group all interfaces to be tested according to the test priority weight, and generate multiple interface test groups;

[0198] The test case allocation subunit is used to allocate test cases to each of the interface test groups to form a test case set.

[0199] The duration calculation subunit is used to calculate the short-cycle window duration corresponding to each interface test group based on the number of test cases in each interface test group and the preset time threshold.

[0200] The parameter generation subunit is used to generate corresponding short-cycle window parameters for each interface test group based on the short-cycle window duration, resulting in multiple short-cycle windows. The window parameters include the window start time, window end time, and window sequence.

[0201] Furthermore, the grasping unit 203 includes:

[0202] The metrics collection subunit is used to collect multi-dimensional metrics such as code change scope, historical failure rate, business priority, and resource availability.

[0203] The plan generation subunit is used to calculate the execution order and resource quota for each short-cycle window based on the multi-dimensional indicators, and generate a window execution plan;

[0204] The prediction subunit is used to analyze the window execution plan using predictive preloading technology and predict the scope of code changes;

[0205] The ready subunit is used to prepare the test environment and test data in advance before the code is pushed, based on the predicted scope of code changes, and generate a preload ready signal;

[0206] The resource pool allocation subunit is used to allocate a dedicated resource pool to each short-cycle window according to the resource quota in the window execution plan when the preload ready signal is received.

[0207] The real-time recording subunit is used to call the corresponding dedicated resource pool according to the execution order to execute tests of the corresponding code change scope within each short cycle window, and to record the test traffic generated during the test in real time.

[0208] Furthermore, the first detection unit 206 includes:

[0209] The syntax tree parsing subunit is used to parse the code under test using a non-compiled static analysis engine to generate code structure feature data.

[0210] The voucher detection subunit is used to perform hard-coded voucher detection processing on the code structure feature data and generate voucher risk index values.

[0211] The function call subunit is used to identify high-risk function calls from the code structure feature data and generate a function call risk map.

[0212] The vulnerability scanning subunit is used to perform basic injection vulnerability scanning processing on the code structure feature data and generate a candidate set of injection vulnerabilities.

[0213] The aggregation subunit is used to aggregate the credential risk index value, the function call risk graph, and the injection vulnerability candidate set to construct a preliminary security assessment matrix.

[0214] The result generation subunit is used to generate a first security scan result based on the preliminary security assessment matrix.

[0215] Furthermore, the second detection unit 207 includes:

[0216] The data acquisition subunit is used to acquire code complexity assessment data, historical vulnerability density assessment data, and business criticality assessment data from the code to be tested in order to generate deep testing input parameters.

[0217] The weighted scoring subunit is used to input the depth detection input parameters into the analytic hierarchy process for weighted scoring to generate a comprehensive risk score.

[0218] The level determination subunit is used to determine the test depth level and corresponding test duration based on the comprehensive risk score, so as to generate depth test configuration parameters;

[0219] The detection execution subunit is used to perform deep security detection based on the deep testing configuration parameters, combining static data stream tracing, control path exploration and attack scenario simulation, to generate an original vulnerability discovery set;

[0220] The vulnerability classification subunit is used to classify the original vulnerability discovery set, and to expand the evaluation of the business impact dimension and remediation difficulty dimension of the original vulnerability discovery set to generate a second security scan result.

[0221] Furthermore, the splitting unit 202 includes:

[0222] The template library acquisition sub-unit is used to acquire the attack payload template library and business permission configuration data;

[0223] The data capture subunit is used to capture normal traffic data through the short-period window and generate a basic traffic sample set.

[0224] The parameter parsing subunit is used to parse the parameters of the basic traffic sample set and extract the variable parameter nodes;

[0225] The payload injection subunit is used to inject the structured query language injection payload and path traversal payload from the attack payload template library into the mutable parameter node to generate derived attack traffic.

[0226] The feature extraction subunit is used to extract request sequence features from the basic traffic sample set and construct a traffic sequence pattern graph.

[0227] The relationship identification subunit is used to identify the dependency relationship of business operations based on the traffic sequence pattern graph and generate the operation path topology structure.

[0228] The sequence construction subunit is used to construct an unauthorized access test sequence based on the operation path topology and the business permission configuration data.

[0229] The traffic merging subunit is used to merge the derived attack traffic with the unauthorized access test sequence to form an enhanced penetration test case set;

[0230] The update subunit is used to update the enhanced penetration test case set to the penetration test case library, generating an updated test case library.

[0231] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working process of the above-described apparatus and unit can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0232] The present invention also provides a computer-readable storage medium having a computer program stored thereon, which, when executed, can implement the methods provided in the above embodiments. The storage medium may include various media capable of storing program code, such as a USB flash drive, a portable hard drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk.

[0233] The present invention also provides a computer device, which may include a memory and a processor. The memory stores a computer program, and when the processor calls the computer program in the memory, it can implement the methods provided in the above embodiments. Of course, the computer device may also include various network interfaces, power supplies, and other components.

[0234] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For the apparatus disclosed in the embodiments, since it corresponds to the method disclosed in the embodiments, the description is relatively simple; relevant parts can be referred to in the method section. It should be noted that those skilled in the art can make various improvements and modifications to this invention without departing from its principles, and these improvements and modifications also fall within the protection scope of the claims of this invention.

[0235] It should also be noted that, in this specification, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusivity.

[0236] The term "comprises" implies that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprises a..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

Claims

1. A method for implementing secure access control in software development, characterized in that, include: Receive the code to be tested; Functional testing and interface testing are broken down into multiple short-cycle windows, and the code to be tested is tested through multiple short-cycle windows; At the end of each short-cycle window, capture the test traffic and deduplicate the test traffic. The deduplicated test traffic was replayed for attack testing to obtain the test results; Set a first security checkpoint and a second security checkpoint, and set a first preset time and a second preset time for the first security checkpoint and the second security checkpoint respectively; the first preset time is less than the second preset time; wherein, the first security checkpoint is set after the artifact compilation and unit testing in the continuous integration phase, and the second security checkpoint is set before the application version is approved and ready to be deployed to the production environment; At the first security checkpoint, the code to be tested is subjected to access control detection to obtain a first security scan result; when the access control detection time exceeds the first preset time and the access control detection is not completed, at the second security checkpoint, the code to be tested is subjected to access control detection according to the second preset time to obtain a second security scan result; the test result, the first security scan result and the second security scan result are reported.

2. The software development security access control implementation method according to claim 1, characterized in that, The step of breaking down functional testing and interface testing into multiple short-cycle windows and testing the code under test through these windows includes: obtaining all business functions for the functional testing and establishing a business function matrix corresponding to each business function; classifying all business functions based on the business function matrix from two dimensions—business value and risk level—to form a four-quadrant priority model; determining the window execution priority for each business function based on the four-quadrant priority model; using a core-edge splitting strategy based on the window execution priority to decompose each business function into a core path and an edge scenario; constructing a fast feedback window and an extended verification window; assigning the core path to the fast feedback window and the edge scenario to the extended verification window, thus forming multiple short-cycle windows; wherein the business processing time of the fast feedback window is less than the business processing time of the extended verification window.

3. The software development security access control implementation method according to claim 1, characterized in that, The step of breaking down functional testing and interface testing into multiple short-cycle windows and testing the code under test through multiple short-cycle windows further includes: collecting historical data of the interfaces under test, including interface importance level and interface call frequency; establishing a hierarchical model based on the interface importance level and interface call frequency; assigning a test priority weight to each interface based on the hierarchical model; grouping all interfaces under test according to the test priority weight to generate multiple interface test groups; assigning test cases to each interface test group to form a test case set; calculating the short-cycle window duration corresponding to each interface test group based on the number of test cases in each interface test group and a preset time threshold; and generating corresponding short-cycle window parameters for each interface test group based on the short-cycle window duration to obtain multiple short-cycle windows, wherein the window parameters include window start time, window end time, and window sequence.

4. The software development security access control implementation method according to claim 1, characterized in that, The process of capturing test traffic at the end of each short-cycle window includes: collecting code change scope, historical failure rate, business priority, and resource availability as multi-dimensional indicators; calculating the execution order and resource quota for each short-cycle window based on the multi-dimensional indicators, and generating a window execution plan; analyzing the window execution plan using predictive preloading technology to predict the code change scope; preparing the test environment and test data in advance before code push based on the predicted code change scope, and generating a preload ready signal; when the preload ready signal is received, allocating a dedicated resource pool for each short-cycle window according to the resource quota in the window execution plan; and executing tests corresponding to the code change scope within each short-cycle window by calling the corresponding dedicated resource pool according to the execution order, and recording the test traffic generated during the test in real time.

5. The software development security access control implementation method according to claim 1, characterized in that, The step of performing access control detection on the code under test at the first security checkpoint to obtain the first security scan result includes: parsing the code under test using a non-compiled static analysis engine to generate code structure feature data; performing hard-coded credential detection processing on the code structure feature data to generate credential risk index values; performing high-risk function call identification processing on the code structure feature data to generate a function call risk graph; performing basic injection vulnerability scanning processing on the code structure feature data to generate an injection vulnerability candidate set; aggregating the credential risk index values, the function call risk graph, and the injection vulnerability candidate set to construct a preliminary security assessment matrix; and generating the first security scan result based on the preliminary security assessment matrix.

6. The software development security access control implementation method according to claim 1, characterized in that, The step of performing access control detection on the code to be tested at the second security checkpoint according to the second preset time to obtain the second security scan result includes: obtaining code complexity assessment data, historical vulnerability density assessment data, and business criticality assessment data from the code to be tested to generate deep detection input parameters; inputting the deep detection input parameters into the analytic hierarchy process (AHP) for weighted scoring to generate a comprehensive risk score; determining the test depth level and corresponding test duration based on the comprehensive risk score to generate deep test configuration parameters; performing deep security detection combining static data flow tracing, control path exploration, and attack scenario simulation based on the deep test configuration parameters to generate an original vulnerability discovery set; classifying the original vulnerability discovery set and expanding the evaluation of the business impact dimension and remediation difficulty dimension of the original vulnerability discovery set to generate the second security scan result.

7. The software development security access control implementation method according to claim 1, characterized in that, The process of breaking down functional and interface testing into multiple short-cycle windows and testing the code under test through these windows further includes: acquiring an attack payload template library and business permission configuration data; capturing normal traffic data through the short-cycle windows to generate a basic traffic sample set; parsing the parameters of the basic traffic sample set to extract mutable parameter nodes; injecting structured query language injection payloads and path traversal payloads from the attack payload template library into the mutable parameter nodes to generate derived attack traffic; extracting request sequence features from the basic traffic sample set to construct a traffic sequence pattern graph; identifying the dependencies of business operations based on the traffic sequence pattern graph to generate an operation path topology; constructing an unauthorized access test sequence based on the operation path topology and the business permission configuration data; merging the derived attack traffic with the unauthorized access test sequence to form an enhanced penetration test case set; and updating the enhanced penetration test case set to the penetration test case library to generate an updated test case library.

8. A software-developed secure access control implementation device, characterized in that, include: The receiving unit is used to receive the code to be tested. The split unit is used to break down functional tests and interface tests into multiple short-cycle windows, and to test the code to be tested through multiple short-cycle windows; The capture unit is used to capture test traffic at the end of each short-cycle window and to deduplicatize the test traffic. The test unit is used to perform replay attack tests on the deduplicated test traffic and obtain the test results. A setting unit is used to set a first security checkpoint and a second security checkpoint, and to set a first preset time and a second preset time for the first security checkpoint and the second security checkpoint, respectively; the first preset time is less than the second preset time; wherein, the first security checkpoint is set after the artifact compilation and unit testing in the continuous integration phase, and the second security checkpoint is set before the application version is approved and ready to be deployed to the production environment; a first detection unit is used to perform access control detection on the code to be tested at the first security checkpoint to obtain a first security scan result; a second detection unit is used to perform access control detection on the code to be tested at the second security checkpoint according to the second preset time when the access control detection time exceeds the first preset time and the access control detection is not completed, to obtain a second security scan result; a reporting unit is used to report the test result, the first security scan result and the second security scan result.

9. A computer device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the software development security access control method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, causes the processor to perform the software development security access control implementation method as described in any one of claims 1 to 7.

Images