Beyond trade policy: What the BIS Connected Vehicle Rule really demands from automotive software teams

When the Bureau of Industry and Security’s Connected Vehicle Rule took effect in March 2025, many in the industry read it primarily as a trade policy measure targeting Chinese and Russian components. Joseph M. Saunders, Founder and CEO of RunSafe Security, argues that framing misses the more significant implication.

The rule’s compliance mechanism – Declarations of Conformity backed by defensible documentation – asks a question the industry has not had to answer at scale before: not what is in your software, but where it came from, and who built it.

In this interview, Saunders explains to Automotive World what that question actually requires of engineering and compliance teams, where existing tools fall short, and how OEMs and suppliers can use the regulation as a catalyst for the software governance infrastructure modern vehicles need.

This isn’t something you can satisfy with a supplier attestation and move on. You must be able to demonstrate how you made the determination and what evidence supported it.

The BIS Connected Vehicle Rule introduces country-of-origin requirements for vehicle software and connectivity components. From a software security perspective, what does the rule require – and why does it matter beyond trade policy?

At its core, the rule is about software provenance. The Bureau of Industry and Security finalized the Connected Vehicle Rule under 15 CFR Part 791, and it restricts transactions involving vehicle connectivity systems and automated driving systems when those components are designed, developed, manufactured, or supplied by entities tied to designated foreign adversaries, primarily China and Russia. It went into effect in March 2025.

What makes this different from a typical trade regulation is the compliance mechanism. Rather than prescribing a technical checklist, BIS built the framework around Declarations of Conformity, certifications that attest that prohibited transactions have not occurred, backed by documentation that must be defensible if regulators come calling. So, this isn’t something you can satisfy with a supplier attestation and move on. You must be able to demonstrate how you made the determination and what evidence supported it.

From a security standpoint, that distinction matters enormously. The automotive industry has spent years improving software development practices, building out vulnerability management programs, and mapping to standards like ISO 21434 and UNECE WP.29. But those programs were largely built around what is in the software, such as vulnerabilities, licenses, and known weaknesses.

The Connected Vehicle Rule asks a different question: where did it come from, and who had a hand in building it? That’s a harder question to answer at scale, and most organizations haven’t had to answer it with this level of rigour before.

The Connected Vehicle Rule asks a different question: where did it come from, and who had a hand in building it? That’s a harder question to answer at scale.

The rule targets software with a “sufficient nexus” to countries of concern, including China and Russia. Given the complexity of modern SDV stacks, how can engineering teams realistically determine whether components in their supply chain meet that threshold?

This is where it gets genuinely difficult. If you think about what a modern software-defined vehicle contains, you’re talking about potentially 100 million lines of code, with 40 to 100 distinct software packages across autonomous driving systems, infotainment, ECUs, telematics, and ADAS. The supply chain is extraordinarily deep. There are common suppliers, software packages, and open architectures shared across multiple OEMs and tier-one providers. The interconnectedness of it all is part of what makes these vehicles so capable and what makes origin tracking so complex.

The honest answer is that you can’t do this manually. The organizations that will be in the best position are those that have invested in capturing provenance at build time – understanding not just what packages are present in a finished binary, but where those inputs came from as the software was being constructed. That’s a fundamentally different approach than scanning a completed artifact after the fact.

You can’t do this manually. The organizations that will be in the best position are those that have invested in capturing provenance at build time.

What engineering teams need to move toward is instrumenting the build process itself. When you observe software as it’s being built – by recording which source files, libraries, toolchains, and configurations contribute to each output – you preserve attribution before optimization and packaging obscures it. That’s the kind of evidence that can support a Declaration of Conformity.

RunSafe focuses heavily on memory safety vulnerabilities in embedded and automotive systems. Is there any meaningful connection between country-of-concern software components and broader software security risk, or are these fundamentally separate issues?

They’re distinct regulatory concerns, but they’re not unrelated in practice, and I think it’s worth being clear about both. The Connected Vehicle Rule is primarily about origin and provenance. It’s asking whether components were designed or supplied by entities subject to the jurisdiction of a foreign adversary. That’s a geopolitical and national security question.

Memory safety vulnerabilities, such as buffer overflows, heap overflows, and out-of-bounds writes, are a software quality and security question. Somewhere between 40% and 70% of the vulnerabilities we see in embedded automotive systems are memory-based. These are the vulnerabilities that enable remote code execution, privilege escalation, and the kind of attack that lets someone steer a car off the road. We’ve seen real-world demonstrations of exactly that since 2014, and the threat has only grown as vehicles have become more connected.

The two issues converge in the software supply chain. If you have a component from a country-of-concern supplier embedded deeply in a safety-critical system, you don’t just have a compliance problem; you may have a software supply chain that is difficult to audit, difficult to patch, and carries unknown vulnerabilities.

The opacity that creates a compliance risk also creates a security risk. So, while the regulatory frameworks are separate, the underlying challenge of achieving full visibility into complex, multi-layer software stacks is common to both. Solving one well tends to help with the other.

The opacity that creates a compliance risk also creates a security risk.

Software Bills of Materials (SBOMs) are increasingly positioned as foundational to BIS compliance. In practical terms, what must an SBOM include to support country-of-origin analysis – and where do automotive suppliers typically fall short?

While the BIS Rule does not specifically require SBOMs for compliance, they are a big help in the journey. SBOMs have historically been discussed in the context of vulnerability management and open-source license compliance. The Connected Vehicle Rule is pushing the industry to think about them as governance and attestation artifacts as well.

For country-of-origin analysis, an SBOM needs to go beyond a list of package names and version numbers. You need component attribution to identify who authored or supplied each element, under what jurisdiction, and how it was incorporated into the build. You need visibility into commercial libraries and proprietary middleware, not just open-source components well-indexed in public databases. And you need that data captured at build time, not inferred after the fact from a binary scan.

Here’s where most suppliers fall short today. Traditional Software Composition Analysis (SCA) tools are optimized for open-source identification. They’re good at matching against known public databases. But the Connected Vehicle Rule explicitly exempts most open-source software.

It’s commercial libraries, modified third-party components, and supplier-provided binaries where the compliance risk concentrates. Those are precisely the components that post-build scanning tools struggle to see, especially when code has been statically linked, optimized, or embedded deep within a final artifact. So, organizations are running tools that are well-suited for a problem the rule mostly exempts, and under-equipped for the problem the rule targets.

Organizations are running tools that are well-suited for a problem the rule mostly exempts, and under-equipped for the problem the rule targets.

What we need to get to – and what RunSafe is working toward – is SBOMs enriched with build-time provenance data, with attestation embedded directly in the artifact. That’s what transforms an SBOM from a security tool into a compliance instrument that can support a Declaration of Conformity.

Legacy C and C++ codebases still dominate automotive software. If a component with country-of-concern provenance is discovered deep within a safety-critical system, what realistic remediation options exist – and what are the security and regulatory implications of leaving it in place?

This is the question that keeps engineering teams up at night, and rightly so. The reality is that most automotive software is still written in C and C++. These are what we call memory-unsafe languages, and the vulnerabilities they introduce are the highest-severity class in these systems.

They’re also extraordinarily expensive to remediate through rewriting. Translating a safety-critical codebase into Rust, for example, takes enormous time and resources, requires developers with genuinely scarce skills, and introduces new validation burdens under functional safety standards. For most organizations, that’s not a near-term option.

So, what are the realistic paths? First, understand what you have. You can’t remediate what you can’t see, and many organizations genuinely don’t know the full composition of their software stack at the component level. That discovery process must come first.

You can’t remediate what you can’t see, and many organizations genuinely don’t know the full composition of their software stack at the component level.

Second, for components where a country-of-concern connection is identified, the question becomes whether you can replace the component with a compliant alternative, apply runtime protections that mitigate exploitation risk without requiring a rewrite, or pursue an authorization or exemption pathway through BIS.

The regulatory implications of leaving a non-compliant component in place without acting are significant. It undermines the Declaration of Conformity and exposes the company to legal liability.

But beyond the regulatory dimension, the security implications are that you’re carrying an opaque component of unknown quality in a safety-critical system, and you don’t have a clear patching pathway. That’s a risk no OEM should be comfortable accepting long-term.

The rule places compliance pressure upstream across the supply chain. How should OEMs approach conversations with tier-one and tier-two suppliers, and what evidence or assurances should they be asking for to meaningfully reduce risk?

Supplier assurances alone are not enough. That’s not a criticism of suppliers; it’s just the reality of what the rule requires. The burden of accuracy rests with the certifying entity, meaning the OEM must be able to demonstrate how compliance determinations were made, not merely that a supplier said everything was fine.

What OEMs should be asking for is structured, machine-readable evidence. That means build-time SBOMs with provenance data, not just declarations of compliance. It means being able to trace specific components back to their origin, understand who supplied them, and verify that the supplier’s processes produce the artifacts that support downstream certification.

Supplier assurances alone are not enough. The burden of accuracy rests with the certifying entity – the OEM must be able to demonstrate how compliance determinations were made, not merely that a supplier said everything was fine.

The good news is that this kind of transparency is increasingly achievable, and it benefits everyone in the ecosystem. When suppliers can provide OEMs with visibility into what they’re shipping – and I mean genuine visibility, not just a spreadsheet – it enables communication, coordinated vulnerability response, and the kind of trust that makes the software supply chain more resilient. The OEMs who are doing this well treat it not as a compliance checkbox but as a quality and security program that also satisfies the regulation.

Although the rule is US-focused, many OEMs and suppliers operate globally. Does BIS compliance create a broader security baseline for the industry, or is there a risk that it becomes a box-ticking exercise disconnected from real-world threat exposure?

The risk of box-ticking is real, and it’s worth being direct about that. Any time a regulation is framed around documentation and declarations, there’s a temptation to optimize for producing the right paperwork rather than building genuinely secure systems. That would be the wrong lesson to take from this rule.

What I believe the Connected Vehicle Rule can do, if the industry engages with it seriously, is push automakers and suppliers toward the kind of software governance infrastructure that should already have existed. Capturing provenance at build time, maintaining defensible documentation of component origin, and having visibility into the full composition of your software stack are the foundations of a mature software security program.

The automotive industry is facing a genuinely significant threat environment. The attack surface on a modern SDV is enormous. The connectivity that makes these vehicles so compelling is the same connectivity that creates exposure. If BIS compliance drives organizations to build better visibility into their software supply chains, that investment will pay dividends well beyond satisfying US regulators.

The same provenance data that supports a Declaration of Conformity also helps you respond faster when a vulnerability is disclosed, communicate more effectively with suppliers, and demonstrate to customers and regulators globally that you take software security seriously.

The same provenance data that supports a Declaration of Conformity also helps you respond faster when a vulnerability is disclosed, communicate more effectively with suppliers, and demonstrate to customers and regulators globally that you take software security seriously.

For engineering teams beginning this process today, what are the first three concrete actions that would materially improve their security posture beyond simply meeting compliance requirements?

First, get real visibility into what’s in your builds. Not post-build scanning of finished binaries. I mean build-time instrumentation that captures what went into each output artifact as it was being constructed. That means commercial libraries, proprietary middleware, toolchain inputs, and configuration data, not just the open-source components your SCA tool can identify. You can’t make accurate compliance determinations or security decisions without that foundation.

Second, close the gap between your safety and security programs. ISO 26262 and ISO 21434 are complementary, not competing. Security vulnerabilities are safety issues. A memory vulnerability that enables remote code execution on an ADAS system is as much a safety risk as a mechanical failure. Engineering teams that have integrated these disciplines and that have certified tools capable of meeting both sets of requirements are in a significantly stronger position. Start mapping your security controls to your safety requirements if you haven’t already.

Third, build runtime protection into your software development lifecycle now, before you have a crisis. The reality is that vulnerabilities will be discovered in systems that are already deployed. Over-the-air updates are essential, but they’re not instantaneous, and they’re not always possible. If you can eliminate an entire class of memory safety vulnerabilities through protections applied at build time – without adding agents, without rewriting code, without slowing down systems – you dramatically reduce the window of exposure when something new is found. That’s resilience.

The organizations that will do this well are the ones that treat the Connected Vehicle Rule not as a hurdle to clear, but as an opportunity to build the software governance infrastructure that modern vehicles genuinely require. Safety and security are not in opposition to innovation but are what make innovation sustainable.

Sponsored Content: This article was produced on behalf of RunSafe Security. While RunSafe provided information and expert commentary, Automotive World retained responsibility for the final content.