【Falco】响应与生态边界：告警下游到哪里为止
内容提要
本文总结Falco 0.44.1告警响应边界：引擎仅保证输出至现存sink（如stdout/file/http），下游SIEM、自动处置等属平台响应栈。规则协作需明确仓库所有权、版本兼容及plugin字段依赖。自动化接口将Falco作事件源，动作由其他控制面执行。不涉及SIEM配置细节，开放问题留待第16篇。
延伸解读
告警下游的边界：检测内核与响应栈的分工
Falco 引擎只保证将告警写入仍存在的 sink（如 stdout、file、http），而 SIEM 解析、工单、自动处置等均属于平台响应栈。升级到 0.44.0 后 gRPC output 已删除，旧 runbook 若仍依赖 gRPC 会导致“引擎没告警”的假象。排障时应先核对 sink 白名单，再检查规则条件，避免将响应栈问题误归因于检测内核。
规则协作的三大接口：所有权、版本与插件依赖
规则仓库协作需明确合并权与误报责任，不能仅在 SIEM 侧静音。升级 Falco 时规则兼容性需单独验证，不能假设旧规则文件永远可热加载。依赖 plugin 字段（如 container.*）的规则，协作方必须同时锁定 plugin 版本，否则可能出现“规则仓库绿了但集群条件永远假”的情况。
自动化接口：Falco 是事件源，不是编排器
自动化应把 Falco 当作事件源，处置动作（如杀 Pod、改 NetworkPolicy）由其他控制面执行。最小可验收演练可选用一条高优先级规则，确认 sink 投递成功，再由人工或独立控制器执行可回滚动作，并记录告警 ID 与动作 ID 的对账。失败若发生在 sink 归 Falco 五轴，若在动作控制面则归对应系统，避免混为一谈。
Q&A
Falco 0.44.1 中告警输出到下游的边界在哪里？
Falco 0.44.1 引擎只保证将告警输出到仍存在的 sink，如 stdout、file、http 等。下游的 SIEM 解析、工单、自动处置等属于平台响应栈，不在 Falco 检测内核范围内。
Falco 0.44.0 删除了 gRPC output，对升级用户有什么影响？
如果旧 runbook 仍将 gRPC 作为唯一下游，升级后会出现“引擎好像没告警”的表象，实际是接线点已不存在。排障时应先核对 sink 白名单，再检查规则条件。
在 Falco 规则仓库协作中，如何避免误报和字段依赖问题？
规则合并权应由安全/平台联合评审，误报关闭必须修改异常或条件，禁止仅在 SIEM 侧静音。依赖 plugin 字段的规则集，变更单必须附 plugin 版本钉，否则可能导致规则仓库正常但集群条件永远为假。
Falco 自动化响应接口有哪些？如何设计自动化 ADR？
自动化接口包括：结构化告警离开 sink、与资产上下文合流、处置动作落在别的控制面。自动化 ADR 应写清触发条件来自哪条规则与哪个 sink、动作由谁执行、回滚谁负责。不要在 Falco ConfigMap 中实现 SOAR。
如何验证 Falco 告警到下游的链路是否正常？
最小可验收演练：选一条可合成的高优先级规则，确认 sink 落盘或 http 投递成功，再由人工或独立控制器执行一次可回滚动作，并记录“告警 ID → 动作 ID”对账。失败若在 sink 归 Falco 轴 5，若在动作控制面归对应系统。
Falco 系列文章不包含哪些内容？
不包含 SIEM 逐步配置（如 Splunk/ELK 的 indexer、pipeline 截图）、告警到工单系统的字段映射、推荐 SOAR playbook 产品清单，以及将已删除的 gRPC output 写成当前能力。
Falco 生态中还有哪些开放问题？
开放问题包括：driver.kind=auto 回退是否应成为一等公民、plugin 与 syscall 主路径的一致性 SLO、与 Tetragon/Cilium 的联合 runbook、BPF iterators 在容器运行时的默认策略。这些将在第 16 篇展开。
