Identifying Foreign Influence Exposure Across ECUs, Cloud, and the Supply Chain
In Model Year 2027, connected vehicles that rely on software tied to Chinese or Russian ownership, control, or influence will no longer be allowed to be sold in the United States. This is not a proposal or a future scenario. It is a finalized federal rule issued by the U.S. Department of Commerce, Bureau of Industry and Security (BIS), with an enforcement timeline that is already in motion.
What is striking is not the rule itself. It is how little attention it has received outside regulatory and trade compliance circles. Most automotive cybersecurity discussions still focus on vulnerabilities, penetration testing, and secure development practices. Meanwhile, a more consequential shift is approaching quietly. Who controls the software in a vehicle now matters as much as whether it is secure.
This is not about a new exploit or threat actor. It is a compliance requirement that forces OEMs and suppliers to prove they understand the origin, control, and influence behind the software they ship. For many organizations, especially those that rely heavily on open-source software (OSS), that proof does not yet exist.
With BIS issuing its Connected Vehicles final rule, automotive cybersecurity is no longer just about protecting and defending software. It is about understanding who controls it, who influences it, and where it comes from. This rule signals the U.S. is defending connected vehicle assets from foreign ownership, control, or influence (FOCI), extending a long-standing government and defense industrial base risk lens into the automotive software supply chain.
If you build, buy, or secure software for connected vehicles, you are now in scope, and you need to understand whether the software you ship meets the rule’s definition of “covered software” (including its exclusions).
From Vulnerabilities to Influence
This is a new class of risk for automotive OEMs and suppliers.
Security teams are comfortable answering questions such as whether a component has known Common Vulnerabilities and Exposures (CVEs), whether the code is vulnerable to injection, deserialization, or memory corruption, and whether it has passed static application security testing (SAST), dynamic application security testing (DAST), and software composition analysis (SCA).
The BIS Connected Vehicles rule asks a different question.Was this software designed, developed, manufactured, or supplied by an entity owned by, controlled by, or subject to the jurisdiction or direction of China or Russia?
That is not a vulnerability question.It is a question of sovereignty and influence.
The rule makes clear that software provenance is in scope even when no exploit exists.
What the BIS Connected Vehicles Rule Does
In January 2025, BIS finalized a rule under its Information and Communications Technology and Services (ICTS) authority to address national security risks associated with connected vehicles in the United States.
The concern is straightforward. Modern vehicles are rolling computers. They collect data, communicate externally, receive updates, and can be remotely accessed. If adversarial nation states exert influence over the software or hardware in those systems, the risk becomes systemic.
Three core prohibitions
- Sale of connected vehicles by Chinese or Russian companies (Model Year 2027). Beginning in Model Year 2027, manufacturers owned by, controlled by, or subject to the jurisdiction or direction of China or Russia cannot sell connected vehicles in the United States, regardless of where the underlying technology originated.
- Import or sale of vehicles containing covered Chinese or Russian software (“covered software” means application, middleware, and system software, executed by the primary processing unit(s), that directly enables the function of VCS/ADS at the vehicle level. It's important to note that this excludes firmware and excludes open-source unless proprietary-modified and not redistributed/shared.
- Import of Chinese or Russian VCS hardware (Model Year 2030 or January 1, 2029). BIS will prohibit the import of VCS hardware tied to Chinese or Russian companies, with timing dependent on whether the component aligns to a model year.
Together, these requirements force a difficult question. Can you prove where every meaningful piece of connected vehicle software and hardware came from and who ultimately controls it?
Declarations of Conformity, Where Compliance Becomes Real
The most operationally significant element of the rule is the Declaration of Conformity.
Before importing VCS hardware or selling connected vehicles in the United States, manufacturers and importers must certify to BIS that they are not engaging in prohibited transactions, that their hardware and covered software were not designed, developed, manufactured, or supplied by entities subject to Chinese or Russian ownership, control, or jurisdiction, and that they conducted documented due diligence to substantiate these claims.
Declarations must be:
- Filed at least sixty days before import or sale
- Updated when material changes occur
- Re-certified annually if no changes take place
BIS explicitly states that due diligence may rely on a software bill of materials (SBOM) and third party assessments.
This is where OSS moves into the spotlight for due diligence and provenance evidence, and in some cases may fall within “covered software” depending on how it is modified and distributed.
Why Open-Source is Now a FOCI Risk Vector
OSS underpins nearly every connected vehicle stack, from operating systems and networking libraries to cryptography, middleware, diagnostics, OTA update mechanisms, and cloud/edge integrations.
Historically, OSS risk management focused on licenses, vulnerabilities, and project health. The Connected Vehicles rule adds a new concern: provenance and influence, who can shape the code you depend on and whether you can document that lineage.
Even where OSS is excluded from “covered software,” it still matters for FOCI because governance, maintainer affiliation, distribution pathways, and downstream modification determine what provenance evidence you can credibly produce, and OSS can become in-scope when it’s modified into proprietary, non-redistributed components.
Open-source components may be:
- Maintained primarily by developers employed by companies in specific jurisdictions
- Sponsored or governed by foreign entities
- Distributed through infrastructure subject to foreign control
- Forked or modified downstream in opaque ways
None of this necessarily creates a CVE. But it can create FOCI exposure by weakening your ability to show who influenced the software and what changed between upstream and what ships.
Why Traditional AppSec Tooling Falls Short
SAST, DAST, and SCA remain essential, but they were not built to answer FOCI questions. Most tools can reliably tell you which components you use, which CVEs they contain, and which licenses apply. What they generally cannot tell you is who maintains a project today, where those maintainers are employed, whether a dependency is indirectly supplied through a restricted entity, or whether upstream ownership, governance, or influence has shifted since your last scan.
FOCI risk is dynamic, contextual, and organizational. It is not purely technical. That gap is becoming a compliance liability.
The New Expectation: SBOM, Provenance, and Influence
The BIS rule does not prescribe a single technical solution, but it does set a clear operational expectation: you must be able to perform repeatable, defensible due diligence on software and hardware provenance, including foreign ownership, control, or influence. That means provenance needs to go beyond names and versions, supplier transparency has to be enforceable contractually, and compliance claims must be supportable with evidence that holds up over time.
In practice, many organizations will use SBOMs as one input to that evidence trail, but the real requirement is broader: correlate what you ship with supplier and entity intelligence, track ownership, governance, and control as they change, detect when a component’s risk profile shifts due to external developments, and respond quickly when material changes occur.
What this means for OEMs and Tier Ones
The rule creates immediate pressure in three areas.
- Supply chain visibility: If you cannot trace software lineage beyond Tier One suppliers, certification becomes difficult.
- Continuous monitoring: FOCI risk can change without a single line of code changing. Annual attestations are not enough.
- Regulatory readiness: Declarations of Conformity are legal documents. Unsupported claims introduce enforcement risk.
This is no longer just a security problem. It is a business continuity issue.
Where Manifest Fits
At Manifest, we believe the next evolution of application security is contextual supply chain intelligence, and FOCI risk makes the case. It sits at the intersection of software, suppliers, and geopolitics, cannot be solved through scanning alone, and requires continuously updated, defensible insight.
By enriching SBOM data with entity, ownership, and influence context, teams can:
- Identify open-source components with elevated FOCI exposure
- Prioritize remediation beyond CVE severity
- Support BIS declarations with evidence
- Communicate risk clearly to legal, compliance, and executive stakeholders
Manifest enables customers to understand which components and third-party dependencies put the business at risk. Learn more about the Manifest Platform.
What Comes Next
The BIS Connected Vehicles rule will not be the last of its kind. Expect similar frameworks in other regulated industries, increased scrutiny of software provenance, broader definitions of covered software, and more frequent audits and enforcement. Organizations that treat FOCI risk as a first-class security signal will be better positioned to comply and compete.
The Connected Vehicles rule marks a clear transition point. Security is no longer only about defending systems from attackers, it is about defending supply chains from undue influence. For the automotive industry and the security teams that support it, FOCI risk is not coming. It is already here.
.png)
