Over the last decade, the auto industry’s use of open source software has skyrocketed. Today, automotive manufacturers use OSS in everything from infotainment and connectivity spaces to active safety and autonomous driving applications.
The growth of open source has led the automotive industry to change the way it approaches OSS management. It’s now common for OEMs and suppliers to have at least one person overseeing open source programs; larger organizations may even have dedicated teams. The industry has also introduced new and strengthened procedures that govern OSS license compliance and vulnerability management efforts.
Of course, these changes — and the sheer volume of OSS in modern vehicles — have created new challenges in the area of OSS management. In this blog, we’ll share best practices from a pair of industry experts designed to help your automotive organization reduce the license compliance, security, and quality risks that come with the use of open source software.
The experts are:
- Brad Goldring from GTC Law Group, previously an attorney at Ford Motor Company
- Russ Eling from OSS Engineering Consultants, previously the OSS Compliance Officer at General Motors
This article is based on a webinar Brad and Russ recently conducted on simplifying OSS compliance in the automotive industry. For more information on this topic, we encourage you to view the on-demand version of the webinar.
1. Implementing OSS Management Policies with Stakeholder Buy-In
Even established open source program offices may struggle to implement legal or security policies governing OSS usage. Successfully doing so requires effective communication coordination between multiple teams, including the engineering organization.
“It's very challenging, especially in a large enterprise where development teams are already probably bogged down with a good chunk of red tape, policies, and approvals,” Goldring says.
One solution to the challenge of policy implementation is to identify and work with who Goldring terms the “vocal developer.” The vocal developer is an individual regarded as a thought leader within the engineering organization.
“They may be a little more outspoken than some of the other developers, or they may be the leader of a software guild inside your organization for certain technologies,” Goldring says. “Involving them is so valuable. They’re going to have visibility into some of the issues and challenges that might not be immediately obvious to the legal or security teams.”
“They’ll also be incredibly helpful to you as a legal or security group when there’s pushback after implementing policy or procedures — they can act as advocates for that new policy to help the larger development teams understand the value it provides.”
Along those lines, Russ Eling suggests OSS management teams set expectations with developers that cover licensing and vulnerability management reviews.
“It can be helpful for your development teams to have clear expectations on turnaround time for manual reviews conducted by legal and security teams,” Eling says.
2. Delivering License Notices
Open source license compliance generally requires the delivery of notice and attribution files alongside the distributed software. But given the volume of open source in modern vehicles — not to mention the practical challenges of finding suitable delivery formats — this can be easier said than done.
“Something a lot of people don’t consider is the actual compliance aspect,” Eling says. “Displaying license text and copyright notices on an instrument cluster or an infotainment screen might not be that difficult. But what happens when you have a device like your body control module, which doesn’t have a screen to display anything on?”
“Maybe you put that in the owner’s manual, which is fine. But what about the other 40 something ECUs or modules in the vehicle that pose the same problem? Plus, given the complexity of the auto industry’s multi-layered supply chain, with various suppliers contributing different components to the vehicle, how do you get the coordinated effort into a single display? With the amount of software in today’s vehicles, if it was printed out, the license compliance section might almost look like its own textbook.”
“There’s also the question of maintaining license compliance for the growing number of vehicles that support over-the-air updates,” says Goldring. “Simply compiling everything in a printed owner’s manual wouldn’t allow manufacturers to update license notices following a software update.”
“Including a URL inside an infotainment system or an owner's manual, preferably both, is a best practice,” Goldring says. “You would also then provide that customer the ability to access all the source code that may be required to be shipped alongside the vehicle or any notice and attribution files that are required. With over-the-air updates, something like that is really a requirement.”
Adds Eling: “It’s up to each company’s risk tolerance as well. Do they want a URL out there that’s pointing somewhere? Do they want it on their own site or a supplier’s site? There's a lot to consider. Each company is going to have different views and different levels of risk tolerance regarding how they maintain license compliance.”
3. Generating a Software Bill of Materials
The Biden Administration’s recent executive order on improving America’s cybersecurity requires organizations that sell to the federal government to deliver a software bill of materials (SBOM) with each product. This includes automotive organizations that directly or indirectly do business with U.S. government agencies.
Even if your organization isn’t currently selling to the U.S. federal government, there are many other compelling reasons to produce an accurate software bill of materials. They provide mission-critical visibility into the automotive software supply chain and potential security, license compliance, and quality risks.
Generating an accurate SBOM starts with a full inventory of the software components in a given product. This often begins with an accounting of the open source elements.
“I always talk about the importance of inventorying your open source usage,” Eling says. “Inventory is critical regardless of your focus, whether it’s OSS compliance or security. You can neither comply, secure, nor remediate any software if you don’t know the components that comprise it.”
An SBOM also includes information on proprietary code elements, such as those that an automotive manufacturer may obtain from one of its suppliers. In contrast to gathering an inventory of OSS components — which can be easily done with a software composition analysis tool like FOSSA — it can sometimes be tricky to get a full accounting of proprietary elements.
That’s why Goldring recommends OEMs add language to supplier contracts that require the delivery of SBOM data in an agreed-upon format.
“It can be important to work to contractually define the format and level of inclusion for those components and their dependencies,” Goldring says. “This helps ensure that the software supplier provides this data prior to or alongside the delivery of the software.”
When determining the specific data elements to include in a software bill of materials (and the format used to deliver an SBOM), it may be helpful to consult the recent cybersecurity executive order. The EO includes a list of required minimum elements for a software bill of materials. They are as follows:
- Data fields: Information about each software component such as name, version, and dependency relationship
- Automation support: SBOMs must be delivered in one of three formats: SPDX, SWID Tag, or CycloneDX
- Practices and processes: How and when SBOMs should be generated and distributed
As mentioned, only organizations that sell to the federal government are required to generate SBOMs that meet these requirements, but it’s quite possible that private enterprises may increasingly adopt these standards as well.
OSS Management in the Automotive Industry: Additional Resources
The explosive growth of open source in modern vehicles has made OSS management increasingly challenging. Here are several resources that can help your automotive organization:
Try FOSSA’s OSS Management Tool
FOSSA helps automotive organizations automate key OSS management processes, (generating SBOMs, vulnerability management, continuous compliance with licensing requirements).
Consult with an Expert
Russ Eling and Brad Goldring, the experts who contributed to this blog and the above webinar, help numerous automotive organizations tackle challenges related to OSS management. You can reach them at the email addresses below.
Russ Eling
OSS Engineering Consultants
russ@ossengineeringconsultants.com
Brad Goldring
GTC Law Group
Watch the On-Demand Webinar
Get more insight from Brad and Russ by viewing the on-demand webinar: Simplifying OSS Compliance in the Automotive Industry.
