Key Takeaways:

• The U.S. Connected Vehicle Rule focuses on software origin and provenance
• Open-source software is largely exempt, while commercial and proprietary components are in scope
• SCA tools lack the visibility needed for Connected Vehicle compliance
  Software provenance captured at build-time provides defensible evidence to support Declarations of Conformity
• Detailed build-time SBOMs enable automakers to move from assumptions to provable compliance

In March 2025, the U.S. Department of Commerce’s Bureau of Industry and Security (BIS) finalized the Connected Vehicle Rule under 15 CFR Part 791. The rule, driven by concerns about national security risk, reflects a growing recognition that software origin matters.

For automakers and suppliers, the challenge is no longer simply shipping secure software, but demonstrating—credibly and defensibly—where that software came from.

Listen to the Audio Overview

 

The BIS Connected Vehicle Rule: Background and Scope

The Connected Vehicle Rule addresses risks posed by foreign adversaries to vehicle connectivity systems (VCS) and automated driving systems (ADS). It restricts certain transactions involving VCS hardware and “covered software” when those components are designed, developed, manufactured, or supplied by entities owned by, controlled by, or subject to the jurisdiction of designated foreign adversaries, including the People’s Republic of China and the Russian Federation.

The rule applies to connected vehicle manufacturers and VCS hardware importers and went into effect on March 17, 2025. Rather than prescribing a single technical compliance mechanism, BIS established a framework built around Declarations of Conformity, supported by internal records and subject to review during enforcement actions, advisory opinions, or authorization requests.

For most market participants, compliance will hinge on the ability to submit accurate Declarations of Conformity certifying that prohibited transactions have not occurred, and to back those certifications with evidence if asked.

What Declarations of Conformity Require in Practice

Although the final rule does not mandate automatic submission of technical artifacts such as a Software Bill of Materials (SBOM), it does require organizations to maintain documentation sufficient to substantiate their certifications. In practical terms, that means being able to answer a set of foundational questions with confidence:

• What software is present in VCS and ADS items within the vehicle?
• Which portions of that software qualify as “covered software” under the rule?
• Who authored or supplied those components, and under what jurisdiction?
• Do any components fall under exemptions, such as open-source software or legacy code?

Importantly, the burden of accuracy rests with the certifying entity. Supplier assurances alone are not enough. If BIS requests supporting information, organizations must be able to demonstrate how compliance determinations were made and what evidence informed them.

Open Source Is Mostly Exempt, and That Changes the Compliance Focus

One of the interesting aspects of the Connected Vehicle Rule is that it explicitly excludes open-source software from the definition of “covered software,” provided that the source code is freely available and redistributable in its entirety. Open source only comes back into scope if it has been modified for proprietary purposes and not shared.

Many automotive software governance programs have historically focused on open-source license compliance, vulnerability management, and even snippet detection. Under the Connected Vehicle Rule, however, open-source software is generally not the primary regulatory concern.

Instead, compliance risk concentrates on commercial libraries, proprietary middleware, modified third-party components, and supplier-provided binaries whose internal composition is difficult to assess. These are precisely the areas where many traditional Software Composition Analysis (SCA) tools provide the least visibility.

Why Traditional SCA Approaches Fall Short

Most legacy SCA tools are optimized to identify known open-source packages using public databases and post-build scanning. While effective for vulnerability and license tracking, these approaches often struggle to identify commercial or proprietary components, especially when code is statically linked, optimized, renamed, or embedded deep within final binaries.

In modern automotive software environments, this is the norm rather than the exception. Performance, safety, and determinism requirements frequently drive static linking and aggressive build optimizations. Code reuse across suppliers and contractors can further obscure origin and authorship. Snippet detection, while useful for license enforcement in some contexts, often increases false positives and scan times without improving confidence in software origin under the BIS rule.

The result is a gap between what organizations are asked to certify and what their existing tools can reliably demonstrate.

Software Provenance: From Inference to Evidence

While the Connected Vehicle Rule does not prescribe specific technical solutions, it implicitly favors approaches that generate durable, auditable evidence of software origin. One increasingly important strategy is capturing software provenance during development and at build-time, rather than relying exclusively on post-hoc analysis of finished binaries.

Build-time provenance focuses on observing software as it is constructed. By instrumenting the build process itself, organizations can record which source files, libraries, toolchains, and configurations contribute to each output artifact. This preserves visibility into statically linked and proprietary components before optimization and packaging obscures their identity.

For compliance purposes, this shift from inference to observation is critical. When provenance is captured directly from build inputs, attribution is based on evidence rather than heuristics. That evidence can then support Declarations of Conformity, internal audits, and regulatory inquiries with far greater confidence.

How RunSafe Supports Connected Vehicle Rule Compliance

The Connected Vehicle Rule places commercial and proprietary software squarely in scope—exactly where many traditional tools struggle. RunSafe addresses this gap by generating highly detailed, build-time SBOMs that capture software provenance as code is built.

RunSafe’s approach enables the identification of commercial libraries that post-build scans frequently miss and provides deeper insight into how and where components are introduced. By capturing build configuration, toolchain inputs, and component attribution, RunSafe helps automakers understand not just what is in their software, but how it got there and who supplied it.

This level of visibility supports confident internal review, reduces reliance on manual investigations or supplier assertions, and provides defensible evidence to support Declarations of Conformity. 

Looking ahead, RunSafe is also working to embed certification directly into the SBOM itself to create a clear, auditable artifact that automakers can use as part of attestation for Connected Vehicle Rule compliance.

Listen in to a discussion on automotive compliance standards and building cyber resilience.

SBOMs as Compliance Artifacts, Not Just Security Tools

SBOMs are often discussed in the context of vulnerability management or license compliance. The Connected Vehicle Rule highlights a broader role. Although BIS removed the requirement to submit SBOMs with Declarations of Conformity, it preserved the expectation that regulated entities maintain sufficient documentation to support their claims.

When generated at build time and enriched with provenance data, SBOMs become governance and attestation artifacts. They help demonstrate not only what software is present, but where it came from and how it was incorporated—exactly the questions the rule is designed to address.

Software Provenance and Connected Vehicle Compliance

The U.S. Connected Vehicle Rule represents a meaningful shift in how automotive software risk is regulated. Practices that capture software provenance during development and reflect it in structured artifacts such as SBOMs offer a practical path forward for compliance that supports certification, recordkeeping, and long-term governance without disrupting modern vehicle software development.

For automakers, the goal is not to slow innovation, but to ensure that what they certify can be clearly demonstrated when it matters most.

How is your organization approaching the Connected Vehicle Rule? To learn more about how RunSafe’s SBOM generator supports compliance, get in touch with our team.