As vehicles are becoming increasingly dependent on software, automotive software teams are adopting CI/CD (continuous integration and continuous deployment/delivery). This enables them to build, test, and deploy code faster than ever while simultaneously reducing potential maintenance costs.
In automotive projects, functional and security bugs can be highly consequential, especially if they are found in the later stages of software development or, even worse, after shipping. Large parts of the industry are therefore integrating automated testing procedures directly into CI/CD pipelines. This way, the code base is automatically and continuously tested starting in the early stages of the SDLC.
In this article, I will evaluate how CI/CD-integrated security testing fits into automotive software development and look at how it can help automotive companies comply with norms and standards.
.webp?width=714&height=373&name=Embedded%20Blog%20Thumbnails%20(9).webp)
Embedded Software Development Is Shifting Towards Continuous Integration
Embedded software development is shifting to CI/CD for faster build, test, and deployment cycles. Previously, embedded developers had to contend with long build times and manual testing.
Automation eliminates repetitive tasks and helps to streamline the whole process. It also makes it easier for teams to work on projects collaboratively by allowing them to share code and test results quickly.
Why Automotive Needs CI/CD-Integrated Security Testing
It’s no secret that software is eating the automotive industry. What used to be simple contained systems now controls crucial functions within vehicles and is connected to the outside.
How Does DevSecOps Fit Into Automotive?
To deal with the rising complexity, automotive software testing processes are being revised throughout the entire industry. Traditionally, automotive software has been tested at the later stages of the development process in a dedicated testing phase. Late-stage testing presents developers with unique challenges, as it requires them to find and fix vulnerabilities that have been in the codebase for a long time, making it difficult to understand the erroneous code. Also, bug fixes become more expensive with each phase of the development process that they pass through undetected due to consequential errors.
DevSecOps and CI/CD-integrated software testing represent a new way of automotive software development. Using automated testing tools, these approaches allow automotive developers to test for security and functional issues on their own, starting in the early stages of the development process. This way, developers no longer have to wait for external pentesters to come in later, and they can fix bugs themselves while they are still mentally invested in the erroneous code.
The Benefits of Feedback-Based Fuzz Testing for Automotive DevSecOps
Feedback-Based Fuzzing is one of the most popular methods for CI/CD-integrated software testing. It’s increasingly finding adoption in embedded security testing due to its ability to uncover issues in memory-unsafe languages such as C/C++. Click here if you are not yet familiar with the technology. If you are, you will find some of the benefits of feedback-based fuzzing for automotive DevSecOps below.
1. Testing at Each Pull Request
Modern fuzz testing tools allow for automated software testing at each pull request (or at each code change, depending on configuration). Each time a developer merges their changes to main, a modern fuzzer can automatically test the changes for bugs. If it finds something, the developer can fix the issue right away, as fuzzing always provides the crashing input. This way, issues can be fixed long before they become difficult and expensive to alleviate.
For example, fuzz testing can detect:
- Denial of services
- Memory safety issues
- Uncaught exceptions
2. Maximize and Monitor Code Coverage
Code coverage is an essential metric for evaluating the effectiveness of any test. Without accurate code coverage measurements, it is difficult to determine which parts of an application test inputs have reached. The importance of measuring code coverage lies in its ability to uncover missing permissions, roadblocks, and other issues that can lead to low coverage that tend to be overlooked. In feedback-based fuzzing, code coverage is what guides test inputs. This enables detailed measurements and substantially helps with the interpretation of test results.
3. Reproduce All Findings
Fuzz testing is a dynamic testing approach, meaning that the software under test is executed during testing. While static testing approaches tend to dig up large amounts of false-positive test results that have to be weeded out manually, findings from fuzzing are reproducible. As fuzzing tools provide developers with the crashing input, bug fixes are easy to implement. Some fuzzing tools even enable developers to jump straight from the findings dashboard to the buggy section of the source code.
| What Is Feedback-Based Fuzzing? Fuzzing is a type of security testing that involves feeding random inputs, known as "fuzzy inputs" into the system to expose potential vulnerabilities. Feedback-based fuzzers use information from previous test runs to actively mutate test cases. With the help of these intelligent mutations, feedback-based fuzzers can come up with unexpected or unusual test inputs that can trigger deeply hidden bugs and vulnerabilities. |
Automated Fuzz Testing for Automotive With CI Fuzz
CI Fuzz is an enterprise platform for automated and CI/CD-integrated fuzz testing. Companies such as CARIAD, Continental, and Woven Planet already use it to enhance software security in modern vehicles. If you want to learn more, you can always jump on a call with us or check out our guided product tour.
If you're interested in exploring fuzz testing for your automotive CI/CD pipeline, you can try our open-source CLI tool, CI Fuzz (available in C/C++), which offers all the core functionality of CI Fuzz minus the enterprise reporting features.
