The automotive software supply chain is highly complex. OEMs and their suppliers have spent years building vehicles on a layered mix of open-source libraries, proprietary firmware and third-party components, often without a complete picture of what is actually running in the stack.
It is most certainly not an easy web to untangle. And while a lack of visibility into the software supply chain has always been a cybersecurity risk, now it’s a compliance challenge with real deadlines rapidly approaching.
In March 2025, the Bureau of Industry and Security (BIS) Connected Vehicle Rule (CV) went into effect. The CV Rule targets national security risks tied to foreign adversary-linked entities having design or supply influence over software and hardware in U.S. connected vehicles. Its reach extends across the full supply chain. Since its enactment, OEMs and software manufacturers have been working furiously to comply. However, it’s become apparent just how difficult it will be to unravel supply chain dependencies.
Just last month, Polestar announced it had not received an exemption from BIS rule requirements. As a result, the automaker will not be able to sell vehicles in the U.S. starting with the 2027 model year.
Also in June 2026, BIS released General Authorization 3 (GA 3) to create an Approved Supplier Registry for manufacturers and hardware importers not covered under the original rule. The need to add a list for additional Tier 1 and lower suppliers is just another example that automotive dependencies run deep, and all the links in the chain have a part to play in compliance.
Declarations of Conformity: Showing Your Work
The main compliance mechanism under the CV rule is the Declaration of Conformity. Organizations must certify that no prohibited transactions occurred. BIS doesn't require automakers to submit detailed technical artifacts up front, but it does require records sufficient to substantiate that certification on request.
If BIS investigates, automakers need to show their work. That means answering these four questions with confidence:
- What software is present? Identify all software in VCS and ADS items within the vehicle.
- Who supplied it? Determine authorship, supplier and jurisdiction for each component.
- What qualifies as “covered” under the rule? Distinguish commercial and proprietary components from open-source and firmware.
- Are exemptions applicable? Legacy code, open-source, or general authorization may apply.
Where Standard Approaches Fall Short
The two most common methods for understanding software content both have real limitations here. Binary scanning tools, including software composition analysis tools, identify many components but tend to miss statically linked libraries and proprietary code that has been optimized or repackaged. Those are often the exact components that matter most for provenance questions. Supplier manifests have the same problem from a different direction: they are only as accurate as the supplier's own records, and the same visibility gaps that affect OEMs run all the way down the chain.
Both approaches produce inferences rather than evidence. Software Composition Analysis (SCA) tools perform well on known open-source packages but provide limited insight into proprietary or commercial components, which is precisely what BIS cares about.
Build-Time Provenance as the Answer
What actually holds up is a record of what went into each software artifact, captured at the moment it was built, before optimization and packaging have a chance to obscure the picture. Build-time Software Bills of Materials (SBOMs) do exactly that. By instrumenting the build process itself, they record which source files, libraries, toolchains, and configurations contributed to each output. That record captures statically linked libraries, identifies commercial and proprietary components, and produces the kind of attribution data that supports a credible Declaration of Conformity.
While the CV Rule removed any specific requirements for SBOMs from its original draft of the regulation, SBOMs are an effective mechanism for understanding provenance and an industry-recognized way to document which components are included in a specific piece of software.
The Reckoning That Was Already Overdue
The CV Rule has exposed the software supply chain problem in the automotive industry. Automakers have spent years sourcing software components across a global network of suppliers, integrating open-source libraries, proprietary firmware, and third-party stacks without always knowing exactly what they were building on. That network is important for building modern vehicles with modern features, but now regulators want provenance, and the industry doesn't have a clean answer.
Build-time SBOMs don't solve that overnight. But they're the only mechanism that captures what actually went into a software product when it was built, before the layers of optimization and packaging that make downstream analysis a guessing game. The compliance reckoning the CV Rule forced is, in the end, an argument for something the industry should have been doing anyway: knowing what's in the code.
