Security Hub加入修复计划：共同根因集中处理，影响数字不能直接相加
2026年10月1日，AWS为Security Hub推出remediation plans。新功能把共享根因的暴露发现放进修复计划，让团队围绕底层资源处理问题。它覆盖Security Hub已提供服务的区域，并包含在Essentials计划内，不增加这项功能的费用。
从逐条发现转向共同资源
官方指南说明，计划按目标资源与可处理的暴露特征组合生成，每个计划针对一个资源。例如同一处过宽配置可能参与多个暴露路径，修好这一处，就可能同时解决或降低多项风险，避免给同一个修改动作开出一串互相不知情的工单。
这给安全与资源负责人的沟通提供了更具体的对象：要改哪一个资源、位于哪个账户和区域、涉及哪些暴露。优先级分为Critical、High、Medium、Low，但新发现出现后，对应计划可能不会立即生成。计划列表为空，不能单独证明没有待处理暴露。
AI模型生成的概念插图：多条安全发现汇聚到同一个待修复资源，再展开检查步骤；不是实际Security Hub看板或风险统计。
影响分成三类，不能都算成已解决
一个计划的Impact会区分完全解决、降低严重程度，以及进行了处理但严重程度不变的暴露项。最后一种情况仍可能有价值，但在汇报中应保留它与“关闭风险”的差别。否则一次局部改进很容易被描述成整条暴露路径已经消失。
仪表盘最多显示五个New或Updated计划，按优先级排序。每个计划独立统计自己的影响，多计划若覆盖同一暴露，该暴露会在各计划中重复出现。把五行影响数直接相加，可能高估实际涉及的不同暴露数量；应回到Affected exposures明细按记录核对。
这也影响工作量估算。同一暴露可能有多个可选修复计划，团队需要选适合当前架构的路径，而非把所有计划机械地全部执行。目标资源的所有者、业务依赖和变更窗口，会决定哪一种风险降低方式更容易可靠落地。
指导步骤更完整，执行仍属于自己的变更流程
公告列出AWS CLI、Terraform、CloudFormation、Python和CDK等示例格式；实际可用格式与步骤取决于目标资源的指导。指南可分为前提、快照、修复、验证和完成等阶段，部分步骤还带回滚说明。缺少指导时，界面会报告，而不是凭空补出操作。
官方特别明确：Security Hub描述步骤，资源由用户自行修改。API让智能体可以读取计划，并不自动授权它执行其中的每个动作。接入自动化时，应让资源范围、执行身份和批准条件与计划一起传递，再保存实际执行及验证结果。
还要留意Rollout字段：有些修复立即生效，有些需要部署。配置文件已经更新而尚未部署时，线上风险可能仍在；反过来，命令返回成功也不保证所有相关发现已经重新评估。验收应对照计划覆盖的具体暴露，而不仅是执行日志。
接API做盘点时，还要处理分页。官方SDK说明，GetRemediationsV2默认最多返回25项，max_results可设为1至100；后续页要使用返回的next_token。按单条发现查询可用metadata_uid，但不能与target_uid或filters并用。只保存第一屏或第一批响应，就可能漏掉仍在等待处理的计划。
来源与核对时间
资料核对：2026年10月3日（北京时间）。本文未执行云端修复；计数解释与变更验收讨论为原创分析。
