一人成军_从零搭建基于 Openclaw(兼容Hermes)的功能安全 Agent(12)软件安全分析(下)-夜雨聆风

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

分析技巧 · Lesson Learn 体系 · 端到端流程

上半部讲了输入提炼、图片识别、分析框架和活动卡体系——告诉你这条流水线”有什么”和”为什么”。下半部讲”怎么做对”和”怎么让下次自动做对”。

这些技巧和教训不是某个项目的专属经验——是从多轮 SSA 执行、几十次 VR 翻车、多个架构遗漏中提炼出来的。换一个项目、换一个架构，它们一样适用。

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

五、软件安全分析技巧总结

5.1 推理链：每个结论都必须可追溯

安全分析报告里最常见的注水写法：检查项填了、方法引用了”架构文档”、发现写了”这是基础软件”、结论直接写”OK”。

这种写法在审查里活不过第一轮。因为”发现”和”结论”之间没有推理——你怎么从”这是基础软件”推出”OK”的？基础软件也有安全等级、也要做输入隔离、也被依赖故障影响。结论需要论据支撑。

正确的做法：方法引用具体章节而非笼统的”架构文档”（如”架构文档 §3.2.1 分层架构图 + §4.1.3 ASIL 分配表”）；发现是观察到的客观事实而非概括（如”该组件位于基础软件层，架构图颜色标注为安全等级 B，接收来自 QM 等级通信栈的 CAN 消息”）；结论与前两者构成逻辑链条（如”由于接收了低等级输入且无端到端保护覆盖，标记为 [待确认: FFI 输入隔离未验证]”）。

每一个结论，必须能顺着”用了什么方法 → 发现了什么事实 → 因此得出什么结论”这条线追踪回去。如果分析人员偷懒写”OK”，审查者无法判断这个结论是基于分析还是基于假设——整条链路的安全论证就出现了断点。一条推理链缺失可能意味着一个未被覆盖的失效模式；一份报告中如果有 10 个”OK”没有推理支撑，审查者将无法信任这份报告的任何结论。

5.2 时序分析：共路径不要重复计算

一个常见陷阱：多个运行模式共用同一条数据路径，如果给每个模式单独写时序分析，容易把共享的处理窗口和判决执行时间重复计算多次。

正确做法：共路径的模式合并为一份时序分析，用共享的时间元素估算，只在触发信号和校核逻辑上区分。多个模式共一份时序表，不是多份。

重复计费的后果：累计时间超过故障容错时间，报告会误判为”时序不满足”——但实际上是重复计算导致的假阳性。这种假阳性会浪费大量审查和解释时间。

5.3 架构覆盖：不遗漏全局安全机制

SSA 最常见也最隐蔽的遗漏：架构文档中有独立的”安全完整性机制”章节（看门狗与程序流监控、ADC 自检、时钟监控、ECC 监控、电压监控、中断监控），但 SSA 只分析了功能数据路径——这些全局机制一个都没覆盖。

为什么容易漏？因为 SSA 的分解逻辑是”按安全目标 → 按运行模式 → 提取数据路径”。全局安全机制不属于任何一个安全目标——它们是所有安全目标的共享基础设施。按功能路径分解，它们天然被跳过。

对策很简单但必须强制执行：在分析前后，需要提取架构文档的完整章节树，逐章确认是否在 SSA 中有对应分析。每个架构文档的一级/二级章节必须要么在 SSA 中有完整数据路径和时序分析，要么显式标注 N/A 并写清理由。

遗漏一个全局安全机制意味着：这个机制的失效模式没有被评估——看门狗如果失效了会怎样？时钟监控是否覆盖了所有关键时钟源？ECC 是否覆盖了所有安全关键数据区？这些问题的答案不会因为你没分析就不存在——它们会在审查时被逐条揪出来。

5.4 同一分析类型必须结构一致

SSA 中有多个子功能（多种运行模式），每个子功能都有独立的 DataPath 和 Timing 分析。一个常见质量问题：前几个子功能的分析是完整版（逐步骤分解 + 安全机制详细 + 潜在违背场景），后面的子功能变成压缩版（一句话带过时序、安全机制只写”OK”、缺少潜在违背分析）。

根因：Agent 没有结构一致性约束——它不知道前面的详细分析是后面分析的模板。

对策：在 Engineer 的约束中明确”以第一个子功能的完整分析为模板，所有后续子功能的分析深度和结构必须一致”。Manager VR 检查清单中增加结构一致性检查——取第一个子功能的章节结构，用 grep 提取子标题，与其他子功能的子标题比对，不一致即 FLAG。

这个技巧的通用性：只要是”同一类型 × 多个实例”的分析——多个运行模式、多个 ECU、多个信号路径——都必须有一致性约束。不一致的分析质量会破坏审查者对整份报告的信任。

5.7 修改指令要精确——同时解决多个问题

当 VR 发现多个不满足项后，用户通常不会说”你改一下时序”——而是给出精确指令。比如：”全部 FTTI → 1000ms”、”MPU 已配置，更新所有相关标注”。

每条精确指令通常能同时解决 2-3 个 VR 不满足项。比如修改 FTTI 值，同时解决”某运行模式违反 FTTI”、”降级模式边界时序”、”安全监控周期不足”三个问题。

作为总控（Head），收到用户的修改指令后，要做的不是”转发给 Engineer”——而是把每条指令拆解为受影响的检查项列表，一起传给 Manager(Engineer)。这样 Engineer 知道要改什么、为什么要改、改了之后哪些结论要重新验证。

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

六、Lesson Learn 梳理

6.1 为什么传统的教训记录方式不适用于 Agent 流水线

传统的做法：找一个文档页面，把所有项目的教训堆在一起。时间一长变成几百 KB 的文本。问题有三个：第一，谁也不会去翻——下次执行时没人记得去读；第二，教训和活动没有绑定——做 FMEA 时不会去翻 SSA 的教训；第三，只记录了”不要做什么”，没记录”正确的做法是什么”。

在 Agent 流水线上，这三个问题都是致命的。因为 Agent 不会”记得”——它的上下文每次都是新的。如果教训没有在正确的时机被注入正确的 Agent 的上下文，等于没有记录。

6.2 五条核心 Lesson Learn

以下五条是从 SSA 流水线的实际执行中提炼的，按根因→正确做法的方式描述。

Lesson 1：安全等级的唯一权威源是架构图颜色，不是文字描述。

根因：文字描述”基础软件层，透明传输”不包含安全等级信息。架构图颜色标注是唯一可靠源。缺失则标记开口项，不自己推断。

生效方式：写入 SW Engineer 活动卡的 ASIL 判定规则，同时写入 Manager VR 检查清单。

Lesson 2：图片识别必须多角度提问，尤其必须包含颜色/安全等级。

根因：单次识别只提取了组件拓扑，漏掉了颜色标注，导致整个报告的安全等级全错。

生效方式：在文档准备阶段的多角度识别流程中强制加入”这张图中每种颜色对应什么安全等级”的专项提问。识别结果在注入 MD 前必修颜色信息完整性检查。

Lesson 3：架构覆盖必须在分析前后做章节交叉对比。

根因：按安全目标分解的 SSA 天然跳过全局安全机制——它们不属于任何功能路径。

生效方式：在 SW Engineer 活动卡中写入”执行前通读架构文档/提取完整章节树 → 分析后逐章对照确认覆盖”的自检步骤。Manager VR 和 Head CR 都做交叉对比。

Lesson 4：每个分析结论必须有可追溯的推理链。

根因：裸写”OK”无法区分”经过分析确认 OK”和”没分析假设 OK”。审查时无法信任没有推理的结论。

生效方式：在 SW Engineer 活动卡中明确”结论必须能从方法+发现中推导出来”。Manager VR 专门检查推理链完整性——无法追溯的结论一律 FLAG。

Lesson 5：Excel 交付前必修逐 Sheet 审计。

根因：Markdown 表格格式差异（双竖线 vs 单竖线前缀）导致列偏移；图片缩放导致模糊；遗漏架构图片嵌入。这些在生成时往往看不出来，打开 Excel 才发现。

生效方式：生成 Excel 后运行审计脚本，逐 Sheet 验证：表格数据是否齐全、关键列是否对齐、图片是否嵌入且原始分辨率。0 问题后再交付。

6.3 Lesson Learn 的自动化生效机制

记录教训只是第一步。更重要的是建立”让教训在下一次自动生效”的机制。具体做法：

第一，逐活动绑定。每条教训绑定到产生它的活动——SSA 的教训写入 SW Engineer 活动卡的约束规则和 Manager VR 的检查清单，不放在通用教训文件里。这样下次执行 SSA 时，Agent 自动读到这些约束。

第二，规则化而非描述性。教训必须写成”约束”而非”故事”。”上次做 SSA 时架构覆盖漏了”——这是故事，Agent 不会从中推导出”下次要 grep 架构章节树”。正确的写法：”执行分析前，必修 grep 架构文档完整章节树，分析后逐章确认覆盖”——这是规则，Agent 会执行。

第三，多角色覆盖。重要教训同时在 Engineer 活动卡、Manager VR 检查清单、Head CR 检查清单中反映。比如”架构覆盖完整性”这个教训：Engineer 活动卡中写入自检步骤（预防），Manager VR 中写入检查项（发现），Head CR 中再次交叉对比（兜底）。三道防线。少一道，就多一个漏出的可能。

第四，生命周期闭环。一个教训从发现到生效的完整路径：发现问题 → 定位根因 → 确定责任环节 → 写入对应角色活动卡/检查清单 → 下次执行时自动触发 → 验证问题不再出现 → 关闭。如果下次执行时同一个问题又出现了，说明规则写得不够精确或触发时机不对——修正规则，再次验证。

图5: Lesson Learn 生命周期闭环 — 五步循环与三道防线

这套机制的最终目标不是”把教训记下来”，而是让教训在下一次执行时自动生效。如果只记录不建立自动读取机制，下次执行时跟没记录一样——同一个错误会重复出现。

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

七、完整工作流展示

7.1 端到端流程

整个 SSA 流水线从用户发起”开始软件安全分析”到最终交付 Excel，共十一个关键节点：

1. 总控确认输入依赖。总控列出软件安全分析所需的全部输入材料清单（架构文档、安全需求表、分析模板、分析指南、安全手册如有），等待用户确认”开搞”。不做确认就开搞，可能发现输入不全会导致分析中断。

2. 文档转换。将用户提供的 xlsx/docx/PDF 全部转换为 Markdown。xlsx 用 openpyxl 逐 sheet 转 Markdown 表格，同时解压提取内嵌图片。docx 用 python-docx 提取文字 + 解压提取图片。所有输出写入项目的 input/ 目录。

3. 图片识别与 MD 注入。用视觉语言模型批量处理所有提取的图片。每张图多角度提问：组件拓扑、安全等级分配、数据流方向、接口归属。对方法论密集型图表用文本提取模式。识别结果以结构化格式注入 Markdown 对应章节。

4. 预消化——两级压缩(Hermes)。总控（Head）在分派 Engineer 前，对输入文件做两级压缩：指南→检查清单映射（100KB → 5KB），架构→结构化提取（200KB → 5KB）。预消化产物写入项目 reference/ 目录。Engineer 用摘要工作，只在核验时回读原始文件。

5. 试点单子功能。不直接做全量分析——先选一个子功能做试点。总控提取该子功能的架构上下文，分派 SW Engineer 执行试点分析，输出单个子功能的完整软件安全分析。试点阶段不做 Manager VR——直接交付用户审查。

6-7. 用户审查试点。用户打开试点 Excel，审查分析深度、格式、结论质量。通过 → 确认方法/格式/深度，推进完整分析。不通过 → 用户给出修改方向，重做试点直到通过。试点的价值：暴露方法问题、避免完整分析返工。

8. Engineer 完整分析。总控分派 SW Manager(Engineer)，注入预消化文档路径和全部约束规则。Engineer 对每个子功能独立执行完整分析——每个子功能有自己完整的分析流程。分析后做架构覆盖自检。

9. Manager VR 审查。总控分派 SW Manager，对照检查清单和标准条款逐项审查 Engineer 交付物。Manager 返回通过/Flag/不通过清单。不通过项必须修复。

10. 用户判定。总控汇总 VR 结果上报用户。用户通过 → 进入 CR。用户列修改项 → 总控重新启动 Engineer → Manager 全链路。用户每个修改指令都被拆解为受影响的检查项列表传给 Engineer。

11. Head CR → 交付 Excel。VR 通过后，总控执行 CR 认可评审——确认交付物完整性和自洽性，交叉对比架构章节树 vs SSA 覆盖。CR 通过后，生成 Excel 文件——逐 sheet 解析 Markdown 表格，嵌入架构图片（原始分辨率），运行审计脚本逐 sheet 验证。确认 0 问题后交付用户。

图6: SSA 端到端工作流 — 11 个关键节点全流程

7.2 效率来源

传统手工完成整套 SSA 需要数周——安全工程师逐条追溯数据路径、逐个场景做时序计算、逐组件评估依赖故障、交叉核对架构和需求表。一个笔误的修改可能引发链条式的返工。

流水线的效率来源不是”AI 做得更快”——是分工明确。AI 处理体力活：读架构文档、对检查清单、交叉核对、格式检查、Excel 生成。人的精力留在真正需要专业判断的地方：审查发现、做判定、指导修改方向。

最关键的是信息链路的一致性——从架构图颜色 → 图片识别描述 → Engineer 的安全等级标注 → Manager 的检查 → Head 的整体一致性审查。五个环节只要断一个，最终的安全等级就可能全错。这条链路的质量不是靠”AI 更强”保证的，是靠每道关卡的独立验证保证的。

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

全文总结

下半部覆盖了软件安全分析流水线的三个核心环节：实操技巧总结（安全等级来源、推理链可追溯性、数据路径图三路流、时序共路径去重、架构覆盖完整性、结构一致性约束、修改指令精确化、Excel 交付陷阱——八条技巧全部有根因有对策有后果）、Lesson Learn 自动化机制（五条核心教训 + 逐活动绑定 + 规则化 + 多角色覆盖 + 生命周期闭环）、以及完整的端到端工作流（十一个关键节点 + 修改循环 + 效率来源）。

上下两部的核心主题可以归结为一句话：软件安全分析的质量不是由 AI 的输出能力决定的，而是由信息流转的正确性和每道关卡的独立验证决定的。架构图里的颜色 → 图片识别 → 安全等级标注 → Manager 检查 → Head 一致性审查——五个环节只要断一个，最终结论就可能全错。

这套流水线换一个项目、换一个架构、换一个分析模板，结构和约束不变——因为分析维度（数据路径/时序/调度/运行模式）是 ISO 26262-6 要求的，三角色分工（Engineer/Manager/Head）是工作流固有的，信息链路（输入→转换→分析→审查→交付）是每次执行都要走的。

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