This article is compiled from Mr. Zhang Yang, Director of Jihu GitLab Solution Department, who shared the theme "Riding the Wave of Code Surge and Escorting Software-Defined Cars" at the AUTOSEMO conference.
Challenges of software-defined cars
“Software eats the world”, this is what Netscape founder Marc Andreessen said in 2011. The rapid development of the software industry in recent years has also verified this sentence. Smartphones are a very vivid example. Various apps have completely changed people's daily necessities.
For the automotive industry, it has also entered the era of software-defined cars. In the field of smart cars, software costs account for an increasing proportion of car costs, and the value brought by software is reshaping the entire smart car business model . As shown in the smile curve below, more interesting business models that can bring value are emerging at both ends of the entire automotive industry chain.
Take a typical example: software subscription system. In the early car sales model, the purchase and sale of vehicles was basically a "one-time sale." After the vehicle was sold, it was difficult for the OEM manufacturer to earn the user's money (except for some possible maintenance). However, under the software subscription model, if the user wants to use a certain function of the car (such as autonomous driving, remote automatic start and stop of air conditioning, etc.), he can do so by subscribing to the car software. A one-month subscription gives you one month's use. If you no longer want to use it, just cancel the subscription. The advantage of this is that users have the right to make free choices and can "customize" some functions of the car through software according to their own needs. OEM manufacturers not only increase stickiness with users in this way, but also add a new feature that allows them to Ways for companies to continue to increase revenue.
Software defines cars, so what defines software? The answer is: code. The basis for running software is code, and in the context of software-defined cars, according to statistics from professional organizations: a smart car has about 100 million lines of code, which is much larger than large passenger aircraft (about 15 million lines) and fighter jets. (about 25 million lines) and the code amount of some well-known operating systems (such as Windows Vista, about 40 million lines). And these are the data for 2020. With the booming development of smart driving, this data may reach a staggering 500 million in 2025 .
In addition, as can be seen from the figure below, under the traditional software development model, the number of defects (including quality and safety issues) introduced during the coding phase is the largest (85%), but the real discovery of a large number of defects is in the post-coding stage. This situation brings two problems:
-
The repair of defects is delayed, and feedback on problems is slow, resulting in a relatively long repair cycle;
-
The cost of repair is high. As can be seen from the figure, the repair cost for defects introduced during the coding stage is the lowest, while the repair cost for defects discovered while the software is running is extremely high, about 640 times that of the coding stage.
This situation is even more severe for automotive software, and with the development of smart cars, the challenges posed by this surge in code volume are huge. This is a problem for OEMs, Tier 1 or those who deal with software in the entire automotive software ecosystem. This is the same for all organizations.
How to deal with the challenge of code explosion
Software in the automotive industry is different from software in the general industry. In some cases, the delivery speed can be a little slower and the cost is a little higher, but security is a red line that can never be compromised. " Software can be restarted, but life cannot be restarted ." Security is the biggest challenge that the proliferation of codes poses to automotive software.
How to ensure software security?
Let’s give two examples first. The first one is the Boeing 737 Max aircraft. As we all know, the 737 Max has been involved in two accidents before. Later, there was speculation that the accident may be related to a software on the aircraft that prevents the aircraft from stalling and losing control. Because of this problem, a large number of 737 Max aircraft were grounded, and many confirmed orders were cancelled. If this kind of thing happened in the automobile industry, no car company would be able to bear the recall, suspension or even suspension of sales due to car software problems. And once a topic like personal safety is involved, the impact of public opinion may be devastating to car companies.
The second is the log4j vulnerability event of "epic vulnerability". log4j is an open source component with users all over the world, so when a vulnerability was disclosed, it affected many users around the world. This is actually a typical open source software supply chain security issue.
In order to cope with the challenges brought by functional safety and information security, there are many standards or specifications for reference in the automotive software R&D industry or security field, such as ISO 26262, MISRA, AUTOSAR, OWASP Top10, and CWE Top 25. Through these standards or specifications Improving the quality and safety of automotive software.
In addition, there is another point to note, which is a new concept with the arrival of the era of software-defined cars-SBOM. SBOM is a software bill of materials, a component list of software. The main issue SBOM deals with is the security of the open source software supply chain . With the current increase in the adoption rate of open source, few companies have built all systems from scratch. They basically use some open source frameworks or libraries to accelerate the construction of their own products. This brings up a question: How to ensure the security compliance of these open source components used or referenced? If the open source components used contain some malicious code or even some high-risk vulnerabilities, the risk will be great. SBOM solves the above problems very well by taking inventory of corporate digital assets.
SBOM also solves another problem: license compliance. Jihu GitLab has many car company customers, and their business needs to be exported overseas. If the software license compliance issue is ignored during this process, it may cause the overseas business to be blocked. For example, the car company software contains some software that contains "strong contagion". "sexual" license (such as GPL), but the source code is not open. At this time, it actually violates some licensing features of these licenses. These are not allowed at home and abroad, and foreign countries are also facing globalization. Competition and related regulations are very strict.
It is not easy for Chinese companies to do business overseas. Many friends around the world are eyeing the opportunities for their opponents to make mistakes. License compliance is a very easy link in the software field. If a company has security issues due to license compliance, it will Enterprises going overseas will inevitably cause irreparable losses and major impacts.
So back to the response to the security compliance challenges brought about by the proliferation of code, there are three main solutions at the code level for reference.
The first part is code coverage testing, which falls under the category of unit testing. Unit testing is the best way to verify whether each part of the code (classes, functions, conditions, etc.) is working properly from a white-box perspective. It is also an important means to identify software problems in the early stages of software development. However, its shortcomings are also obvious, because these test codes also require technical personnel to write, which involves the investment of resources. However, with AIGC's continuous exploration and evolution in the software field, intelligent unit test code generation is not a fantasy and will eventually be realized in the near future. One thing to note is that unit testing needs to look at quantity, that is, some coverage of functions in the code, and quality, that is, coverage of conditional branches.
The second part is code static analysis . This part does not require R&D personnel to do many things. They only need to configure the corresponding tools or processes to check the code. The inspection mainly includes two parts: inspection of coding standards and code security inspection. Coding standards are to improve the maintainability of code and facilitate the continuous iterative evolution of software, while code security inspection can use SAST to do a scan to dig out potential security issues in the code;
The third part is the SBOM mentioned earlier. Use the SBOM list to analyze some vulnerability information and license information of third-party components.
The content of these three parts can be implemented in the coding and construction stages of the software life cycle, effectively helping the R&D team to solve software safety and quality-related issues as early as possible. This is the concept of security shift left in the DevSecOps system that we often mention .
The so-called security shift left means that security begins to intervene in the early stages of the software development life cycle. For example, in the coding stage or even earlier in the design stage, corresponding security measures are included. The value brought by this is: security issues Early detection, early repair, and lowest cost. So how to implement DevSecops?
The core points of safely moving left when landing
The first is a change in philosophy . Whether it is DevOps or DevSecOps, the main idea is to break down the barriers between various roles. This is completely different from the waterfall model (R&D → Test → Security → Operation and Maintenance). The DevSecOps model requires some initiatives to break down the walls between functional roles and allow all personnel to serve a unified goal.
For example, for R&D personnel, if a security vulnerability is found after writing and submitting the code, the security vulnerability needs to be repaired; for security personnel, it is necessary to set up security access control and clarify the management of these security issues, such as Not all discovered problems need to be repaired immediately, do all security issues need to be repaired, etc., but also the ability to communicate with R&D personnel to guide them to make some vulnerability repairs or improvements; for managers, In fact, it is a God's perspective, which requires an overall understanding of the automotive software to be released, and what its quality and safety are. So from a conceptual point of view, the implementation of DevSecOps actually requires the stringing together of these roles, and everyone collaborates to do a good job in security .
Of course, to achieve good collaboration among multiple roles, management alone is not enough. Ultimately, tools are needed to help achieve this. That is to say, we need to use tools to build an assembly line for the digital world. For example, the final output of the parts assembly line is a car, then the final output of the code assembly line is software, and the code assembly line is what everyone often talks about now as CI/CD. Therefore, in the future, car companies will have two production lines: the first is in the physical world or the industrial world, used to manufacture complete vehicles, and the other is a software assembly line, used to build the software required for enterprise operations .
This software pipeline requires tools to carry it. That means using tools to create a closed-loop pipeline.
The core thing is that after the developers submit the code, they must be able to automatically compile and build the code, test, security scan, etc. All these operations are highly automated and do not require too much human intervention. After all the automated steps are completed, R&D, testing, security and other personnel can find some data reports on security and quality at the code level, application level or obtained from various environments, and then continue to iterate based on the reported data. , which forms a complete pipeline closed loop.
After clarifying the concepts, methods and tools, the rest is implemented.
The Implementation Path of Safe Shift to the Left
The implementation practice of safe shift left mainly consists of three steps:
➤ Step one: solidify corporate R&D specifications
Enterprise R&D specifications should not only address coding quality, but also include security. For example, after R&D personnel complete local development, they need to submit the changed code into the database. What conditions must be met before the changed code can be included in the database? For example, ASPICE may pursue two-way traceability of requirements and code. Then companies can require R&D personnel to make one-to-one correspondence between code changes and requirement IDs when submitting code. In addition, some files containing key information must not be It should be pushed to the code base, and there are other branch management specifications that need to be followed.
There is "code access", and there is the corresponding "code access". The so-called "code access" refers to what standards the code developed by R&D personnel must meet when it is merged into the main branch, which involves code review. , which is the "code responsibility field" respected by the industry. This process needs to be safe and testers can review the changed code together. This can be done by viewing the CI/CD build results and data reports of the changed code. What ultimately needs to be ensured is that if the CI/CD build results fail, or the data reports It shows that the changed code has serious quality or security issues, then the code should not be merged, and as long as the code can be merged, it can be put online directly.
➤ Step 2: Continuous integration
Continuous integration means automating all the unit testing, quality scanning and security scanning mentioned earlier. It only requires manual configuration once to benefit the entire team. This process has nothing to do with programming languages and is suitable for car-side or cloud applications. It just needs to use automated means to string together the corresponding processes.
➤ Step 3: Efficient code review
If you want to solve more security or quality issues during the development phase, code review is an important means. This code review consists of two parts. The first part needs to be based on some data reports generated by the second step of continuous integration to judge whether the changed code complies with the company's own R&D standards, and these standards must be able to pass custom rules on the tool. To achieve practical implementation, and finally by including all people related to code quality and security into the review system, we will do a good job in code review; the second part is manual review, which is to dig out problems in the code with the naked eye. Of course, Jihu GitLab is currently also actively exploring the use of AIGC to implement automatic code review, such as scoring changed codes, pointing out problems in the code, giving suggested codes, etc.
Jihu GitLab integrated DevSecOps solution
Implementing DevSecOps is not something that can be accomplished with just one or two tools, because in the DevSecOps system, there are three roles that need to work together: R&D, security, and management personnel. The perspectives of these three roles are different. R&D personnel mainly write code, security personnel mainly judge security issues, and managers are more responsible for overall management. But one common touch point among the three is the code merge request, which is the part on the left side of the figure below: When the changed code needs to be merged, the changed code must be reviewed. Only in this process can all roles be aligned. , so every company should implement code review in the software development process.
It should be noted that this process also brings new challenges: the complexity of the tool chain . R&D, testing, operation and maintenance, project managers, etc. all have their own tools, and the result is a serious fragmentation between these tools. Jihu GitLab itself is an integrated DevSecOps platform that allows project managers, R&D, testing, operation and maintenance personnel to collaborate on a platform with a unified interactive interface. The capabilities provided by the ten integrated functions can Covers the entire process of general software development.
This integrated DevSecOps platform has four major advantages: integrity, uniformity, high performance and scalability.
integrity
Integrity refers to the 7 types of security scans built into GitLab, which can cover the entire software development life cycle. And one thing that needs special explanation is that when a certain security capability needs to be used, only two lines of code are needed to add security scanning to the CI/CD pipeline, which is basically available out of the box.
unity
Uniformity means that whether R&D, security or management personnel have corresponding security dashboards to view security-related data reports.
high performance
Jihu GitLab can carry out security scans of multiple security protection methods in parallel, which can greatly improve the efficiency of security scans.
Scalable
Scalability is a very important point. Although GitLab itself has a lot of built-in security capabilities, many times customers have some security tools they use. At this time, we can use the command line or API to integrate these tools into JiHu GitLab CI/CD pipeline, and as long as the output of these tools is in the JSON format that meets the requirements of JiHu GitLab, then the data can be visualized, embedded in MR or displayed in the dashboard. This is another value brought by Jihu GitLab, an open source and open product.
The value of GitLab DevSecOps
According to Forrester's research report, the ROI brought by using Jihu GitLab integrated DevSecOps platform is as high as 427%. There are many reasons. For example, enterprises do not need to purchase many tool chains. Correspondingly, they do not need too many people to maintain many tool chains. These two aspects can truly increase revenue and reduce expenditure or reduce costs and increase efficiency. In addition, due to the reduction of tool chains, the problem of data islands will no longer exist. All data related to software research and development will be on a unified platform. Enterprises can easily obtain these data to conduct performance analysis on the entire research and development process. Then take some measures to improve R&D efficiency.
In addition, Jihu GitLab provides Chinese users with fully localized enterprise-level service support, allowing users to achieve efficient and safe automotive software research and development through an integrated DevSecOps platform, helping car companies improve their competitiveness and go overseas.