BIS Connected Vehicle Rule 自 2025 年 3 月 17 日生效。硬件来源与软件来源认证截止时点分别为 MY2027 和 MY2030。供应链治理是让这条规则可运行的运作模型。
美国 Connected Vehicle Rule 改变了多年来塑造汽车网络安全的一项前提:一款产品在技术上可以是安全的,但仍可能因谁设计、供应、控制或可能影响其关键技术而被认定为不可接受。
美国商务部工业与安全局(BIS)发布的最终规则,对涉及中国或俄罗斯关联的特定车辆连接系统硬件与联网软件予以限制。软件类禁令自 MY2027 起适用。VCS 硬件限制自 MY2030 起适用;对于无车型年的涉规硬件,则自 2029 年 1 月 1 日起适用。该规则于 2025 年 3 月 17 日生效,并要求涉规制造商与进口商提交年度合规声明,设有有限的豁免与授权程序。
这不是一般的组件合规练习。证据必须把企业所有权、开发控制权、软件来源、硬件供应链、车辆配置与车型年适用性串联起来。一份静态的供应商名单远远不够。
本指南说明 OEM 与供应商如何构建可重复的合规运行模型,而无需再起一份脱节的电子表格项目。
该规则试图控制什么
该规则针对的是联网车技术可能带来的国家安全风险,这些技术可能持续访问车辆、敏感数据、关键基础设施或自动驾驶功能。其聚焦两大技术范畴:
- 车辆连接系统(VCS):支持车辆通过蜂窝、卫星、Wi-Fi、蓝牙、射频或类似外部连接进行通信的硬件与软件。
- 自动驾驶系统(ADS)软件:在规定场景中,共同支持高度自动化车辆在无人类驾驶员执行驾驶任务时运行的软件。
法律定义、排除项、阈值与涉规交易均很重要。组织应依据最终规则与 BIS 指引对产品进行分类,而非依赖如"telematics"或"autonomy"这类非正式标签。
运营层面的含义远不止制造国。团队必须理解所有权、控制权、管辖权与指挥关系。一个在某国组装的模块,所含软件可能由受另一管辖区影响的实体开发、维护或远程管理。一家美国子公司仍可能需要对其母公司、治理结构、人员访问权与更新权进行更深入的分析。
合规时间表
最重要的日期为:
- 2025 年 3 月 17 日:该规则生效。
- MY2027:对涉规 VCS 软件与 ADS 软件,以及由中国或俄罗斯所有、控制或受其管辖或指挥的制造商销售特定联网车辆的行为,适用禁令。
- MY2030:对涉规 VCS 硬件进口适用禁令。
- 2029 年 1 月 1 日:对无关联车型年的涉规硬件适用硬件禁令。
软件日期是最紧迫的优先事项,因为 MY2027 的采购与平台决策可能已经锁定或接近锁定。软件也比硬件更难清点。它可能嵌入供应商的二进制文件、在量产后才更新、通过云端托管服务交付,或由传统采购渠道之外的团队维护。
因此,一次合规的发布决策需要在车辆进口或销售日之前就具备证据。采购、架构、软件发布与供应商批准的卡点必须现在就把这条规则纳入。
为何常规物料清单不够用
机械物料清单回答的是"采购了哪个部件"。软件物料清单回答的是"包含哪些软件组件"。BIS 规则要求第三种视图:谁设计、开发、制造、供应、拥有、控制、指挥、更新涉规技术,或可对其产生实质性影响。
一个有用的合规模型把以下要素链接起来:
车型年 -> 整车平台 -> ECU 或系统 -> VCS/ADS 功能 -> 硬件组件 -> 软件包或二进制 -> 供应商 -> 开发实体 -> 母公司与控股实体 -> 国家与管辖指标 -> 交易与声明证据。
没有任何单一传统工件能囊括全部信息。采购系统持有供应商名称与零件号。架构工具持有功能与接口。SBOM 系统持有软件包。法务团队持有所有权分析。发布系统持有部署版本。贸易合规团队持有声明。
挑战在于跨这些来源构建一张受控的证据图,而不至于让每次更新都变成一次人工调查。
从产品与交易分类入手
首要工作流不是供应商接洽,而是确定什么在范围内。
对每个面向美国市场的车辆项目,记录:
- 车辆是否符合该规则的联网车定义与适用的重量或产品标准。
- 哪些系统执行 VCS 功能。
- 哪些软件贡献于涉规 VCS 功能。
- 是否有 ADS 软件落入范围。
- 哪些硬件组件属于涉规 VCS 硬件。
- 本组织是作为联网车制造商、VCS 硬件进口商,还是其他涉规方。
- 适用的车型年日期。
- 是否可能适用某项豁免、一般授权或特定授权。
分类应当版本化。某个系统在一种架构下可能不在范围内,而在新增远程连接、新增无线芯片组或自动驾驶功能后会变为涉规。因此,产品变更应触发分类复核。
不要按部门来分类。同一域控制器可能同时包含连接、信息娱乐、诊断与驾驶辅助软件。范围跟随功能与技术,而非组织架构图。
构建涉规技术清单
一份可靠的清单需要四个层。
功能层
识别对外连接或对 ADS 有贡献的车辆功能。包括直接与间接连接、远程指令、诊断、车队服务、应用集成、软件更新、数据上传与服务间通信。
架构层
梳理实现这些功能的 ECU、高性能计算机、网关、调制解调器、无线芯片组、天线、网络接口、操作系统、中间件与云依赖。
软硬件层
记录软件标识、版本、供应商、构建来源、源码或二进制状态、更新权、硬件零件号、制造来源与子组件。清单应区分开源库与集成并控制涉规软件产品的实体。
控制与所有权层
记录相关供应商法律实体、母公司、必要时的受益或控股所有权、开发地点、管理访问权、维护团队、远程支持安排与合同更新权。
该清单将成为尽调、声明、变更控制与审计响应的基础。
超越问卷的供应商尽调
问卷只有在答案可被验证并定期刷新时才有用。诸如"贵方是否遵守美国法律?"这类泛泛问题几乎不能提供证据。
请向供应商索取结构化信息,涵盖:
- 提供该产品或服务的确切法律实体。
- 母公司、控股与相关关联实体。
- 设计、开发、集成、制造、测试、托管、支持与维护的所在地。
- 贡献涉规硬件或软件的子供应商身份与角色。
- 源码所有权与代码变更审批人。
- 签名密钥、代码仓库管理、构建系统访问权与更新权的持有方。
- 远程访问路径与支持人员。
- 软硬件来源记录。
- 针对所有权、人员、地点或子供应商变更的通知义务。
- 有文件支撑的声明,而不仅仅是签字。
基于风险的核验可包括企业登记检查、合同审阅、构建与签名证据、代码仓库访问审查、场地信息、SBOM 分析、硬件拆解或独立测试。
供应商也应主动指出不确定项。一个诚实的"未知"可以被调查;一个无依据的绝对陈述只会带来隐性风险。
为年度合规声明定义证据
BIS 指引指出,在进行涉规进口或销售活动前,涉规联网车制造商与 VCS 硬件进口商通常须按年提交合规声明,设有有限豁免。
声明流程背后应有一份可重复的证据包,其中可包含:
- 涉规车辆与硬件范围。
- 车型年与配置。
- 已分类的 VCS 与 ADS 功能。
- 供应商与子供应商清单。
- 软硬件来源。
- 所有权与控制权分析。
- 尽调结果与未决例外。
- 已批准的授权或咨询意见。
- 自上次声明以来的变更记录。
- 负责的高管与审阅人。
- 记录保存位置与访问控制。
不要把声明当作年末填写的法律表格。它是持续的产品与供应链治理的输出。如果底层清单持续更新,年度提交就成为一次受控复核;否则就变成一次高压重构。
把软件与传统零件区别管理
软件带来几个合规陷阱。
嵌入式供应商二进制
Tier-1 可能交付一个包含来自多家子供应商连接软件的二进制。即便源码不可得,OEM 仍需要足够的来源信息来判断谁开发并控制了涉规功能。
云控车辆功能
部分联网功能依赖后端软件、凭据、策略引擎或远程配置。团队应评估对面向车端的软件或服务的控制权是否构成涉规暴露,而不能仅审查车内存储的代码。
量产后更新
车辆在销售时可能合规,而后续的软件更新可能改变供应商、组件、管理路径或功能。发布治理必须拦截会使合规基础失效的更新。
共享平台
一个软件平台可能同时用于美国与非美国车辆。组织需要具备变体感知的配置与部署证据,确保受限组件不会通过复用或紧急补丁进入美国版构建。
开发工具与外包工程
并非所有用于构建软件的工具都属于涉规技术,但外包开发、代码控制、签名权与远程管理会影响所有权与控制权分析。法务与技术团队应审视实际运行模型。
建立变更触发条件
合规结论可在没有新整车平台的情况下发生变化。定义自动重新打开评估的事件:
- 新的软件供应商或子供应商。
- 企业所有权或控制权变更。
- 收购、合并、合资或重组。
- 新的开发或支持地点。
- 源码、代码仓库、签名或更新权的转移。
- 新增无线接口或连接功能。
- ADS 功能扩展。
- 硬件重新设计或替换组件。
- 来自新来源的紧急漏洞补丁。
- 后端迁移或托管服务变更。
- 车型年配置发生实质性变化。
每个触发条件都需要责任人、复核截止日期、所需证据与发布后果。会影响声明的变更不应取决于是否有人记得发邮件给贸易合规。
把规则纳入采购与合同
合同条款应让所需的可见性与响应能力成为可能。可考虑下列条款:
- 完整且准确的所有权与控制权信息。
- 披露涉规子供应商。
- 对实质性变更的事先通知与批准。
- 交付软硬件来源信息。
- 审计与核查权。
- 在规定保存期内访问支持性记录。
- 对此前不准确陈述的即时通知。
- 对未授权远程访问与更新权的限制。
- 配合 BIS 的问询、授权或整改。
- 供应商变为禁规对象时的过渡协助。
- 针对不合规变更的责任与成本分配。
商务团队也需要退出策略。如果关键供应商不再合资格,组织能否在适用车型年之前替换该组件、迁移软件、转移维护,或隔离该功能?
审慎使用授权与咨询意见
BIS 框架包含一般授权、特定授权与咨询意见。这些机制不应被视为绕过尽调的捷径。它们要求清晰定义的事实情形。
在寻求之前,先整理:
- 确切的交易与产品配置。
- 相关实体与所有权关系。
- 技术范围与功能。
- 访问、控制、更新与数据流。
- 安全缓解与治理。
- 已考虑的替代方案。
- 时效性与业务影响。
- 若获批,所承诺的监控措施。
当技术架构与企业事实足够稳定、可精确描述时,咨询意见最有价值。模糊的请求只会带来模糊的价值。
设计跨职能治理模型
没有任何单一职能能端到端拥有这条规则。
- 贸易合规与法务负责规则解释、实体识别、授权与申报义务。
- 网络安全与架构识别 VCS/ADS 功能、信任边界、访问路径与技术控制。
- 采购与供应商质量获取并核验供应商信息。
- 软件工程与 DevSecOps 维护构建、仓库、签名与发布来源记录。
- 硬件工程与制造管理组件来源与替换。
- 联网服务与云团队记录后端控制与远程管理。
- 项目管理负责执行车型年卡点。
- 高管层批准声明与风险决策。
设立一个具备明确升级标准的决策论坛。冲突应在采购或发布批准前解决,而不是在年度提交截止前。
一份实用合规工作流
第 1 步:筛查项目组合
识别面向美国市场的项目、涉规车型、车型年、VCS 硬件、联网软件与 ADS 软件。
第 2 步:把实体映射到技术
把每项涉规要素链接到供应、开发、控制、支持与更新该要素的实体。
第 3 步:收集并核验证据
使用结构化的供应商提交、内部记录、法律分析、SBOM、架构数据与访问控制证据。
第 4 步:处置例外
替换、重新设计、寻求授权,或记录该项为何不在范围内。跟踪假设条件与有效期。
第 5 步:对发布与采购设置卡点
在采购批准、软件发布、硬件替换或美国部署之前要求最新的合规状态。
第 6 步:准备声明
从受控清单生成年度申报范围与证据摘要。
第 7 步:监测变更
跨供应商、企业所有权、软件、硬件、访问权与车辆配置运行持续变更检测。
面向管理层的度量
实用指标包括:
- 面向美国市场涉规系统的完整分类比例。
- 已核实开发与控制来源的涉规软件比例。
- 完成全分层可追溯的涉规硬件比例。
- 未决实体所有权问题数量。
- 等待重评估的供应商变更数量。
- 评估一次软硬件替换的平均耗时。
- 已被合规卡点覆盖的 MY2027 发布比例。
- 按项目的声明证据完整度。
- 依赖授权的配置数量与时效。
- 回答"哪些美国车辆使用了指定实体的技术"所需时间。
这些指标应可下钻到车辆、版本、供应商与证据。聚合数字本身无法支撑一次声明。
互联 CSMS 证据层如何支撑该规则
该规则并非 ISO/SAE 21434 要求,但同一份联网产品模型可以减少重复劳动。架构、供应商、SBOM、漏洞、软件版本、控制、批准与已部署配置本就对网络安全管理至关重要。在其上增加所有权、管辖权、控制权与声明属性,即可在不再起一份孤立数据库的前提下构建出美国合规视图。
ThreatZ 可作为车辆架构、涉规技术、供应商、软件组件、证据与发布决策之间的可追溯层。最有力的试点是一个 MY2027 项目结合一个高风险连接域。其产出应是对一个简单问题的可重复回答:"在此配置中,哪个实体控制每一个涉规软件要素?有何证据?"
常见问题
这只是采购问题吗?
不是。采购掌握重要的供应商数据,但软件架构、仓库控制、签名权、远程访问、更新治理与企业所有权都会影响分析。
SBOM 能证明合规吗?
不能。SBOM 有助于识别软件组件,但其本身无法证明所有权、管辖权、指挥关系、开发控制、远程管理或规则所要求的交易层事实。
已合规的车辆在售后会变为不合规吗?
量产后更新或供应商控制权变更,可能使支撑原分析的事实失效。组织需要发布与变更控制,以在时间维度上保持合规基础。
MY2027 应优先完成什么?
优先处理涉规软件分类、供应商与子供应商来源、企业控制权分析、更新权,以及面向美国配置的发布卡点。
每个组织都应申请授权吗?
不是。授权与咨询意见是事实特定的工具。应先与合格法律顾问一道确定范围、替代方案,以及确切的技术与企业事实。
权威参考
- BIS Connected Vehicles 概览
- BIS《Connected Vehicles Rule 小型实体合规指南》
- BIS 信息与通信技术及服务办公室