RASMIL-STD-882E 所要求的软件安全案例
VisualPro Tech Brief
MIL-STD-882E 所要求的软件安全案例
问题不在于分析，而在于关联
MIL-STD-882E 系统安全 | 国防软件安全论证 | 行业动态简报
MIL-STD-882ESwHASSRSwCI 1-5安全案例
01概述（TL;DR）— 882E 要求的是论证，而不是文档
美国国防部系统安全标准 MIL-STD-882E 规定，在从概念探索到退役处置的整个生命周期内，须以有计划、有纪律的方法消除危害，并将无法消除的风险降至最低。该标准广泛适用于武器、车辆和飞机；如今软件已承担大部分功能，实践的重心也随之转向构建软件安全案例。
安全案例不是一摞报告，而是一个主张–论据–证据的层级结构，用以论证：所有可预见的危害均已识别，控制措施已将每项危害降至可接受的风险水平，这些控制措施已被正确实现，且残余风险已获得正式接受。它并不主张软件没有缺陷——这样的主张无法实现，也不是 882E 的要求。
而在实践中，这一论证崩塌之处并不在于分析的深度，而在于分析与验证之间的关联。
软件安全工作最常见的失败不是分析不足，而是后续衔接不足。
02为何是现在——推动国防软件安全论证的三重压力
1软件已成为危害的主要路径危害路径转移
随着武器系统的功能转移到软件中，导致灾难性危害的贡献路径也随之转移。882E 将软件对硬件的控制程度（五类软件控制类别）与严重度（四个等级）交叉，构成软件安全关键性矩阵（SSCM），由此得出软件关键性指数（SwCI 1-5），并据此确定所需的严格度等级（Level of Rigor）。关键性越高，代码覆盖率目标、独立验证和形式化分析就越成为必须履行的义务，而非可选项。
2合同明确规定交付物合同要求
882E 的任务在合同工作说明书（Statement of Work）中规定，交付物以 CDRL 形式提交。在软件密集型系统中，工作量主要集中在五项任务上——Task 205（软件安全要求分析）、Task 206（软件安全设计分析）、Task 301（安全评估）、Task 302（试验与评价安全）以及 Task 303（系统安全工作评审）。安全数据包中包括 SwHA 工作表、SSR 清单和追溯矩阵、软件 FMEA、安全关键测试用例及结果、覆盖率报告、危害风险决策报告（HRDR）以及安全评估报告。
3能力差距即是合同差距竞争地位
残余风险的接受权限随危害风险指数（HRI）而变化。灾难性且频繁发生的危害（HRI 1）须上报至里程碑决策当局；可忽略且极不可能发生的危害（HRI 20）则在工作组层面即可关闭。安全案例是一份动态文档——每次软件修改都需要评审，任何涉及已接受残余风险的变更都需要新的 HRDR。依靠文件维持这一循环的组织与依靠工具维持这一循环的组织之间，差距正在拉大。
03882E 软件安全分三个阶段逐层展开
三阶段分析链
| 阶段 | 工作内容 | 交付物 |
|---|---|---|
| PHA 初步危害分析 | 通过功能分解和运行概念识别系统级危害 | 危害清单、初始 HRI、贡献功能 |
| SwHA 软件危害分析 | 将系统危害映射到软件失效模式 | 危害–失效模式工作表 |
| SSR 推导 软件安全要求 | 规定针对每种失效模式所要求的软件行为 | 正向、负向、范围约束以及监控要求 |
SSR 采用四种规范形式编写——正向约束（必须执行的动作）、负向约束（禁止的状态）、范围约束（有效输出边界）以及监控要求（使危害能够被探测的条件）。
五环追溯链——真正断裂的地方
| 环节 | 要求内容 |
|---|---|
| PHA 危害 → SwHA | 所有存在软件贡献的危害都须落到 SwHA 的某一行 |
| SwHA → SSR | 每一行 SwHA 至少对应一条 SSR |
| SSR → SRS/SDD | 每条 SSR 都对应到需求规格和设计文档中的具体条目 |
| SSR → 验证证据 | 每条 SSR 都有测试用例、覆盖率、软件 FMEA 或评审记录作为证据 |
| 证据 → 配置基线 | 每项证据都绑定到确切的软件版本 |
要点 原文将追溯性描述为“SwHA 质量的运行指标”，并指出追溯缺口是评审周期中 SwHA 返工最常见的原因。最后一个环节同样没有商量余地：如果没有配置基线来确切标识所测试的版本，测试结果就不是可复现的证据。
04SwHA 的五类失效模式与 FMEA、STPA 共享同一骨架
SwHA 将系统危害分解为五种规范的软件失效模式。这一分类在结构上对应于我们已在使用的两种方法。
| 882E SwHA 失效模式 | FMEA 视角 | STPA 视角 |
|---|---|---|
| 错误输出 | 功能异常——值或状态错误 | 提供导致危害的控制行为（UCA） |
| 无输出（遗漏） | 功能丧失 | 未提供所需的控制行为（UCA） |
| 延迟输出 | 时序失效 | 时序或顺序错误（UCA） |
| 误输出 | 非预期动作 | 在不需要时提供控制行为（UCA） |
| 输出至错误目标 | 接口失效 | 控制路径缺陷——属于损失场景范畴 |
前四种与 STPA 的不安全控制行为类型直接重合；第五种不是 UCA，而是对应于 STPA 损失场景中的控制路径缺陷类别。这意味着，两种分析方向相反的方法覆盖的是同一个失效空间。
实践意义 882E 并不要求您学习一种新的分析语言，而是要求在同一结构上关联 FMEA 的失效模式维度、STPA 的控制视角和 FTA 的逻辑展开，并一路追溯到证据。事实上，软件 FMEA 已在安全数据包中被明确列为交叉核查 SwHA 完整性的证据。
实践意义 882E 并不要求您学习一种新的分析语言，而是要求在同一结构上关联 FMEA 的失效模式维度、STPA 的控制视角和 FTA 的逻辑展开，并一路追溯到证据。事实上，软件 FMEA 已在安全数据包中被明确列为交叉核查 SwHA 完整性的证据。
05VisualPro 如何提供支持
一棵结构树，五种分析结构共享
FMEA、FTA、HARA、TARA 和 STPA 共享同一个系统结构数据库。PHA 中识别的危害被放置在结构树上，SwHA 失效模式和 FTA 逻辑展开也在同一棵树上延续。危害无需重复录入。
SSR 与证据的可追溯性核心价值
危害、失效模式、安全要求和验证项在单一数据库中双向关联。882E 所要求的追溯矩阵直接由分析数据库生成，因此一旦发生设计变更，断开的关联会立即暴露。原文所指出的“最常见的失效模式”正是在这里于工具层面被阻断。
严重度与关键性体系评级体系
由四级严重度和五级概率构成的危害风险指数，以及基于软件控制类别得出的 SwCI，均可按项目进行配置，其处理方式与 AIAG-VDA AP、ISO 26262 ASIL 和 ISO/SAE 21434 CAL 相同。
基于 MCP 的 AI 智能体集成AI 集成
VisualPro 为 FMEA、FTA、HARA、TARA 和 STPA 提供 MCP（Model Context Protocol）支持，使 Claude 等 AI 智能体能够直接与 VisualPro 通信：从候选失效模式识别到 SSR 草拟，均可通过对话完成，分析人员则专注于验证与判断。对没有专职安全团队的供应商而言，效果尤为显著。
06常见问题（FAQ）
Q1汽车领域的 FMEA 能力能否迁移到国防软件安全论证？
原理是相同的。危害识别、失效模式分解、要求推导和验证追溯构成了 ISO 26262 与 882E 共享的骨架，SwHA 的失效模式分类也与 FMEA 相对应。不同之处在于评级体系（ASIL 对应 SwCI 和 HRI）、交付物名称（安全案例、HRDR、SDP），以及任务通过合同 SOW 和 CDRL 规定这一点。这只是统一表示方法与交付物的问题，而不是学习一种新方法。
Q2安全案例必须用 GSN 绘制吗？
不必。原文明确指出，Goal Structuring Notation（GSN）是可视化层级关系的一种方式，但并非必需，无论采用何种表示法，关键在于逻辑结构本身。重要的是主张、论据和证据之间是否无缺口地连接起来，以及这些连接能否被追溯。
Q3我们已经完成了 SwHA，但在评审中收到了返工意见。应该从哪里着手检查？
先从追溯缺口查起——原文指出这是导致 SwHA 返工最常见的原因。检查以下四点：存在软件贡献却没有对应 SwHA 行的危害、未落实到任何 SSR 的 SwHA 行、未与测试用例关联的 SSR，以及未标识版本基线的测试结果。大多数问题都会从这四点中暴露出来。
07立即开始（Next Step）
国防软件安全论证需要同时具备分析能力和追溯能力，而后者离开工具便难以维持。借助已在汽车、半导体和机器人项目中得到验证的 VisualPro，准备一份在同一结构上将危害一路关联到验证证据的安全案例。
从危害到证据，环环相扣——借助 VisualPro 开展国防软件安全论证。
参考资料——Corvus Intelligence, “Software Safety Case Development under MIL-STD-882E”（2026-06-25）；LDRA, MIL-STD-882E / JSSSEH 资料