AUTOSAR was developed in 2003 to address the explosion of automotive software, defining an open industry-standard for electronic vehicle architectures. Over the years AUTOSAR has evolved to meet emerging automotive use cases such as autonomous driving and vehicle-to-everything (V2X) connectivity, resulting in the creation of the AUTOSAR Adaptive Platform (Figure 1).

Although most safety-critical automotive software is still coded in the C language, the growing number and complexity of systems addressed by the AUTOSAR Adaptive Platform demand a transition to C++. While still fast, lightweight, and portable with a low level of abstraction, C++ supports object-oriented programming and other useful mechanisms for developing larger, more distributed systems.

Unfortunately, the last significant work in safety-critical C++ coding standards occurred roughly 10 years ago with the release of MISRA C++:2008. Not only has the C++ language progressed considerably since then with several new versions, the industry has also changed: Cybersecurity concerns, for instance, are now more real than ever before.

Hence, AUTOSAR recently updated MISRA C++:2008 for its own purposes with the AUTOSAR C++14 coding guidelines. AUTOSAR C++14 maintains the rules classification approach of MISRA C++:2008, but also relies heavily on work from ISO/IEC 14882:2014 to modernize C++ implementations up to the language’s 2014 version.

In addition, AUTOSAR C++14 provides traceability to other C++ standards, such as the CERT C++ Secure Coding Standard.

Proactive Automotive Software Security with CERT C++

CERT C++ is a product of Carnegie Mellon University’s Software Engineering Institute (SEI) and sets for a catalog of living rules and recommendations for the secure and reliable implementation of C++ code. Where MISRA C++ and AUTOSAR C++ were developed primarily with an emphasis on safety, the CERT C++ guidelines focus on security, and do so in a proactive rather than reactive manner.

Because security standards like Common Weakness Enumeration (CWE) and Open Web Application Security Project (OWASP) are driven largely by their respective lists of pressing vulnerabilities, they are, by their very nature, addressing the symptoms of bad coding practices rather than the bad code itself.

Here, CERT C++ and other SEI secure coding standards endeavor to minimize the creation of vulnerable code in the first place. This starts with a risk assessment framework that provides a scoring rubric for code that does not comply with a given rule or recommendation. Each CERT C++ rule or recommendation is assigned a priority based on Failure Mode, Effects, and Criticality Analysis (FMECA) defined in IEC 60812. If a section of code violates one of the CERT C++ rules or recommendations, its Severity, Likelihood, and Remediation Cost are scored on a scale of one to three.

• Severity indicates the seriousness of the rule being ignored, with values ranging from Low (one) to High (three)
• Likelihood indicates the probability of the violation leading to an exploitable vulnerability, with values ranging from Unlikely (one) to Likely (three)
• Remediation Cost indicates the expense of bringing code into compliance with the rule, with values ranging from High (one) to Low (three)

The three values for a given violation are then multiplied, resulting in a Level 1 (score of 12 to 27), Level 2 (score of six to nine), or Level 3 (score of one to four) flaw (Figure 2). These flaws can be detected automatically by static analysis tools with integrated unit testing such as Parasoft C/C++test.

“I like the SEI CERT secure coding standard for several reasons,” says Arthur Hicken, Chief Evangelist at Parasoft. “First, it’s much more focused on secure coding practices rather than just the symptoms – for example, always validating input is a secure coding practice, while SQL Injection is a symptom. CERT has analyzed which guidelines are most critical, can be analyzed soundly, and then separated into “rules” that should be followed, as well as “recommendations” that are less critical and/or less capable of sound analysis. This helps quickly trim static analysis findings to the most critical.

“In addition, CERT has created a risk assessment framework that helps further prioritize the static analysis findings for particular guidelines, taking into account inherent severity of the guideline, the difficulty of exploiting such an item, and the cost of remediating it,” Hicken continues. “With this you get very granular prioritization that helps you focus on what is most important, rather than dealing with a deluge of static analysis violations.

“CERT is preventative. It focuses more on if you write your code this way, what can you prevent. It’s saying that code is a safer subset of C to produce more safe and reliable code,” he adds.

The latest release of Parasoft C/C++test integrates a security dashboard for SEI CERT C compliance, which provides visualization and mapping of violations and their respective recommendations, as well as drilldown capabilities into specific issues (Figure 3). The ISO 26262-compliant version of Parasoft C/C++test also includes support for the AUTOSAR C++14 standard and integration with additional compilers and IDEs such as Texas Instruments’ Code Composer Studio.

Automotive Software Success Hinges on Safe and Secure

By now we’re all aware that modern high-end vehicles are driven by roughly 100 million lines of code. That’s more than Facebook, the Large Hadron Collider, and even a Boeing 787. As cars become more autonomous and connected, the amount of software in them will only increase.

Guidelines such as AUTOSAR C++14 bring safe C++ coding practices into the modern era in support of emerging automotive applications. With some of the advanced capabilities that AUTOSAR enables, however, come additional security concerns. A development mindset, and tools, that considers both safety and security will be critical to the auto industry’s continued progression.

“It’s a lot easier to secure bug-free software than buggy software,” Hicken says. “80 percent of security vulnerabilities are also quality issues. CERT is such a powerful tool because it treats the engineering problems, not their results.”