速览.

大多数平台评估奖励功能列表和基于厂商数据的演示，随后在生产中栽在变型、重新导入和审计轨迹上。应改为：以您现有工具栈今天无法回答的问题给候选平台打分，在您自己的文件上验证，按 OEM 或 Tier-1 角色加权，并以部署和身份要求作为门禁。

汽车网络安全平台评估已成为 OEM 与 Tier-1 团队的一项常规工作，而许多团队做得不好，原因也不难理解：招标需求是一份功能列表，演示跑在厂商的样例数据上，评分表奖励的是勾选最多的那一列。几个月后团队才发现，TARA 说不清某项风险适用于哪些变型，或者审计轨迹停在"记录已修改"这一行。

这份检查清单写给真正做决定的人：CSMS 负责人、PSIRT 与 VSOC 负责人、工程经理，以及审核部署与身份要求的 IT 安全和采购人员。七个领域每一个都采用同样的结构：提问、演示验证、风险信号，以及 OEM 与 Tier-1 应如何加权。它不点名任何厂商，也不做任何排名。

从现有工具栈无法回答的问题出发

列出五到十个组织回答得很慢或根本无法回答的问题：哪些项目群和变型搭载了某个组件版本；哪些控制措施处置了某项风险，哪些测试在已交付基线上验证了这些措施；哪些市场的车辆搭载了某个活跃 CVE 所波及的零件号。这些问题就是演示脚本，一个能在您自己的文件上、从关联记录中回答这些问题的平台，做到了电子表格做不到的事。

让通用工具留在原位：工单系统、GRC 平台和 SIEM 继续扮演各自的角色，它们留下的空白见为何通用 GRC 与 ITSM 平台会丢失汽车网络安全上下文。评估的对象是作为关联、带版本记录的产品模型。

权重因角色而异。OEM 主要为项目群层面付费：众多项目和供应商、变型、车队暴露面以及事件指挥。Tier-1 则为 TARA 深度付费，并为 OEM 无需重新录入、也无需购买席位即可读取的证据付费。

用今天回答不了的问题给平台打分，而不是用已经拥有的功能。

架构建模：按工程实际而非图纸建模的系统

提问：平台能否从工程源记录系统以 UML/XMI 和 AUTOSAR ARXML 格式导入架构，而不要求重新绘制？它是否承载组件类型、协议和加密等连接属性以及信任边界？车辆架构中的每个组件能否链接到其独立的安全项目，使组件级分析汇总到项目群？一个 ECU 能否容纳多个软件单元，每个单元拥有自己的架构和 SBOM？

应索取的验证：导入一个真实模型。一次可靠的导入会在保存前显示一致性摘要，列出继承环或找不到接口的端口等质量警告，并把未绘制的元素记入降级清单，确保没有内容被静默丢弃。对生产项目，要求由第二人审批的分阶段导入，每一步都进入审计轨迹。

风险信号：杂乱模型没有任何警告；组件只是没有属性的图形；项目群只是项目的文件夹，而不是项目群与车辆架构中描述的车辆架构。

权重：OEM 高，因为项目群层面和变型都依赖于此；Tier-1 中，随着客户要求按交付物提供架构级证据而上升。

TARA：生成式风险、受治理的评分与可追溯的处置

提问：风险是从链接到攻击路径的威胁场景生成（每个资产和网络安全属性一条），还是手工录入？影响是否取自关联的损害场景在安全、财务、运营和隐私四个维度的评级，可能性是否取自攻击可行性，网络安全保障等级（CAL）是否由影响和攻击向量推导？策略是否定义风险方法、可接受等级和允许的处置策略，并拒绝其不允许的操作？处置是否记录策略（降低、保留、转移或规避）、理由、负责人和残余风险，把降低的风险链接到目标、需求和控制措施，把保留的风险链接到带证据的声明？方法本身见 ISO/SAE 21434 TARA 指南。

应索取的验证：导入一份您自己的 TARA（电子表格或 OpenXSAM 格式），沿一条风险从资产追到测试用例。删除该资产，风险应被标记为引用已移除，而不是消失。在只接受中等及以下等级的策略下尝试保留一项高风险。凡是由 AI 推荐处置的地方，询问建议如何被接受或拒绝，以及 AI 增补的记录是否带有评审人必须确认的标记。

风险信号：可以手动编辑的风险分值；只是填好模板的合规面板；没有残余风险；无法按基线建立版本的 TARA，这正是 TARA 版本控制要解决的问题。

权重：Tier-1 高，因为 TARA 深度就是交付物；OEM 高，重点在于跨（比如说）14 个组件项目的汇总。

SBOM 与 CVE 影响分析：从组件到零件号

提问：支持哪些格式（至少 CycloneDX 和 SPDX）和哪些重新导入选项（合并、替换、仅更新），使供应商的重新交付被比对差异而不是被覆盖？匹配哪些漏洞来源，包括 GB 44495 适用时的 CNVD 等区域漏洞库，策略是否控制哪些来源可信？是否有包含"已接受并附理由"和"已抑制为误报"的状态工作流，使一份"不受影响"声明成为记录而不是一封邮件？最重要的是，架构模块是否映射到 SBOM 组件——按包 URL 或唯一名称自动匹配，歧义时搁置待审——漏洞能否从软件组件追溯到软件单元、系统组件、零件号、车辆和市场？

应索取的验证：带来您自己某个软件单元的 SBOM，且该单元的架构也能导出。匹配后读取三个数字：已匹配、未匹配组件、未匹配模块。选一个带已知漏洞的组件，要求查看它穿过架构的影响范围，再要求查看哪些市场的车辆搭载了它所波及的零件号。如果链路不完整，平台应当明说，正如汽车 CVE 跨车辆变型的影响范围所解释的。

风险信号：没有状态工作流的漏洞计数；真实 SBOM 上零歧义；只是一份联系人列表的"供应商管理"。格式方面见 CycloneDX 与 SPDX 在汽车领域的对比。

权重：OEM 高，为的是零件号与车队链路；Tier-1 高，为的是按交付物的卫生状况和站得住脚的"不受影响"声明。

事件处理：从车队信号到已实现的风险

事件必须链接到受影响的组件、建模了该攻击的风险、存在漏洞的软件以及本应检测到它的控制措施，并反馈到 TARA。提问：哪些来源可以开启事件（人工报告、自动监控、威胁情报、漏洞扫描、外部方）？当已确认的事件表明某个建模过的攻击正在发生时，风险是否被标记为已实现？当攻击从未被建模时，是否会提出 TARA 缺口供工程团队补齐？按严重性划分的响应时间是否在策略中设定并强制执行？

应索取的验证：从一条威胁情报告警开启事件，将其链接到一个组件和一项风险，添加一条更新和一个附件，然后检查该风险的状态。询问项目群负责人如何看到它：按市场划分的未关闭事件，与漏洞和风险并列在同一视图中，并有一张以该事件为锚点的追溯图。索取 webhook 通知，以及平均解决时间之外的指标（超越 MTTR 的事件响应指标）。

风险信号：无法链接到风险或组件的事件；没有回到 TARA 的路径；没有强制执行的 SLA 字段。评估人期望看到的关闭证据见汽车事件关闭证据检查清单。

权重：OEM 极高，因为生产后监控和全车队响应是 OEM 在 UN R155 下的义务，而欧盟 CRA 又增加了报告责任；Tier-1 中，重点在于与 OEM 之间的双向升级。

证据与可追溯性：基线、审批与审计轨迹

以上一切只有在平台能够复现决策做出时记录的原貌时才成立。提问：是否有项目基线，已发布基线只读且可分支出新的草稿？设计冻结是否在保障链继续推进的同时保护 TARA？变型是否经过建模，使共享实体无法从某一变型内部被修改？以某条发现为锚点的项目群级追溯图能否以链接形式分享并还原完全相同的视图？策略是否自动建立版本，削弱性变更是否需等待第二位审批人？声明能否携带上传的证据并带有"待证据"或"已验证"等状态？

应索取的验证：发布一个基线，尝试编辑其中的一项风险，再分支出草稿并在那里做修改。索取一次分阶段导入和一次策略变更的审计轨迹。索取触及某项风险的每一条记录，再在项目群层面对某个漏洞做同样的事。这条链路在汽车网络安全可追溯性实用指南中有描述，评估人的视角见 CSMS 审核准备。

风险信号：所谓"版本管理"就是导出一份 PDF；没有字段、操作者和理由的审计日志；策略是文档而不是强制执行的配置。

权重：双方都高。OEM 需要它来支撑 UN R155 和 R156 下的型式认证；Tier-1 需要它，因为每一次交接都是一个基线，而客户会依据 ISO/SAE 21434——并日益依据 CRA——进行审核。

集成：分阶段导入、开放格式与回流的状态

按类别和方向评估集成，而不是数 logo。贯穿整条流水线：通信矩阵输入（ARXML、DBC、VSS）；系统建模（UML/XMI、SysML、AUTOSAR）；从诊断目录识别资产（ODX、CDD）；TARA 导入（电子表格、OpenXSAM）；需求交换（ReqIF）；软件架构与 SBOM（CycloneDX、SPDX）；代码与二进制分析发现（SARIF）；漏洞数据库；作为验证证据返回的台架测试；数据交换（STIX、PDF、CSV、Excel）；VSOC 与威胁情报（事件流、STIX 摄取）；以及身份（SAML 2.0、LDAP）。将 SIEM 与 VSOC 连接到工程工具涵盖运营侧。

提问：每一次导入是否都在落入图谱之前经过暂存和评审？当某项处置在工单系统中创建任务时，状态是否回流？标识符是否在往返过程中得以保留：SARIF 中的 CWE、SBOM 中的包 URL、ReqIF 中的需求 ID？API 是否包含在您的版本层级中？应索取的验证：在您的文件上完成一次往返——架构导入，需求以 ReqIF 导出，SBOM 导入，一条发现经 SARIF 导入，一个任务导出并且其状态回流。风险信号：单向导出；没有格式版本的连接器列表；无法预览的导入。

权重：OEM 高，为的是 VSOC、威胁情报和工单往返；Tier-1 高，为的是与需求工具的互换和 OEM 可读的导出。

面向 OEM 与 Tier-1 的部署和安全要求

部署往往在工程评估之后才决定，这是本末倒置：一个无法在您的数据被允许存放之处运行的平台，根本不是候选者。托管订阅适合数据分级允许的部门；私有云使用组织自己的租户环境；本地部署和物理隔离部署则是涉密车辆数据以及有数据驻留规则的市场的常态。对于物理隔离实例，首要问题是漏洞源如何到达：答案必须是具有明文规定节奏的离线漏洞源同步。

要求为何重要应提的问题应索取的验证
SSO / SAML入职与离职由身份提供方一次性处理支持哪些协议（SAML 2.0、LDAP），在哪个版本层级？通过您的身份提供方登录；被移除的用户失去访问权限
RBAC供应商、评审人和审批人看到的内容不同权限是否按模块和操作（读取、写入、处置、审批、导出）划分？一个只能看到共享证据的供应商账户
MFA审批需要的不只是密码能否对所有用户强制启用，对生产变更要求更强因子？一次生产导入提交要求新的通行密钥
审计轨迹评估人会问谁在何时为何改了什么每一次变更（包括策略和导入）是否记录操作者、字段、时间戳和理由？导出一次分阶段导入和一次策略编辑的轨迹
数据驻留车辆与供应商数据可能不得离开某一司法辖区各模式下数据存储在何处；中国等市场是否提供区域内托管？各模式的数据流说明；合同中的区域选项
物理隔离漏洞源同步匹配结果只与漏洞源一样新NVD、OSV 和区域漏洞源如何离线交付，频率多高，完整性校验是什么？在断网实例上离线导入漏洞源，漏洞源日期可见
API 访问自动化需要稳定接口有文档、带版本、包含在层级中、遵守 RBAC？用一个受限范围的令牌通过 API 读取您自己的项目

OEM 应把 SSO、RBAC、审计轨迹和数据驻留当作通过/不通过项。Tier-1 应补上表中遗漏的一项要求：与在供应商实例中不持有许可的客户共享证据。

可打印的汽车网络安全平台评估检查清单

下表把七个领域合并为可评分的行。权重分为高（H）、中（M）或通过/不通过（P），先列 OEM，再列 Tier-1。

领域问题应索取的证据权重（OEM / Tier-1）
架构导入带一致性摘要、警告、降级清单和分阶段审批；组件链接到各自的项目？导入您的模型；分析、审批、提交的审计轨迹；项目群到项目的导航H / M
TARA风险由威胁场景和攻击路径生成；影响、可能性和 CAL 为推导所得？一条风险从资产追到控制措施；删除资产后显示标记H / H
TARA策略设定可接受等级和处置策略并拒绝违规；处置记录残余风险和链路？在严格策略下保留一项高风险；处置向导；保障图H / H
SBOMCycloneDX 与 SPDX 导入；合并、替换、仅更新；状态工作流？重新导入一份已变更的供应商 SBOM，显示差异M / H
SBOM模块与组件匹配，歧义搁置待审；CVE 追溯到零件号和市场？已匹配与未匹配计数；一条 CVE 追到市场，或诚实的"链路不完整"H / H
事件链接到组件、风险和软件；已确认攻击将风险标记为已实现；未建模攻击提出 TARA 缺口；SLA 强制执行？从威胁情报告警到风险状态的完整事件流程；向测试端点发送 webhookH / M
证据已发布基线只读且可分支；设计冻结；变型保护；追溯图可通过链接分享？发布基线，尝试编辑，分支出草稿；重新打开分享的追溯图链接H / H
治理策略自动建立版本；削弱性变更需第二位审批人；ReqIF 导出？带"待审批"横幅的策略编辑；ReqIF 文件H / H
集成往返：ReqIF 导出、SARIF 导入、工单导出、状态回流、标识符保留？在您的文件上完成往返H / H
部署身份、RBAC、MFA、审计、数据驻留、物理隔离漏洞源、API 符合上表？部署表中的每一项验证P / P

三条规则让评分保持诚实。提前一周发送您的文件并坚持演示在其上运行；在厂商数据上的演示任何一行最多得一分。每行按零到三分评分：未展示、在厂商数据上展示、在您的数据上展示、在您的数据上展示并附审计轨迹。最后在一个项目群和一个基线上做限定时间的试点。供应商网络安全问卷把同样的纪律用在交接的另一侧。

ThreatZ 如何回应这份检查清单

ThreatZ 围绕这份清单反复追问的关联记录而构建。它的架构模型导入 UML/XMI 和 AUTOSAR，并把每个车辆组件链接到项目群内其独立的安全项目。风险由威胁场景和攻击路径生成，依据损害场景和攻击可行性评分，由影响和攻击向量赋予 CAL，并受一套拒绝其不允许操作的策略治理。处置把每项风险链接到目标、需求和控制措施，或链接到带证据的声明，ISO/SAE 21434 合规面板标出缺口。Software Composition（软件成分）把架构模块与 SBOM 组件匹配，并在 Traceability Map（追溯图）和 Fleet and Risk Map（车队与风险图）上把漏洞经软件单元、系统组件和零件号追溯到 VIN 和市场。事件在确认后把建模过的风险标记为已实现，在攻击从未被建模时提出 TARA 缺口。这为 ISO/SAE 21434、UN R155 与 R156、欧盟 CRA 和 GB 44495 工作提供证据支撑；它不替代评估本身。

Team 与 Professional 层级以托管订阅形式在 AWS Marketplace 上运行，Professional 及以上提供 MFA 和 RBAC。Enterprise 增加项目群层、车队图和事件指挥、供应商工作区、SSO/SAML 和 API 访问，以及表中的部署选项：私有云或本地部署——支持物理隔离，配有离线漏洞源同步和面向 GB 44495 工作的区域内托管。许可按命名用户、按层级计费，按年结算；只查看共享证据的供应商共享访客免费。每次评估都可以从基于样例车辆数据的四周免费试用开始。

常见问题

一次汽车网络安全平台评估应持续多久？

按阶段而非按日历规划：用一到两周商定尚未回答的问题并收集文件，对每个候选平台在这些文件上做一次脚本化演示，再对入围平台在一个项目群和一个基线上做限定时间的试点。四周试用正好匹配试点；拖得更久的评估通常缺的是脚本，而不是时间。

OEM 与其 Tier-1 供应商应当使用同一个平台吗？

未必；这份清单允许双方独立评分。接口处真正重要的是证据以开放格式跨越接口——需求用 ReqIF，SBOM 用 CycloneDX 或 SPDX，TARA 内容用 OpenXSAM——并且供应商能够与客户共享记录，而客户无需在供应商的实例中购买席位。

托管部署对车辆网络安全数据而言可以接受吗？

这取决于数据分级和司法辖区，这也正是部署表作为门禁而非评分行的原因。许多部门运行着带 SSO、MFA 和 RBAC 的托管订阅。涉及涉密车辆数据或严格驻留规则的项目群通常要求私有云、本地部署或物理隔离运行，并配以离线漏洞源同步。

应如何评估 TARA 平台中的 AI 功能？

把 AI 当作评审人辅助的起草工具，并测试围绕它的控制：建议能否被明确接受或拒绝，生成的记录在有人确认之前是否带有可见标记，风险分值是否仍然由威胁模型和策略推导而来？一条悄无声息落入保障链的建议是一个治理问题。

最能说明问题的单项演示请求是什么？

在威胁模型中删除一个资产，观察其风险会发生什么；然后重新导入一份已变更的供应商 SBOM，观察之前那份会发生什么。两项测试都显示平台是否把关系当作受管数据来维护。标记出"引用已移除"和比对差异的重新导入算通过；消失的风险和静默覆盖算失败。

要点速览
  • 先写脚本再选型： 写下现有工具栈回答不了的问题，并在您自己的文件上用它们检验每一次演示。
  • 按角色加权： OEM 侧重项目群层、车队暴露面和事件指挥；Tier-1 侧重 TARA 深度、按交付物的 SBOM 和低成本的交接。
  • 导入必须分阶段： 一致性摘要、警告、降级清单和第二人审批，把受管导入与简单粘贴区分开来。
  • 风险是生成的，不是录入的： 源自威胁场景和攻击路径，依据损害场景和可行性评分，由强制执行的策略治理。
  • 沿 CVE 追到零件号： SBOM 的价值在于从组件到软件单元、系统组件、零件号、车辆和市场的链路。
  • 事件反哺 TARA： 已确认的攻击把其风险标记为已实现；未建模的攻击提出 TARA 缺口。
  • 部署是门禁： SSO、RBAC、MFA、审计轨迹、数据驻留、物理隔离漏洞源同步和 API 访问是通过/不通过项，在功能评分之前决定。

VxLabs Security 相关延伸阅读

权威参考

  • ISO/SAE 21434 道路车辆——网络安全工程 — ISO 与 SAE International, ISO/SAE 21434
  • 联合国第155号法规 网络安全与网络安全管理系统 — UNECE, R155
  • 联合国第156号法规 软件更新与软件更新管理系统 — UNECE, R156
  • 网络弹性法案 — 欧洲议会与理事会, Regulation (EU) 2024/2847
  • GB 44495-2024 汽车整车信息安全技术要求 — SAMR/SAC, GB 44495-2024
  • ISO/PAS 5112 道路车辆——网络安全工程审核指南 — ISO, ISO/PAS 5112