A method for secure management of software development data

Abstract

The application is suitable for the technical field of data management, and provides a security management method for software development data, which comprises the following steps: obtaining development data; adopting a parser to perform line-by-line analysis according to an annotation mark, obtaining the label authorization range of a current operator in a permission mapping table, and judging whether the current operator is allowed to submit or view this time; the analysis result comprises a field type, a desensitization strategy combination recommendation is performed according to a use scene, a desensitization operation is performed according to the recommendation, an operation result is obtained, and operation result information is written into a version registration file; behavior data is the record data of the operation of each developer, a statistical feature vector is constructed based on a historical behavior sequence, the deviation degree between the current behavior and the historical mean value is calculated, and the standardized deviation value and the baseline are compared; a set of light-weight, dynamic and interpretable data security protection mechanism is constructed, and the safety control capability in the capital development process is significantly improved.

Description

Technical Field

[0001] This invention belongs to the field of data management technology, and in particular relates to a method for secure management of software development data. Background Technology

[0002] Security Challenges. As business complexity increases and development collaboration expands, the risk of data exposure during development also rises. For example, sensitive logic code (such as fund settlement and risk control rules) is easily modified or accessed without authorization. Test data contains a large amount of real user information (such as ID card numbers, bank card numbers, and transaction amounts), which can easily lead to data leaks if effective anonymization is lacking. In addition, development activities themselves lack effective monitoring methods, and it is often difficult to detect and respond to abnormal operations such as account abuse or permission violations in a timely manner.

[0003] In existing technologies, access control is mostly based on repositories, branches, or modules, making it difficult to cover sensitive segments such as function levels and configuration sections. Data anonymization typically uses static templates, which cannot flexibly adjust strategy combinations according to usage scenarios and lacks process traceability. Monitoring of development behavior mainly relies on access logs, lacking modeling of behavioral patterns and deviation judgment, making it difficult to identify abnormal and risky operations in a timely manner. In addition, some current data security solutions rely too heavily on platform-level integration, resulting in complex deployment, high migration costs, and weak applicability.

[0004] Therefore, there is an urgent need for a development data security management method that aims to be more granular, more targeted, and more traceable, capable of accurately identifying and determining permissions for sensitive logic before developers submit it. Summary of the Invention

[0005] The purpose of this invention is to provide a method for secure management of software development data, aiming to solve the problems raised in the third part of the background art.

[0006] This invention is implemented as follows: a method for secure management of software development data, the method comprising: Acquire development data, which includes code, basic information, and inspection logs. The basic information includes time, personnel, and file paths. The parser performs line-by-line analysis based on the annotation tags to obtain the current operator's tag authorization scope in the permission mapping table, and determines whether the current operator is allowed to submit or view this time. The analysis results include field types, recommendations for de-identification strategies based on usage scenarios, execution of de-identification operations based on recommendations, acquisition of operation results, and writing of operation result information into the version registration file; Behavioral data is a record of each developer's actions. Statistical feature vectors are constructed based on historical behavior sequences. The deviation between the current behavior and the historical mean is calculated, and the standardized deviation is compared with the baseline.

[0007] Preferably, the step of using a parser to perform line-by-line analysis based on annotation tags to obtain the current operator's tag authorization range in the permission mapping table, and determining whether the current operator is allowed to submit or view this time, specifically includes: Annotation tags are embedded based on the development data. A parser is used to analyze the file line by line based on the annotation tags to obtain the file structure and extract the location range and category tag of the protected section. Obtain the current operator's tag authorization scope in the permission mapping table, compare it with the developer's permission level, and determine whether the current operator is allowed to submit or view this time; If the permission requirements are not met, including whether the user is allowed to edit, submit, or read the fragment, access to the fragment will be terminated, and the violation attempt information will be recorded.

[0008] Preferably, the annotation markers are used to identify sensitive logic segments.

[0009] Preferably, the analysis results include field types, recommendations for de-identification strategy combinations based on usage scenarios, execution of de-identification operations based on recommendations, acquisition of operation results, and writing of operation result information into the version registration file, specifically including: Obtain the parser analysis results, which include field types such as ID card number, mobile phone number, bank card number, and transaction amount, and obtain the development data usage scenarios; Obtain a combination of desensitization strategies, recommend desensitization strategy combinations based on the use case, and perform desensitization operations according to the recommendations; Obtain the operation result and write the operation result information into the version registration file. The operation result includes the corresponding field, the desensitization method identifier, the processing time, and the verification code before and after desensitization.

[0010] Preferably, the desensitization strategy combination includes structure-preserving masking, full forgery replacement, range perturbation, and generalization processing.

[0011] Preferably, the behavioral data is a record of each developer's operations. The steps of constructing a statistical feature vector based on historical behavioral sequences, calculating the deviation between the current behavior and the historical mean, and comparing the standardized deviation with the baseline specifically include: Acquire behavioral data, which is a record of each developer's actions; Statistical feature vectors are constructed based on historical behavior sequences, historical mean is obtained, and the degree of deviation between the current behavior and the historical mean is calculated to obtain standardized deviation values. The standardized deviation is compared with the baseline. If the standardized deviation exceeds the baseline, a warning mechanism is triggered, the behavior is marked as abnormal, subsequent operation permissions are restricted, and secondary verification is enforced.

[0012] Preferably, the behavioral data includes the access path of the source file, the frequency of code submission, the distribution of access time periods, and the number of times key resources have been modified.

[0013] This invention provides a method for secure management of software development data. It embeds sensitive logic markers into the source code and extracts the location and type of protected segments through line-by-line parsing. This enables structured identification and fine-grained access control of critical code such as financial logic and risk control rules, avoiding the problems of coarse-grained and broad-coverage traditional access settings. Furthermore, by analyzing the types of development data fields and automatically matching de-identification strategies based on usage scenarios, it can intelligently perform operations such as masking, forgery, perturbation, or generalization, ensuring that test data is both usable and compliant with regulatory requirements. Simultaneously, it completely records the de-identification results and verification information, providing high traceability.

[0014] Collect behavioral data from each developer, construct statistical feature vectors, and calculate the degree of deviation between current operations and historical behaviors. By comparing standardized deviation values ​​with security baselines, accurately identify unauthorized, abnormal, or potential misuse behaviors. Once a risk is detected, a warning mechanism is triggered, operations are restricted, and secondary verification is enforced, effectively preventing the abuse of sensitive resources. Attached Figure Description

[0015] Figure 1 A flowchart illustrating a method for secure management of software development data, provided as an embodiment of the present invention.

[0016] Figure 2 This is a flowchart illustrating the steps of using a parser to analyze line by line based on annotation markers, as provided in an embodiment of the present invention, to determine whether the current operator is allowed to submit or view the current content.

[0017] Figure 3 This is a flowchart illustrating the steps of recommending a combination of de-identification strategies based on the usage scenario, performing de-identification operations according to the recommendations, and writing the operation result information into the version registration file, as provided in this embodiment of the invention.

[0018] Figure 4 The behavioral data provided in this embodiment of the invention is a record of each developer's actions. A flowchart outlines the steps for calculating the deviation between the current behavior and the historical mean, comparing the standardized deviation with a baseline. Detailed Implementation

[0019] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the invention.

[0020] It is understood that the terms "first," "second," etc., used in this application may be used herein to describe various elements, but unless otherwise specified, these elements are not limited by these terms. These terms are used only to distinguish one element from another. For example, without departing from the scope of this application, a first script may be referred to as a second script, and similarly, a second script may be referred to as a first script.

[0021] like Figure 1 As shown, this invention provides a method for secure management of software development data, the method comprising: S100, Obtain development data, which includes code, basic information, and inspection logs. The basic information includes time, personnel, and file paths.

[0022] In this step, the development data is obtained. The first thing to extract is the code content, including the source code files edited and submitted by the developer in the local or remote repository, such as .py, .java or .sql formats. The content may involve business logic, interface configuration or key calls, which will be used later to identify sensitive parts and determine permissions.

[0023] Secondly, collect basic information related to each operation, including the time the operation occurred (e.g., 2025-06-04 09:12:30), the specific developer's identity (e.g., employee ID dev-1032 or account ID), and the path of the file being operated on (e.g., / risk-engine / score-calculator.py). This information provides the behavioral context, which is a prerequisite for behavioral modeling and violation tracking.

[0024] Finally, the corresponding inspection logs are recorded synchronously, such as events that fail to identify highly sensitive fields and restricted access sections. These logs typically include the hit rules, the scope of impact, and the processing results, and are stored in a structured manner (such as JSON) for subsequent auditing.

[0025] S200: Based on the annotation tags, the parser performs line-by-line analysis to obtain the current operator's tag authorization scope in the permission mapping table, and determines whether the current operator is allowed to submit or view this time.

[0026] In this step, a parser performs line-by-line analysis based on the annotation markers. To prevent developers from unauthorized viewing or modification of critical code, the system requires special marking of important logic segments during the development phase. These markers are written into the source code as comments to identify which parts are sensitive content, such as core modules like fund processing, transaction limits, and permission configuration. When developers finish writing their code and are ready to submit it, the system automatically starts the parser to scan the submission line by line to check for these markers.

[0027] Once the parser detects the marking information, it identifies the location of the marked code segment and extracts the corresponding "security tag". The system then queries the identity of the current operator and retrieves the scope of authorized tags from the permission mapping table. The permission mapping table is essentially a permission lookup table that indicates which types of content each developer can access.

[0028] Next, the system will compare the developer's authorization tags with the tags actually marked in the code. If a fragment is found to be marked as "funding logic" and the current operator is not authorized to access this type of content, the system will immediately prevent them from submitting or viewing the fragment code. At the same time, the system will record an access denial event, including the operator's identity, time, the file path attempted to be accessed, and the sensitive tag type, ensuring that all violations can be traced and reviewed.

[0029] S300: The analysis results include field types, recommend combinations of desensitization strategies based on the usage scenario, perform desensitization operations according to the recommendations, obtain the operation results, and write the operation result information into the version registration file.

[0030] In this step, the analysis results include field types. To ensure compliant processing of the test data, the data to be processed is first analyzed to identify the type of each field. For example, ID card numbers are identified as identity fields, bank card numbers as financial identifier fields, and transaction amounts as numeric sensitive fields. This step typically involves determining the type based on field names, data formats, and content characteristics.

[0031] After completing field identification, a suitable combination of de-identification strategies is recommended based on the current data usage scenario. In the demonstration scenario, completely fabricated alternative fields are recommended. Transaction amounts can be perturbed to a certain extent during functional testing, while the original structure can be retained during performance verification.

[0032] Once the strategy is determined, the relevant fields are anonymized according to the recommended method, and the results of each operation are obtained, including the field name, the type of strategy used, the processing time, and the operator's identification. After processing, these results are written to the version registration file to ensure that each data processing can be accurately recorded and traced.

[0033] S400, behavioral data is the recorded data of each developer's operations. It constructs a statistical feature vector based on historical behavior sequences, calculates the degree of deviation between the current behavior and the historical mean, and compares the standardized deviation value with the baseline.

[0034] In this step, behavioral data refers to the recorded actions of each developer during their daily development process. This includes information such as the time and frequency of code submissions, the types of files modified, access paths, and time periods of the actions. This data is continuously collected in a structured format, forming complete sequences of actions used to analyze individual behavioral characteristics.

[0035] After acquiring sufficient historical behavior data, statistical analysis methods are used to transform it into a feature vector, such as a set of values ​​comprising dimensions like daily submission count, the proportion of accesses to sensitive files, and nighttime operation frequency. The behavioral feature vector corresponding to the current operation is calculated and compared with the developer's historical mean vector to obtain the difference in each dimension. The differences are standardized to determine the overall degree of deviation. This deviation is then compared with a preset behavioral baseline.

[0036] like Figure 2 As shown in the preferred embodiment of the present invention, the step of performing line-by-line analysis based on the annotation tags using a parser to obtain the tag authorization range of the current operator in the permission mapping table, and determining whether the current operator is allowed to submit or view this time, specifically includes: S201, embed annotation tags according to the development data. The annotation tags are used to identify sensitive logical segments. A parser is used to perform line-by-line analysis based on the annotation tags to obtain the file structure and extract the location range and category label of the protected segment.

[0037] In this step, annotation tags are embedded based on the development data. To identify and control sensitive logic, developers can embed annotation tags in specific locations when writing code to clearly indicate which logic is protected. For example, code segments involving fund calculations, permission determination, or risk control logic can be tagged separately for categorization and identification. The annotation tags use a uniform format for easy subsequent parsing and processing.

[0038] After acquiring the development data marked with comments, the parser analyzes the code file line by line. The parser not only identifies the comments themselves but also combines code indentation, function structure, or syntax block boundaries to determine the specific line number range corresponding to the marked segment. For example, the function logic starting from comment line 20 and ending at line 45 is identified as a protected segment in the "Funding Logic" category. The system also extracts the category tag to which the segment belongs, serving as an important basis for subsequent access control, access judgment, and logging.

[0039] S202: Obtain the current operator's tag authorization scope in the permission mapping table, compare it with the developer's permission level, and determine whether the current operator is allowed to submit or view this time.

[0040] In this step, we obtain the current operator's tag authorization scope in the permission mapping table. To determine whether a developer has permission to access specific sensitive logic, we first need to obtain their authorization information in the permission mapping table. The permission mapping table is a data collection that records the tag permissions that each developer has. For example, a developer may be authorized to access "Interface Configuration" and "General Logic," but may not have access permissions for tags such as "Funds Logic" and "Risk Control Rules."

[0041] After the parser extracts the category tags of the protected segment, the system compares these tags with the authorized tags of the current operator. If the extracted tags (such as financial logic) are not within the developer's permission scope, the system determines that the operator is not authorized to view or submit the corresponding segment and blocks the operation.

[0042] For example, if a developer attempts to submit code that includes a "funds logic" tag, but this tag is not included in their permission mapping, the system will reject the submission and log the event for auditing or subsequent security analysis.

[0043] S203 If the permission requirements are not met, including whether the user is allowed to edit, submit, or read the fragment, then the fragment access is terminated and the violation attempt information is recorded.

[0044] In this step, if the permission requirements are not met, when a developer attempts to access code segments with sensitive tags, the system will determine whether they have the corresponding permissions based on the permission mapping table. Permission requirements include whether the developer is allowed to read (view), edit (modify), or submit (save and push) the code snippet. The system will evaluate each of these operation types to ensure that execution is only permitted within the authorized scope.

[0045] If the system detects that the current operator lacks a certain permission, such as being prohibited from reading code snippets tagged "Funds Logic," but attempts to view that content, the system will immediately terminate the loading or display of the snippet. Simultaneously, a violation attempt event will be recorded, including the developer's identity, the time of the violation, the type of operation attempted (e.g., reading), the target file path, and the tags involved. All violation information will be written to the security audit log for subsequent behavior analysis, accountability, or permission optimization.

[0046] For example, if developer "dev-203" submits code involving a segment labeled "risk control rule" but their permissions do not include this label, the system will interrupt the submission process and return the message: Operation rejected, no permission to submit risk control rule segment.

[0047] like Figure 3 As shown, in a preferred embodiment of the present invention, the steps of analyzing the results including field types, recommending de-identification strategies based on usage scenarios, performing de-identification operations according to the recommendations, obtaining operation results, and writing the operation result information into the version registration file specifically include: S301, Obtain the parser analysis results. The analysis results include field types, such as ID card number, mobile phone number, bank card number, and transaction amount. Obtain the development data usage scenario.

[0048] In this step, the parser analysis results are obtained. To identify and process sensitive fields in the development data, the data content is first parsed in a structured manner. The parser analyzes each data field one by one, extracting the field name, value type, and format characteristics, and identifying the field type to which it belongs. For example, a field named "id_number" with an 18-digit format matches the "ID card number" type; fields such as "mobile" or "phone" with an 11-digit format are identified as "phone number"; 16- or 19-digit fields starting with "62" can be identified as "bank card number"; and fields with keywords such as "amount" or "balance" in their names and floating-point values ​​are identified as "transaction amount".

[0049] After identifying the field type, it is also necessary to obtain the usage scenario of the current data, that is, the specific stage in which the development data will be applied, such as interface integration testing, performance testing, demonstration, or functional verification. The usage scenario can be determined automatically through development configuration parameters, environment identifiers, or task scheduling context, or it can be actively marked by developers when submitting tasks.

[0050] For example, if a piece of data is identified as containing a bank card number field and the usage scenario is "demonstration", the system will subsequently select a stronger de-identification strategy (such as complete forgery and replacement); if the scenario is "interface integration", it may only retain the last four digits of the card number for location purposes.

[0051] S302, obtain the de-identification strategy combination, recommend the de-identification strategy combination according to the use scenario, and execute the de-identification operation according to the recommendation. The de-identification strategy combination includes structure-preserving mask, full forgery replacement, range perturbation and generalization processing.

[0052] In this step, a combination of data masking strategies is obtained. After identifying the field type and use case, the system will recommend a suitable combination of masking strategies based on both. Each strategy combination consists of several specific methods, aiming to minimize the risk of sensitive information leakage while ensuring data availability. Strategy selection considers not only the sensitivity of the field itself but also the requirements for data authenticity and integrity for the current development purpose.

[0053] Common strategies include: structure-preserving masks, used for format-sensitive fields such as mobile phone numbers and bank card numbers, which retain the first and last few digits and replace the rest with symbols (such as "6222 **** **** 1234"), suitable for interface integration testing; Full forgery replacement generates legitimate but fake data (such as random ID numbers or compliant bank card numbers), suitable for demonstration or public display scenarios; Range perturbation allows numerical fields, such as transaction amounts, to fluctuate within a certain percentage range (e.g., ±5%), which is suitable for functional testing. Generalization processing, such as processing "April 15, 1989" as "post-80s" or converting precise amounts into ranges, is suitable for risk assessment or trend analysis scenarios.

[0054] Perform desensitization operations on the fields sequentially according to the recommended combination, and record the results of each process, including the strategy used, field name, processing time, etc., to ensure that the process is traceable.

[0055] S303, Obtain the operation result and write the operation result information into the version registration file. The operation result includes the corresponding field, the desensitization method identifier, the processing time, and the verification code before and after desensitization.

[0056] In this step, the operation results are obtained, and an operation result record is generated for each processed field. This record contains four types of key information: First, the corresponding field name, used to identify the field being processed, such as "mobile-number" or "transaction-amount"; second, the de-identification method identifier, indicating the specific strategy type used, such as "MASK", "FAKE", "NOISE", or "GEN"; third, the processing time, recording the specific timestamp of the operation to ensure that each change has a clear time basis; and fourth, the verification codes before and after de-identification, calculating hash verification codes for the original value and the processed result respectively, used for subsequent verification of data consistency and confirmation of whether it has been tampered with.

[0057] For example, when processing the "id_number" field, a "forgery" strategy was employed. The process was executed at "2025-06-04 15:32:10". The system automatically generated hash checksums for the original and forged values ​​and wrote all the content as a single record to the version registration file. This file is read-only and appends data chronologically, allowing for subsequent auditing and traceability.

[0058] like Figure 4 As shown, in a preferred embodiment of the present invention, the behavioral data is a record of each developer's operations. The steps of constructing a statistical feature vector based on historical behavioral sequences, calculating the deviation between the current behavior and the historical mean, and comparing the standardized deviation with the baseline specifically include: S401, Obtain behavioral data. The behavioral data is a record of the operations of each developer. The behavioral data includes the access path of the source file, the frequency of code submission, the distribution of access time periods, and the number of times key resources are modified.

[0059] In this step, we acquire behavioral data, which refers to the operational records of each developer during the development process, used to characterize their daily behavioral features. This type of data is automatically collected through continuous monitoring of code operation behavior, and mainly includes four aspects.

[0060] First, the source file access path records the specific file locations accessed or modified by the developer, such as " / payment / core / transfer-logic.py", used to identify the modules they focus on and the frequency of accessing sensitive resources. Second, code commit frequency tracks the number of commits made by the developer within a certain time period, such as average daily commits and consecutive active days, used to measure workload and pace. Third, access time period distribution analyzes the specific time periods during which operations occur through timestamps to determine if there are abnormally active periods, such as high-frequency operations late at night. Fourth, the number of times key resources are modified tracks the number of times the developer modifies sensitive tags (such as funding logic, risk control rules, etc.) within a specific time period, used to identify potential unauthorized access risks.

[0061] For example, if a developer frequently accesses multiple sensitive path files within a week and submits a large number of changes outside of working hours, the system will mark their behavior as deviating from the norm and use it as input for subsequent analysis.

[0062] S402: Construct a statistical feature vector based on historical behavior sequences, obtain the historical mean, calculate the degree of deviation between the current behavior and the historical mean, and obtain the standardized deviation value.

[0063] In this step, statistical feature vectors are constructed based on historical behavior sequences. To identify abnormal developer behavior, a statistical model needs to be built based on their long-term behavioral data. First, the historical behavior sequences of each developer are collected, including indicators such as the number of file paths accessed daily, the number of commits, the distribution of operation time, and the number of times sensitive resources were modified, and archived in chronological order. Then, these behavioral features are transformed into statistical feature vectors, that is, multi-dimensional data is uniformly encoded into a calculable numerical form, such as "average number of commits per day = 5", "nighttime operation ratio = 10%", "number of accesses to sensitive periods this week = 8".

[0064] Next, the system calculates the developer's historical mean vector based on behavioral feature vectors over a past period (e.g., the last 30 days), representing their typical behavioral characteristics. Then, it calculates the difference between the behavioral feature corresponding to the current operation and the historical mean to obtain the degree of deviation in each dimension. After standardization processing (e.g., Z-score or normalization), it generates a standardized deviation value with a uniform scale for cross-dimensional comparison.

[0065] For example, a developer usually submits 4 times a day, but today submitted 12 times, which is a significant deviation; at the same time, the number of accesses to sensitive sections is also much higher than the average. Based on this, the system can initially judge that there is abnormal behavior.

[0066] S403. Compare the standardized deviation value with the baseline. If the standardized deviation value is determined to exceed the baseline, a warning mechanism is triggered, the behavior is marked as abnormal, subsequent operation permissions are restricted, and secondary verification is enforced.

[0067] In this step, the standardized deviation value is compared with the baseline. After obtaining the standardized deviation value of the current operation, this value is compared with a preset behavioral baseline threshold. This baseline can be set based on historical statistical models, organizational security policies, or the average upper limit of deviation for the same position, and is used to define the boundary between "normal" and "abnormal" operations. The comparison process covers multiple dimensions, such as submission frequency, access volume to sensitive resources, and operation time distribution, and a judgment is made based on the degree of deviation from these dimensions.

[0068] If current behavior is found to deviate significantly from the baseline in one or more dimensions, such as a developer modifying sensitive sections more than three times their historical average number of times this week, concentrated outside of working hours, a warning mechanism will be immediately triggered. This behavior will be automatically marked as abnormal, and risk control actions will be implemented, including restricting subsequent access to sensitive sections or suspending some of their submission privileges. Simultaneously, the system will initiate a two-factor authentication process, such as CAPTCHA verification, QR code confirmation, or manual approval, to ensure that the action was initiated by the developer themselves.

[0069] For example, if a developer frequently modifies the fund settlement module code late at night, and the amount of work far exceeds their historical average, the system will prevent them from submitting further work and require them to verify their identity via SMS verification code to prevent account misuse.

[0070] In one embodiment, a computer device is provided, the computer device including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor, when executing the computer program, performs the following steps: Acquire development data, which includes code, basic information, and inspection logs. The basic information includes time, personnel, and file paths. The parser performs line-by-line analysis based on the annotation tags to obtain the current operator's tag authorization scope in the permission mapping table, and determines whether the current operator is allowed to submit or view this time. The analysis results include field types, recommendations for de-identification strategies based on usage scenarios, execution of de-identification operations based on recommendations, acquisition of operation results, and writing of operation result information into the version registration file; Behavioral data is a record of each developer's actions. Statistical feature vectors are constructed based on historical behavior sequences. The deviation between the current behavior and the historical mean is calculated, and the standardized deviation is compared with the baseline.

[0071] In one embodiment, a computer-readable storage medium is provided, on which a computer program is stored, which, when executed by a processor, causes the processor to perform the following steps: Acquire development data, which includes code, basic information, and inspection logs. The basic information includes time, personnel, and file paths. The parser performs line-by-line analysis based on the annotation tags to obtain the current operator's tag authorization scope in the permission mapping table, and determines whether the current operator is allowed to submit or view this time. The analysis results include field types, recommendations for de-identification strategies based on usage scenarios, execution of de-identification operations based on recommendations, acquisition of operation results, and writing of operation result information into the version registration file; Behavioral data is a record of each developer's actions. Statistical feature vectors are constructed based on historical behavior sequences. The deviation between the current behavior and the historical mean is calculated, and the standardized deviation is compared with the baseline.

[0072] It should be understood that although the steps in the flowcharts of the various embodiments of the present invention are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the various embodiments may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these sub-steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least a portion of the sub-steps or stages of other steps. Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), Rambus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.

[0073] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0074] The embodiments described above are merely illustrative of several implementations of the present invention, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of the present invention. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of the present invention, and these modifications and improvements all fall within the scope of protection of the present invention. Therefore, the scope of protection of this patent should be determined by the appended claims.

[0075] The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A method for secure management of software development data, characterized in that, The method includes: Acquire development data, which includes code, basic information, and inspection logs. The basic information includes time, personnel, and file paths. The parser performs line-by-line analysis based on the annotation tags to obtain the current operator's tag authorization scope in the permission mapping table, and determines whether the current operator is allowed to submit or view this time. Specifically, this includes: embedding annotation tags based on development data, using a parser to perform line-by-line analysis based on the annotation tags, obtaining the file structure, and extracting the location range and category label of the protected section; Obtain the current operator's tag authorization scope in the permission mapping table, compare it with the developer's permission level, and determine whether the current operator is allowed to submit or view this time; If the permission requirements are not met, including whether the user is allowed to edit, submit, or read the fragment, access to the fragment will be terminated, and the violation attempt information will be recorded. The analysis results include field types, recommendations for de-identification strategies based on usage scenarios, execution of de-identification operations based on recommendations, acquisition of operation results, and writing of operation result information into the version registration file; Behavioral data is a record of each developer's actions. Statistical feature vectors are constructed based on historical behavior sequences. The deviation between the current behavior and the historical mean is calculated, and the standardized deviation is compared with the baseline.

2. The method for secure management of software development data according to claim 1, characterized in that, The annotation markers are used to identify sensitive logical segments.

3. The method for secure management of software development data according to claim 1, characterized in that, The analysis results include field types, recommendations for de-identification strategies based on usage scenarios, execution of de-identification operations according to the recommendations, acquisition of operation results, and writing of the operation result information into the version registration file. Specifically, this includes: Obtain the parser analysis results, which include field types such as ID card number, mobile phone number, bank card number, and transaction amount, and obtain the development data usage scenarios; Obtain a combination of desensitization strategies, recommend desensitization strategy combinations based on the use case, and perform desensitization operations according to the recommendations; Obtain the operation result and write the operation result information into the version registration file. The operation result includes the corresponding field, the desensitization method identifier, the processing time, and the verification code before and after desensitization.

4. The method for secure management of software development data according to claim 3, characterized in that, The de-identification strategy combination includes structure-preserving masking, full forgery replacement, range perturbation, and generalization processing.

5. A method for secure management of software development data according to claim 4, characterized in that, The behavioral data refers to the recorded data of each developer's operations. A statistical feature vector is constructed based on historical behavioral sequences. The deviation between the current behavior and the historical mean is calculated, and the standardized deviation is compared with the baseline. Specifically, this includes the following steps: Acquire behavioral data, which is a record of each developer's actions; Statistical feature vectors are constructed based on historical behavior sequences, historical mean is obtained, and the degree of deviation between the current behavior and the historical mean is calculated to obtain standardized deviation values. The standardized deviation is compared with the baseline. If the standardized deviation exceeds the baseline, a warning mechanism is triggered, the behavior is marked as abnormal, subsequent operation permissions are restricted, and secondary verification is enforced.

6. A method for secure management of software development data according to claim 5, characterized in that, The behavioral data includes the access path of the source file, the frequency of code submissions, the distribution of access time periods, and the number of times key resources have been modified.

Images