3、项目定义：TARA的项目边界、假设条件、依赖关系定义

好，咱们进入TARA实战的第三讲。项目定义这一步，说实话，很多团队容易走过场。觉得不就是写几行字嘛，赶紧开始分析风险多好。但我得说，这一步要是没做扎实，后面全是坑。

我个人习惯，在启动任何TARA之前，先花半天时间，把项目边界、假设条件和依赖关系这三件事掰扯清楚。你想想看，连你要分析的东西到底有多大、哪些算你的、哪些不算，都没说清楚，那分析结果谁敢信？

3.1 项目边界：你到底在分析什么？

项目边界，说白了就是划地盘。你得明确告诉所有人：这个TARA分析的范围，从哪开始，到哪结束。

我记得有一次，一个客户说“分析我们整个智能座舱系统”。结果一开会，发现他们说的“整个系统”包括了手机APP、云端服务器、还有第三方地图服务。这哪是一个TARA能搞定的？

所以，定义边界时，我建议你至少回答这几个问题：

• 目标系统是什么？ 是单一ECU，还是整个域控制器？
• 包含哪些硬件和软件？ 比如：主芯片、操作系统、中间件、应用层。
• 外部接口有哪些？ 比如：CAN总线、以太网、蓝牙、Wi-Fi、OBD接口。
• 哪些东西明确不包含？ 比如：生产工具、售后诊断仪、手机APP。

我一般会用一张简单的表格来记录边界定义。嗯，就像下面这样：

边界项	包含	不包含	备注
硬件	域控制器主板、电源模块	传感器、执行器	传感器由供应商单独分析
软件	AUTOSAR基础软件、应用层	Bootloader、诊断栈	Bootloader在另一项目分析
通信	CAN、车载以太网	4G/5G、蓝牙	无线通信由Tier1负责

3.2 假设条件：你默认哪些事是对的？

假设条件，是TARA里最容易出问题的地方。为什么？因为大家默认“这事肯定没问题”，结果最后发现，问题就出在这。

举个例子。我曾经参与一个项目，团队假设“所有OTA升级包都经过签名验证”。结果分析做到一半，发现签名验证的密钥是硬编码在代码里的。这个假设直接导致风险等级评估错误。

所以，定义假设条件时，我建议你遵循一个原则：能验证的，就不要假设。实在验证不了的，才作为假设写下来。

常见的假设条件包括：

• 安全机制假设： 比如“假设HSM模块能正确保护密钥”。
• 环境假设： 比如“假设车辆在TARA分析期间未连接外部诊断设备”。
• 人员假设： 比如“假设开发人员遵循安全编码规范”。
• 第三方假设： 比如“假设供应商提供的组件已通过安全测试”。

我个人习惯，在项目定义文档里，给每个假设条件加一个“验证状态”列。比如：

假设编号	假设内容	验证状态	验证方法
A-001	HSM模块密钥存储安全	待验证	安全审计
A-002	OTA签名算法为ECDSA	已验证	代码审查
A-003	CAN总线无外部接入	待验证	物理检查

3.3 依赖关系：你的分析受谁影响？

依赖关系，就是告诉你：你的TARA分析，不是孤立的。它可能依赖上游的架构设计，也可能依赖下游的测试结果。

我记得有一次，我们做TARA时，发现某个关键安全机制依赖一个第三方库。但那个库的版本还没确定。结果我们只能基于“最坏情况”来做假设，导致风险分析结果偏保守。后来版本定了，又得重新分析一遍。

所以，定义依赖关系时，我建议你关注这几类：

• 输入依赖： 比如“依赖系统架构文档”、“依赖功能安全分析结果”。
• 资源依赖： 比如“依赖安全专家参与”、“依赖渗透测试工具”。
• 时间依赖： 比如“依赖在SOP前完成所有风险处理”。
• 外部依赖： 比如“依赖供应商提供安全评估报告”。

另外，依赖关系里有一个容易被忽略的点：依赖的变更管理。你想想看，如果上游的架构改了，你的TARA要不要更新？如果依赖的第三方库版本变了，你的假设还成立吗？

所以，我建议你在项目定义里，明确写一条：当依赖项发生变更时，需要触发TARA的重新评估。别等到项目快结束了，才发现分析结果已经过时了。

3.4 实战中的常见问题

嗯，这里我总结几个我在项目中踩过的坑，给你提个醒：

• 边界划得太宽： 想把整个车都分析一遍，结果分析到一半发现做不完。我建议你，第一次做TARA，先聚焦一个子系统，比如“智能座舱域控制器”。
• 假设条件写得太少： 只写了3条假设，结果后面发现一堆不确定的事。我建议你，至少写10条假设，覆盖安全机制、环境、人员、第三方。
• 依赖关系不更新： 项目定义写完后，就再也不看了。结果依赖项变了，TARA还是老版本。我建议你，每个迭代都检查一下依赖关系是否有效。

好，这一讲就到这里。下一讲，咱们聊聊“资产识别与分类”。说白了，就是搞清楚你到底要保护什么东西。到时候见。