## 安全审计发现整改进度跟踪 {.case data-case-id="053"} | 字段 | 值 | | --- | --- | | 案例编号 | `053` | | 行业 / 部门 | 金融 / 安全合规 | | 角色 | 安全负责人 | | 难度 | `进阶` | | 调用来源 | `manual`（审计报告交付后由安全负责人发起一次手动调用，带入整改清单的令牌化条目——发现编号、行动项编号、级别与截止日） | 整改清单发下去两个月，监管来问进度才发现一半条目停在"进行中"，说不清哪项逾期、哪项真关了。目标：审计报告交付后由安全负责人发起一次手动调用，让获授权 Agent 对带入的整改清单逐项跟踪当前状态与截止日：按期与已关闭的项发进度回执并证据留痕；逾期或临期的项当日通知整改 Owner 并抄送安全负责人。整改关闭不自动判定——Owner 申报关闭必须经安全负责人人工确认后才计入"已关闭"。漏洞细节与内网资产名全程脱敏，回执只用发现编号、级别与整改状态。指标：逾期或临期项 100% 在当日通知到 Owner 并抄送安全负责人；计入"已关闭"的项 100% 经人工确认并附判定依据与时间戳。 - **覆盖**：手动调用逐项跟踪整改状态与截止日、三路分流（按期/已关闭、逾期/临期、清单不完整）、关闭需人工确认、零结果与取数失败回执。 - **不覆盖**：自动判定整改关闭、自动改整改计划或截止日、自动在审计系统销项。 - **假设**：有一个经授权能读取整改进度并在读取侧脱敏与令牌化的 Agent（通过 App/Extension）；整改清单在调用时作为输入提供，含发现编号、行动项编号、级别、Owner 角色代号、截止日；Owner 仅用清单字段，缺失标"待确认"。 把下面这段发给 Loop，它会在后台帮你创建这个 Workflow： ```text 帮我创建一个 Workflow：安全审计报告交付后由安全负责人发起一次手动调用，让获授权的跟踪 Agent 经 App/Extension 读取整改进度，App/Extension 在读取侧即完成脱敏与令牌化，Agent 只接收发现编号、行动项编号、级别、Owner 角色代号、截止日、状态与更新时间等白名单字段，不接收 Owner 姓名与工号——展示名由安全 App 在发送侧按角色代号回填；漏洞细节与内网资产名不进入 Agent 消息与运行记录，返回每项的发现编号、行动项编号、级别、整改状态与时间。 触发：手动发起调用，调用时带入整改清单的令牌化条目（发现编号、行动项编号、级别、截止日）、安全频道、审批人与跟踪 Agent。 结果分三类处理： 按期或已关闭：发进度回执，每项附当前状态与最近更新时间戳，证据留痕并留审计时间戳；其中申报已关闭的项必须经安全负责人人工确认（附判定依据与时间戳）后才计入"已关闭"，不自动判定关闭。 有逾期或临期：通知整改 Owner（仅用清单字段，Owner 缺失标"待确认"，不从资产名或系统记录猜）并抄送安全负责人，附发现编号、级别、截止日与当前状态，留审计时间戳。 输入清单不完整（发现缺编号、级别、Owner 或截止日）：告警并留审计时间戳，通知安全负责人补全后新开一次调用，本次不重试、不猜测缺失字段。 另设两类边界结果： 本期无待跟踪发现（查询成功但令牌化条目为空）：发一条"本期无待跟踪发现"汇总回执并留时间戳，不静默结束。 取数失败（整改进度数据源不可达、数据陈旧）：告警失败、留审计时间戳，按重试上限重试，仍失败则升级到值班频道；不当作"本期无待跟踪发现"，也不当作按期。 审批：申报已关闭的项由安全负责人确认后才计入"已关闭"，不自动判定关闭；审批为二值确认或驳回，不设自动超时，无默认通过/否决。 异常：跟踪 Agent 回传不合结构就停在等待点等它重新提交，不自动重跑；通知发送失败按重试上限重试，仍失败则升级到值班频道并保留待发内容供人工补发。 完成：进度回执、逾期通知、清单不完整告警、零结果回执、取数失败升级，各自留审计时间戳后结束。 ``` ![案例 053 安全审计发现整改进度跟踪：审计报告交付后手动调用获授权 Agent 逐项跟踪整改进度与截止日；按期推进的项直接发进度回执（每项附状态与最近更新时间戳、证据留痕，不经人工确认），只有申报已关闭的项才进安全负责人人工确认（附依据与时间戳），确认后计入已关闭；有逾期或临期通知整改 Owner（缺失标待确认）并抄送安全负责人，清单不完整告警留审计新开调用不重试，本期无待跟踪发现发零结果回执，进度数据源不可达按取数失败告警留审计重试升级；漏洞细节与内网资产名脱敏；回传不合结构停在原等待点](../../../media/cases/fig-case-053-01-flow.svg){#fig-case-053-01 width=92%} 如上图所示，正常路径、人工决策与异常同时可见： 1. **手动触发**：审计报告交付后由安全负责人发起一次调用，带入整改清单的令牌化条目（发现编号、行动项编号、级别、截止日）、安全频道、审批人与跟踪 Agent。 2. **跟踪进度**：获授权 Agent 经 App/Extension 读取整改进度，App 在读取侧完成脱敏与令牌化，Agent 只接收白名单字段（发现编号、行动项编号、级别、Owner 角色代号、截止日、状态、更新时间），Owner 展示名由安全 App 发送侧按角色代号回填，对清单逐项回传当前状态与最近更新时间；回传结构不合要求时停在原等待点，等其重新提交，不自动重跑。 3. **三路分流**： - **按期推进**：直接发进度回执，每项附当前状态与最近更新时间戳，证据留痕；按期项不经人工确认，也不与申报关闭混在同一条路。 - **申报已关闭**：只有申报已关闭的项进入安全负责人人工确认（附判定依据与时间戳），确认后才计入"已关闭"；驳回则该项回跟踪中留审计。 - **有逾期或临期**：通知整改 Owner（仅用清单字段，缺失标"待确认"）并抄送安全负责人，附发现编号、级别、截止日与当前状态，留审计时间戳。 - **输入清单不完整**：告警、留审计时间戳，通知安全负责人补全后新开一次调用，本次不重试。 4. **两类边界结果**：本期无待跟踪发零结果回执并留时间戳；整改进度数据源不可达按取数失败告警留审计，按重试上限重试，仍失败升级值班频道。 你不需要手写代码或配置。把上面的提示词发给 Loop，AI 会理解意图、在后台画出这个"手动调用 + 关闭人工确认 + 三路分流"流程——它知道"跟踪进度"需要一个发消息并等待回调的 Agent 环节、"按进度结论分流"需要一个条件路由、"确认关闭"需要一个审批环节、"回执与通知"各需要一个发消息环节。AI 还会在后台校验流程结构是否完整，你不必关心这些技术细节。 - **整改被"口头关闭"**：这是审计整改最常见的漏洞。关闭判定只认安全负责人的人工确认，附判定依据与时间戳；Owner 申报关闭只是触发确认的输入，不是结论。 - **整改进度数据源不可达、数据陈旧**：不当作"本期无待跟踪发现"或按期，而是告警留审计，按重试上限重试；仍失败升级到值班频道由人工确认。 - **整改 Owner 缺失**：Agent 不从资产名或历史记录猜 Owner，通知中该字段标"待确认"，由安全负责人补全或指定。 - **输入清单不完整**：不猜缺失的编号、级别或截止日，告警留审计并通知安全负责人补全后新开一次调用，本次不重试。 - **通知发送失败**：按重试上限重试投递；超过上限则升级到值班频道，并保留待发内容供人工补发。 - **本期无待跟踪（结果为 0）**：仍发零结果汇总回执并留时间戳，让"没消息"变成可核验的记录。 - **跟踪 Agent 回传不合结构**：本次完成请求被拒绝，停在等待点等其修正后重新提交，不自动重跑。 - **长时间无人确认关闭**：审批本身不设自动超时，流程停在等待状态。若业务需要响应时限，由另一条定时检查的 Workflow（或值班人员）扫出超时项并通知安全负责人。 申报已关闭的项必须经安全负责人确认后才计入"已关闭"，本流程不自动判定关闭。确认时能看到该发现的编号、级别、状态与最近更新时间（漏洞细节与内网资产名已脱敏），是"有依据的快速确认"。审批只有确认或驳回两种结果，驳回则该项回到跟踪中，不设自动超时，也没有"超时默认关闭"。若要更严（如高危发现的双签确认），在提示词里写明，AI 会在流程里多加一个审批环节。 整改进度的读取由获授权 Agent 通过 App/Extension 完成，工作流不直接调用外部系统，也不写回审计系统。安全频道与审批人作为调用输入提供；整改进度数据源的访问凭据用 `` 占位，由 Agent 运行时从密钥引用。数据源不可达或数据陈旧属于取数失败，走失败回执与升级。最小披露：回执与通知只用发现编号、行动项编号、级别与整改状态，不外带漏洞细节与内网资产名；Owner 展示名由安全 App 发送侧按角色代号回填。进入 Agent 消息、Run/Activation/Effect 记录与 App/Extension 工具日志的字段以白名单为准（仅令牌化/白名单字段，原值不进入以上任何一层），漏洞细节、内网资产名与 Owner 姓名工号在源头即被脱敏/令牌化，并按 10% 抽查四层实际记录。 - **回放集与基准**：取最近一次审计的 60 项发现（含按期、逾期、临期、申报关闭、字段缺失样本）回放，基准为既定的状态分类与应通知清单。 - **分类准确**：按期/已关闭与逾期/临期判定和基准一致率 ≥ 95%；逾期或临期项 100% 在当日通知到 Owner 并抄送安全负责人。 - **关闭防线**：计入"已关闭"的项 100% 经人工确认并附判定依据与时间戳，自动判定关闭 0 例。 - **字段纪律**：清单提供 Owner 时 100% 原样带出；缺失时 100% 标"待确认"，不出现猜测的 Owner；清单不完整时 100% 告警留审计、新开调用，0 次自动补猜。 - **脱敏**：回执与通知按 10% 抽样，漏洞细节与内网资产名出现 0 次。 - **源头脱敏**：进入 Agent 消息、Run/Activation/Effect 记录与 App/Extension 工具日志的字段 100% 在白名单内（仅令牌化/白名单字段，原值不进入以上任何一层），漏洞细节、内网资产名与 Owner 姓名/工号出现 0 次，按 10% 抽查四层实际记录。 - **结果可见**：进度回执、逾期通知、清单不完整、零结果、取数失败五类结果 100% 各有可见回执与审计时间戳，不出现静默成功；每次运行记录跟踪与通知时间戳。 ### 复用与变体 - **同构迁移**：监管检查意见整改跟踪、内控缺陷整改跟踪、渗透测试发现修复跟踪。 - **分级提醒**：高危发现临期 14 天即通知，一般发现临期 7 天通知，在提示词里写明即可。 - **写回审计系统**：确认关闭后加一个 Agent 环节，由它通过 App/Extension 把"已关闭"状态写回审计系统销项台账；写回须是获授权 Agent 经 App/Extension 的幂等动作（幂等键=行动项编号+确认批次），响应未知先查后写、按重试上限有限重试、失败升级值班并置"待处理"保留补偿，全程留审计。若不需要写侧能力，改为只读汇总或仅留 Loop 回执更安全。