一人成军_从零搭建基于 Openclaw(兼容Hermes)的功能安全 Agent(11)软件安全分析(上)

输入提炼 · 图片识别 · 分析框架 · 活动卡体系

前几章讲完了 FMEA 与 FMEA-MSR 的系统级安全分析——从接口分类到失效模式穷举再到三级审查。这一章转向软件层面。

软件安全分析（Software Safety Analysis, SSA）是 ISO 26262-6 要求的核心活动。它的目标不是”验证软件没有 Bug”，而是证明软件架构设计能够满足安全需求——数据路径上每一步的 ASIL 等级没有断档，每一条时序链路满足故障容错时间，每一种运行模式下的降级路径都已被覆盖。

不同于 FMEA——FMEA 有 AIAG & VDA 7-Step 这样的标准化方法论，有 Table 30 这样的”官方字典”——软件安全分析在工程实践里更依赖”对架构的理解”而不是”套模板填表”。一份几百页的软件架构文档、十几张时序图、五层软件分层——分析质量直接取决于对这份文档的理解深度。

我在 Openclaw和Hermes Agent 上跑通了整套软件安全分析流水线。这篇分上下两部，上半部讲输入处理、图片识别、分析框架和活动卡体系，下半部讲技巧总结、教训梳理和完整工作流展示。

不论你使用的是Hermes还是Openclaw，相信这篇文章都可以给你提供帮助。

──────────────────────────────────────────────────

一、必要输入和关键信息提炼

软件安全分析需要的输入材料比 FMEA 更多、更杂。FMEA 的核心输入是架构接口清单和 FSR 安全需求表——相对扁平。SSA 需要的是一整套立体信息。

1.1 五类必要输入

第一，软件架构文档。这不是一份扁平的结构图。一份合格的软件架构文档至少包含五层信息：整体分层架构（基础软件 → 运行时环境 → 应用层）、端到端数据链路（从传感器到执行器的完整路径）、逐场景时序图（每种运行模式下任务调用的先后顺序和时间约束）、安全完整性机制（看门狗、内存保护、端到端校验等底层机制的实现位置）、以及任务调度设计（各任务优先级、周期、中断结构）。分析的质量取决于对这五层信息的理解深度。

第二，安全需求表（SSR / FSR）。每一条安全需求标定了 ASIL 等级和故障容错时间（FTTI）。SSA 要回答的问题是：软件架构的设计能否满足这些需求？每条路径上的每个组件是否分配了足够的安全等级？每个场景的端到端延迟是否小于 FTTI？

第三，分析模板。模板定义了分析的维度——数据路径分析要检查哪些列、时序分析要包含哪些计算表、运行模式要覆盖哪些状态。模板不是建议，是约束。跳过模板中的任何一列，意味着对应的安全风险维度没有被评估。

第四，分析指南。指南定义了每个分析步骤的验收标准——怎么判断一个分析结论是”充分”的、什么情况下需要标记开口项、依赖故障分析要深入到什么程度。指南里的要求不是”建议”，是”必须”。

第五，安全手册（如有）。如果软件路径上有带安全手册的元件（如特定型号的 MCU），手册中声明的安全机制和诊断覆盖率是分析的硬输入——不能凭经验推断。

图1: SSA 输入处理流水线 — 从五类输入到 Agent 上下文的全流程

1.2 关键信息提炼的三个要点

输入材料扔给 Agent 只是第一步。真正有用的信息往往藏在容易被忽略的地方。

第一，架构图里的颜色标注是最危险的信息丢失点。大多数架构图用颜色标记安全等级——安全相关组件和非安全组件的颜色不同。这个信息在文字描述里经常缺失。一个基础软件组件到底是否具有安全等级？文字描述可能写”基础软件层，透明传输”，看着不像安全组件——但架构图上它是安全颜色的，说明它实际被分配了安全等级。如果这一步判断错误，整条链路的安全等级一致性论证全部作废。

第二，分析之前，我们不光要定义模板，还要根据模板的正确使用方法总结成指南进行输出。模板的作用是定义分析范围，而指南就是明确指出模板中的每一页该如何正确使用。分析模板的每一列都必须与指南相对应，跳过任何一列，审查时必然被揪出来。如果输入提炼阶段没有逐项核对模板的设计意图，交付物一定会缺维漏项，后续审查必然驳回。缺少某个分析维度不是格式问题——意味着对应类型的安全风险没有被评估。

第三，指南中的验收标准必须被提取为可检查的判定条件。指南定义了每个分析步骤要回答的问题——不是”建议”，是”必须”。比如”时序分析必须包含故障检测时间和故障响应时间两个独立指标”——如果分析结果只有一个总时间没有分拆，审查时会被要求重做。不按指南验收标准自检就提交的后果：一轮审查打回，两轮修改重来，三轮信誉受损。

1.3 大文件预消化——不灌入上下文(Hermes)

软件架构文档动辄 200KB 以上，分析指南可能再 100KB。如果把原始文档全文灌入 Agent 的上下文，只有一个结果——超时。

对策：两级压缩法。

第一级——指南→检查清单映射。把指南的每个章节压缩为”检查什么 + 判定标准是什么”的短表。一份 100KB 的指南可以压缩到不到 5KB 的检查清单，覆盖全部检查维度，不丢验收标准。

第二级——架构→结构化提取。用 grep 提取架构文档的完整章节树，逐章节提取触发信号、CAN 消息、时序约束、安全机制、数据流路径。200KB左右的架构文档可以压缩到约 5KB 的结构化摘要。

Agent 用摘要工作，只在需要核验某个具体接口的时序或信号名时，才回读原始文件的具体小节。目标：Agent 的主力工作上下文控制在 25KB 以内。

跳过这一步的后果：Agent 上下文溢出 → 生成不完整 → 遗漏关键安全机制 → 审查打回 → 重新分析。而且由于超时，你不会知道 Agent 到底读了哪些部分、跳过了哪些部分——这是一个不可验证的黑盒。

──────────────────────────────────────────────────

二、图片识别与 MD 插入

2.1 图片是信息瓶颈，不是格式附件

架构文档中的图片——整体架构图、端到端时序图、逐场景时序图、安全完整性机制流程图——包含的信息远比文字多。一张架构图里同时编码了：组件拓扑、数据流方向、安全等级分配、接口类型、运行环境的边界。这些信息在文字段落中通常是分散的，但在图中是一次性呈现的。

直接对话时，Agent 拿到的是文字描述，不是原始图片。你给它一个图片文件名，它只能看到文件名——看不到图中的箭头、颜色、标注。

2.2 通用处理流程

第一步——文档转换。原始输入文件（xlsx/docx/PDF）必须先转换为 Markdown，同时把所有内嵌图片提取出来。xlsx 中的图片存储在 zip 容器内的 xl/media/ 目录，docx 中的图片存储在 word/media/。不能依赖库函数的路径属性（如 openpyxl 的 img.path）——多个 sheet 的不同图片可能显示为同一个文件名，但实际是不同的二进制文件。

第二步——批量图片识别。用视觉语言模型（如 Qwen VL/3.5 Plus）对每张图做结构化识别。注意：默认 prompt 倾向于描述”视觉结构”（”三个圆圈的 Venn 图”）而非提取文本内容。对于方法论密集型图表，必须用文本提取模式的 prompt：”提取并转录图中所有可见文字，不描述视觉布局”。已识别的描述以结构化格式插入到 Markdown 中对应位置。

第三步——图片描述注入 MD。在 Markdown 对应章节标题后插入图片描述块，确保后续所有角色（Engineer、Manager、Head）都能读到图片的结构化信息，而不是面对一个文件名干瞪眼。

图2: 图片识别与MD注入 — 三阶段流水线及翻车案例

2.3 一次翻车：颜色信息丢失的连锁反应

这个环节踩过最大的坑。架构文档里有两张关键图——一张整体静态架构图，识别结果带了完整的安全等级标注；但另一张系统架构图，识别结果只有组件名称和层级，没有安全等级信息。

结果：Engineer 拿到 Markdown 后，看不到架构图里的颜色标注，只能根据行业惯例推断——基础软件组件走资格化路径，标为”无安全等级分配”。但架构图的实际颜色是：所有这些组件都是安全等级的。

一个图片识别遗漏 → 整个报告中多个组件的安全等级标注全错 → 整条链路的安全等级一致性论证全部作废。

2.4 吸取的教训

第一，图片识别结果必须包含颜色/安全等级信息。没有这个信息的图片描述是不完整的。补救方案：让图像模型单独回答”这张图里每种颜色对应什么安全等级”，把答案补到原始描述里。

第二，图片识别不是”一图一描述”，而是”一图多角度”。对同一张架构图，需要从组件拓扑、安全等级分配、数据流向、接口归属四个角度分别提问，确保完整提取。

第三，原始图片要保留。不要以为文字描述够用了就删图。跨层审查时，需要直接看图来验证 Agent 的理解是否准确。

省略这一步的代价：一个安全等级标注错误会污染整条链路的分析结论，审查发现后需要逐页返工——不是改一行，是改所有引用这个错误标注的分析页。

──────────────────────────────────────────────────

三、软件安全分析主要分析内容

3.1 四维验证框架

软件安全分析本质上是对安全相关数据流做四维验证：

第一维——数据路径分析。沿安全信号逐组件追溯，验证路径上每个软件单元的 ASIL 等级一致性、非安全输入隔离、运行时操作安全性、共因失效防护。核心问题是：安全信号从输入到输出的每一步，是否都受到与其 ASIL 等级匹配的保护？

第二维——时序分析。验证端到端延迟是否小于故障容错时间（FTTI）。不是只算一条路径——是要在每种运行模式下，计算故障检测时间 + 故障响应时间的总和，与 FTTI 做比较。核心问题是：在最坏情况下，系统能否在 FTTI 内完成故障检测和响应？

第三维——调度分析。验证安全相关任务的优先级和周期设计是否能保证时序约束。需要同时检查任务结构和中断结构——中断可能抢占安全任务，破坏时序假设。

第四维——运行模式分析。验证每种运行模式（初始化、正常运行、升级、降级、安全状态）下的安全路径是否都已被覆盖。很多分析只做了正常模式，遗漏了降级模式下的安全路径。核心问题：系统在降级运行时，安全功能是否仍然满足要求？

这四个维度缺一不可。只做数据路径不做时序，等于只验证了”路通不通”没验证”来不来得及”。只做正常模式不做运行模式，等于假设系统永远不会初始化、不会降级、不会升级。

图3: 软件安全分析 — 四维验证框架及架构覆盖完整性检查

3.2 数据路径分析的四个核心问题

沿安全信号从输出端反向追溯到原始输入源，对路径上的每个软件单元，逐一回答四个问题：

第一，安全等级是否一致？路径上是否存在等级更低的单元？除非端到端保护覆盖，否则不允许降级。这是一个硬约束——如果安全信号经过一个 QM 等级的组件且没有端到端保护覆盖，这就是一个明确的架构缺陷。

第二，非安全输入是否交叉？安全信号有没有被非安全软件单元读取或处理过？一个 ASIL B 的组件如果接收了 QM 组件的输入且没有做输入验证，就可能被非安全输入污染。

第三，运行时操作是否安全？哪些标定量、参考值、外部库函数被安全路径依赖？它们的来源和安全等级是否明确？一个标定量如果存储在非安全保护的 Flash 区域，被篡改后安全功能可能静默失效。

第四，共因防护是否到位？内存保护是否覆盖所有关键路径？错误检测编码是否用于所有安全数据流？如果安全组件和非安全组件共享同一块 RAM 且没有内存保护，非安全组件的野指针写就能破坏安全数据。

每一个检查点都必须记录：检查了什么、用什么方法检查的、发现了什么证据、得出的结论是什么。裸写一个”OK”不够——需要论证为什么 OK。一条推理链缺失可能意味着一个未被覆盖的失效模式。

3.3 时序分析的最低标准

时序分析不是算一条路径的延迟。合格的分析至少要包含：

第一，调用结构描述——正常场景下的步骤序列，谁调谁、传递什么数据。

第二，故障场景描述——故障检测的触发条件、检测路径、拦截机制。

第三，端到端延迟计算表——至少列出故障检测时间和故障响应时间两个独立指标，每个指标关联到具体的函数和预估执行时间。

第四，FTT 验证——明确数值比较声明”端到端延迟 < FTTI”。

第五，潜在违背分析——至少分析两个可能的违背场景，每个场景给出缓解措施。

绝对禁止的写法：”时序结构同 XX 模式，正常路径约 100ms”。这句话没有分析价值——审查者无法验证这个 100ms 的数字是怎么来的、故障检测时间占多少、响应时间占多少、是否包含中断抢占的延迟。

3.4 架构覆盖完整性——最容易被遗漏的检查

SSA 最常见的遗漏不是某个数据路径没分析——而是整个安全机制章节被跳过。架构文档中往往有独立的安全完整性机制章节，这些机制不是某个功能路径的一部分，而是全局基础设施。

如果 SSA 只按安全目标→运行模式分解功能路径，这些全局安全机制会全部漏掉——因为它们不属于任何一个功能路径。

遗漏一个全局安全机制意味着：这个机制的失效模式没有被评估、它的诊断覆盖率没有被验证、它与其他安全机制的耦合没有被分析。对于看门狗这类”最后一道防线”的机制，遗漏分析的风险是不可接受的。

──────────────────────────────────────────────────

四、各层级活动卡介绍

SSA 流水线采用与 FMEA 相同的三角色架构，但活动卡的内容完全不同——因为 SSA 的分析对象是软件架构，不是硬件接口。

4.1 活动卡的职责不是描述流程——是定义约束

活动卡不是”操作手册”。操作手册告诉你怎么做——”打开文档、读第三章、填第一列”。活动卡定义的是约束——”你要检查什么、参考哪个标准条款、违反了什么规则会触发 VR 不通过”。

为什么这个区别重要？因为 Agent 会遵守约束，但不会遵守”操作步骤”。你说”逐组件追溯数据路径”——Agent 可能会跳过中间层。你说”路径上任何组件 ASIL 低于信号 ASIL 且无端到端保护覆盖即 FLAG”——Agent 会严格检查每个组件。

4.2 SW Engineer 活动卡——分析执行的唯一入口

SW Engineer 是唯一产出分析内容的角色。它的活动卡定义了全部分析维度的执行约束：

数据路径分析段规定：逐安全目标→逐运行模式→逐数据路径追溯。对路径上每个软件单元，检查 ASIL 一致性、非安全输入隔离、运行时操作安全性、共因防护。每个组件的分析结果必须是 OK / [待确认: 具体事项] / NOK 三态之一，禁止混判（如 “OK [待确认: xxx]”）。

时序分析段规定：每个运行模式的时序分析独立完成（不允许多个模式共用一份时序表）。必须包含调用结构描述、故障场景描述、端到端延迟计算表、FTT 验证、潜在违背分析。延迟计算表至少 5 行，含函数名和预估时间。

运行模式分析段规定：覆盖全部运行模式（至少包含初始化、正常运行、降级、升级、安全状态五种）。每种模式下分析安全路径是否保持有效。

架构覆盖检查段规定：在分析前扫描架构文档的完整章节树，确保所有安全相关章节都已被纳入分析范围——不限于功能数据路径，还要覆盖全局安全机制（看门狗、时钟监控、电压监控等）。

4.3 SW Manager 活动卡——VR 技术审查

SW Manager 不产出内容，只对照标准条款和检查清单逐项审查 Engineer 的交付物。核心检查项包括：

ASIL 一致性——路径上是否存在未覆盖的 ASIL 降级？

时序合规性——端到端延迟是否小于 FTTI？延迟计算是否包含检测和响应两个独立指标？

FFI 免于干扰——安全组件是否受到非安全组件的干扰？MPU 是否已配置？

运行模式覆盖——每种运行模式下的安全路径是否都已分析？

依赖故障——共因失效和级联失效是否已被识别和缓解？

追溯完整性——每条安全需求是否都有对应的分析验证？

架构覆盖——是否存在架构文档中的章节未被 SSA 覆盖？

Manager 返回 VR 报告：✅（通过）/ ⚠️（Flag）/ ❌（不通过）。不通过项必须修复后重新 VR，不允许跳过。

4.4 Head 活动卡——CR 认可评审与调度

Head 是总控。在 SSA 流水线中，Head 做三件事：

第一，调度——将任务分派给 SW Engineer 和 SW Manager，注入活动上下文。这里的关键是上下文控制：Head 在分派前必须对输入文件做预消化（两级压缩），确保子 Agent 上下文不溢出。同时，Head 必须将核心约束以短文本形式注入 context——不让 Agent 自己去从活动卡中发现规则。

第二，汇总——将 Manager 的 VR 结果整理上报用户，等待用户判定。用户通过 → 进入 CR。用户列修改项 → 重走 Engineer → Manager 全链路。

第三，CR 认可评审——在 VR 通过后、交付用户前，做最后一道独立审查。Head 的 CR 侧重点不在逐条检查（那是 Manager 的工作），而在交付物的完整性和自洽性：文件结构是否完整？上下游一致性是否保持？假设是否明确陈述？架构覆盖是否遗漏整章？CR 发现的问题列成”不符合项清单”→ 派回 Engineer 修改 → Manager VR 复查 → 循环到通过。

4.5 三角色的边界——为什么不能跳步

一个经常出现的问题：Manager VR 发现 3 个不满足项，用户给了精确修改指令后，Head 直接把指令灌给原 Engineer 让改——改完跳 VR 直接 CR。这是错误的。

正确的做法：Hermes——Head 启动新 Engineer → Engineer 修改 → Head 启动新 Manager → Manager 复查修改项 → Head 汇总 → 用户判定。每轮修改完整重走 Engineer → Manager 链路。

Openclaw——Head spawn Manager → Manager spawn Engineer 修改 → Engineer 修改后返回Manager → Manager 复查修改项 → Head 汇总 → 用户判定。每轮修改完整重走 Engineer → Manager 链路。

为什么不能跳？因为修改可能引入新问题。Engineer 改了 FTT 值后，原来满足的时序边界可能不再满足。Manager 的独立复查是防止修改引入新缺陷的唯一屏障。跳过 Manager VR → CR 是没有意义的——CR 的前置条件是 VR 已通过。

图4: SSA 三角色活动卡体系 — Engineer/Manager/Head 分工与修改循环规则

4.6 活动卡的生命周期

活动卡不是写完就不变的。每次分析中发现新问题、新遗漏模式、新审查标准，都必须回写到对应的活动卡和 Manager VR 检查清单中。

比如：发现 SSA 可能遗漏架构文档中的全局安全机制章节 → 在 Engineer 活动卡中新增”架构覆盖自检”步骤 → 在 Manager VR 检查清单中新增”架构章节覆盖”检查项 → 在 Head CR 中增加”交叉对比架构 ToC vs SSA 覆盖”专项检查。

活动卡的质量就是分析质量的上限。活动卡里的约束不全，Agent 就不会执行。Agent 不会自动去标准里找你没写进活动卡的规则。

──────────────────────────────────────────────────

这一章讲了什么（上半部小结）

上半部覆盖了软件安全分析流水线的前四个核心环节：必要输入与关键提炼（五类输入 + 三个信息丢失点 + 大文件预消化）、图片识别与 MD 插入（图片是信息瓶颈 + 颜色信息丢失的连锁反应 + 处理流程）、分析内容框架（四维验证：数据路径/时序/调度/运行模式 + 架构覆盖完整性检查）、以及活动卡体系（三角色分工 + 活动卡定义约束而非描述流程 + 修改循环不可跳步）。

下半部将覆盖：软件安全分析的实操技巧总结（安全等级判定、推理链、数据路径图、时序分析的常见陷阱）、Lesson Learn 的自动化机制（怎么记录教训、怎么让教训在下一次自动生效）、以及从文档准备到最终交付的完整端到端工作流。

──────────────────────────────────────

Next: Part 12 — 软件安全分析（下）

────────────────────────────────────────

© 2026 本文档内容受知识产权保护，未经作者许可，严禁以任何形式转载、复制或用于商业用途。