Cloud software version integrity verification and secure storage method

Abstract

The invention relates to a cloud software version integrity verification and secure storage method, which comprises the following steps of: when a new version is uploaded, acquiring structure change data of the new version and at least one historical version by a system, analyzing an evolution path through a variation sequence behavior, and if logic discontinuous rewriting or dependency missing is found, marking as potential integrity abnormity; performing structure division on the abnormal version, taking an active boundary of a historical version module as a credible evolution boundary, triggering fault identification when cross-boundary migration or abnormal calling is detected, and outputting a boundary crossing mark; constructing a behavior expectation window based on a historical change baseline, and performing interval matching on the current change; the version is divided into different credibility partitions according to an analysis result: credible segments are stored in a common encryption area, uncredible segments are stored in an isolation encryption storage area, and a content mapping table is established to realize dynamic access control; a non-traceable sealing node is generated for a non-trusted version, a subsequent version is forbidden to inherit logic, and it is ensured that cloud version evolution is safe and controllable.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of cloud software version, and particularly relates to a cloud software version integrity verification and secure storage method. BACKGROUND

[0002] At present, in the prior art, such as CN110069415A, a software integrity verification and software testing method for a software testing process can meet the static integrity verification requirement of the cloud software version in the testing link to a certain extent, but the scheme has many technical bottlenecks and application limitations. From the overall technical structure, the scheme mainly depends on a single encryption algorithm to generate a ciphertext of a version file, and compares the ciphertext with a pre-stored ciphertext to determine whether the version is complete. The essence is a hash comparison type static detection, which cannot identify potential changes in the structure, behavior path and dependency relationship dimensions of the code, which means that once an attacker makes a sophisticated local modification based on maintaining the overall code size unchanged and reusing a large amount of original code, such as control flow redirection, parameter type drift and call level reversal, the encryption comparison method cannot effectively identify the integrity anomaly in the behavior logic level, which is easy to cause misjudgment in the testing link, thereby exposing security risks after publishing in the cloud.

[0003] In terms of version evolution tracking and behavior expectation modeling, there is no mechanism to compare multiple historical version evolution paths, only binary verification is performed on a certain complete version and a current version, and the structural evolution law and dependency migration trend between versions are ignored. With the expansion of the project size and the frequent evolution of the version, the structural boundary is no longer static and unchanged. If the active area of the module cannot be dynamically extracted, the change frequency cannot be counted, and the behavior evolution model cannot be constructed, the system will lack global cognition of the version evolution trend, and it is easy to miss the unexpected behavior of structural abnormal transition or cross-boundary migration, especially in agile development or micro-service architecture, multiple teams submit in parallel, and cross-module collaboration is more likely to cause fault-type defects.

[0004] In terms of credibility evaluation and access control, no strategy for trusted partitioning of software content is proposed, and there is a lack of measurement and management means for code trusted sources, change complexity and behavior risk level dimensions. It is impossible to distinguish between small-range optimization code submitted by core developers and structural-level refactoring submitted by low-privilege accounts, and it is also impossible to set up independent isolation storage and key mechanisms for high-risk sections. Such a one-size-fits-all approach is easy to cause a full release, and once part of it is tampered with, the whole is damaged.

[0005] Regarding access control and dynamic key management, the scheme fails to consider the visitor's identity background, operational context, and dynamic device fingerprint attributes, relying solely on verification as the criterion for operational capability, lacking a dynamic authorization mechanism. In practical applications, users may come from different organizations, possess different operational permissions, and have varying device environments, temporal behaviors, and access frequencies. Without a dynamic context-aware mechanism and a least-privilege access strategy, it is highly susceptible to overly broad permissions or credential abuse. Furthermore, in terms of key management, the scheme lacks a key rotation or hot / cold period mechanism. For high-frequency access scenarios or multi-user concurrent environments, there may be risks of key reuse and over-reliance on single-point keys for decryption, which deviates from the dynamic defense concept of modern cloud security. Summary of the Invention

[0006] The purpose of this invention is to provide a method for cloud-based software version integrity verification and secure storage, thereby addressing some of the drawbacks and shortcomings pointed out in the background art.

[0007] The technical solution adopted by the present invention to solve the above-mentioned technical problems is as follows: a cloud-based software version integrity verification and secure storage method, comprising: when a new version of software is uploaded to the cloud, the system obtains the structural change data of the current version and at least one historical version, analyzes the evolution path through a mutation sequence behavior judgment mechanism, and if there is a rewriting of discontinuous structural logic or missing dependency relationship, it is marked as a potential integrity anomaly. The marked version is divided into structural regions. The active boundary of the module in the historical version is used as the trusted evolution boundary. When a structural migration or abnormal call that crosses the boundary is detected, the fault identification process is triggered and an out-of-bounds flag is output. The behavior expectation window is constructed based on the historical change baseline. The change behavior of the current version is matched in intervals. If it exceeds the range and is concentrated in the abnormal area, it is marked as unexpected behavior and the release is suspended. Based on the integrity analysis results, the version content is split into multiple trust partitions. Trusted segments are stored in the ordinary encrypted area, and untrusted segments are stored in the isolated encrypted storage area. A content mapping table is established to implement dynamic access control. For versions marked as untrusted, an unretrospective archive node is generated, and subsequent versions are prohibited from inheriting its logic.

[0008] Furthermore, the mutation sequence behavior judgment mechanism includes identifying whether the newly added code block bypasses the interface module in the historical call chain to determine that it is a rewriting behavior with discontinuous structural logic; wherein the rewriting behavior with discontinuous structural logic includes function entry change, interface parameter heterogeneity, or control flow redirection; the missing dependency relationship is judged by detecting the module call path or reference chain breakpoint that is interrupted in the current version.

[0009] Furthermore, the active boundary of the module is generated based on the frequency of changes in the past N versions, where N is a positive integer ranging from 3 to 50, and can be dynamically adjusted according to project characteristics and version change frequency; the statistical period is a configurable time window; and the fault identification process further verifies whether there is cross-layer dependency reversal behavior when it detects cross-boundary references of modules.

[0010] Furthermore, the cross-layer dependency reversal behavior is that the lower-level module calls the higher-level strategy module, violating the original dependency hierarchy rules; wherein the behavior expectation window is constructed based on the historical modification density of each module and excludes interfering commit data during abnormal periods.

[0011] Furthermore, when receiving software version submissions, the system constructs a risk scoring function for trustworthiness partitioning based on the submitter's information, the characteristics of the changed content, and historical behavior. The scoring function is as follows:

[0012] in: This represents the overall risk value of the current code change; The evolution of submission behavior over time; The submitter's authentication strength function reflects the user's... Confidence level of authentication methods at any given moment; This is an identity trust mapping function used to convert multi-factor authentication and device consistency information into risk contribution values; This indicates the size and scope of the code changes; Indicates weights with structural perturbation The change affects the perturbation function, which is used to calculate the degree of dynamic interference of the code on the system's dependent structures; This indicates the submitter's historical behavior scoring trajectory; This is a behavioral compliance average function, reflecting the average trustworthy behavior over a recent period. Behavioral change rate is used to capture behavioral mutations or deteriorating trends; The risk weighting factor set for the system satisfies It can be configured adaptively according to the actual business scenario.

[0013] The risk value Used to determine the credibility partition level to which the version content should be assigned. Exceeding the high confidence threshold If the version change is not found, it is marked as a low-trust segment and stored in an isolated and sealed storage area; the system further calculates the access trust product value based on the visitor's authentication confidence level and the matching degree of the operation context. ,when When the access threshold is preset, access is only granted to the minimum content range required for the current target operation, and a key rotation mechanism bound to that content is initiated.

[0014] Furthermore, by calculating the function complexity and call fan-out ratio of the scope of influence of the code, the disturbance coefficient of the change on the overall stability of the system is determined, and the credibility partitioning result is corrected accordingly; when the disturbance coefficient exceeds a preset threshold, the system triggers risk amplification calculation and classifies the changed area into a lower credibility partition; the calculation of the call depth is to assign a decay coefficient to each layer of call nodes, and finally generate a hierarchical sensitivity index for credibility calculation.

[0015] Furthermore, the dynamic key rotation mechanism determines the rotation trigger point by calculating the ratio of the access request frequency function to the average key usage time; wherein when the access frequency surges or the key duplication rate exceeds a set ratio, the system generates a new key and puts the old key into a cooling-off period to prevent concurrent decryption.

[0016] Furthermore, the access permission allocation for the visitor is based on the product of the identity authentication confidence value and the current operation context matching value. When the product is lower than a threshold, the granularity of accessed content is restricted. The operation context matching degree is calculated by comparing the consistency of the access device fingerprint, time features and geographical coordinates.

[0017] Furthermore, the identity authentication confidence value is calculated by weighting the identity authentication method level, the success rate of authentication history, and the consistency score of the authentication device; wherein the identity authentication method level is weighted according to the following priority order: multi-factor biometrics > dynamic token verification > static password matching.

[0018] Furthermore, the access device fingerprint includes browser version number, operating system type, device hardware characteristics, and TLS fingerprint. The device fingerprint is compared with historical access records to calculate a similarity score. The time feature includes the degree of consistency between the access time and the historical active time window. A Gaussian distribution is used to fit the user's active time period to generate a confidence interval. The geographical coordinate consistency is obtained by calculating the geographical distance between the current IP address location result and the user's commonly used login location and standardizing it to obtain a matching degree value.

[0019] The beneficial effects of this invention are: it enables accurate identification of structural logic anomalies and missing dependency chains during software version evolution; by introducing a mutation sequence behavior judgment mechanism and module activity boundary identification technology, it improves the ability to identify nonlinear rewriting behavior, cross-layer calls, and abnormal changes, effectively avoiding version integrity failures caused by internal tampering, external injection, or unauthorized refactoring. Compared to traditional solutions relying on single-point hash verification, it can identify suspicious version behavior in a structure-aware manner and proactively block the automatic deployment process when a gap or expected deviation is detected, enhancing security control capabilities during the continuous delivery of cloud-based software.

[0020] By constructing a trust-based partitioning mechanism grounded in source trust level, scope of influence, and call depth, fine-grained security storage control at the content level is achieved. Simultaneously, dynamic key rotation and context-aware permission allocation methods are introduced, granting only the minimum necessary access scope to requests with high identity trust and reasonable access behavior, effectively controlling the leakage channels of high-risk content. Through consistency comparison of access device fingerprints, time characteristics, and geographical location, the system can dynamically adjust access authorization levels, enabling access control policies to be adaptive and behavior-aware, significantly improving the confidentiality, controllability, and trusted access capabilities of version data in the cloud environment. Attached Figure Description

[0021] Figure 1 This is a flowchart illustrating the cloud-based software version integrity verification and secure storage process of this invention.

[0022] Figure 2 This is a flowchart of the cloud software version integrity verification process of the present invention.

[0023] Figure 3 This is a diagram showing the relationship between the risk assessment and dynamic access control functions of this invention.

[0024] Figure 4 This is a flowchart of cloud software version structure risk detection in Embodiment 1 of the present invention.

[0025] Figure 5 This is a diagram showing the partition relationship between software version risk assessment and dynamic permission control in Embodiment 2 of the present invention. Detailed Implementation

[0026] The specific embodiments of the present invention will now be described in detail with reference to the accompanying drawings.

[0027] Combined with appendix Figure 1This invention discloses a cloud-based software version integrity verification and secure storage method. Its core objective is to identify potential integrity anomalies by analyzing structural changes in software versions, thereby ensuring that version data stored in the cloud is not tampered with or damaged during uploading, storage, and access. In implementation, when a new software version is uploaded to the cloud, the system obtains structural change data between the current version and at least one historical version. By comparing with historical versions, the system can identify newly added code segments, modified modules, or deleted functions. After obtaining this change data, the system analyzes the changes through a mutation sequence behavior judgment mechanism, aiming to determine whether there are any anomalies in the evolution path of the new version.

[0028] The mutation sequence behavior judgment mechanism is based on the change trajectory of software versions over time. By comparing the differences between the current version and historical versions, it determines whether there are rewrite behaviors with discontinuous structural logic or missing dependencies. If an illogical rewrite is detected in the code structure of the current version, or if a dependent module, interface, or service is missing or invalid in the current version, the system will mark the version as a potential integrity anomaly and promptly notify the relevant development or operations personnel.

[0029] When the system detects a potential integrity anomaly in a software version, it performs structural region partitioning for that version. This partitioning is based on the active boundaries of various modules in historical versions as trusted evolution boundaries. By comparing the structural differences between the current version and historical versions, the system identifies whether there are structural migrations or abnormal call behaviors in the current version that cross these historical boundaries. If the changes in the current version involve modifications beyond the trusted evolution boundaries, or if abnormal module calls occur, the system triggers a fault detection process, further outputting an out-of-bounds flag to warn system administrators or developers.

[0030] During fault identification, the system constructs a behavior expectation window based on historical change baselines. This window establishes a normal range of change behavior through statistical analysis of historical version change trajectories, defining version behaviors within this range as expected. When the system detects that the current version's change behavior exceeds this expectation range, particularly if it deviates from the expected range, it marks the version as exhibiting unexpected behavior and immediately suspends its release. By suspending releases, the system prevents unverified versions from entering the production environment, avoiding potential security risks or functional failures.

[0031] Based on the version's trustworthiness assessment results, the system stores the trusted portions of the version in a regular encrypted area, while the untrusted portions are stored in an isolated encrypted storage area. This separate storage of trusted and untrusted segments helps improve system security, ensuring that trusted content can be accessed and used normally, while untrusted content is effectively isolated, preventing potential security risks or adverse effects from spreading to the normal parts of the system.

[0032] The system partitions content based on its perceived trustworthiness and establishes a content mapping table. This table records the specific location of each partition and associated access control rules. Through a dynamic access control mechanism, it ensures that only users and system processes meeting specific security conditions can access the corresponding version content. For versions marked as untrusted, the system generates irreversible archive nodes. Archive nodes are a special data structure that ensures that once a version is marked as untrusted, its content cannot be referenced or inherited by subsequent versions.

[0033] Combined with appendix Figure 2 When the system receives a new version, it identifies the newly added code blocks and analyzes whether these code blocks bypass interface modules in the historical call chain. If the newly added code blocks are not integrated according to the original call chain rules, or skip key modules or interfaces defined in the historical version in the call path, the system will determine that the code is a rewrite behavior with discontinuous structural logic.

[0034] Function entry point change refers to modifications to the function's entry address, call order, or parameter passing method, causing the original call chain to become unusable. Interface parameter heterogeneity refers to changes in the type, number, or order of interface parameters, affecting data interaction between the interface and the caller. Control flow redirection manifests as changes in the original control flow jump logic, leading to unexpected system behavior.

[0035] The system analyzes the module call paths and reference chains of the current version to detect any breaks in module call paths or dependencies. If certain modules cannot be accessed through their original call paths in the current version, or if there are breakpoints in the reference chains due to missing modules or inaccessible interfaces, the system will determine that dependencies are missing and mark the version as having potential integrity anomalies. These mechanisms effectively ensure the structural stability and functional consistency of software versions.

[0036] The module activity boundaries are generated based on the frequency of changes over the past N versions, where N is a positive integer ranging from 3 to 50. This value can be dynamically adjusted according to the project's characteristics and version change frequency. The system analyzes the update frequency of each module across different versions based on historical change records to determine which modules are active and delineate their activity boundaries accordingly. These activity boundaries represent areas where modules change frequently across different versions. The system uses these areas to determine which parts of the code have changed significantly and which have remained stable. The system generates these activity boundaries based on these statistical results and uses them as a basis for integrity analysis during subsequent version updates.

[0037] The time window used in this statistical process is configurable, and users can adjust its size according to their needs. By adjusting the time window size, users can control the scope of analysis for historical versions. If the time window is set to be long, the system will statistically analyze changes over a longer period, thereby identifying modules that have been active for a long time; if the time window is set to be short, the system will mainly focus on changes in recent versions.

[0038] During the module active boundary segmentation process, the system also performs a fault detection process. When the system detects that a module in the current version references another module across the active boundary, it further verifies whether there is cross-layer dependency inversion behavior. Cross-layer dependency inversion behavior refers to a situation where a lower-level module calls a higher-level module. This situation usually violates the module's dependency rules, causing abnormalities in the normal operation of the software.

[0039] The system constructs a behavior expectation window based on the historical modification density of each module. This window is set by statistically analyzing the module's modification frequency across multiple versions. Typically, during stable periods, module modification frequency is low, while frequent modifications during version updates can trigger changes in expected behavior. The system analyzes the module's modification density over a period to determine which behaviors are normal and which deviate from historical patterns. When a module's behavior exceeds the expectation window, the system marks it as abnormal and triggers further checks.

[0040] When constructing the expected behavior window, the system excludes disruptive commit data within abnormal periods. Disruptive commit data refers to abnormal modifications caused by external factors or errors, which do not represent the true evolution trend of the module. By excluding this disruptive data, the system can ensure the accuracy of the expected behavior window, making the identification of cross-layer dependency reversal behavior more reliable.

[0041] Combined with appendix Figure 3When the system receives a software version submission, it constructs a risk scoring function based on the submitter's information, the characteristics of the changes, and historical behavior to classify the version into trustworthy categories. This scoring function considers multiple factors, including the strength of the submitter's authentication, the scope of the code changes' impact, and the submitter's historical behavior score. By weighting and synthesizing these factors, the system can assess the risk of the current version and thus determine its trustworthiness.

[0042] The specific form of the scoring function is:

[0043] in, This represents the overall risk value of the current code change. It is the evolution of submission behavior over time. (Function) This function represents the strength of the submitter's authentication, reflecting the time... The credibility of the authentication methods used by the submitter at any given time. It is an identity trust mapping function that transforms multi-factor authentication and device consistency information into risk contribution values. This indicates the size of the code changes and their scope of impact. It has structural perturbation weights The change affects the perturbation function, which is used to calculate the degree of dynamic disturbance that code causes to system dependencies. This indicates the submitter's historical behavior scoring trajectory. It is a behavioral compliance average function, reflecting the average credibility of the submitter's behavior over a recent period. This represents the rate of behavioral change, used to capture sudden changes or deteriorating trends in behavior. Weighting factor. Controlling the influence of the above three factors and satisfying It can be configured adaptively according to business scenarios.

[0044] Rating value This will be used to determine the credibility partition level to which the version content should be assigned. Exceeding the high confidence threshold When this happens, the system marks the version as a low-trust segment and stores it in an isolated, sealed storage area to prevent misuse or accidental release. The system also calculates the access trust product based on the visitor's authentication confidence level and the matching degree of the operation context. .when Less than the preset access threshold At this time, the system only authorizes visitors to access the minimum content required to complete the target operation and initiates a key rotation mechanism to enhance access control security. Through this mechanism, access to relevant content and operations is only granted when the visitor's identity and behavior meet the trust standards.

[0045] The system calculates the impact range of a code change and uses function complexity and call fan-out ratio to assess the disturbance coefficient of that change on the overall system stability. Function complexity represents the computational complexity of the changed code, while the call fan-out ratio describes the degree of impact of the change on other modules in the system. Through these calculations, the system can derive a disturbance coefficient that reflects the risk and instability caused by the code change. If the calculated disturbance coefficient exceeds a preset threshold, the system triggers a risk amplification calculation and, based on the calculation result, classifies the changed area into a lower confidence partition.

[0046] The system further assesses the impact of changes by calculating the call depth of the code. Call depth refers to the level of code calls; deeper levels generally mean a greater impact on other modules. The system assigns a decay coefficient to each call node, which decreases according to the call level. In this way, the system can generate a level sensitivity index, reflecting the degree of impact of code changes at different levels. The level sensitivity index will be used as part of the credibility calculation, helping the system more accurately determine which module changes have a greater impact on system stability, and thus make corresponding adjustments in the credibility partition.

[0047] The system monitors the frequency of access requests and records the occurrence frequency of each access operation. The system also calculates the average usage time of each key, that is, the average time a key is used during its operation. By calculating the ratio of access request frequency to average key usage time, the system can determine a dynamic trigger point to decide when to rotate keys.

[0048] If access frequency suddenly increases or the key is used frequently, the system will generate a new key and put the currently used old key into a cooling-off period, temporarily suspending its use. The purpose of the cooling-off period is to prevent multiple concurrent requests from using the old key for decryption, thereby ensuring data security and avoiding the risk of key abuse due to frequent access.

[0049] Visitor access permissions are dynamically adjusted based on the product of the authentication confidence score and the current operation context matching score. Once a visitor's authentication is successful, the system calculates a confidence score reflecting the reliability of the visitor's identity. The system also calculates a matching score based on the current operation's context information, obtained by comparing the access device fingerprint, access time characteristics, and geographic coordinate consistency. The access device fingerprint includes the device's hardware characteristics, browser information, and operating system type. The time characteristics include the degree of matching between the specific time of access and the user's historical active time periods. Geographic coordinate consistency is calculated by comparing the geographic location of the current IP address with the geographic distance to the user's frequently used login locations.

[0050] The system multiplies the identity authentication confidence value with the operation context matching value to obtain a comprehensive trust product value. When this product value is lower than a preset threshold, the system restricts the visitor's permissions, allowing them to access only the minimum content range required to complete the target operation. This dynamic permission allocation mechanism ensures that, in cases of low identity trust or abnormal operation context, visitors can only access content strictly related to their operational needs, thereby enhancing system security and preventing over-authorization and potential security risks.

[0051] The confidence score for identity authentication is calculated based on a weighted combination of multiple factors. The system assesses the reliability of visitor authentication based on the level of the authentication method. The authentication methods are assigned weights in order of priority, with multi-factor biometrics receiving the highest weight, followed by dynamic token verification, and finally static password matching. Multi-factor biometrics, by combining fingerprint and facial recognition authentication methods, provides the strongest authentication guarantee and is therefore assigned the highest confidence weight. Dynamic token verification confirms identity based on a temporarily generated token; its reliability is slightly lower than multi-factor biometrics, hence it has the second highest weight. Static password matching is the most traditional identity verification method, but it is easily cracked and therefore assigned the lowest confidence weight.

[0052] When calculating the authentication confidence score, the system weights each authentication method according to the aforementioned weights and combines this with the visitor's historical success rate and the consistency score of the authentication device for a comprehensive evaluation. The historical success rate reflects the ratio of the number of successful authentications in the past to the total number of authentications; a higher ratio indicates a more reliable identity. The consistency score of the authentication device reflects the stability and reliability of the device used by the visitor; if the visitor uses the same device multiple times for authentication, the score is higher, further increasing the credibility of the authentication. The system combines these factors through weighted calculations to form an authentication confidence score, which serves as the basis for subsequent permission allocation and access control.

[0053] The system assesses visitor credibility by accessing device fingerprints. Device fingerprints include multiple dimensions such as browser version number, operating system type, device hardware characteristics, and TLS fingerprints. The browser version number confirms the stability and consistency of the browser used by the visitor; the operating system type identifies the operating system version used by the visitor; device hardware characteristics include the device's hardware ID, model number, and other information related to device uniqueness; and the TLS fingerprint verifies the device's encryption features in the Transport Layer Security (TLS) protocol. The system combines these device characteristics into a fingerprint and compares it with historical access records to calculate a similarity score. The similarity score reflects the consistency between the current accessing device and the user's past devices; a higher score indicates a greater consistency between the current and past devices, and a correspondingly higher level of visitor credibility.

[0054] The system analyzes visitors' historical active time periods and fits these periods to a Gaussian distribution model. Based on this model, the system generates a confidence interval, within which access times are considered normal active periods for the user. If the current access time is outside the confidence interval, the system will conduct a higher level of risk assessment, indicating that the access poses an abnormal risk.

[0055] Geographic coordinate consistency is also a crucial factor in determining access trustworthiness. The system assesses geographic consistency by calculating the geographic distance between the current IP address and the user's frequently logged-in locations. When a visitor attempts to access the site from a location far from their usual login location, the system calculates and standardizes that geographic distance to arrive at a match score. A lower match score indicates a significant difference between the accessed geographic location and the user's historical login locations, thus increasing the risk of access failure. Example 1:

[0056] Combined with appendix Figure 4 A cloud-based software management platform manages the uploading, verification, and storage of multiple software versions. The platform's development team is currently uploading a new version. After the software version is submitted, the system uses a mutation sequence behavior judgment mechanism to analyze whether there are potential structural logic discontinuities in the code changes within the new version. This version submission introduces the following two key changes: **New Code Block:** The developer added a data processing function, but this function does not follow the original call chain of interface modules; instead, it directly calls non-public functions from other modules. **Interface Parameter Heterogeneity:** In the new code, the parameter types of some interfaces have changed; interfaces that previously used string input have now changed to accept integers.

[0057] The system identified the newly added code block and found that the function did not follow the original interface call chain and directly called private functions of other modules. To verify whether there was any structural logic discontinuity in the rewriting behavior, the system further checked the changes in interface parameters and found that the parameter types of the original interface had been heterogeneous. The system regarded this as a potential structural rewriting problem.

[0058] In this version, the system continues to check dependencies. In the new version, some external service interfaces called by certain modules are no longer working, manifesting in the following ways: The third-party API interfaces that the original modules depended on were not updated in the new version, so the call paths became invalid; the reference chains of some modules have been broken, and the external libraries that were originally depended on have not been updated, so the references cannot find the corresponding versions.

[0059] By scanning the version change log, the system detected the aforementioned invalid module call paths and broken reference chains. The system identified missing dependencies in the current version, determining that the version's integrity was compromised. The system then marks this version as potentially integrity-agnostic. As version changes continue, the system begins generating module activity boundaries based on the frequency of changes over the past N versions. For example, if a module has undergone frequent modifications in the past 5 version commits, while other modules have remained largely unchanged, the system generates the module's activity boundaries based on this historical data and assesses its change frequency.

[0060] With N set to 5 versions, the system identifies active modules by analyzing the change frequency of each module, paying particular attention to the number of modifications made to a specific module. The system found that this module had been modified 4 times in the past 5 versions, while other modules had lower modification frequencies. Based on this data, the system determined this module to be an active module, and its boundaries required special attention.

[0061] The system detected through a fault identification process that this module in the new version crossed the original active boundary, indicating an abnormal cross-boundary reference. Further verification revealed that the module was calling functions that originally belonged to higher-level modules, which should not be directly called by lower-level modules. This cross-layer dependency reversal violated the module dependency hierarchy rules, prompting the system to immediately issue a warning and mark the version as a potential risk.

[0062] The system generates active boundaries and dependencies of modules based on version history data, and then performs cross-layer dependency reversal detection. In a new version, the relationship between module A and module B changes. Module A originally depended on an interface provided by module B, but in the new version, module A calls an interface of module C, while module C should depend on module A. After recognizing this behavior, the system marks it as a cross-layer dependency reversal and adjusts the credibility partition of that version to a low-credibility segment. The system's risk scoring function is set to R=0.85, which is lower than the set high-credibility threshold. Therefore, the system marked this version as a low-trust version and stored it in an isolated and sealed storage area. The system also calculated that this version has a call depth of 3 and a hierarchy sensitivity index of 0.75, which means that this version has a significant impact on the system. The system ensures through all verification steps that this version will not affect the overall stability and security of the system.

[0063] After a new version is submitted, the system analyzes it. By analyzing the code's dependencies, the system discovers that low-level module A calls high-level strategy module B, violating the original dependency hierarchy rules. Module A should only be able to call module C, while module B should provide support for module C. By tracing the call chain between versions, the system identifies that the call path of low-level module A has changed, calling high-level module B, which should not be directly accessed.

[0064] To accurately identify changes in this dependency, the system constructs a behavior prediction window based on the historical modification density of modules A and B. Module A is assumed to have been modified less frequently in the past five versions, averaging two modifications per version, while module B has been modified more frequently within the same period, averaging six modifications per version. Based on this data, the system generates a behavior prediction window with a set standard range, representing the expected behavior of modules A and B under normal circumstances.

[0065] The system also excludes disruptive commits made during abnormal periods. In the past two versions, the frequency of modifications to module A increased abnormally due to a temporary external requirement or testing error. This data will be excluded from the expected behavior window to ensure more accurate and reasonable window calculations.

[0066] By comparing the behavior of module A in the current version, the system found that module A called module B, which does not conform to the set expected behavior window. Since the number and frequency of changes to module A have been consistently low, while the change frequency of module B should remain relatively high, this cross-layer dependency behavior clearly exceeds the normal range. The system will mark this change as unexpected behavior and immediately suspend the release of this version to prevent it from entering the production environment.

[0067] The system calculated a behavioral deviation of 0.85 between module A and module B, which is higher than the system's preset tolerance threshold of 0.5. The system triggered a warning and adjusted the credibility of this version to low. The system performed a detailed analysis of this version and placed it in an isolated area during storage. Further calculations showed that this cross-layer dependency reversal behavior had a moderate impact on system stability, causing dependency confusion between modules and affecting overall functional consistency. Through in-depth analysis of module behavior, the system successfully identified the cross-layer dependency reversal behavior and eliminated interfering data by constructing a behavior expectation window, thereby ensuring the accuracy and stability of the version. Implementation: 2:

[0068] Combined with appendix Figure 5 Based on Example 1, when the system receives a software version submission, it constructs a risk scoring function for trustworthiness partitioning based on the submitter information, change content characteristics, and historical behavior. The function takes the following form:

[0069] The submitter is configured to use multi-factor biometric authentication. This authentication method is assigned weight in the system. This indicates that identity authentication has a significant impact on risk assessment. The system calculates the identity authentication strength function. The value obtained afterwards This value indicates a 95% confidence level in identity authentication at the time of submission. Then, it is processed through the identity trust mapping function. This certification strength value is converted into a risk contribution value. The mapping function is set as follows: Then we have:

[0070] The system needs to assess the scale and scope of the code changes. Assuming the current version involves changes across 10 modules, with 5 of those modules involving modifications related to core functionality, the system will assess these changes through functions. Calculate the size and scope of the change. System Settings This indicates that the code changes in this version have a significant impact on the core functional modules.

[0071] To further calculate the perturbation coefficient of this change on system stability, a perturbation function of the change's impact is introduced into the system. The structural perturbation weights The system calculates:

[0072] The system will also evaluate the submitter's historical behavioral scoring trajectory. Through the behavioral compliance averaging function Calculate the compliance of the behavior. Set the submitter's average behavior score over the past 6 months as [value missing]. rate of change in behavior This indicates whether there has been a significant change in the submitter's behavior. If the submitter's behavior has been stable over the past two weeks, then the rate of change is... .

[0073] The system will ultimately substitute all the above calculation results into the risk scoring function:

[0074] Set time range The length is 1 month, and the integration result is simplified as follows:

[0075] A risk score is calculated. The system compares the credibility of this version with a preset high credibility threshold. A comparison was made. Because... Below the high confidence threshold This version was marked as a low-trust version and stored in an isolated and sealed storage area to prevent potential risks from affecting system stability.

[0076] The system further calculates the access trust product based on the visitor's authentication confidence level and the matching degree of the operation context. The current visitor's authentication confidence level is set to 0.9, and the operation context matching score based on device fingerprint, geolocation, and access time features is set to 0.85. The access trust product value is then calculated. for:

[0077] Set the system's preset access threshold ,because Less than The system restricts the visitor's permissions, granting them access only to the minimum content required to complete the current target operation. The system triggers a key rotation mechanism, generating a new access key and putting the old key into a cooldown period to prevent concurrent decryption attacks.

[0078] The new version's code changes involved 10 modules, with four modules' functional modifications significantly impacting the system's overall structure and stability. The system assessed the complexity of the changes by calculating the function complexity of these modules, setting the function complexity of one critical module at 3.5 and another module at 2.8. The system then used these values ​​to calculate the overall impact of the changes.

[0079] The system calculates the call fan-out ratio, which is the number of other modules called by the changing module. This critical module was set to call five other modules, and these modules also have certain interdependencies. By analyzing the call relationships between these modules, the system calculated a call fan-out ratio of 2.5, meaning that each module has a relatively wide impact range. Combining these calculation results, the system derives the disturbance coefficient for this change. This indicates that the change has a significant impact on the overall stability of the system.

[0080] According to the preset threshold, when the disturbance coefficient When the perturbation coefficient exceeds 0.8, the system will trigger a risk amplification calculation, further classifying the changed area into a lower confidence partition. If the perturbation coefficient for this change is set to 0.9, exceeding the system's threshold of 0.8, the system will mark this change as low confidence and store it in an isolated, sealed storage area to prevent it from entering the production environment.

[0081] The system further analyzes the call depth of the code. Call depth represents the dependency hierarchy between modules; the greater the depth, the wider the impact. Assuming the change affects a module chain with a depth of 4, the system assigns a decay coefficient to each call node: 0.8 for layer 1, 0.6 for layer 2, 0.4 for layer 3, and 0.2 for layer 4. The system generates a hierarchy sensitivity index of 0.6 based on the decay coefficients, indicating a higher risk in higher-level module calls and a significant impact on system stability. The system uses this hierarchy sensitivity index as a reference value for reliability calculation, further determining the reliability partition for this version.

[0082] After analyzing the version change, the system began assessing security, particularly crucial for key management during frequent access or sensitive data processing. The system simulated a sudden increase in access frequency after the release of this version, especially with multiple users simultaneously requesting access to sensitive data. By calculating an access request frequency function, the system found that the access request frequency increased by 40% for this version, while the average key usage time was 2 hours. The system calculated the ratio of access frequency to average key usage time to be 20. This ratio exceeded the preset rotation threshold of 15, leading the system to conclude that there was a potential security risk.

[0083] When access frequency surges or the key duplication rate exceeds a set limit, the system generates a new access key and puts the old key into a cooldown period. The old key has been used 80 times, and a new key is assigned to the current access request. After the system enters the cooldown period, the old key will be suspended for 24 hours, effectively preventing concurrent decryption attacks.

[0084] When a developer submits a new version, the platform verifies the submitter's identity. The submitter is assumed to use multi-factor biometric authentication, and the system calculates an authentication confidence score after successful verification. The submitter's authentication uses both facial recognition and fingerprint recognition. Based on the reliability of these two authentication methods, the system assesses the submitter's authentication confidence score at 0.95, indicating that the submitter's identity is highly trustworthy.

[0085] The system calculates the submitter's operational context matching degree, which involves multiple factors, including device fingerprint, access time, and geographic coordinate consistency. The system obtains the submitter's device fingerprint, which includes the device's hardware information, browser version, and operating system version. A device fingerprint matching degree of 0.9 is set, indicating that the device used by the submitter is highly consistent with devices in the historical records.

[0086] The system calculates the time feature matching degree, that is, whether the submitter's access time matches their past active time periods. The submitter's access time is set to fall within the normal working time window and is highly consistent with historical active time windows; therefore, the time matching degree is 0.85.

[0087] The system calculates the matching degree based on geographic coordinate consistency. If the submitter's location is near their frequently used login location when submitting a version, the system calculates a geographic coordinate matching degree of 0.8, indicating a small deviation between the current access location and historical login locations.

[0088] The system multiplies the identity authentication confidence value by the operation context matching value to obtain a comprehensive trust value. The calculation is as follows:

[0089] The system's preset access threshold Due to the calculation results Less than the threshold The system restricts the visitor's permissions to only the minimum content required for the current operation. The system also prevents the submitter from accessing other unrelated modules and functions; only modules directly related to the current submission can be accessed.

[0090] The system calculates the submitter's authentication confidence score. This score is weighted based on the submitter's authentication method, historical success rate, and the consistency score of the authentication device. The submitter is configured to use multi-factor biometric authentication, which is given the highest weight. The submitter's historical authentication success rate is set at 90%, meaning a success rate of 0.9, while the device's consistency score is 0.8. The system performs a weighted calculation based on these parameters:

[0091] The submitter's identity verification confidence level is 0.905.

[0092] The system found the device previously used by the submitter in the history and calculated a similarity score of 0.85 by comparing the device fingerprint with the history.

[0093] The system also assesses the matching degree of the user's operational context based on the consistency between the access time and the submitter's historical active time window. Setting the submitter's historical active time period to 9:00 AM to 6:00 PM on weekdays, the system fits the user's active time period using a Gaussian distribution and generates a confidence interval. Setting the current access time to 2:00 PM, after Gaussian distribution fitting, the calculated time matching degree is 0.8, indicating that the current access time is within the user's common active time window and matches the expected behavior.

[0094] The system assesses the consistency of geographic coordinates. Assuming the submitter frequently logs in from city A, while the IP address of this visit indicates they are located in city B, the system calculates a geographic distance of 1000 kilometers between the two locations. The system standardizes this distance, calculating a geographic coordinate match score of 0.7. This indicates a discrepancy between the visitor's location and their historical login location, reducing the credibility of the operation.

[0095] The system uses the product of authentication confidence and operational context matching for final access control. The operational context matching is defined as a comprehensive evaluation of device fingerprint similarity, temporal feature matching, and geographic coordinate consistency, calculated as follows:

[0096] The system multiplies the identity authentication confidence level with the operation context matching level to obtain the trust product value. :

[0097] The system's preset access threshold Due to the calculated trust product value If the content is below a preset threshold, the system will restrict the visitor's permissions. The system will only authorize the visitor to access the minimum range of content relevant to the current operation.

[0098] The foregoing has shown and described the basic principles, main features, and advantages of the present invention. Those skilled in the art should understand that the present invention is not limited to the above embodiments. The embodiments and descriptions in the specification are merely illustrative of the principles of the invention. Various changes and modifications can be made to the invention without departing from its spirit and scope, and all such changes and modifications fall within the scope of the present invention as claimed. The scope of protection of this invention is defined by the appended claims and their equivalents.

Claims

1. A method for verifying the integrity of cloud-based software versions and for secure storage, characterized in that... include: When a new version of the software is uploaded to the cloud, the system obtains the structural change data of the current version and at least one historical version, analyzes the evolution path through the mutation sequence behavior judgment mechanism, and marks it as a potential integrity anomaly if there is a rewriting of discontinuous structural logic or missing dependency relationship. The marked version is divided into structural regions. The active boundary of the module in the historical version is used as the trusted evolution boundary. When a structural migration or abnormal call that crosses the boundary is detected, the fault identification process is triggered and an out-of-bounds flag is output. The behavior expectation window is constructed based on the historical change baseline. The change behavior of the current version is matched in intervals. If it exceeds the range and is concentrated in the abnormal area, it is marked as unexpected behavior and the release is suspended. Based on the integrity analysis results, the version content is split into multiple trust partitions. Trusted segments are stored in the ordinary encrypted area, and untrusted segments are stored in the isolated encrypted storage area. A content mapping table is established to implement dynamic access control. For versions marked as untrusted, an unretrospective archive node is generated, and subsequent versions are prohibited from inheriting its logic.

2. The cloud-based software version integrity verification and secure storage method according to claim 1, characterized in that... The mutation sequence behavior judgment mechanism includes identifying whether the newly added code block bypasses the interface module in the historical call chain, so as to determine that it is a rewriting behavior with discontinuous structural logic; The rewriting behaviors that result in discontinuous structural logic include: changing function entry points, heterogeneous interface parameters, or redirecting control flow; The missing dependency is determined by detecting the module call path or reference chain breakpoint that is interrupted in the current version.

3. The cloud-based software version integrity verification and secure storage method according to claim 1, characterized in that... The active boundary of the module is generated based on the frequency of changes in the past N versions, where N is a positive integer ranging from 3 to 50, and can be dynamically adjusted according to project characteristics and version change frequency; the statistical period is a configurable time window; and the fault identification process further verifies whether there is cross-layer dependency reversal behavior when it detects cross-boundary references of modules.

4. The cloud-based software version integrity verification and secure storage method according to claim 3, characterized in that... The cross-layer dependency reversal behavior is when a lower-layer module calls a higher-layer strategy module, violating the original dependency hierarchy rules; the behavior expectation window is constructed based on the historical modification density of each module and excludes interfering commit data during abnormal periods.

5. The cloud-based software version integrity verification and secure storage method according to claim 1, characterized in that... The credibility partitioning criteria include the source credibility level of the modified code, the scope of code impact, and the call depth; the source credibility level is dynamically calculated based on the submitter's identity authentication information, historical behavior compliance score, and approval records; the isolated and sealed storage area adopts a dynamic key rotation mechanism and dynamically allocates permissions based on the visitor's identity authentication results and operation context, authorizing access only to the minimum content range required to complete the target operation.

6. The cloud-based software version integrity verification and secure storage method according to claim 5, characterized in that... By calculating the function complexity and call fan-out ratio of the scope of the code's impact, the disturbance coefficient of the change on the overall stability of the system is determined, and the credibility partitioning result is corrected accordingly. When the disturbance coefficient exceeds a preset threshold, the system triggers a risk amplification calculation and classifies the changed area into a lower credibility partition. The calculation of the call depth assigns a decay coefficient to each call node, and finally generates a hierarchical sensitivity index for credibility calculation.

7. The cloud-based software version integrity verification and secure storage method according to claim 5, characterized in that... The dynamic key rotation mechanism determines the rotation trigger point by calculating the ratio of the access request frequency function to the average key usage time. When the access frequency surges or the key duplication rate exceeds a set ratio, the system generates a new key and puts the old key into a cooling-off period to prevent concurrent decryption.

8. The cloud-based software version integrity verification and secure storage method according to claim 5, characterized in that... The access permission allocation for visitors is based on the product of the identity authentication confidence value and the current operation context matching value. When the product is lower than the threshold, the granularity of accessed content is restricted. The operation context matching degree is calculated by comparing the consistency of the access device fingerprint, time features and geographical coordinates.

9. The cloud-based software version integrity verification and secure storage method according to claim 8, characterized in that... The identity authentication confidence value is calculated by weighting the identity authentication method level, the success rate of authentication history, and the consistency score of the authentication device; wherein the identity authentication method level is weighted according to the following priority order: multi-factor biometrics > dynamic token verification > static password matching.

10. The cloud-based software version integrity verification and secure storage method according to claim 8, characterized in that... The access device fingerprint includes browser version number, operating system type, device hardware characteristics, and TLS fingerprint. The device fingerprint is compared with historical access records to calculate a similarity score. The time feature includes the degree of consistency between the access time and the historical active time window. A Gaussian distribution is used to fit the user's active time period to generate a confidence interval. Geographic coordinate consistency is achieved by calculating the geographic distance between the current IP address location and the user's commonly used login location and then standardizing the result to obtain a matching value.

Images