4. HSM安全需求捕获与治理基线
HSM（Hardware Security Module）在AURIX中的安全能力并不是孤立存在的，它必须服务于整车层面的安全目标。因此，HSM安全需求的捕获不能从HSM自身功能出发，而应从整车TARA（威胁分析与风险评估）的输出——安全目标（Security Goal）开始，逐层派生到HSM的功能需求、接口需求和验证需求。这一过程的核心挑战在于：整车安全目标通常以“防止非授权访问”“防止固件篡改”等抽象语言描述，而HSM需求必须落到具体的密钥管理、安全启动、访问控制、加解密引擎配置等可执行、可验证的层面。
从整车TARA到HSM安全目标的映射
整车TARA的输出通常包含资产识别、威胁场景、攻击路径、影响评级和风险值。以“通过OBD接口刷写非授权固件”这一威胁场景为例，其安全目标可表述为“确保只有经过认证的固件才能被写入并执行”。该目标需要进一步分解为若干子目标：固件完整性验证、固件来源认证、刷写权限控制、刷写过程防中断保护。这些子目标中，固件完整性验证和来源认证直接落在HSM的安全启动与签名验证功能上；刷写权限控制涉及HSM的访问控制策略；刷写过程防中断保护则可能涉及HSM的看门狗与状态机管理。
映射过程中需要明确一个关键原则：安全目标到HSM需求的派生不是一对一的，而是一对多或多对一的网状关系。一个安全目标可能派生多条HSM需求，一条HSM需求也可能支撑多个安全目标。这种网状关系正是需求追溯性管理的核心对象。
HSM安全需求的派生方法
从安全目标派生HSM需求，推荐采用“目标分解—功能映射—参数约束”三步法。以SG-01“固件完整性”为例：首先将目标分解为“启动时验证”和“运行时验证”两个子目标；然后将子目标映射到HSM的具体功能，如安全启动（Secure Boot）的签名验证流程、HSM固件自身的完整性校验；最后为每条功能需求附加参数约束，例如签名算法必须为ECDSA P-256、哈希算法必须为SHA-256、公钥必须存储在HSM的OTP区域且不可改写。
参数约束是HSM需求区别于普通软件需求的关键。HSM的密钥存储位置（OTP、DFlash、HSM RAM）、访问权限（主机是否可读、是否可写）、生命周期状态（初始化、运行、调试、失效）都会直接影响安全目标的达成。因此，每条HSM需求都应附带明确的参数约束表，而不是仅描述功能行为。
需求追溯性的建立
需求追溯性要求建立双向链接：正向追溯从安全目标到HSM需求再到测试用例，确保每个安全目标都有对应的HSM需求覆盖，每条HSM需求都有对应的验证手段；反向追溯从测试用例回到HSM需求再回到安全目标，确保没有孤立的需求或测试。在实际项目中，推荐使用需求管理工具（如DOORS、Polarion或Jama）建立追溯矩阵，矩阵的行是安全目标，列是HSM需求，交叉点标注覆盖状态（完全覆盖、部分覆盖、未覆盖）。
追溯矩阵中需要特别关注“部分覆盖”和“未覆盖”的条目。部分覆盖通常意味着安全目标被多条HSM需求共同支撑，但每条只覆盖了目标的一部分，需要确认组合后是否完整覆盖。未覆盖则意味着存在安全目标没有对应的HSM需求，必须补充需求或调整安全目标。
治理基线文档的构成
治理基线文档是HSM安全需求管理的“单一事实来源”。一份完整的治理基线文档应包含以下核心内容：
- 需求追溯矩阵：记录SG与HSR的映射关系、HSR与测试用例的映射关系，以及每条需求的覆盖状态和验证状态。
- 需求规格说明：每条HSM需求的唯一标识、描述、来源安全目标、优先级、参数约束、验证准则和验收标准。
- 基线版本记录：基线编号、建立日期、包含的需求版本、变更历史、审批记录。基线一旦建立，任何需求变更都必须走变更控制流程。
- 治理角色与职责：明确需求负责人、评审人、批准人和变更控制委员会的职责边界。
需求变更的治理流程
HSM安全需求并非一成不变。整车TARA更新、法规要求变化、新威胁出现都可能触发需求变更。变更治理流程应包含：变更申请、影响分析、评审决策、基线更新和追溯矩阵同步。影响分析需要评估变更对已实现功能、已通过测试、已交付基线的影响范围。例如，若将签名算法从RSA-2048改为ECDSA P-256，则需评估HSM加解密引擎是否支持、密钥存储空间是否足够、安全启动流程是否需要调整、已有测试用例是否需要重写。
变更控制委员会（CCB）的决策应记录在基线文档的变更历史中，包括变更原因、影响范围、批准人和生效版本。只有经过批准的变更才能进入需求规格说明和追溯矩阵，未批准的变更不得在实现中体现。
治理基线的维护与审计
治理基线建立后，需要定期维护和审计。维护活动包括：需求状态更新（如从“已定义”到“已实现”到“已验证”）、追溯矩阵的完整性检查、基线文档的版本同步。审计活动则验证基线文档与实际实现的一致性，检查是否存在未记录的需求变更、未覆盖的安全目标或未验证的HSM需求。
审计的典型触发点包括：项目里程碑评审、HSM固件发布前、整车安全审核前、法规认证前。审计输出应包含不符合项清单和整改建议，整改完成后更新基线文档并重新审计，形成闭环。