Modern vehicles are built on layers of software that few teams fully control and even fewer can fully see.
Between supplier-delivered components, open source dependencies, and long product lifecycles, gaining a clear, reliable view of what’s actually in a vehicle—and what risks or obligations come with it—is increasingly complex.
RunSafe hosted a discussion on “SBOMs in Automotive: A Roundtable on Open Source License Compliance and Risk” with Hemanth Tadepalli of May Mobility, Pawel Brzezinski of Harman International, and Tyson Benson of the Product Cybersecurity Group. The speakers shared how they are making the most of Software Bills of Materials (SBOMs) and their role in vulnerability identification and license compliance over long product lifecycles.
We’re seeing the industry move from static inventories to SBOMs that support faster decisions, clearer accountability, and fewer surprises in production.
WATCH THE FULL WEBINAR HERE
Why SBOMs for Automotive Are Complex
Automotive software is unusually difficult to govern because of its scale, heterogeneity, and lifespan.
A modern vehicle may contain dozens of ECUs and software domains spanning infotainment, ADAS, and telematics. Each brings its own dependency tree. Many also include substantial open source footprints, from Linux-based systems to middleware and embedded third-party libraries.
That complexity becomes a security and compliance problem the moment a high-profile vulnerability appears. When Log4Shell hit in 2021, many organizations struggled to quickly determine if they were affected, Tadepalli noted. The value of SBOM visibility is that it helps teams answer in “hours and not really just weeks or months.”
The long support life of vehicles further raises the stakes. “A component that’s clean today may have a critical CVE in year seven,” Tadepalli said. If teams do not maintain accurate SBOMs over time, triage slows before remediation even begins.
This is also becoming a governance issue, not just an engineering one. Regulatory pressure is increasing through frameworks such as UNECE R155/R156, ISO 21434, the Cyber Resilience Act, and related expectations from NHTSA and federal procurement environments. In practice, software inventory is moving from best practice to operational requirement.
Visibility Alone Does Not Equal License Compliance
Having an SBOM is not the same as being compliant. While an SBOM can tell you which components are present, it does not automatically indicate whether a restrictive license creates downstream obligations your organization is unprepared to meet. In automotive, where proprietary IP, supplier layering, and long-lived fielded products all intersect, that distinction matters.
Tyson Benson described a misconception that still persists in some organizations. Teams assume open source means public domain or freeware, but it does not. Different licenses impose different obligations, and some are incompatible with each other or with OEM and Tier 1 business models.
His example was practical: even GPLv2 and GPLv3, while similarly named, “are not compatible because they have different licensing terms.” That means a component decision made by an engineer during development can create a legal and commercial problem later in the lifecycle.
Pawel Brzezinski offered an example many engineering leaders will recognize. His team once evaluated a library whose license included extra legal disclaimer language intended to make adoption easier. Instead, it introduced so much ambiguity that legal would not approve it. “They said, no, we will not use it because we don’t know what will happen with that library,” he explained.
That is the real issue with license risk in embedded systems. The problem is often not only restrictive licensing. It is also ambiguity, interpretation risk, and poor traceability.
How Restrictive Licenses Slip Into Production
Most license problems do not begin with malicious intent or negligence. They begin with speed.
A developer needs a library to solve a specific problem. The component works. It gets merged. It moves downstream through the software supply chain. By the time someone thoroughly checks the license, it may already be in production firmware.
“A developer pulls in a GPL license library to solve a specific sensor,” Tadepalli said. “It works, it gets merged, and it travels downstream through the supply chain, but sometimes into the production firmware before anything really is flagged.”
That is why shift-left license governance matters. Not because compliance teams want another gate, but because late discovery is expensive.
As Tadepalli noted, “GPL doesn’t really care about your ship date.” In automotive systems, copyleft remediation gets more expensive the later it is found. That can mean rework, legal review, supplier negotiation, release delays, or in worst cases, architectural changes that should have happened much earlier.
There is also persistent confusion around static versus dynamic linking. Some engineering teams assume dynamic linking insulates them from GPL obligations. That assumption is not reliable.
“A lot of these courts and legal interpreters are really not constantly agreeing on this,” Tadepalli said, particularly as obligations extend into network-delivered software and connected vehicle architectures.
For leaders balancing roadmap pressure with product risk, the lesson is that if license decisions are not governed early and automatically, they will be governed later and at greater cost.
A Trustworthy SBOM Must Have Provenance, Freshness, and Depth
What makes an SBOM trustworthy?
A trustworthy SBOM requires provenance, freshness, and depth, Tadepalli explained.
First, provenance. Teams need to know how the SBOM was generated and from what source. “A manually authored SBOM is kind of not the same as one that was produced automatically from the actual build system,” Tadepalli said. A hand-maintained inventory may satisfy a document request, but it rarely holds up under incident response.
Second, freshness. An SBOM generated months ago for actively changing software is operationally weak. “Drift really happens in days and not just in months,” Tadepalli said. If the inventory does not reflect what is actually shipping now, it creates false confidence.
Third, depth. Flat inventories that only list direct dependencies miss where risk often hides. In other words, transitive dependencies matter.
Brzezinski reinforced this with an operational example. Teams may have multiple versions of the same library in a single system because different suppliers provide their own implementations. “You can have three or four different versions of the same library in the system,” Brzezinski said. For something like OpenSSL, the question becomes: which version is actually linked, where, and with what exposure?
This is where build-time automation becomes essential. In Brzezinski’s environment, SBOM generation and scanning were integrated into CI pipelines with gating logic for non-acceptable licenses and review workflows for ambiguous cases. That kind of automation keeps documentation aligned with the shipped reality.
Supplier Transparency Is Still Difficult
Automotive teams rarely control the full software stack directly. They inherit risk through Tier 1s, Tier 2s, vendor SDKs, middleware providers, and legacy integrations. That makes supplier transparency difficult.
Tadepalli emphasized the importance of contract language that specifies format, dependency depth, and validation criteria. “The specification of the ask really determines the quality of the answer,” he said. A vague request for a software inventory is much less useful than explicit requirements for SPDX or CycloneDX outputs, version pinning, and transitive dependency coverage.
Validation matters as much as receipt. An SBOM that is not machine-readable, version-specific, or clearly auto-generated may not be operationally useful. It may satisfy a checkbox while leaving the OEM unable to act during a vulnerability event.
Brzezinski added a broader perspective on the software supply chain. Under regulations like the CRA, incident notification timelines can be extremely tight. If a vulnerable component is discovered, organizations may have only hours to understand who is affected and who must be notified. That only works if SBOMs are up to date and linked to both supplier relationships and customer deployments.
In that sense, the SBOM is not just an inventory artifact. It is a coordination mechanism.
Compliance Fails When It Feels Like a Gate
Compliance programs break down when engineers experience them as friction instead of infrastructure.
“The moment you’re looking at compliance and you’re positioned as kind of a gate… you’re already lost,” Tadepalli said. If every issue becomes a blocker, teams end up routing around the process. If every flag is treated as urgent, nothing is.
The alternative is risk-tiered automation embedded in the developer workflow:
- Hard stops for critical violations
- Warnings for medium-risk issues
- Logging and tracking for lower-risk items
- SBOM generation at build time
- License scanning in CI/CD
- Defined lists for approved, prohibited, and review-required licenses
Benson made the same point from the legal-product interface. The best compliance controls are the ones integrated into the toolchain so they do not feel like a separate ceremony. The goal is to reduce the “gotcha moment” late in the lifecycle and replace it with continuous visibility early.
What Automotive Teams Should Do Next
SBOM maturity extends beyond license compliance. It improves vulnerability response, strengthens supplier governance, and gives product leaders a more defensible basis for risk decisions across long vehicle lifecycles.
Here are several starting points for automotive teams:
- Generate SBOMs automatically at build time for high-risk components and vehicle software domains.
- Use standard machine-readable formats such as SPDX or CycloneDX.
- Scan for license risk in CI/CD, not just before release.
- Define policy tiers for approved, prohibited, and review-required licenses.
- Require supplier SBOM terms to be contractually specified, including transitive dependency expectations and validation criteria.
- Validate supplier SBOMs, rather than treating them as inherently trustworthy.
- Treat SBOMs as living operational artifacts, not point-in-time compliance documents.
Meaningful SBOMs for Automotive
The automotive industry needs software inventories that reflect what is actually built, what is actually shipped, and what obligations actually exist. Accurate SBOMs, automated license checks, and supplier transparency are key to how modern automotive organizations protect IP, reduce exploitability, and sustain compliance across products that may remain on the road for 10 to 20 years.
Interested in strengthening your SBOM strategy for embedded and automotive software? Request a consultation.
