Software release method for embedded development security operation and maintenance software

Abstract

The invention provides a software release method for embedded development security operation and maintenance software, which comprises the following steps of: performing security check on submitted incremental codes according to selected security item configuration; if the incremental code meets the standard of security check before warehousing, the submitted incremental code is stored in a code library, and the code in the code library is subjected to security check after warehousing; security compiling construction of the codes is automatically executed, if security compiling construction succeeds, a compiled file is generated, and dynamic security testing and binary product traceability analysis are conducted on the compiled file; if the compiled file meets the standards of the dynamic security test and the binary product traceability analysis, judging whether the compiled file needs to be subjected to software containerization processing or not, and if the software containerization processing is successful, taking the containerized file as the compiled file; the data in the controlled library are subjected to software product acceptance processing and then stored in a product library, and the data in the product library are deployed in airborne equipment.

Description

Technical Field

[0001] The present invention relates to the technical field of software operation and maintenance, and in particular to a software publishing method for embedded development security operation and maintenance software. Background Art

[0002] As the functions of embedded software continue to increase and technical capabilities continue to improve, the amount of code and possible defects also increase relatively. In order to ensure the release of embedded software, improve the quality and delivery speed of embedded software, combine the development of security operation and maintenance methods, integrate DevOps and DevSecOps concepts into the embedded software release process, combine general software field tools, automate the transformation of embedded field tools or independently develop them, automate the software development process from code development to product delivery, and perform security management and control in the process to reduce manual operations and ensure the quality and functionality of the code in each agile iteration cycle. Summary of the invention

[0003] In view of this, the embodiments of this specification provide a software release method for embedded development security operation and maintenance software. The method is to achieve the continuous release capability of embedded software through automated processes and security configurations, and to find defects and problems in the code as early as possible in the early stages of development through automation, so as to improve the quality of embedded software and accelerate the speed of software delivery.

[0004] The embodiments of this specification provide the following technical solutions:

[0005] A software release method for embedded development security operation and maintenance software, comprising:

[0006] Perform security checks on the submitted incremental code according to the selected security configuration;

[0007] If the incremental code meets the standards for the pre-storage security check, the submitted incremental code is saved in the code library, and the start conditions for the security check of all codes after the code is stored are set. According to the start conditions, a post-storage security check is performed on all codes in the code library;

[0008] If all the codes in the code base meet the standards of the post-entry security check, the code security compilation and construction will be automatically performed. If the security compilation and construction is successful, the compiled files will be generated, and dynamic security testing and binary product traceability analysis will be performed on the compiled files.

[0009] If the compiled file meets the standards of dynamic security testing and binary product traceability analysis, determine whether the compiled file needs to be processed as a software container. If necessary, the compiled file is processed as a software container. If the software containerization is successful, the containerized file is used as the compiled file.

[0010] Perform software binary version management on compiled files, save compiled files to a controlled library, perform software product acceptance processing on data in the controlled library and save them to the product library, and deploy data in the product library to airborne devices.

[0011] Furthermore, the incremental code is subject to security checks before storage, including:

[0012] Setting a first error rate threshold, performing a first static white box test and a code duplication check process on the incremental code respectively, and taking the sum of the error rates of the first static white box test and the code duplication check process as the first error rate;

[0013] If the first error rate is less than the first error rate threshold, it is determined that the incremental code meets the standards of the pre-warehousing security check;

[0014] If the first error rate is greater than or equal to the first error rate threshold, alarm and error processing are initiated and subsequent processing is stopped.

[0015] Furthermore, all codes in the code base are subject to security checks after entry, including:

[0016] Set a second error rate threshold, perform a second static white box test and overall code tracing processing on the code in the code base respectively, and take the sum of the error rates of the second static white box test and the overall code tracing processing as the second error rate;

[0017] If the second error rate is less than the second error rate threshold, it is determined that the code in the code library meets the criteria for security inspection after storage;

[0018] If the second error rate is greater than or equal to the second error rate threshold, alarm and error processing are initiated and subsequent processing is stopped.

[0019] Furthermore, dynamic security testing and binary artifact traceability analysis are performed on the compiled files, including:

[0020] Set a third error rate threshold, perform dynamic security testing and binary product traceability analysis on the compiled file, and take the sum of the error rates of the dynamic security testing and binary product traceability analysis as the third error rate;

[0021] If the third error rate is less than the third error rate threshold, determining that the compiled file complies with the standards of dynamic security testing and binary product traceability analysis;

[0022] If the third error rate is greater than or equal to the third error rate threshold, alarm and error processing are initiated and subsequent processing is stopped.

[0023] Furthermore, the compiled files are processed into software containers, including:

[0024] Determine whether the compiled file needs to be processed as a software container;

[0025] If necessary, scan the Dockerfile configuration file and the image file of the software container, and use the sum of the error ratios of the scanned Dockerfile configuration file and the image file as the fourth error rate;

[0026] Setting a fourth error rate threshold, and if the fourth error rate is less than the fourth error rate threshold, determining that the software containerization is successful;

[0027] If the fourth error rate is greater than or equal to the fourth error rate threshold, alarm and error processing are initiated and subsequent processing is stopped.

[0028] Furthermore, enable warning and error handling, including:

[0029] Obtain error information for pre-warehousing security checks, post-warehousing security checks, secure compilation and construction, dynamic security testing and binary product traceability analysis, software containerization processing, and software binary version management, where the error information includes the specific cause of the error, the code corresponding to the error, and the type of error;

[0030] The error information is saved as a new problem item and published to the software quality management software, and an alarm message is issued through the software quality management software.

[0031] Furthermore, it also includes:

[0032] Manually review the incremental code before submitting it to the code base;

[0033] If the manual review is successful, the incremental code will be submitted to the code base.

[0034] Furthermore, it also includes:

[0035] After saving the data in the controlled library to the product library, verify the authority of the personnel operating the product library;

[0036] If the authority meets the requirements for operating the artifact library, extract the software artifact from the artifact library and verify the software artifact;

[0037] If the software artifact verification is successful, the data in the artifact library will be deployed to the onboard device.

[0038] Furthermore, it also includes:

[0039] If the acceptance process fails, alarm and error handling are initiated.

[0040] Compared with the prior art, the at least one technical solution adopted in the embodiments of this specification can achieve the following beneficial effects:

[0041] Through automated processes and secure configurations, we can achieve the continuous release capability of embedded software. Through automation, we can find defects and problems in the code as early as possible in the early stages of development to improve the quality of embedded software and speed up software delivery. BRIEF DESCRIPTION OF THE DRAWINGS

[0042] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings required for use in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative work.

[0043] Figure 1 It is a flowchart of a software publishing method for embedded development security operation and maintenance software according to an embodiment of the present invention. DETAILED DESCRIPTION

[0044] The embodiments of the present application are described in detail below with reference to the accompanying drawings.

[0045] It should be noted that, in the absence of conflict, the embodiments and features in the embodiments of the present application can be combined with each other. The present invention will be described in detail below with reference to the accompanying drawings and in combination with the embodiments.

[0046] like Figure 1 As shown, the software release method includes:

[0047] Security check before entering the code repository: Through modular check, select and set security configuration items before entering the code repository. The code is incrementally submitted to the code repository for static white box testing (SAST) and code duplication detection (SCA), namely, programming specification scanning (such as MISRA C), common vulnerability library scanning and code duplication comparison in the library, and configure specific thresholds. The unified management and configuration of the code is carried out in the Git code repository. After the developer obtains a basic version of the code to start development, after the merge branch request is made for the newly developed code, the configuration-based programming specification scanning and code duplication comparison are started. Only the code within the acceptable threshold (the first error rate threshold) can enter the next step of the code merge request, manual code review. The security check at this stage is generally for the developer to submit the code and wait for the results to be displayed quickly on the screen, so the check is preliminary, the detection range is certain, and the results are produced quickly. For those that exceed the acceptable threshold range, the code submission fails, an alarm is issued, and an issue item (Issue) is created to record the details of this failure, requiring the developer to modify the code again (implemented through software quality management software). Only codes that have passed automatic security checks and manual code reviews are allowed into the repository.

[0048] Security check after entering the code base: After the code enters the code base, it enters the code static testing phase. According to the startup conditions set by the pipeline management configuration personnel and the specific thresholds, detailed static white box testing (SAST) and overall code traceability (SCA) are implemented at a fixed time every day to detect defects in various vulnerability libraries in the industry, compare various open source code bases, open source license management, generate code reference relationship trees, etc., to ensure coding security through security left shift, detect common vulnerabilities, and facilitate daily confirmation of false positive content processing. Time-consuming work is completed during the developer's rest time to reduce the developer's waiting time. The security check results after the code is entered into the library are quickly obtained according to the threshold (the second error rate threshold). If the failure rate reaches the set threshold, an alarm is issued and an issue item (Issue) is created to record the detailed results and logs of this inspection, which is convenient for developers to modify the code. If the failure rate is less than the set value, it enters the construction phase.

[0049] Automated security build, through automated script commands to achieve embedded language (such as C / C++) compilation and construction, this process is generally based on GCC and other methods to achieve security configuration, such as enabling FORTIFY, CANARY, NX (DEP), RELRO, etc. to ensure safe compilation and construction, build failure to issue an alarm and create an issue to record the results and logs of this build, to facilitate developers to modify the code. If the build is successful, it will enter the dynamic test phase.

[0050] During the testing phase, unit testing, integration testing, dynamic security detection and binary artifact traceability analysis SCA are connected. By running the software to input different data and operations to check whether the program results meet expectations. For non-embedded code, common dynamic application security testing (DAST), such as Web application detection and Web API detection, cannot be used, because many embedded products are not Web products, and malicious damage simulation is required according to product characteristics. This requires higher requirements for embedded software testing teams. Common interface application security testing (IAST), because the core technology is plugging, C / C++ language support for plugging technology is still relatively weak, so the embedded software testing team needs to continuously update and integrate technology to achieve dynamic security defects and vulnerability mining. At present, the binary software formed after the embedded code is compiled can be combined with the binary traceability analysis SCA function to check the binary artifacts, set the qualified threshold, and realize the security check before entering the product library. If the test failure rate reaches the set threshold (the third error rate threshold), an alarm is issued and an issue item (Issue) is created to record the detailed results and logs of this test, which is convenient for developers to modify the code. If the failure rate is less than the set value, it will enter the release stage.

[0051] The release phase requires software containerization or software binary version management, and the complete and correct software products (security is ensured by signatures, certificates, and encryption) are placed in a controlled library through a secure means. In order to ensure the safety of the containerization process, it is necessary to scan the software container Dockerfile configuration file. Only images that meet the qualified threshold requirements (that is, meet the (fourth error rate threshold)) can be included in the controlled library. If they do not meet the requirements, an alarm needs to be issued and an issue item (Issue) needs to be created to record the reasons for non-compliance. Among them, the scanning of the Dockerfile configuration file and the image file includes the scanning of image build errors, image layer errors, dependency errors, and image security vulnerabilities. The error rate of the above problems is recorded as the fourth error rate through the scanning tool.

[0052] The products placed in the controlled library are regularly scanned for security vulnerabilities, and acceptance tests are performed, and manual approval is set. Only software products that meet the acceptance test cases and pass the manual approval can enter the product library from the software controlled library and enter the deployment stage. If the requirements are not met, an alarm needs to be issued and an issue item (Issue) needs to be created to record the reasons for non-compliance.

[0053] During the deployment phase, only personnel who have been granted designated permissions and passed verification can obtain software products from the software product library. Personnel without permission will only receive an alert. After obtaining the product, the integrity and correctness of the software product must be verified first. Only those that pass the integrity verification can be used.

[0054] In one embodiment of the present invention, the error type, error cause, error location, and error detection link are extracted from the issue item (Issue), and the error solution is summarized. The existing problem defect library is constructed by RAG technology. The existing problem defect library is used to store the error type, error cause, error location, error detection link, and error solution.

[0055] By utilizing the extended functions of the AI ​​big model, the existing problem defect library is used as a training set to train the AI ​​big model and generate a customized dedicated AI model. The customized dedicated AI model is used to match and query new errors to obtain solutions to the errors.

[0056] Specifically, by sorting out and summarizing various problems and defects of the product, it is necessary to combine machine learning and AI algorithms for data analysis when necessary. Because the process records the characteristics, solutions and root causes of each problem defect, the existing problem defect library is then constructed through RAG technology, and fine-tuned in combination with the AI ​​large model to form a special field problem defect library and a special model. Retrieval of new problems makes it easier to find solutions to similar problems and defects. Among them, RAG technology, namely Retrieval-Augmented Generation, is an artificial intelligence technology that combines information retrieval technology with language generation models. This technology retrieves relevant information from an external knowledge base and inputs it as a prompt to a large language model (LLMs) to enhance the model's ability to handle knowledge-intensive tasks, such as question and answer, text summarization, and content generation.

[0057] Beneficial effects of the embodiments of the present invention:

[0058] Through automated processes and secure configurations, we can achieve the continuous release capability of embedded software. Through automation, we can find defects and problems in the code as early as possible in the early stages of development to improve the quality of embedded software and speed up software delivery.

[0059] The above is only a specific embodiment of the present invention, and cannot be used to limit the scope of the invention. Therefore, the replacement of equivalent components, or equivalent changes and modifications made according to the scope of protection of the patent of the present invention, should still fall within the scope of this patent. In addition, the technical features of the present invention can be freely combined with each other, with each other, and with each other.

Claims

1. A software publishing method for embedded development security operation and maintenance software, characterized in that: include: Perform security checks on the submitted incremental code based on the selected security item configuration; If the incremental code meets the standards of the pre-warehousing security check, the submitted incremental code is saved in the code library, and the start conditions for the security check of all codes after the code is stored are set. According to the start conditions, the post-warehousing security check is performed on all codes in the code library; If all codes in the code library meet the standards of the post-entry security check, the code security compilation and construction is automatically performed. If the security compilation and construction is successful, a compiled file is generated, and dynamic security testing and binary product traceability analysis are performed on the compiled file; If the compiled file meets the standards of dynamic security testing and binary product traceability analysis, determine whether the compiled file needs to be processed as a software container. If necessary, perform software containerization on the compiled file. If the software containerization is successful, use the containerized file as the compiled file. The compiled file is managed as a software binary version, the compiled file is saved in a controlled library, the data in the controlled library is processed as a software product for acceptance and then saved in a product library, and the data in the product library is deployed to the airborne device.

2. The software publishing method for embedded development security operation and maintenance software according to claim 1, characterized in that: A security check is performed on the incremental code before storage, including: Setting a first error rate threshold, performing a first static white box test and a code duplication check process on the incremental code respectively, and taking the sum of the error rates of the first static white box test and the code duplication check process as the first error rate; If the first error rate is less than the first error rate threshold, it is determined that the incremental code meets the standard of the pre-warehousing security check; If the first error rate is greater than or equal to the first error rate threshold, alarm and error processing are initiated and subsequent processing is stopped.

3. The software publishing method for embedded development security operation and maintenance software according to claim 1, characterized in that: Perform a post-entry security check on all codes in the code repository, including: Setting a second error rate threshold, performing a second static white box test and an overall code tracing process on all codes in the code base respectively, and taking the sum of the error rates of the second static white box test and the overall code tracing process as the second error rate; If the second error rate is less than the second error rate threshold, it is determined that the code in the code library meets the standard of the post-storage security check; If the second error rate is greater than or equal to the second error rate threshold, alarm and error processing are initiated and subsequent processing is stopped.

4. The software publishing method for embedded development security operation and maintenance software according to claim 1, characterized in that: Perform dynamic security testing and binary artifact traceability analysis on the compiled file, including: Setting a third error rate threshold, performing dynamic security testing and binary product traceability analysis on the compiled file respectively, and taking the sum of the error rates of the dynamic security testing and the binary product traceability analysis as the third error rate; If the third error rate is less than the third error rate threshold, determining that the compiled file complies with the standards of dynamic security testing and binary product traceability analysis; If the third error rate is greater than or equal to the third error rate threshold, alarm and error processing are initiated and subsequent processing is stopped.

5. The software publishing method for embedded development security operation and maintenance software according to claim 1, characterized in that: The compiled file is subjected to software containerization processing, including: Determining whether the compiled file needs to be processed as a software container; If necessary, scan the Dockerfile configuration file and the image file of the software container, and use the sum of the error ratios of the scanned Dockerfile configuration file and the image file as the fourth error rate; Setting a fourth error rate threshold, and if the fourth error rate is less than the fourth error rate threshold, determining that the software containerization is successful; If the fourth error rate is greater than or equal to the fourth error rate threshold, alarm and error processing are initiated and subsequent processing is stopped.

6. The software publishing method for embedded development security operation and maintenance software according to any one of claims 1 to 5, characterized in that: Enable warning and error handling, including: Obtain error information of the pre-warehousing security check, the post-warehousing security check, the secure compilation and construction, the dynamic security test and binary product traceability analysis, the software containerization processing, and the software binary version management, wherein the error information includes the specific cause of the error, the code corresponding to the error, and the type of error; The error information is saved as a new problem item and published to the software quality management software, and an alarm message is issued through the software quality management software.

7. The software publishing method for embedded development security operation and maintenance software according to any one of claims 1 to 5, characterized in that: Also includes: Before submitting the incremental code to the code repository, manually reviewing the incremental code; If the manual review is successful, the incremental code is submitted to the code base.

8. The software publishing method for embedded development security operation and maintenance software according to any one of claims 1 to 5, characterized in that: Also includes: After the data in the controlled library is saved in the product library, the authority of the person operating the product library is verified; If the permission meets the requirement of operating the artifact library, extract the software artifact from the artifact library and verify the software artifact; If the software product is successfully verified, the data in the product library is deployed to the onboard device.

9. The method for releasing software for embedded development security operation and maintenance software according to any one of claims 1 to 5, characterized in that: Also includes: If the acceptance process fails, alarm and error processing are initiated.

Images