A red-yellow-blue partition-based research and development data access and exit control method

Abstract

The application discloses a research and development data access and exit control method based on red, yellow and blue zoning, which comprises the following steps: deploying a one-way gateway with a fingerprint verification interface in a blue zone external domain, a yellow zone transfer domain, a red zone core domain and a fingerprint verification interface, configuring domain function modules, and laying a cross-domain control foundation; monitoring open source CVE vulnerabilities in the blue zone, generating an update requirement work order containing CVE information, a source code download address and a benchmark fingerprint, and synchronizing the work order to the yellow zone through the one-way gateway; the yellow zone triggers the blue zone to download the source code according to the work order, calculates an actual fingerprint and verifies the actual fingerprint with the benchmark fingerprint, and performs a security scan after verification; submitting the scan report and the actual fingerprint to the yellow zone for grading approval; and after the approval, the red zone obtains the source code through the gateway. The application constructs a technical system of "CVE vulnerability driving + three-level security domain one-way control + full-link data fingerprint verification + closed-loop prevention and control", and realizes full-process control from vulnerability perception, code access, product circulation to release and deployment.

Description

Technical Field

[0001] This invention relates to the field of R&D data security management technology, specifically to a R&D data access and exit management method based on red-yellow-blue partitioning. Background Technology

[0002] With the deepening of digital transformation, the demand for the flow of R&D data, including source code, artifact files, and open-source components, across multiple security-level environments has surged. Enterprises' R&D systems are increasingly reliant on external open-source code, making secure data flow and the stability of the open-source supply chain core requirements for R&D management.

[0003] In the current hybrid security domain environment, existing technologies have the following core pain points:

[0004] 1. Cross-domain data lacks a strict one-way control mechanism, which can easily lead to the leakage of R&D assets and poses the risk of illegal outflow of internal products and inflow of malicious external data;

[0005] 2. The import of open-source components does not form a closed-loop process of "download-scan-approval-import", and malicious code and vulnerable components can easily enter the internal R&D environment;

[0006] 3. The lack of a tiered approval mechanism for the release of R&D products means that the release of products that have not been fully tested and verified can easily lead to safety risks.

[0007] 4. Open-source code and artifacts lack internal caching mechanisms and rely directly on external services, making them susceptible to supply chain disruptions due to external interruptions.

[0008] 5. The interfaces between system modules lack standardized management, the data flow links are not transparent, and it is difficult to trace and audit them;

[0009] Existing technical solutions can be divided into four categories, but all have limitations: cross-security domain data transmission control solutions only focus on isolation and encryption of the transmission process, without involving open-source code scanning approval and one-way flow rules; open-source supply chain risk prevention and control solutions only achieve single-point vulnerability detection, without forming a closed loop with cross-domain flow approval; open-source component internal cache management solutions only solve storage problems, lacking security control and flow approval linkage; and secure isolation collaborative development environment solutions only achieve data security within the environment, without covering cross-domain exit approval and supply chain full-process control. Summary of the Invention

[0010] The present invention proposes a research and development data access and exit control method based on red, yellow and blue partitioning, which can at least solve one of the technical problems in the background art.

[0011] To achieve the above objectives, the present invention adopts the following technical solution:

[0012] A method for controlling access to and from R&D data based on red-yellow-blue partitioning includes the following steps:

[0013] S1. Deploy the blue zone external domain, yellow zone transit domain, red zone core domain, and a one-way gateway with fingerprint verification interface, configure the functional modules of each domain, and lay the foundation for cross-domain management and control.

[0014] S2. Monitor open-source CVE vulnerabilities in the blue zone, generate update request tickets containing CVE information, source code download address and baseline fingerprint, and unidirectionally synchronize them to the yellow zone through the network gateway;

[0015] S3. The yellow zone triggers the blue zone to download the source code based on the work order, calculates the actual fingerprint and verifies it with the benchmark fingerprint. After the verification is successful, a security scan is performed and a risk assessment report is generated.

[0016] S4. Submit the scan report and actual fingerprints to the yellow zone for hierarchical approval; after approval, the red zone obtains the source code through the network gateway, verifies the fingerprints again, and stores it in the red zone's trusted software source.

[0017] S5. The red zone compiles the source code to generate artifacts, generates artifact fingerprints, and transfers the artifacts unidirectionally to the yellow zone via the network gateway for testing and verification.

[0018] After the S6 and yellow zone tests are passed, the product is unidirectionally published to the blue zone via the network gateway, and after final fingerprint verification, it is stored and provided as a service.

[0019] As a preferred embodiment of the R&D data access and exit control method based on red-yellow-blue partitioning described in this invention, the reference fingerprint and the actual fingerprint are both data hash values ​​generated using the SHA-256 algorithm.

[0020] As a preferred embodiment of the R&D data access and exit control method based on red-yellow-blue partitioning described in this invention, the hierarchical approval includes automatic rule approval and manual review; the automatic rule approval is based on the CVE security scoring dimension and the license compliance scoring dimension, with each dimension scored independently and then weighted and summarized; the CVE security scoring dimension is scored using the CVSS vulnerability scoring system; the license compliance scoring dimension is comprehensively evaluated internally based on the type of open-source license, its constraints, and its potential impact on business; the comprehensive score is obtained by weighting the scores of the above two dimensions, as shown in the following formula:

[0021] Overall score = (CVE security score × CVE weight) + (License compliance score × License weight);

[0022] CVE weight and license weight: These are set internally based on the emphasis on security and compliance, and the sum of their weights is 1.

[0023] As a preferred embodiment of the R&D data access and exit control method based on red-yellow-blue partitioning described in this invention, the security scan is a targeted scan, which only detects risk points related to the current CVE vulnerability.

[0024] As a preferred embodiment of the R&D data access and exit control method based on red, yellow and blue partitions described in this invention, the red zone, yellow zone and blue zone are physically isolated and data is transmitted unidirectionally through a dedicated network gateway, prohibiting reverse data backflow.

[0025] As a preferred embodiment of the R&D data access and exit control method based on red-yellow-blue partitioning described in this invention, the following features are provided: all cross-module interfaces throughout the entire process carry work order IDs and fingerprints, and a traceable link is formed through log records. When submitting a transfer application in the red zone, the product version number, compilation log, product fingerprint, corresponding source code fingerprint, and work order ID must be submitted simultaneously.

[0026] As a preferred embodiment of the R&D data access and exit control method based on red-yellow-blue partitioning described in this invention, the network gateway prohibits reverse data backflow, triggers fingerprint verification during cross-domain transmission, and blocks transmission if inconsistent.

[0027] As a preferred embodiment of the R&D data access and exit control method based on red, yellow and blue partitions described in this invention, it further includes establishing hierarchical caches in the red zone, yellow zone and blue zone respectively, and storing corresponding fingerprint information to achieve full-link data traceability.

[0028] In another aspect, the present invention also discloses a computer-readable storage medium storing a computer program, which, when executed by a processor, causes the processor to perform the steps of the method described above.

[0029] In another aspect, the present invention also discloses a computer device, including a memory and a processor, wherein the memory stores a computer program, and when the computer program is executed by the processor, the processor performs the steps of the method described above.

[0030] The beneficial effects of this invention are:

[0031] 1. Data leakage prevention: One-way flow rules combined with physical isolation of the network gateway prevent the direct outflow of data from the red zone. Cross-domain flows are subject to approval and fingerprint verification to block illegal leakage paths.

[0032] 2. Open source security control: Before importing open source code, it undergoes targeted scanning and graded approval to double-block malicious code and vulnerable components, ensuring the security of the development environment;

[0033] 3. Supply chain stability: Core code and artifacts are stored in internal multi-level cache nodes, without relying on external services, thus avoiding the risk of supply chain disruptions.

[0034] 4. End-to-end traceability: Standardized interfaces are associated with fingerprint logs to achieve full-process auditing of data sources, transfer nodes, and operators, and support rapid tracing of tampering behavior;

[0035] 5. High-efficiency collaboration and compliance: Automated vulnerability detection, work order creation, and scanning approval processes reduce manual intervention while meeting R&D security compliance requirements, balancing security and efficiency. Attached Figure Description

[0036] Figure 1 This is an overall flowchart of the R&D data access and exit control method based on red, yellow, and blue partitioning of the present invention.

[0037] Figure 2 This is a timing diagram of the R&D data access and exit control method based on red-yellow-blue partitioning of the present invention. Detailed Implementation

[0038] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are some embodiments of the present invention, but not all embodiments.

[0039] like Figures 1-2 As shown, this invention divides security into three levels: red, yellow, and blue. It deploys a one-way gateway with fingerprint verification interfaces and supporting functional modules to construct a technical system of "CVE vulnerability-driven + three-level security domain one-way control + full-link data fingerprint verification + closed-loop prevention and control." This system achieves full-process control from vulnerability awareness, code access, artifact flow to release and deployment. The specific steps are as follows:

[0040] 1. Deploy a three-tier security domain and supporting modules: Divide the domain into blue zone (external domain), yellow zone (transfer domain), and red zone (core domain). Deploy yellow-blue gateways and red-blue gateways between the blue zone and the yellow zone, and between the yellow zone and the red zone, respectively. Deploy a CVE management platform, download server, code storage area, and central / satellite repository in the blue zone; deploy a DevOps platform and yellow zone artifact repository in the yellow zone; deploy a trusted software source (Gitea + Nexus), red zone artifact repository, and trusted data processing service in the red zone.

[0041] 2. CVE vulnerability-driven work order creation: The Blue Zone CVE management platform monitors the open source vulnerability database in real time, matches the source code addresses of affected components and patch versions of the enterprise, generates a work order containing CVE information and baseline fingerprint (SHA-256 algorithm), and synchronizes it to the Yellow Zone DevOps platform through the Yellow-Blue Network Gateway;

[0042] 3. Open source code download and access control: The yellow zone issues download instructions with work order ID and baseline fingerprint. The blue zone download server completes the code download and generates the actual fingerprint, which is then verified against the baseline fingerprint for the first time. If the verification is consistent, a CVE targeted scan is triggered. After the scan report and the actual fingerprint undergo hierarchical approval (automatic rules + manual review), the red zone trusted data processing service performs a second verification of the fingerprint. If it passes, it is imported into the red zone trusted software source and a "code-fingerprint-work order" association file is established.

[0043] 4. Cross-domain transfer control of products: The code in the red zone is compiled to generate products and bound to fingerprints. A transfer application is submitted to the yellow zone. After the application is approved, the product is pushed to the product warehouse in the yellow zone through the red and blue network gate. The yellow zone verifies that the fingerprint is consistent, stores it, and updates the work order status to pending testing.

[0044] 5. Product Testing and Release Control: Products in the yellow zone undergo automated functional testing, manual verification, and security scanning in sequence, with fingerprints recorded for each round of testing. After passing the test and undergoing release review, the products are pushed to the central warehouse in the blue zone through the yellow-blue network gateway. After the blue zone completes the final fingerprint verification, the products are distributed to the satellite warehouse for external service.

[0045] 6. End-to-end traceability and interface control: Define standardized interfaces across modules, and all interactions carry work order ID and data fingerprint; interface logs record fingerprint generation time, verification results and other information, forming a unique association chain of "work order-ID-fingerprint-log".

[0046] The specific implementation examples are as follows:

[0047] I. Core Basic Configuration

[0048] (I) Implementation of SHA-256 Data Fingerprint Generation

[0049] 1. Linux command-line method: Applicable to fingerprint calculation of source code files and artifact files. Command and output examples are as follows:

[0050] sha256sumdemo.rpm

[0051] f8799969d9e238d09774428d560054e7949f20b802784227890006e37542096demo.rpm

[0052] Code-level integration (Java example, suitable for automatic system calculations)

[0053] import java.io.File;

[0054] importjava.io.FileInputStream;

[0055] import java.security.MessageDigest;

[0056] public class SHA256Util {

[0057] public static String getFileSHA256(File file) throws Exception {

[0058] MessageDigest md = MessageDigest.getInstance("SHA-256");

[0059] FileInputStream fis = new FileInputStream(file);

[0060] byte[] buffer = new byte

[8192] ;

[0061] int len;

[0062] while ((len = fis.read(buffer)) != -1) {

[0063] md.update(buffer, 0, len);

[0064] }

[0065] fis.close();

[0066] / / Convert to hexadecimal string

[0067] StringBuilder sb = new StringBuilder();

[0068] for (byte b : md.digest()) {

[0069] sb.append(String.format("%02x", b));

[0070] }

[0071] return sb.toString();

[0072] }

[0073] public static void main(String[] args) throws Exception {

[0074] FilesourceFile=newFile(" / path / to / demo.rpm");

[0075] Stringsha256=getFileSHA256(sourceFile);

[0076] System.out.println("File SHA-256 hash value: "+sha256);

[0077] }

[0078] }

[0079] Fingerprint storage requirements: A code-fingerprint association table should be established in the blue zone, and a product-fingerprint traceability table should be established in the red, yellow, and blue zone product warehouses. All fingerprints must not contain null values ​​or placeholders and must form a unique association chain with the work order ID.

[0080] (II) Specific Configuration Scheme of Network Gateway

[0081] Transmission direction restrictions:

[0082] Permitted directions: Red zone → Yellow zone (product transfer), Blue zone → Red zone (code import), Blue zone → Yellow zone (work order / scan report synchronization), Yellow zone → Blue zone (product release);

[0083] Among them, the processes of red zone → yellow zone (product circulation), blue zone → red zone (code import), and yellow zone → blue zone (product release) are file transfers; the process of blue zone → yellow zone (work order / scan result synchronization) is an API call process for workflow creation, and each corresponds to a one-way policy configuration in the network gateway.

[0084] Prohibited directions: Except for the one-way policies configured above, data or file transfers in other directions are not allowed.

[0085] Fingerprint verification interface configuration:

[0086] Interface name: / api / gateway / verify-sha256;

[0087] Request method: POST;

[0088] Request parameters:

[0089] {

[0090] "ticketId":"CVE-2025-001",

[0091] "dataHash":"f8799969d9e238d09774428d560054e7949f20b802784227890006e37542096",

[0092] "dataType":"SOURCE_CODE",

[0093] "sourceZone":"BLUE",

[0094] "destZone":"RED"

[0095] }

[0096] Response example (validation passed):

[0097] {

[0098] "code":200,

[0099] "message":"Fingerprint verification passed, transmission allowed",

[0100] "timestamp":"2025-10-2015:00:00"

[0101] }

[0102] Response example (validation failed):

[0103] {

[0104] "code":403,

[0105] "message": "Fingerprint mismatch, transmission blocked",

[0106] "timestamp":"2025-10-2015:00:00",

[0107] "errorDetail": "The actual hash value does not match the hash value bound to the work order."

[0108] }

[0109] (III) Configuration of hierarchical approval rules

[0110] Automatic rule approval: The comprehensive score consists of the following two dimensions, and each dimension is scored independently and then weighted and summarized.

[0111] 1. CVE security scoring dimensions

[0112] Scoring criteria: The score for this dimension is directly based on the CVSS (General Vulnerability Scoring System) scores released by official organizations such as the National Vulnerability Database (NVD).

[0113] Scoring range: typically from 0.0 to 10.0. The higher the score, the more severe the security vulnerability and the greater the potential risk.

[0114] Note: This dimension's score is authoritative and objective, reflecting the known security vulnerabilities inherent in the software components themselves.

[0115] 2. License Compliance Scoring Dimensions

[0116] Scoring criteria: The score for this dimension is determined internally based on a comprehensive assessment of the type of open source license, its constraints, and its potential impact on the business.

[0117] Key considerations:

[0118] License types: such as the differences between Apache 2.0, MIT, BSD (permissive license) and GPL, AGPL (aggressive license).

[0119] Contagion risk: Focus on assessing compliance risks that highly contagious licenses such as GPL may bring, such as open-source code requirements and restrictions on the licensing of derivative works.

[0120] Commercial Use Restrictions: Evaluate the specific constraints that the license imposes on the use, distribution, and modification of the software in a commercial environment.

[0121] Scoring range: An internally set scoring range (e.g., 0 to 10 points) is used. The higher the score, the higher the compliance risk of the license and the greater the potential restrictions on business.

[0122] Note: This score reflects the legal compliance risks that software components may face during use, especially the constraints of open source licenses.

[0123] 3. Comprehensive scoring calculation method

[0124] The overall score is calculated by weighting the scores from the two dimensions mentioned above, as shown in the following formula:

[0125] Overall score = (CVE security score × CVE weight) + (License compliance score × License weight)

[0126] CVE weight and license weight: These are set internally based on the company's emphasis on security and compliance (e.g., CVE weight 0.6, license weight 0.4), and the sum of the two weights is 1.

[0127] Scoring Results: The overall scoring result will serve as the final quantitative indicator for the software component risk assessment, guiding subsequent risk management and decision-making. The scoring... A score of 5 will be automatically approved. A score of 5 will trigger manual review.

[0128] Approval form types include: open source code import approval form (blue zone → red zone), product red zone → yellow zone transfer approval form, and product yellow zone → blue zone release approval form, all of which require association with work order ID and fingerprint information;

[0129] Rejection criteria: Applications will be rejected directly if fingerprints do not match, the scan report indicates a high risk, or the application materials are incomplete.

[0130] II. Detailed Implementation of Core Processes

[0131] (I) CVE Vulnerability-Driven Work Order Creation Process

[0132] 1. The Blue Zone CVE Management Platform monitors official vulnerability databases such as NVD and open-source communities in real time, and analyzes the CVE number, scope of impact, remediation priority, and official patch version of newly added vulnerabilities;

[0133] 2. By connecting with the enterprise's internal dependency component database and SBOM inventory management system, the open source components that need to be updated are accurately located according to the matching logic of "CVE-affected component name → enterprise SBOM inventory → affected project / component version";

[0134] 3. Obtain the official source code download address of the component's patched version and the publicly available benchmark fingerprint from the open-source community, generate a "CVE update request ticket" containing full CVE information, source code address, benchmark fingerprint, and patch urgency level, and unidirectionally synchronize it to the yellow zone DevOps platform through the yellow-blue network gateway;

[0135] 4. The Yellow Zone DevOps platform completes the archiving of work order information and the caching of baseline fingerprints, triggering the subsequent download process.

[0136] (II) Open Source Code Download and Access Control Process

[0137] 1. The Yellow Zone DevOps platform sends download instructions to the Blue Zone download server through a standardized interface. The instructions carry the work order ID, official benchmark fingerprint, and source code download address.

[0138] 2. The Blue Zone download server downloads the code package from the official repository of the open source component, temporarily stores it in the Blue Zone code storage area, and calculates the actual fingerprint using the SHA-256 algorithm, and performs the initial verification with the baseline fingerprint carried in the work order;

[0139] Inconsistent verification: Discard the code and trigger a high-risk alert.

[0140] No official fingerprint release: Skipping the initial comparison and proceeding directly to the scanning stage;

[0141] 3. After verification, the code security scanning tool is automatically triggered to perform targeted scanning for the current CVE vulnerability (only detecting risk points related to the vulnerability), identify the vulnerability risk level, open source protocol compliance and malicious code, generate an assessment report and bind code fingerprints;

[0142] 4. After binding the assessment report, actual code fingerprint, and work order ID, the blue zone download server transmits the data unidirectionally to the yellow zone DevOps platform through the yellow-blue network gateway to initiate a code access application;

[0143] 5. The Yellow Zone DevOps platform initiates a tiered approval process:

[0144] Automatic rule approval: Based on a weighted score of CVE vulnerability severity and license compliance, approval is automatically granted if there are no serious or high-risk issues;

[0145] Manual review: When automatic approval fails, the administrator will review the medium / low risk application.

[0146] 6. After approval, the Yellow Zone DevOps platform triggers the Red Zone Trusted Data Processing Service, which issues code through a standardized interface to obtain instructions. The instructions carry the work order ID and the official benchmark fingerprint.

[0147] 7. The red zone trusted data processing service initiates a code retrieval request to the blue zone code storage area through the red-blue network gateway. After verifying the legality of the request (matching the work order ID with the baseline fingerprint), the blue zone code storage area transmits the encrypted code package to the red zone.

[0148] 8. After receiving the code packet, the Red Zone Trusted Data Processing Service recalculates the actual fingerprint and performs a secondary verification with the official benchmark fingerprint:

[0149] Inconsistent verification: Block import and trigger a high-risk alert;

[0150] Verification of consistency: The code package is unpacked and formatted, and then imported unidirectionally into the trusted software source in the red zone (gitea + nexus) to establish a "code-fingerprint-CVE ticket" related file;

[0151] 9. The trusted data processing service in the red zone sends the import result (success / failure) to the DevOps platform in the yellow zone through the red-blue network gateway. The DevOps platform then updates the work order status to "code imported".

[0152] (III) Control Procedures for Cross-Regional Circulation of Products

[0153] 1. The code in the trusted software source in the red zone starts the build process through a preset automated compilation pipeline, records key information such as compilation parameters and dependent component versions, and generates a complete compilation log;

[0154] 2. After the build is completed, non-source code artifacts such as binary packages and image files are generated and automatically stored in the red zone artifact repository. The red zone artifact repository generates artifact baseline fingerprints using the SHA-256 algorithm, establishes a unique association chain with the corresponding source code fingerprints, and synchronously stores artifact files, artifact fingerprints, and compilation logs.

[0155] 3. The red zone artifact warehouse submits a transfer application to the yellow zone DevOps platform. The application materials include artifact version number, compilation log, artifact baseline fingerprint, corresponding source code fingerprint and work order ID.

[0156] 4. After the Yellow Zone DevOps platform verifies the completeness of the application materials and that the fingerprint is not empty, it initiates the approval process and automatically verifies the legality of the association between the product fingerprint and the source code fingerprint.

[0157] 5. After approval, the red zone product warehouse pushes products unidirectionally to the yellow zone product warehouse through the red and blue network gate, carrying the product fingerprint and work order ID during the push process;

[0158] 6. After receiving the product, the yellow zone product warehouse immediately calculates the actual fingerprint using the SHA-256 algorithm and verifies it against the product baseline fingerprint synchronized in the red zone.

[0159] Verification of consistency: Store artifacts, associate them with workflow records and work order information, write them to the local fingerprint sub-table, and report the receiving results to the Yellow Zone DevOps platform. The platform will then update the artifact status to "Pending Test".

[0160] Inconsistent verification: Reject reception and trigger a high-risk alarm, sending a "Reception failed - fingerprint abnormal" message to the red zone product warehouse.

[0161] (iv) Product testing and release control process

[0162] 1. The products awaiting testing in the yellow zone product warehouse are tested sequentially according to the process:

[0163] Automated functional testing: Verifying the availability of core functionalities;

[0164] QA manual verification: Investigating detailed issues;

[0165] Security scanning: vulnerability retesting + compliance verification to ensure no new risks are added;

[0166] After each round of testing, the current actual fingerprint of the product is recorded and compared with the baseline fingerprint generated in the red zone to ensure that the product has not been tampered with during the test. If the fingerprints do not match, the test is paused and an alarm is triggered.

[0167] 2. After all tests are passed, the release review will be initiated. The review materials include test reports, security scan reports, and the entire product fingerprint record (compilation fingerprint, fingerprints of each round of testing).

[0168] 3. After the review is approved, the developers submit an artifact release application through the Yellow Zone DevOps platform. The platform verifies the consistency between the current fingerprint of the artifact and the baseline fingerprint in the Red Zone, as well as the intermediate fingerprint recorded during the testing phase.

[0169] Inconsistency: The application to publish was rejected, triggering a medium-risk alert;

[0170] Consistency: By issuing an application, the push API of the yellow zone product warehouse is triggered;

[0171] 4. The yellow zone product warehouse pushes products to the blue zone central warehouse through the yellow-blue network gateway. The pushed data includes product files, product baseline fingerprints, and work order IDs.

[0172] 5. The yellow and blue network gate automatically verifies the actual fingerprint of the product with the reference fingerprint synchronized with the DevOps platform. If they are inconsistent, the transmission is blocked and a high-risk alarm is triggered.

[0173] 6. After receiving the product, the central warehouse in the blue zone will perform a fourth fingerprint verification. If the fingerprints match, the product will be stored and simultaneously distributed to the satellite warehouse in the blue zone.

[0174] 7. The Blue Zone Central Warehouse reports the release result to the Yellow Zone DevOps Platform through the Yellow-Blue Network Gateway. The platform updates the work order status to "released". The Blue Zone Central Warehouse and Satellite Warehouse officially provide artifact services to the public and support users to initiate fingerprint verification requests.

[0175] (V) Full-chain traceability implementation process

[0176] 1. Define standardized cross-module interfaces, covering four core categories:

[0177] Data transmission interfaces: CVE information synchronization interface (blue zone → yellow zone, carrying CVE information + baseline fingerprint), code transmission interface (blue zone → red zone, carrying code package + actual fingerprint), artifact push interface (red zone → yellow zone, yellow zone → blue zone, carrying artifact + fingerprint + work order ID).

[0178] Fingerprint verification interface: gateway fingerprint verification interface (forces verification of the consistency of transmitted data fingerprints), cached fingerprint query interface (supports querying associated data by work order ID / data fingerprint);

[0179] Workflow control interfaces include: work order creation interface (binding CVE information and baseline fingerprint), approval triggering interface (carrying fingerprint verification results), and result feedback interface (synchronizing data transmission / verification status).

[0180] Audit query interfaces: Product fingerprint traceability interface (query source code fingerprints and work order information through product fingerprints), operation log query interface (query the entire process operation record through work order ID / fingerprint);

[0181] 2. All interface interactions carry the work order ID and data fingerprint, and the interface logs automatically record information such as "fingerprint generation time, verification result, operator, and cross-domain node";

[0182] 3. A unique association chain of "work order-ID-fingerprint-log" can be formed through logs. Any fingerprint anomaly in any link can quickly locate the problem node, enabling tampering traceability and compliance auditing.

[0183] Examples of approval forms are shown in Table 1-3 below:

[0184] Table 1: Open Source Code Import Approval Form (Blue Zone → Red Zone):

[0185]

[0186] Table 2: Product Transfer Approval Form (Red Zone → Yellow Zone)

[0187]

[0188] Table 3: Product Yellow Zone → Blue Zone Issuance Approval Form:

[0189]

[0190] In another aspect, the present invention also discloses a computer-readable storage medium storing a computer program, which, when executed by a processor, causes the processor to perform the steps of the method described above.

[0191] In another aspect, the present invention also discloses a computer device, including a memory and a processor, wherein the memory stores a computer program, and when the computer program is executed by the processor, the processor performs the steps of the method described above.

[0192] In another embodiment provided in this application, a computer program product containing instructions is also provided, which, when run on a computer, causes the computer to execute any of the R&D data access and exit control methods based on red-yellow-blue partitioning in the above embodiments.

[0193] It is understood that the system provided in the embodiments of the present invention corresponds to the method provided in the embodiments of the present invention, and the explanation, examples and beneficial effects of the relevant content can be referred to the corresponding parts of the above method.

[0194] In the above embodiments, implementation can be achieved entirely or partially through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented entirely or partially in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid-state disk (SSD)).

[0195] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0196] The various embodiments in this specification are described in a related manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the system embodiments are basically similar to the method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions of the method embodiments.

[0197] The above embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit it. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A method for controlling the access and exit of R&D data based on red-yellow-blue partitioning, characterized in that, Includes the following steps: S1. Deploy the blue zone external domain, yellow zone transit domain, red zone core domain, and a one-way gateway with fingerprint verification interface, configure the functional modules of each domain, and lay the foundation for cross-domain management and control. S2. Monitor open-source CVE vulnerabilities in the blue zone, generate update request tickets containing CVE information, source code download address and baseline fingerprint, and unidirectionally synchronize them to the yellow zone through the network gateway; S3. The yellow zone triggers the blue zone to download the source code based on the work order, calculates the actual fingerprint and verifies it with the benchmark fingerprint. After the verification is successful, a security scan is performed and a risk assessment report is generated. S4. Submit the scan report and actual fingerprints to the yellow zone for hierarchical approval; After approval, the red zone obtains the source code through the network gateway, verifies the fingerprint again, and stores it in the red zone's trusted software source. S5. The red zone compiles the source code to generate artifacts, generates artifact fingerprints, and transfers the artifacts unidirectionally to the yellow zone via the network gateway for testing and verification. After the S6 and yellow zone tests are passed, the product is unidirectionally published to the blue zone via the network gateway, and after final fingerprint verification, it is stored and provided as a service. The tiered approval process includes automated rule-based approval and manual review. Automated rule-based approval is based on CVE security scoring and license compliance scoring, with each dimension scored independently and then weighted and summed. The CVE security scoring uses the CVSS vulnerability scoring system. The license compliance scoring is determined internally based on the type of open-source license, its constraints, and its potential impact on business. The overall score is calculated by weighting the scores from the two dimensions, as shown in the following formula: Overall score = CVE security score × CVE weight + License compliance score × License weight; CVE weight and license weight: These are set internally based on the emphasis on security and compliance, and the sum of their weights is 1. All cross-module interfaces throughout the entire process carry work order IDs and fingerprints, forming a traceable link through log records. When submitting a transfer application in the red zone, the product version number, compilation log, product fingerprint, corresponding source code fingerprint, and work order ID are submitted simultaneously. The gateway prohibits reverse data flow and triggers fingerprint verification during cross-domain transmission; if the fingerprints do not match, the transmission is blocked. It also includes establishing hierarchical caches in the red, yellow, and blue zones and storing corresponding fingerprint information to achieve end-to-end data traceability.

2. The R&D data access and exit control method based on red-yellow-blue partitioning according to claim 1, characterized in that: Both the reference fingerprint and the actual fingerprint are data hash values ​​generated using the SHA-256 algorithm.

3. The R&D data access and exit control method based on red-yellow-blue partitioning according to claim 1, characterized in that: The security scan is a targeted scan, which only detects risk points related to the current CVE vulnerability.

4. The R&D data access and exit control method based on red-yellow-blue partitioning according to claim 1, characterized in that: The red, yellow, and blue zones are physically isolated and data is transmitted in one direction via a dedicated network gateway, preventing reverse data flow.

5. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by a processor, it causes the processor to perform the steps of the method as described in any one of claims 1 to 4.

6. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the computer program is executed by the processor, it causes the processor to perform the steps of the method as described in any one of claims 1 to 4.

Images