## 依赖库安全漏洞扫描与通知 {.case data-case-id="011"} | 字段 | 值 | | --- | --- | | 案例编号 | `011` | | 行业 / 部门 | 互联网 / 研发 | | 角色 | 技术负责人 | | 难度 | `入门` | | 调用来源 | `schedule`（定时由获授权 Agent 经 App/Extension 查询漏洞库） | 项目依赖的第三方库越来越多，安全漏洞常被忽略直到出事。目标：定时让获授权 Agent 核对依赖列表与漏洞库，按高危、未命中、查询失败三种结果分别给出可见回执，命中高危时通知团队频道并建议负责人。指标：从本次扫描启动到通知发出的中位数 < 10 分钟；已知高危漏洞召回率 ≥ 95%；高危修复启动时间中位数下降 60%。 - **覆盖**：定时核对依赖与漏洞库，按命中、未命中、查询失败三种结果出回执，命中高危时通知团队并建议负责人。 - **不覆盖**：自动修复漏洞、自动升级依赖、扫描代码本身的安全问题、对每个漏洞做深度利用分析。 - **假设**：有一个经授权能查询漏洞库的 Agent（通过 App/Extension）；依赖清单可由调用输入提供或由该 Agent 读取锁文件。 把下面这段发给 Loop，它会在后台帮你创建这个 Workflow： ```text 帮我创建一个 Workflow：定时核对项目依赖列表与漏洞库，由获授权的查询 Agent 返回每个依赖是否有已知高危漏洞。 触发：定时（计划）发起调用，调用时带入依赖清单安全引用（令牌，原始锁文件留在代码库，进入工作流前由 App/Extension 凭引用抽取白名单字段）、团队频道和查询 Agent。 结果分三类处理： 命中高危：通知团队频道，说明库名、漏洞；负责人仅当调用方带入了权威的负责人令牌目录（可信输入，令牌由平台分配且不可反查）时才给出，否则标"待确认"，不从库名或漏洞猜测，并留审计时间戳。 未命中：发一条"本期无新增高危"的汇总回执并留时间戳，不要静默结束。 查询失败（漏洞库不可达或数据陈旧）：告警失败、留审计时间戳，按重试上限重试，仍失败则升级到值班频道。 审批：不涉及审批，安全通知是紧急低风险信息，直接触达。 异常：查询 Agent 回传不合结构就停在等待点等它重新提交，不自动重跑；通知发送失败按重试上限重试，仍失败则升级到值班频道并保留待发内容供人工补发。 完成：三类结果各自出回执后结束。 ``` ![案例 011 依赖库漏洞扫描：定时触发让获授权 Agent 查询漏洞库；查询失败留审计并重试升级，未命中发汇总回执，命中高危则通知频道并建议负责人，均留审计时间戳](../../../media/cases/fig-case-011-01-flow.svg){#fig-case-011-01 width=94%} 如上图所示，正常路径与异常同时可见，三种结果都有可见回执： 1. **定时触发**：计划到点发起一次调用，带入依赖清单安全引用（令牌）、团队频道与查询 Agent。 2. **查询漏洞库**：获授权 Agent 核对依赖与漏洞库并回传结果；回传结构不合要求时停在原等待点，等其重新提交，不自动重跑。 3. **三种结果分流**： - **查询失败**：漏洞库不可达或数据陈旧，告警失败并留审计时间戳，按重试上限重试，仍失败则升级到值班频道。 - **未命中**：本期无新增高危，发一条汇总回执并留时间戳，不静默结束。 - **命中高危**：通知团队频道，附库名、漏洞描述；负责人仅当调用方带入了权威的负责人令牌目录（令牌由平台分配且不可反查）时才给出，否则标"待确认"，不从库名或漏洞猜测，并留审计时间戳。 你不需要手写代码或配置。把上面的提示词发给 Loop，AI 会理解意图、在后台画出这个"定时查询 + 三路分流"流程——它知道"查漏洞"需要一个发消息并等待回调的 Agent 环节、"分三种结果"需要一个条件路由、"通知与回执"各需要一个发消息环节。AI 还会在后台校验流程结构是否完整，你不必关心这些技术细节。 - **漏洞库查询失败或数据陈旧**：不落入"全部安全"或静默结束，而是告警失败、留审计时间戳，按重试上限重试；仍失败则升级到值班频道由人工确认。 - **命中但通知发送失败**：按重试上限重试投递；超过上限则升级，并保留待发内容供人工补发。 - **未命中（结果为 0）**：仍发一条"本期无新增高危"汇总回执并留时间戳，让"没消息"变成可核验的记录，而不是无声结束。 - **查询 Agent 回传不合结构**：本次完成请求被拒绝，停在等待点等其修正后重新提交，不自动重跑。 本案例不涉及审批。安全漏洞通知是紧急且低风险的信息，应第一时间触达团队；因此不设 `request_approval` 环节，三种结果直接出回执。 本工作流的漏洞库查询由获授权 Agent 通过 App/Extension 完成，工作流本身不直接调用外部系统。进入 Agent 消息、Run/Activation/Effect 记录与 App/Extension 工具日志仅记录白名单/令牌化字段，原值不进入以上任何一层，并按 10% 抽查四层实际记录。依赖清单以安全引用（令牌）作为调用输入提供（或由该 Agent 读取锁文件，同样只取白名单字段）；漏洞库的访问凭据用 `` 占位，由 Agent 运行时从密钥引用。漏洞库不可达或数据陈旧属于查询失败，走上面的失败回执与升级，不当作"全部安全"。 - **回放集与基准**：用 100 组已标注的依赖清单（含已知公开漏洞）回放，人工基准答案为既定高危清单；高危召回率 ≥ 95%，误报率（非高危被标高危）< 10%。 - **分母与口径**：召回率分母为基准高危总数；每次回放记录扫描与通知时间戳。 - **结果可见**：命中、未命中、查询失败三类结果 100% 各有可见回执，不出现静默成功。 - **时效**：从本次扫描启动到通知发出的中位数 < 10 分钟；高危修复启动时间中位数下降 ≥ 60%。 - **源头脱敏**：进入 Agent 消息、Run/Activation/Effect 记录与 App/Extension 工具日志的字段 100% 在白名单内（仅令牌化/白名单字段，原值不进入以上任何一层），并按 10% 抽查四层实际记录。 ### 复用与变体 - **同构迁移**：证书到期告警、许可证合规检查、API 限额预警。 - **按严重度路由**：高危发到值班频道并提醒负责人（按令牌回填），中低危汇总成一条周报发到开发群。