Signature-based security control method for consistency between source code version and product version

Abstract

The present invention discloses a signature-based security management method for consistency between source code version and product version, which relates to the field of data processing technology. The method includes signing the code using a digital signature technology when the source code is submitted to a version library; generating a unique product version number when the source code is compiled into a product, and calculating the hash value of the product; establishing a mapping relationship for each product in a compilation file unique index formal table; digitally signing the generated product to ensure the integrity of the product version and content; through real-time signature verification, the integrity of the product and the authenticity of the source can be ensured, the impact of security incidents can be reduced, and the differences between products generated in different compilation environments can be reduced, which makes the subsequent relationship complicated and difficult to handle; through automated version control and product signature processes, the consistency of the version information of all products and their source codes can be guaranteed.

Description

Technical Field

[0001] The present invention relates to the field of data processing technology, and more specifically, to a signature-based security management method for consistency between source code versions and product versions. Background Art

[0002] It is mainly used to ensure the version consistency of the code building, testing and deployment stages in the automated software development and operation and maintenance process, prevent the injection of malicious code and software supply chain attacks, ensure the security and integrity of software products, and ensure that the deployed software version is consistent with the expected version during system upgrades and maintenance, reduce the operation and maintenance risks caused by version inconsistencies, and ensure the compliance of software version management in industries that need to comply with specific regulations and standards (such as finance, medical care, etc.);

[0003] However, in actual use, as the scale of the project expands, managing a large number of source code and product versions and the mapping relationships between them may become complicated and difficult to handle. Although the data can be recorded and tracked during the management and control process, there are difficulties in managing and analyzing this data, especially when a rapid response to security incidents is required. It is difficult to quickly locate and analyze the problem. Summary of the invention

[0004] To solve the above problems, the present invention provides a signature-based method for securely managing the consistency of source code version and product version.

[0005] The method for securely controlling the consistency of source code version and product version based on signatures is characterized by comprising the following steps:

[0006] Step 1: When the source code is submitted to the version library, the code is signed using digital signature technology;

[0007] Step 2: When the source code is compiled into an artifact, a unique artifact version number is generated and the artifact hash value is calculated;

[0008] Step 3: Create a mapping relationship for each artifact in the compilation file unique index formal table;

[0009] Step 4: Digitally sign the generated artifact to ensure the integrity of the artifact version and content.

[0010] Preferably, the specific method of step one is as follows:

[0011] A pair of public and private keys is generated for each user. The private key is kept by the user himself, and the public key is used publicly.

[0012] After the user completes code writing and testing locally, he uses his private key to generate a digital signature for the code or submission information;

[0013] Attach the generated digital signature as metadata to the source code submission;

[0014] The user submits the digitally signed source code to the version control system;

[0015] After receiving the source code submission, the version control system verifies the digital signature using the user’s public key;

[0016] If the signature verification is successful, it proves that the source code has not been tampered with and confirms the identity of the user.

[0017] Preferably, the specific method of step 2 is as follows:

[0018] After the source code is submitted, the product version number is generated using the automated build tool;

[0019] In the process of compiling source code into artifacts, a hash algorithm is used to calculate the hash value of the artifact;

[0020] Store the metadata of the compiled artifacts in the artifact repository;

[0021] Digitally sign the artifact and its metadata using the compiler's private key;

[0022] The compiled artifacts and their digital signatures are stored in the artifact library.

[0023] Preferably, the specific method of storing the metadata of the compiled artifact in the artifact library also includes:

[0024] Get the hash value of each product;

[0025] Perform hash value difference analysis on each product;

[0026] After the difference is determined, the difference is corrected to obtain a differential file;

[0027] Apply the differential file to one artifact to generate an artifact that is consistent with another artifact;

[0028] Verify that the corrected product is consistent with the target product.

[0029] Preferably, the specific manner of correcting the difference after determining the difference is as follows:

[0030] Differential encoding: Calculates the difference between two artifacts and generates a differential file that can be used to convert one artifact to the other;

[0031] Symmetric Difference: Calculates the symmetric difference between two artifacts and generates a single file containing all the differences.

[0032] Preferably, the specific method of step three is as follows:

[0033] Use graph databases to store and manage the connections between source code and artifacts;

[0034] Integrate version control systems with artifact repositories;

[0035] Analyze the relationship between artifacts and source code, predict possible problems and inconsistencies, and provide early warning.

[0036] Preferably, the specific steps of analyzing the relationship between the artifact and the source code, obtaining possible problems and inconsistencies, and providing early warnings are as follows:

[0037] Data collection, including collecting source code submission records, product build records, version numbers, hash values, and compilation environment information;

[0038] Feature extraction: extracting features from the collected data, specifically commit frequency, code change amount, compilation time, artifact size change, and dependency change;

[0039] Anomaly detection.

[0040] Preferably, the specific method of the abnormality detection is as follows:

[0041] According to the formula , calculate and obtain the abnormal monitoring value Z, where n is the number of features, The i-th feature is the actual observation value, is the historical average of the i-th feature, is the historical standard deviation of the i-th feature;

[0042] A threshold value of an abnormal monitoring value is set in advance. If the abnormal monitoring value Z is greater than the threshold value of the abnormal monitoring value, it is marked as abnormal, and an alarm signal is generated and transmitted to the mobile phone terminal of the staff.

[0043] Preferably, the specific steps of step 4 are as follows:

[0044] Work-in-progress is signed immediately after it is generated and verified before distribution;

[0045] Develop different signing and verification strategies based on the importance and risk level of the artifact;

[0046] Real-time monitoring system to monitor the status of signature verification.

[0047] Preferably, the real-time monitoring system monitors the status of signature verification in the following specific manner:

[0048] Signing process into CI / CD pipeline;

[0049] Record detailed logs of all signing and verification activities;

[0050] Set alert rules to trigger an alert immediately when signature verification fails.

[0051] Beneficial effects: Through real-time signature verification, the integrity of the artifacts and the authenticity of the source can be ensured. When problems are found, measures can be taken immediately to reduce the impact of security incidents. It can also reduce the differences between artifacts generated in different compilation environments, which makes subsequent relationships complicated and difficult to handle.

[0052] Through automated version control and product signing processes, the consistency of version information of all products with their source code is ensured; the implementation of key rotation strategies and real-time monitoring systems reduces the risk of key leakage and ensures rapid response when security incidents occur; detailed logging and real-time monitoring provide complete audit trails, allowing for rapid tracking and location of causes when problems occur; automated processes reduce manual intervention, thereby reducing inconsistencies and security issues caused by operational errors; alarm systems and rapid response mechanisms ensure that immediate action can be taken when signature verification failures or other security incidents are detected. BRIEF DESCRIPTION OF THE DRAWINGS

[0053] Figure 1 It is a flow chart of the method of the present invention. DETAILED DESCRIPTION

[0054] like Figure 1 As shown, the signature-based security control method for consistency between source code version and product version includes the following steps: It should be noted that it is mainly used to ensure version consistency in the code building, testing and deployment stages in the automated software development and operation and maintenance process, prevent malicious code injection and software supply chain attacks, ensure the security and integrity of software products, ensure that the deployed software version is consistent with the expected version during system upgrades and maintenance, reduce operation and maintenance risks caused by version inconsistencies, and ensure compliance of software version management in industries that need to comply with specific regulations and standards (such as finance, medical care, etc.);

[0055] However, in actual use, as the project scale expands, managing a large number of source code and product versions and the mapping relationship between them may become complicated and difficult to handle. Although data can be recorded and tracked during the management and control process, there are difficulties in managing and analyzing this data, especially when it is necessary to respond quickly to security incidents. It is difficult to quickly locate and analyze problems;

[0056] Step 1: When the source code is submitted to the version library, the code is signed using digital signature technology;

[0057] Step 2: When the source code is compiled into an artifact, a unique artifact version number is generated and the artifact hash value is calculated;

[0058] Step 3: Create a mapping relationship for each artifact in the compilation file unique index formal table;

[0059] Step 4: Digitally sign the generated artifact to ensure the integrity of the artifact version and content.

[0060] As an optional embodiment: the specific method of step 1 is as follows:

[0061] A pair of public and private keys is generated for each user. The private key is kept by the user himself, and the public key is used publicly.

[0062] After the user completes code writing and testing locally, he uses his private key to generate a digital signature for the code or submission information;

[0063] Attach the generated digital signature as metadata to the source code submission;

[0064] The user submits the source code with the digital signature to the version control system; it should be noted that the version control system in this embodiment may be Git;

[0065] After receiving the source code submission, the version control system verifies the digital signature using the user’s public key;

[0066] If the signature verification is successful, it proves that the source code has not been tampered with and the user's identity is confirmed. It should be noted that the system records all signature verification results, including success or failure logs, for subsequent auditing and tracking; it should also be noted that digital signatures provide a mechanism to ensure that the source code has not been tampered with during transmission. Through public key verification, the identity of the code submitter can be confirmed to prevent identity forgery. Any unauthorized modification will cause the signature verification to fail, thereby preventing the submission of malicious code. All signature records are transparent and can be checked by team members and auditors. Signature records provide evidence of compliance with specific compliance requirements and simplify the compliance certification process.

[0067] As an optional embodiment: the specific method of step 2 is as follows:

[0068] After the source code is submitted, the product version number is generated by an automated build tool. It should be noted that the automated build tool can be Jenkins or GitLab CI, and the version number can be based on a variety of rules, such as timestamp, build sequence number, or semantic version control rules.

[0069] In the process of compiling source code into products, a hash algorithm is used to calculate the hash value of the product. It should be noted that the hash calculation should cover all the contents of the product to ensure integrity. The hash algorithm can be SHA-256.

[0070] The metadata of the compiled artifacts is stored in the artifact library. It should be noted that the metadata of the artifacts includes version number, hash value, compilation time and compiler;

[0071] Digitally sign the artifact and its metadata using the compiler's private key;

[0072] The compiled artifacts and their digital signatures are stored in the artifact library. It should be noted that the integrity, traceability, and security of the artifacts can be ensured, and the security risks and operation and maintenance challenges caused by artifact problems can be reduced.

[0073] As an optional embodiment: the specific manner of storing the metadata of the compiled artifact in the artifact library also includes: It should be noted that there are differences between artifacts generated in different compilation environments, which may make subsequent relationships complicated and difficult to handle;

[0074] Obtain the hash value of each product; it should be noted that the hash value is a mathematical function that can convert an input of any length (such as file content) into an output of a fixed length;

[0075] Perform a differential analysis of the hash values ​​for each artifact; this can be done by comparing each bit of the two hash values, or using a more advanced differential comparison algorithm such as the longest common subsequence (LCS);

[0076] After the difference is determined, the difference is corrected, so as to obtain a differential file; it should be noted that the difference correction method can be differential encoding and symmetric difference;

[0077] Apply the differential file to one product to generate a product that is consistent with the other product; it should be noted that the function and content of the corrected product are consistent with the original product. It should also be noted that in this embodiment, the specific steps may be: obtaining a differential file of the two products, the differential file including all changes required to generate the other product, applying the differential file to the original product, so that the original product and the corrected product are the same;

[0078] Verify whether the corrected product is consistent with the target product. It should be noted that the specific method can be to recalculate the hash value of the generated product, compare the newly calculated hash value with the hash value of the target product, and if the two hash values ​​are equal, it means that the contents of the two products are consistent.

[0079] As an optional embodiment: the specific manner of correcting the difference after determining the difference is as follows:

[0080] Differential encoding: Calculates the difference between two artifacts and generates a differential file that can be used to convert one artifact to the other;

[0081] Symmetric difference: Calculate the symmetric difference of two products and generate a file containing all differences. It should be noted that in this embodiment, the difference between the two products can be realized by a bitwise XOR operation, which can be used to find the difference between the two products.

[0082] As an optional embodiment: the specific method of step three is as follows:

[0083] Use a graph database to store and manage the relationship between source code and artifacts. It should be noted that the graph database can be Neo4j, which can more intuitively represent and query complex relationship networks.

[0084] It should also be noted that graph databases can represent complex network structures, where nodes represent source code files, artifacts, compilation tasks, etc., and also represent the relationship between managing source code and artifacts;

[0085] In addition, graph databases support real-time data updates and retrieval, ensuring that the relationship mapping between source code and artifacts is up-to-date, facilitating rapid response to changes.

[0086] Integrate the version control system with the artifact library; it should be noted that each commit and build can automatically update the mapping relationship;

[0087] It should also be noted that the specific integration method is that whenever there is a new submission or merge of the source code in the version control system, the product building and update process is triggered according to the above process;

[0088] It should also be noted that the mapping relationship should not only store basic version numbers and hash values, but also detailed information such as compilation parameters, dependencies, test results, etc., so as to more fully understand the context of the artifact;

[0089] Analyze the relationship between artifacts and source code, predict possible problems and inconsistencies, and provide early warnings. It should be noted that this allows team members to more clearly understand the relationship between code and artifacts. It should also be noted that through intelligent analysis, problems can be discovered and located more quickly.

[0090] It should also be noted that in this embodiment, possible problems and inconsistencies include:

[0091] Unusual commit frequency: If commit frequency suddenly increases or decreases, it may indicate unusual development activity, such as overload or lack of activity;

[0092] Abnormal code change volume: Large fluctuations in code change volume may indicate large-scale refactoring or potential code breakage;

[0093] Unusual compile times: A significant increase in compile time may indicate performance issues or compile optimization problems in your code:

[0094] Abnormal changes in artifact size: A sudden increase in the size of an artifact file may mean that unnecessary code or resources are introduced, or it may be an error in the build process;

[0095] As an optional embodiment: the specific steps of analyzing the relationship between the artifact and the source code, obtaining possible problems and inconsistencies, and providing early warnings are as follows:

[0096] Data collection: It should be noted that this includes collecting source code submission records, product build records, version numbers, hash values, compilation environment information, etc. It should also be noted that the above information can be obtained through version control systems and product library management tools;

[0097] Feature extraction: It should be noted that features are extracted from the collected data, specifically submission frequency, code change amount, compilation time, product size change, and dependency change; It should be noted that in this embodiment, the submission frequency is obtained by dividing the number of submissions within a preset time by the total duration of the preset time;

[0098] The code change volume reflects the net change volume of the code in a source code commit, which is obtained by subtracting the number of deleted lines from the number of added lines, where the number of added lines represents the newly added code and the number of deleted lines represents the removed code. Taking the absolute value and summing it up is to ensure that whether the change is added or deleted, it is regarded as equivalent work. This indicator helps to evaluate the work volume of a single commit or a series of commits;

[0099] Compile time Compile time measures the time taken from the start of the compilation process to the completion of the compilation. This metric is crucial for evaluating the efficiency of the build system.

[0100] Artifact size change reflects the size difference between the newly built artifact and the previous version. This metric helps monitor the growth of artifacts.

[0101] Dependency change calculates the difference between the new and old artifact dependencies and the ratio to the total dependencies. This indicator helps to evaluate the stability of dependency management. If the dependency change ratio is too high, it may indicate that the project dependencies change frequently, which may increase the risk of introducing compatibility issues or security vulnerabilities.

[0102] Anomaly detection. To be clear, identifying data points that don’t fit a regular pattern, which could indicate a potential problem or inconsistency;

[0103] As an optional embodiment: the specific method of the abnormality detection is as follows:

[0104] According to the formula , calculate and obtain the abnormal monitoring value Z, where n is the number of features, is the actual observed value of the ith feature, is the historical average of the i-th feature, is the historical standard deviation of the ith feature; it should be noted that in this embodiment, the features are submission frequency, code change amount, compilation time, product size change and dependency change, for example is the actual value of the submission frequency,

[0105] A threshold value of an abnormal monitoring value is set in advance. If the abnormal monitoring value Z is greater than the threshold value of the abnormal monitoring value, it is marked as abnormal, and an alarm signal is generated and transmitted to the mobile phone terminal of the staff.

[0106] As an optional embodiment: the specific steps of step 4 are as follows:

[0107] The work-in-progress is signed immediately after it is generated and verified before it is distributed; it should be noted that the security of the work-in-progress is confirmed before it reaches the user;

[0108] Different signing and verification strategies are developed based on the importance and risk level of the artifact. It should be noted that high-risk artifacts require more stringent signing and verification processes.

[0109] It is also necessary to explain that signing keys should be replaced regularly to reduce the risk of key leakage and ensure the security of the keys;

[0110] Real-time monitoring system to monitor the status of signature verification; it should be noted that once verification failure is found, an alarm is immediately triggered and an investigation is carried out.

[0111] As an optional embodiment: the real-time monitoring system monitors the status of signature verification in the following specific manner:

[0112] The signing process is added to the CI / CD pipeline. It should be noted that the signing process is automatically performed after the work-in-progress is built.

[0113] It is also necessary to explain that a key management system is implemented, including key generation, storage, rotation and access control;

[0114] And before the product is distributed, a signature verification service is implemented to check whether the signature of the product is valid;

[0115] A detailed log of all signing and verification activities, including time, product identification, signature status, etc.

[0116] Set alarm rules to trigger an alarm immediately when signature verification fails. It should be noted that in this embodiment, when the signature verification of the product fails, the system needs to be able to know and take action immediately. This is usually achieved by setting an alarm;

[0117] If the signature verification fails, the system will trigger an alarm;

[0118] The verification failure rate is a statistical indicator that measures the frequency of signature verification failures within a certain period of time;

[0119] The number of failed verifications divided by the total number of verifications gives the verification failure rate;

[0120] This ratio can be used to evaluate the stability and security of the signing process;

[0121] Get the security incident response time. The security incident response time measures the length of time from signature verification failure to alarm triggering. It is an important indicator for measuring system response speed. Specifically, it is the time from alarm triggering minus the time from verification failure.

[0122] Among them, the time when the alarm is triggered is the exact time when the system triggers the alarm;

[0123] Verification failure time: the exact time when the signature verification failure occurred;

[0124] Ideally, this time should be as short as possible to ensure a rapid response to security incidents.

[0125] Through these measures and metrics, organizations can ensure the security of keys, detect and respond to potential security issues in a timely manner, and continuously monitor and improve security processes.

[0126] How it works

[0127] Real-time signature verification can ensure the integrity of artifacts and the authenticity of their sources. When problems are discovered, immediate measures can be taken to reduce the impact of security incidents. It can also reduce the differences between artifacts generated in different compilation environments, which can make subsequent relationships complex and difficult to handle.

[0128] Through automated version control and product signing processes, the consistency of version information of all products with their source code is ensured; the implementation of key rotation strategies and real-time monitoring systems reduces the risk of key leakage and ensures rapid response when security incidents occur; detailed logging and real-time monitoring provide complete audit trails, allowing for rapid tracking and location of causes when problems occur; automated processes reduce manual intervention, thereby reducing inconsistencies and security issues caused by operational errors; alarm systems and rapid response mechanisms ensure that immediate action can be taken when signature verification failures or other security incidents are detected.

[0129] The above are only preferred implementations of the present invention. The protection scope of the present invention is not limited to the above embodiments. All technical solutions under the concept of the present invention belong to the protection scope of the present invention. It should be pointed out that for ordinary technical staff in this technical field, some improvements and modifications without departing from the principle of the present invention should also be regarded as the protection scope of this template.

Claims

1. A signature-based security control method for consistency between source code version and product version, characterized in that: The following steps are involved: Step 1: When the source code is submitted to the version library, the code is signed using digital signature technology; Step 2: When the source code is compiled into an artifact, a unique artifact version number is generated and the artifact hash value is calculated; Step 3: Create a mapping relationship for each artifact in the compilation file unique index formal table; Step 4: Digitally sign the generated artifact to ensure the integrity of the artifact version and content; The specific method of step three is as follows: Use graph databases to store and manage the connections between source code and artifacts; Integrate version control systems with artifact repositories; Analyze the relationship between artifacts and source code, predict possible problems and inconsistencies, and provide early warnings; The specific steps of analyzing the relationship between artifacts and source code, obtaining possible problems and inconsistencies, and providing early warnings are as follows: Data collection, including collecting source code submission records, product build records, version numbers, hash values, and compilation environment information; Feature extraction: extracting features from the collected data, specifically commit frequency, code change amount, compilation time, artifact size change, and dependency change; Anomaly detection; The specific method of the anomaly detection is as follows: According to the formula , calculate and obtain the abnormal monitoring value Z, where n is the number of features, is the actual observed value of the ith feature, is the historical average of the i-th feature, is the historical standard deviation of the i-th feature; A threshold value of an abnormal monitoring value is set in advance. If the abnormal monitoring value Z is greater than the threshold value of the abnormal monitoring value, it is marked as abnormal, and an alarm signal is generated and transmitted to the mobile phone terminal of the staff; The specific method of step one is as follows: A pair of public and private keys is generated for each user. The private key is kept by the user himself, and the public key is used publicly. After the user completes code writing and testing locally, he uses his private key to generate a digital signature for the code or submission information; Attach the generated digital signature as metadata to the source code submission; The user submits the digitally signed source code to the version control system; After receiving the source code submission, the version control system verifies the digital signature using the user’s public key; If the signature verification is successful, it proves that the source code has not been tampered with and confirms the identity of the user.

2. The signature-based source code version and product version consistency security management method according to claim 1 is characterized in that: The specific method of step 2 is as follows: After the source code is submitted, the product version number is generated using the automated build tool; In the process of compiling source code into artifacts, a hash algorithm is used to calculate the hash value of the artifact; Store the metadata of the compiled artifacts in the artifact repository; Digitally sign the artifact and its metadata using the compiler's private key; The compiled artifacts and their digital signatures are stored in the artifact library.

3. The signature-based source code version and product version consistency security management method according to claim 2 is characterized in that: The specific method of storing the metadata of the compiled artifact in the artifact library also includes: Get the hash value of each product; Perform hash value difference analysis on each product; After the difference is determined, the difference is corrected to obtain a differential file; Apply the differential file to one artifact to generate an artifact that is consistent with another artifact; Verify that the corrected product is consistent with the target product.

4. The method for securely controlling the consistency of source code version and product version based on signature according to claim 3 is characterized in that: The specific method of correcting the difference after determining the difference is as follows: Differential encoding: Calculates the difference between two artifacts and generates a differential file that can be used to convert one artifact to the other; Symmetric Difference: Calculates the symmetric difference between two artifacts and generates a single file containing all the differences.

5. The method for securely controlling the consistency of source code version and product version based on signature according to claim 1 is characterized in that: The specific steps of step 4 are as follows: Work-in-progress is signed immediately after it is generated and verified before distribution; Develop different signing and verification strategies based on the importance and risk level of the artifact; Real-time monitoring system to monitor the status of signature verification.

6. The method for securely controlling the consistency of source code version and product version based on signature according to claim 5 is characterized in that: The specific method of monitoring the status of signature verification by the real-time monitoring system is as follows: Signing process into CI / CD pipeline; Record detailed logs of all signing and verification activities; Set alert rules to trigger an alert immediately when signature verification fails.

Images