📦 AWS Alert Handler — AWS 警报处理器

AWS Alert Handler 将 AWS 警报归一化为一致的 JSON 格式。可以独立运行或作为事件响应工作流的第一步。 范围 解析 Security Hub（ASFF）、Inspector v2（原始 API 或 EventBridge 封装）和 CloudWatch 报警状态更改（EventBridge 或 SNS 直接）。任何这些封装在 SNS 通知封装中的都会自动解封。 不解析自定义 Slack 消息、AWS Chatbot 输出或成本异常发现。 格式详细信息和范围外指南：references/alert-formats.md。 使用方法 将任何警报 JSON 管道到统一入口点： cat alert.json | scripts/parse-alert.sh echo "$ALERT_JSON" | scripts/parse-alert.sh parse-alert.sh 自动检测格式，解封 SNS 封装，并分派到正确的格式特定解析器。 对于基于 Webhook 的传递（SNS → OpenClaw /hooks/aws-alert），请参阅 references/webhook-setup.md。 归一化输出形状 符合共享的 normalized-alert-v0 接口。 核心字段： source — security-hub | inspector2 | cloudwatch-alarm source_subtype — 格式特定（例如 guardduty、package-vulnerability） severity — CRITICAL | HIGH | MEDIUM | LOW | INFORMATIONAL state — ACTIVE | ALARM | OK | INSUFFICIENT_DATA | RESOLVED account_id、region、resource_ids[]、title、summary、detected_at、console_url raw — 原始有效负载，保留 Inspector v2 结果还携带 inspector_score（CVSS 0.0-10.0）当存在时。 完整模式、示例、严重性映射规则和 CloudWatch 噪音过滤器列表：references/severity-mapping.md 和接口契约。 退出代码 parse-alert.sh 退出： 0 — 正常解析成功；stdout 是归一化的 JSON 2 — 有效负载不匹配任何已知格式；stderr 列出接受的形状 3 — 缺少 jq 4 — SNS SubscriptionConfirmation（不是警报）；stderr 包括 SubscribeURL 10 — 非事件报警被过滤掉；stdout 是跳过哨兵（见下文） 跳过哨兵 CloudWatch 解析器为已知的非事件报警（ECS TargetTracking 自动缩放、Elastic Beanstalk 默认报警、EC2 AutoScaling 策略、Synthetics 金丝雀状态更改）发出跳过哨兵，而不是归一化有效负载。 当这种情况发生时，parse-alert.sh 退出 10，stdout 是： { "skip": "non-incident-alarm", "reason": "...", "alarm_name": "..." } 退出 10 时，丢弃事件：不调用下游处理，不发布到聊天。 可选：移交到事件响应 如果安装了事件响应并且警报需要响应，则调用它并传递完整的归一化有效负载 — 形状包含所有响应需要的分类、范围、关联、调查和建议。 与 ggettert/incident-triage 配对良好 — 推荐的下游事件响应工作流。 github — 在关联步骤中由事件响应使用。 安全解析器 脚本在本地运行；没有外部 API 调用。 raw 字段保留原始有效负载。 如果警报可能包含敏感数据，则在发布到任何可见位置之前剥离 raw。 对于基于 Webhook 的警报： OpenClaw 的 bearer-token 验证保护了端点，但 SNS 默认不发送您的 bearer 令牌。 请参阅 references/webhook-setup.md 以获取欺骗风险和缓解模式。