The Role of Static Analysis in the SAE J3061 Cybersecurity Process Framework

The Society of Automotive Engineers (SAE) J3061 cybersecurity process framework was created to address a large disconnect between advances in automotive software and the increasing security threat posed to automobiles. A modern automobile can have as much as 100 million lines of code, far more than a commercial airliner cockpit. As software starts to become more and more critical in terms of safety with an active role in controlling the vehicle, safety and security are more critical than previous generations.

A study commissioned by the SAE found that 84% of software developers had concerns about their cybersecurity practices, 30% of manufacturers did not have any cybersecurity team or program and less that 50% of their hardware and software was tested for security vulnerabilities.

Another key finding of the study was that vulnerabilities were being assessed very late in the product lifecycle with a vast majority of organizations doing so in post-release phase of the product. Leaving this critical aspect of security until after it is almost complete is expensive and time consuming and is contrary to most security processes, including SAE J3061. Further, as many as 25% of teams are doing no testing for security vulnerabilities and a majority are testing less than half of their hardware and software properly.

Improving Automotive Software Security

The SAE J3061 is a process framework designed to integrate with similar frameworks for safety critical software like ISO 26262. In simple terms, the framework requires security to be built in from the very early stages of product development and that risk assessment include cybersecurity and security be embedded in the requirements of the product. Whereas safety standards are concerned with hazards and mechanisms to mitigate the risk to people and property, cybersecurity is concerned with threats posed by malicious attackers with a goal to cause harm, gain financial benefits or notoriety. A focus on vulnerabilities rather than possible failures. Also, security and, in turn, protection of privacy of personally identifiable information (PII) goes beyond safety critical systems in the automobile to infotainment and other systems.

Security Goes Beyond Safety Critical Systems

The J3061 framework includes guidelines for protecting customer’s privacy in all technology in the automobile. This goes beyond the safety critical systems to include infotainment and even comfort settings. For manufacturers this requires more rigor in the development of these systems than they are accustomed to in previous generations of automobiles. The increase in technology in the cockpit, connectivity to personal device and the Internet necessitates a more serious look at security and privacy.

SAE J3061 addresses this concern by explicitly stating that all safety critical systems are security critical since an attack can directly or indirectly lead to potential safety concerns. However, not all security critical systems are safety critical resulting in the following representation:

Source: SAE Vehicle Electrical System Security Committee: Overview of SAE J3061™ webinar

Despite different concerns of cybersecurity and safety, the goals are the same, to minimize risks to drivers and passengers. Security is more concerned with analyzing threats, managing the risk associated with these attacks and implemented controls and mechanism to mitigate the risk as much as possible. The guiding principles of J3061 are similar to other cybersecurity standards with an emphasis on understanding the security risks through threat analysis during the earliest stages of development. Managing these risks and implementing best practices throughout concept, design, and implementation and testing. Cybersecurity is important in all phases of development including production and use and end of life.

Parallel Roles of Static Analysis in J3061 and ISO 26262

SAE J3061 doesn’t explicitly require software tools and automation although, in reality, it would be difficult for developers to comply with the guidelines without tool support. Software development tools such as static analysis aren’t applicable in all phases of the secure software development lifecycle but do play an important role in implementation and testing phases. In addition, static analysis tools are helpful in evaluating third party and open source software which might introduce unknown risks into the project.

Specific guidelines in the SAE J3061 guidelines that benefit from static analysis are found in section 8.6 “Product Development at the Software Level.” In particular the sections that deal with vulnerability analysis, implementation, code reviews and test are well suited to the use of static analysis. The following table summarizes the role of static analysis in each case:

Static analysis tools are useful in augmenting existing implementation and testing practices and are meant to provide an additional source of discovery for defects and vulnerabilities. Consider the following strengths of static analysis tools which apply for both safety critical development (e.g. complying with ISO 26262) and security processes in SAE J3061.

• Enforcing coding standards for safety, security, and style. Automating code analysis during code development ensures quality in the development stream every day.
• Reducing manual effort in proving software robustness and behavior. Static analysis tools augment software testing by providing more assurance of software quality.
• Reducing number of defects throughout development. Code that works the first time is much cheaper to test and integrate than buggy code. Bugs removed from the code before testing (or even source configuration management) reduces costs and risk.
• Finding serious defects that elude testing. Software testing for safety critical systems is exhaustive and, depending on the level of concern (ASIL in ISO 26262), require complete statement and or decision coverage. Despite this testing rigor, static analysis tools have found defects that were missed. These are the most worrisome types of defects – is it really worth the risk of letting these bugs go into a shipping product?
• Analyzing Legacy and Third Party Code. Use of third party code such as commercial off-the-shelf software (COTS) and open-source software is a fact of life in embedded software development. Static analysis tools can analyze third-party source and binaries to discover defects and security vulnerabilities in software that could be impossible to test otherwise (without including it and running it, an expensive option).
• Accelerating certification evidence. Documenting the results of software unit acceptance is critical to proving compliance to certification standards. Static analysis tools have rich reporting features to help support certification requirements.

In addition static analysis tools help with vulnerability detection and discovery which is part of the product development guidance in SAE J3061. For example, static analysis tools provide the following capabilities:

• Early vulnerability detection and prevention: Static analysis tools such as GrammaTech CodeSonar are integrated with developer’s development environment and project build systems. Early detection of poor security practices and possible vulnerabilities are detected as soon as the code is written. Preventing these kinds of security issues before they enter code repositories or unit testing saves downstream resources.

• Continuous source code assessment: Static analysis is often applied initially to a large code base as part of its initial integration, however where it really shines is after an initial code quality and security baseline is established. As each new code block is written (file or function), it can be scanned by the static analysis tools and developers can deal with the errors and warnings quickly and efficiently before checking code into the build system.

• Tainted data detection and analysis: Analysis of the data flows from sources (i.e. interfaces) to sinks (where data gets used in a program) is critical in detecting potential vulnerabilities from tainted data. Any input, whether from a user interface or network connection, if used unchecked, is a potential security vulnerability. Code injection and data leakage are possible outcomes of these attacks which can have serious consequences.

• Third-party binary code assessment: Static analysis is particularly suited to analyzing large code bases and providing meaningful errors and warnings that indicate both security and quality issues. CodeSonar binary analysis can analyze binary-only libraries and provide similar reports as source analysis when source is not available. In addition, CodeSonar’s binary analysis can work in a mixed source and binary mode to detect errors in the usage of external binary libraries from the source code.

• Secure Coding standard enforcement: Static analysis tools analyze source syntax and can be used to enforce coding standards. Various code security guidelines are available such as SEI CERT C and Microsoft’s Secure Coding Guidelines or MISRA C and C++. The future merger of AUTOSAR C++ and MISRA C++ coding standards should provided better guidance on security and safety.

Summary

Clearly there is an important role for static analysis in the development of safe and secure automobile software. Although not explicitly called out in either ISO 26262 or SAE J3061, static analysis tools help software development team follow the guidelines of both standards for ensuring software quality, safety and security. Used in conjunction with other tools, static analysis helps automate the detection and prevention of vulnerabilities in some cases before they enter the code repository. These tools also assist in demonstrating due diligence of manufactures to certifying authorities by following industry best practices and preventative methods.