第4章：安全案例编写

安全案例这东西，说白了就是一份「自证清白」的文档。你得向审核员证明：我的产品是安全的，所有风险都处理了，所有流程都走完了。我刚开始做安全案例时，总觉得这是走形式。后来有一次项目审核，对方就盯着安全案例问了一整天……嗯，从那以后我再也不敢马虎了。

4.1 安全案例的结构与要素

一个完整的安全案例，我个人习惯分成三大块：声明部分、论证部分、证据部分。这三块缺一不可。

4.1.1 核心要素清单

要素	说明	我的经验
安全目标	明确ASIL等级和对应的安全要求	一定要写清楚ASIL等级，别含糊
功能概念	描述系统功能及其安全相关行为	用图说话，文字为辅
危害分析	HARA的结果，包括危害事件和风险等级	我曾经漏掉一个场景，后来补了三天
安全措施	技术安全概念、硬件/软件安全机制	每个措施都要有对应的验证结果
证据链	测试报告、评审记录、工具鉴定等	证据要能追溯到具体需求

4.2 安全案例的编写方法

写安全案例，我建议你按这个步骤来。这是我在几个项目里摸索出来的，踩过坑才总结出来的。

4.2.1 第一步：搭框架

先别急着写内容。把目录结构定下来。我个人习惯用GSN（目标结构表示法）来画安全论证图。你想想看，一张图就能说清楚安全目标怎么分解、怎么实现，比纯文字强太多了。

安全案例框架示例（GSN风格）：
├── G1: 系统满足所有安全目标
│   ├── S1: 安全目标已定义
│   │   ├── 证据E1: 安全目标列表
│   │   └── 证据E2: ASIL等级分配
│   ├── S2: 安全措施已实现
│   │   ├── 证据E3: 技术安全概念文档
│   │   └── 证据E4: 安全机制测试报告
│   └── S3: 安全措施已验证
│       ├── 证据E5: 集成测试报告
│       └── 证据E6: 安全评审记录

4.2.2 第二步：写论证

论证部分是最考验功力的。你得说清楚「为什么这样设计是安全的」。我曾经犯过一个错：只写了「做了什么」，没写「为什么这么做」。审核员直接问：「你凭什么认为这个机制能覆盖所有故障？」

所以，每个安全措施都要回答三个问题：

• 覆盖什么故障？——对应HARA中的危害事件
• 怎么工作的？——技术原理和实现方式
• 怎么验证的？——测试用例和通过标准

4.2.3 第三步：整理证据

证据是安全案例的「硬通货」。没有证据，你说得天花乱坠也没用。我建议你建一个证据清单，每条证据都要标注：

• 证据编号（唯一标识）
• 证据类型（测试报告/评审记录/工具鉴定等）
• 关联的安全目标
• 版本号和日期
• 存放位置（文档路径或工具链接）

4.3 安全案例的维护

安全案例不是写完就完事了。项目在变，需求在变，安全案例也得跟着变。我见过最惨的情况是：产品都量产了，安全案例还是初版的内容。这要是被审核到，后果很严重。

4.3.1 什么时候需要更新？

• 需求变更时——新增功能或修改功能，必须重新评估安全影响
• 设计变更时——硬件换型、软件重构，安全措施可能失效
• 发现新风险时——测试中暴露的新故障模式，要补充到HARA里
• 标准更新时——ISO 26262第二版和第一版就有不少差异

4.3.2 维护流程

我建议你建立一个变更管理流程。每次变更都要走这个流程：

1. 变更申请——谁改的、改了什么、为什么改
2. 影响分析——这个变更会影响哪些安全目标？
3. 安全案例更新——修改对应的论证和证据
4. 评审确认——至少要有两个人看过，确保没遗漏
5. 版本归档——旧版本要保留，方便追溯

4.3.3 工具支持

说实话，用Word写安全案例真的很痛苦。版本控制、交叉引用、变更追踪，这些用Word做起来太费劲了。我建议你用专门的工具：

• 需求管理工具（如DOORS、Polarion）——可以建立安全目标到证据的追溯链
• GSN建模工具（如Adelard ASCE、NOR-STA）——画安全论证图很方便
• 配置管理工具（如Git、SVN）——版本控制是必须的

嗯，这里要注意：工具只是辅助，核心还是内容。别为了用工具而用工具，把安全案例搞得花里胡哨的，结果内容一塌糊涂。

最后说一句：安全案例是写给审核员看的，也是写给自己看的。好的安全案例，能让审核员快速理解你的安全设计思路，也能让团队成员在后续维护时少走弯路。我做了这么多年功能安全，越来越觉得：安全案例写得好不好，直接反映了这个团队的安全文化水平。