从安全头条到代码补丁：用 AWS Continuum 与 AWS WAF 构建安全事件雷达

摘要：本文介绍开源示例 Security Radar（GitHub：aws-samples/sample-security-radar）：它每 10 分钟从二十余个公开情报源采集安全事件，由代码判定真实性与紧急度，把与你的代码相关的事件精确定位到文件和行，再交给 AWS Continuum 证实可利用并以 Pull Request / Merge Request 交付补丁；在补丁上线之前，它先用 AWS WAF 与 Amazon Route 53 Resolver DNS Firewall 在边缘做缓解。

一、背景：从漏洞披露到被利用，窗口越来越短

AWS 在发布 AWS Continuum for code vulnerabilities 时指出，借助前沿 AI 模型，攻击者可以在几分钟内把一份漏洞披露变成可用的利用代码。而补丁要经过评审和发布，通常以天计。

安全团队手里并不缺工具。代码扫描可以找出漏洞，AWS Continuum 可以证实一个漏洞在你的环境里是否真的可被利用。但它们回答不了另一类问题：

• 外面刚发生了什么？ 安全资讯源多、转载多，同一条消息被多家媒体转发，看起来像是「多方证实」。
• 它和我有没有关系？ 一条 CVE 要落到「哪个仓库、哪个文件、哪一行」才有行动意义。
• 什么时候值得花钱扫？ 全量扫描有成本，不能每条新闻都触发一次。

Security Radar 补的就是这一段：它是 AWS Continuum 的探测器 + 触发器。

二、方案概览

[图 1. 探测器 + 触发器：公网情报 → 交叉验证 → 定位到行 → AWS Continuum 证实可利用并交付补丁]

Security Radar 的探测器 + 触发器闭环

一个完整的闭环分四步：

1. 探测：每 10 分钟采集一轮公开情报（CISA KEV、厂商 PSIRT、安全媒体、Web3 事件库等），由代码完成去重、聚类、真实性分级和严重度判定。
2. 触发：只对 P0，或已被利用、已有 PoC 的 P1 事件，检查它是否命中你登记的代码仓库。命中后，雷达把事件写成安全规则并发起代码评审（AWS Security Agent），同时把精确到 文件:行 的 finding 提交给 AWS Continuum。
3. 证实与修复：AWS Continuum 在隔离沙箱里验证可利用性，按业务影响排序，并把修复以 Pull Request（GitHub）或 Merge Request（GitLab）交付。每个修复都需要人审核合并。
4. 快路缓解：补丁上线前，雷达只在自己创建的资源上挂 AWS WAF 托管规则和 DNS Firewall 规则，一律先用不拦截的观察模式，人确认后才切换为拦截。

关于本文用到的 AWS 安全服务的状态（截至 2026 年 11 月）：

三、架构

[图 2. 每 10 分钟一轮：采集 → 聚合判定 → 分析卡 → Respond → 发布，全部为 Serverless 组件]

Security Radar 架构

整个示例用 AWS CDK 部署为三个栈：

主要组件：

• Amazon EventBridge 每 10 分钟触发一轮 AWS Step Functions 状态机：Plan → Collect（Map，并发 6）→ Process → Analyze → Respond → Mitigate → Publish，单轮超时 25 分钟。
• AWS Lambda（Python 3.12，ARM64）承担每个工位。Process、Analyze、Respond、Mitigate 的并发都设为 1，保证单写者。
• Amazon DynamoDB 单表保存条目、事件和源状态；Amazon Simple Storage Service（Amazon S3） 保存原始批次（90 天过期）和站点数据。
• Amazon Bedrock 为 P0/P1 事件生成分析卡和每日简报。
• Amazon CloudFront 通过 OAC 访问私有 S3 源站，用 CloudFront Functions 和 KeyValueStore 实现演示用的访问门。
• Amazon CloudWatch 设置「30 分钟内没有成功轮次」的告警，避免雷达静默停摆。

任何工位失败都会被状态机捕获，后续发布照常进行。采集失败不会被当成「没有新闻」：每个源都记录失败原因，解析出 0 条也算错误。

四、界面一览

雷达自带一个 React 单页应用，通过 Amazon CloudFront 发布。下面的首页、大屏、Web3 和信源健康截图来自作者的实际部署，事件名称、受害方和损失金额等信息已做马赛克处理；漏洞列表为示例仓库的 mock 数据。

[图 3. 首页：L0 一句话态势、24 小时采集漏斗（采集 → 新/更新 → 事件 → 证实 → P0），L1「必须处理」卡片标出真实性等级、独立来源数，以及是否命中你的环境]

首页：态势与必须处理的事件

[图 4. 大屏：雷达扫描图把事件按漏洞、Web3、安全事件三个扇区分布，两侧是实时事件流、必须处理清单和 Web3 损失排行，底部是 24 小时事件密度]

大屏

[图 5. 漏洞列表：每条事件带严重度（P0/P1/P2）、真实性等级（V1–V4）、独立来源数、利用状态和首报来源；「命中 1/2」表示在你登记的 2 个目标中命中 1 个]

漏洞事件列表

[图 6. Web3 事件：按损失金额、链分布汇总，每条事件标明独立来源数和真实性等级]

Web3 事件列表

[图 7. 信源健康：每个源的分层、采集频率、24 小时条数、最近成功时间和最近错误。失败、降级和从未运行的源会被单独标出，而不是被当成「没有新闻」]

信源健康

五、核心设计一：真实性与严重度由代码判定

[图 8. 真实性等级 V0–V4 全部由代码按证据计算，大模型不参与判定]

事件真实性等级状态机

独立来源计数。 雷达不按「多少篇报道」计数，而是用并查集把「同一组织、一方链接另一方原文、引用同一条推文、标题相似度 ≥ 0.85」的来源合并为一组，每组只算一个独立来源。转载不会抬高可信度。

真实性等级。 来源按 T1（官方、厂商、可复现 PoC）、T2（知名媒体、研究机构、聚合库）、T3（社区与快讯）分层：

对 Web3 事件，雷达会用 eth_getTransactionReceipt 到无需密钥的公共 RPC 查询攻击交易回执：status 为 0x1 即判定为链上已证实。每轮最多查询 8 次，单次超时 6 秒。

严重度。 P0 必须同时满足两个条件：影响规则成立，并且在 72 小时内首次出现或升级。影响规则举例：

• 漏洞类：已确认被利用（CISA KEV 收录，或 T1 来源称在野利用）且达到 V3，或报道被利用且达到 V2。
• Web3：损失金额 ≥ 100 万美元且达到 V2。

升级时间取最新证据的发布时间，而不是处理时间，避免回填的旧数据看起来很「新」。

六、核心设计二：大模型只写带引用的句子

雷达里唯一调用大模型的地方，是为 P0/P1 事件写分析卡（what / so-what / now-what）和每天早上 8 点（UTC+8）的简报。规则很严格：

• 只能使用给定的证据，每句话至少引用一个条目 ID。
• 句中不得出现被引条目里没有的数字、版本号、日期、金额或地址。

代码会逐句校验：没有引用记为 no_citation，引用了不存在的条目记为 unknown_citation，句中的数字在被引原文里找不到记为 ungrounded_number。没通过校验的句子会被标为未证实，而不是静默展示。

本示例通过 Amazon Bedrock 的 Converse API 调用模型，默认使用 Anthropic Claude Sonnet（分析卡与简报）和 Claude Haiku（疑似重复事件的判断）。疑似重复只提示、不自动合并：代码先排除 CVE 或交易不相交的配对，剩下的才交给模型判断。

七、核心设计三：定位到行，触发 AWS Continuum

[图 9. 事件详情页（示例数据）：命中的仓库与文件行、AWS Security Agent 与 AWS Continuum 的动作时间线、修复补丁]

事件详情页中的「在你的环境中」面板

当一个事件通过资格判定，Respond 工位会：

1. 定位：在登记的目标仓库里，把受影响的产品和版本对到具体的 文件:行，例如 Dockerfile:1、composer.json:7、.gitlab-ci.yml:2。
2. 代码评审（AWS Security Agent）：把事件写进规则包并发起代码评审，取回 finding 和修复 diff。
3. 提交 finding（AWS Continuum）：以 OCSF 2002 格式向 AWS Continuum 提交精确到行的 finding，并把已校验的分析卡写入 Continuum 的知识上下文。
4. 取回结论：读取 Continuum 的验证结论（例如 EXPLOITABLE）、issue、可利用性证据和补丁，并把它们回写到事件页。

每个仓库只进入一个 Continuum 环境，代码来源可以是 Amazon S3、GitHub 或 GitLab。增加一种托管方式只需要在 respond.REPO_CHANNELS 里加一行，再加一个同步适配器。

八、核心设计四：补丁上线前，先在边缘缓解

Mitigate 工位是纯确定性代码，不调用大模型。它有三条原则：只针对已定位且确认受影响的目标；只改雷达自己创建的资源；缓解不等于修复。

AWS WAF。 雷达解析 AWS Managed Rules 的变更日志，按「最具体优先」生成计划：

切换到 Block 是人的动作，用 scripts/promote.py waf <web-acl> <group> –by <name> 完成，用 –revoke 撤回。雷达从不自己删除规则。

雷达还会只读核查已有防护的真实状态，逐条报告 absent、too_old、group_counted、staged、blocking。这能发现两种常见的「以为防住了」：规则组被整组设成 Count，或者版本钉在了不包含该 CVE 规则的旧版本。

Amazon Route 53 Resolver DNS Firewall。 雷达只采用证据里防篡改写法的域名（如 evil[.]com），加上 5 个 AWS 托管威胁域名列表，全部设为 ALERT，人确认后再晋升为 BLOCK。amazonaws.com、github.com、pypi.org 等常用域名在永不拦截清单里。

Amazon Inspector。 雷达把目标仓库的 lockfile 转成 CycloneDX 1.5 SBOM，调用无状态的 ScanSbom 接口，求「事件 CVE ∩ 目标 findings」的交集；账号里不需要开通 Inspector。需要注意，ScanSbom 只判语言包，PHP、Node.js 这类运行时版本仍由雷达自己的产品登记表判断。

可选地，用 -c security_hub=on 部署时会创建 AWS Security Hub，用于汇总。

九、安全设计

• 先验门，再传内容。 部署脚本先布防 CloudFront 上的访问门，确认匿名请求返回 401 之后，才上传站点内容；最多重试 30 次、每次 10 秒，仍看不到 401 就中止。
• 门禁失败即关闭。 KeyValueStore 只存凭证哈希，读不到就拒绝访问。
• 最小权限且可测。 每个工位单独授权。测试 tests/test_iam_scope.py 保证 IAM 动作和代码实际调用的 API 一一对应；AWS WAF 的权限只覆盖名称前缀为 security-radar-* 的 web ACL。
• 私有源站。 S3 桶全部阻止公共访问、启用 SSE-S3、强制 TLS，CloudFront 通过 OAC 访问。
• 持续检查。 CI 中启用 cdk-nag，任何没有说明理由的发现都会让合成失败。

十、动手部署

前置条件

• 一个非生产的 AWS 账号。
• 账号已开通 AWS Continuum；ap-northeast-1 可用 AWS Security Agent。
• Amazon Bedrock 已开通 Anthropic Claude Sonnet 与 Haiku 的模型访问。
• 已在 ap-northeast-1 和 us-east-1 执行 CDK bootstrap。
• 本地已安装 uv、Node.js ≥ 22、AWS CLI v2。

示例代码在 GitHub 仓库 aws-samples/sample-security-radar。建议用独立的 STAGE 部署，便于验收和清理：

git clone https://github.com/aws-samples/sample-security-radar.git && cd sample-security-radar
export AWS_PROFILE=<non-production-profile>    # 必须显式设置，否则脚本报错退出

# 构建 → 部署三个 CDK 栈 → 布防访问门 → 上传 UI → 跑一轮 → 验收
STAGE=demo ./scripts/deploy-all.sh

# 输出 PASS / FAIL 验收结果与集成覆盖情况
STAGE=demo ./scripts/verify.sh

可选：

• 用 REVIEW_BUDGET=<n> 限制每天付费代码评审的次数。
• 希望补丁以 GitHub PR 交付：运行 uv run python scripts/sync-fleet.py –channel github –apply，授权 AWS Continuum 的 GitHub App，再在 infra/cdk.json 设置 github_repo。
• 希望以 GitLab MR 交付：运行同一命令并加 –channel gitlab，设置 gitlab_project 和 gitlab_url。

站点访问密码保存在 AWS Secrets Manager 中，对应栈输出 UiSecretArn。

十一、成本

因为扫描是主要成本，雷达内置了几道护栏：

• 只为验证雷达自己已成功提交的 finding 才发起扫描，并且要等上一次扫描结束。
• 每个环境 24 小时内最多扫描一次，关闭定时扫描。
• 每个仓库只进入一个环境。
• 付费代码评审按仓库合批，滚动 24 小时内最多 6 次。
• 每天 500 美元为预算线，超出时在花费看板上标记（只标记，不阻断）。花费数据来自 AWS Cost Explorer。

十二、注意事项与限制

• Region 固定。 雷达与 AWS Security Agent 部署在 ap-northeast-1，AWS Continuum 与 WAF 演示栈部署在 us-east-1，均写在代码中。AWS Continuum for code vulnerabilities 目前只在 us-east-1 和 us-west-2 提供。本示例只在上述海外 Region 部署和测试过；在其他 Region（包括亚马逊云科技中国区域）使用前，请先在区域服务列表中确认所需服务均已提供。
• 部分能力处于预览阶段。 AWS Security Agent 的代码评审能力（现为 Continuum code scanning）仍是预览版，API 与行为可能变化，请使用非生产账号。
• Continuum 资源没有 CloudFormation 类型。 Continuum 的 integration 和 environment 由 Respond 工位按名称对账创建，清理需要运行脚本，不能只靠 cdk destroy。每个环境最多 10 个仓库。
• Inspector 只判语言包。 ScanSbom 不判断 PHP、Node.js 等运行时版本，这部分依赖雷达自己的产品登记表，需要随产品范围维护。
• WAF 只覆盖有专属规则的 CVE。 只有 AWS Managed Rules 变更日志里点名的 CVE 才有专属规则；CWE 档只给建议，所有规则都不会被自动切换为 Block。
• 大模型校验有边界。 数字校验只检查两位以上或含小数点的数字，单个数字不校验；分析卡仍需人阅读判断。
• 演示用访问门。 CloudFront 上的 HTTP Basic Auth 只用于演示，生产环境应换成 Amazon Cognito 或 AWS IAM Identity Center。
• 示例仓库含故意的漏洞代码。 integrations/continuum/targets/ 下是用于演示的漏洞目标，不要部署，也不要复用其中的密钥或地址。
• X（Twitter）源默认关闭。 需要自备有授权的数据源，并配置 X_SEARCH_URL 和 X_API_KEY。

十三、最佳实践

• 始终用 STAGE=<name> 部署。 非默认 stage 的 S3 桶和 DynamoDB 表在销毁时会自动清空删除；默认 stage 为防误删设置了保留策略。
• 先用 REVIEW_BUDGET 控住付费评审。 首次接入时设 REVIEW_BUDGET=1 或 2，观察几天 finding 质量和花费看板，再放开。
• 缓解规则先观察再拦截。 规则挂上后先看 AWS WAF 的 Count 指标和 DNS Firewall 查询日志，确认没有误伤，再用 scripts/promote.py 晋升。
• 每次部署后跑端到端检查。 用 scripts/waf-e2e.py、scripts/dns-e2e.py 确认缓解链路真的生效，而不是只确认资源存在。
• 补丁 PR 一律人审。 AWS Continuum 的修复需要人批准后才合并；在 GitHub 或 GitLab 上为这类 PR 设置必需的代码所有者审核。
• 把雷达自己也纳入 SBOM 检查。 雷达的 lockfile 同样可以交给 ScanSbom，避免情报系统本身带着已知漏洞运行。

十四、清理资源

# 依次删除 Security Agent 代码评审、清空规则包、删除 Continuum environment / integration，
# 再销毁三个 CDK 栈
STAGE=demo ./scripts/destroy-stage.sh

destroy-stage.sh 会拒绝删除默认（未设置 STAGE）的部署，这是为了防止误删。如果你部署了默认 stage，需要手动删除保留下来的 S3 桶、DynamoDB 表和 Continuum 代码桶。

十五、总结

Security Radar 把「外面发生了什么」和「我的代码哪一行受影响」连了起来：真实性和紧急度由代码判定，大模型只写带引用、可校验的句子；命中你的代码后，由 AWS Continuum 证实可利用并以 Pull Request 交付补丁；在补丁上线之前，先用 AWS WAF 和 DNS Firewall 在边缘缓解，最终的拦截与合并都由人决定。

它适合希望把外部威胁情报变成具体代码动作的安全团队和平台团队，也可以作为接入 AWS Continuum 的参考实现。

示例代码：github.com/aws-samples/sample-security-radar

➡️ 下一步行动：

相关产品：

• Amazon WAF — Web 应用程序防火墙
• Amazon S3 — 适用于 AI、分析和存档的几乎无限的安全对象存储
• Amazon CloudFront — 全球内容分发网络
• Amazon Bedrock — 用于构建生成式人工智能应用程序和代理的端到端平台
• Amazon DynamoDB — 无服务器分布式 NoSQL 数据库

相关文章：

• 地理空间 AI 智能体（Code Agent）中国区部署实践
• 5 分钟拉起、90 秒自愈、成本 1/8——基于 Firecracker microVM 与 Bedrock AgentCore 的生产级多租户 AI Agent 平台 OpenClaw Pool
• 从应用安全到云安全，AWS Continuum帮助客户在SDLC 全生命周期进行安全管理（一）
• 从代码自查到渗透验证：Coreapi 的 AWS Continuum 实践
• 针对代码漏洞的 AWS Continuum 现已正式推出

十六、相关资源

• Security Radar 示例代码：本文的完整实现，含部署、验收与清理脚本
• AWS Continuum：产品页与定价
• AWS Continuum for code vulnerabilities 正式发布：AWS News Blog
• AWS Security Agent 用户指南：现为 AWS Continuum 的一部分
• AWS Managed Rules 变更日志：雷达生成 WAF 计划的依据
• Amazon Route 53 Resolver DNS Firewall
• Amazon Bedrock Converse API
• AWS Step Functions Map 状态

*前述特定亚马逊云科技生成式人工智能相关的服务目前在亚马逊云科技海外区域可用。亚马逊云科技中国区域相关云服务由西云数据和光环新网运营，具体信息以中国区域官网为准。

本篇作者

AWS 架构师中心：云端创新的引领者 探索 AWS 架构师中心，获取经实战验证的最佳实践与架构指南，助您高效构建安全、可靠的云上应用