Look under the hood. Here’s why SCA is critical in the auto industry.

SCA, software composition analysis, is an acronym that should be just as familiar within and important to the automotive industry as MPG or RPM. Today, vehicles are software platforms, hosting 80–100 million lines of code.

Cars can have more than a dozen Linux-capable computers and nearly 100 other electronic control units. Systems commonly using such controls include navigation, speed monitoring, fuel efficiency tracking, in-vehicle-infotainment (IVI), and anti-lock braking (ABS). As advanced driver assistance systems (ADAS) and autonomous technologies evolve, software content — including open source — grows.

Open-source software (OSS) helps automotive companies create better software, faster and less expensively. OSS can deliver benefits, but it can also deliver security and vulnerability issues. With OSS use continuing to increase in the auto industry and with 50-70 percent of the automotive software stack originating in OSS, effective management of open-source license compliance and security risk becomes increasingly important. This article addresses the top considerations for evaluating and addressing your risk.

SCA Explained

Software composition analysis helps you manage your open source license compliance and obligation risks by addressing three business objectives: vulnerability management, license management, and component management. A comprehensive SCA program scans applications to evaluate where code comes from; builds an accurate software bill-of-materials (SBOM) to record where code is deployed in automotive products; and evaluates the quality of the open-source code and its associated licenses.

SCA drives an organization’s policies for managing OSS and third-party software, helping with attribution and compliance, guiding developers to preferred OSS components and encouraging best practices to stay in compliance. It can prevent and defend against potential vulnerabilities.
Critical Risks — for OEMs and Consumers

Let’s take a look at the risks that come with OSS usage. It begins in the software supply chain for manufacturers: automakers (OEMs) source components and subsystems from suppliers (Tier Is), who pull from hardware and software vendors (Tier IIs), potentially integrating thousands of open source projects.

With this comes the need to assure the quality of all integrated components and to manage millions of lines of open-source code — efficiently and cost-effectively. At the same time, OEMs must protect their own intellectual property. They need an accurate SBOM with the correct license and copyright information to protect against license compliance issues like copyright infringement and IP protection.

As components and subsystems are integrated into automobiles, automakers need to assure the quality of all components, both in order to guarantee safety for drivers and passengers and to protect their liability. To make sure that the vehicles are safe (and hopefully fun) to drive, OEMs must discover, manage, and remediate vulnerabilities in all types of software stacks. The goal: a differentiated driver experience, provided via value-added software, and support infrastructure (whether in vehicles, on mobile devices, or in the cloud).

6 Goals of SCA Programs in Automotive

SCA can help automakers know what’s in their code by addressing six goals of mitigating and managing risk:

1. Disclose all copyleft or restrictive licenses (for example, the GNU General Public License or GPL) found in vehicles’ systems,
2. Provide a full assessment of OSS compliance,
3. Confirm OSS code used in a supplier’s software development kits (SDKs) and components,
4. Determinize if you are shipping product with potentially vulnerable components (e.g. Open SSL and Apache Struts 2),
5. Create a software bill of materials (SBOM), which lists components in all software, and
6. Automate management of OSS used with an SCA tool.

How Mature Is Your SCA Process?

OSS may be free of cost, but it isn’t free of responsibility. While 95 percent of IT organizations leverage open source, most companies don’t have sufficient tracking of where it is used. Auto manufacturers can take steps to assess current OSS usage and establish a benchmark for improvement. If you don’t yet have a fully mature SCA process, start by evaluating where you stand today within the Software Composition Analysis Maturity Model, then take a step toward the next level.

Level 4: Optimized—In this most mature level with the greatest business value, a company is optimized for growth, scalability, and digital transformation. It selects secure OSS components, tracks OSS usage, complies with OSS license, manages OSS vulnerabilities, and is alert to new OSS vulnerabilities.

Level 3: Automated—All elements of SCA are integrated and automated, making vulnerability remediation and component selection transparent and easy for developers.

Level 2: Enabled—Businesses at this level have made progress in all four dimensions of SCA business objectives. They have improved risk assessment around OSS use and short-term success metrics for security and compliance.

Level 1: Reactive—At this most basic level, an organization knows that vulnerability management is needed to prevent security defects due to third party component usage. It recognizes that manual management of OSS licenses and obligations is inconvenient and risky.

Conclusion

In addition to the many acronyms above, there’s another that’s essential for any business: ROI. Having an effective SCA program in place for managing your open-source software will help ensure a healthy return on investment, including a substantial reduction in risks associated with OSS.