3. 防护验证总览：上线前防护的三大支柱

在 Serverless 平台发布流水线中，上线前的事件触发防护验证并非单一维度的检查，而是由代码扫描、配置审计和流量控制三大支柱构成的立体防御体系。三者分别从源码安全、基础设施合规和运行时稳定性三个层面，确保每一次函数发布都不会引入安全漏洞、配置漂移或流量冲击。

3.1 三大支柱定义与职责

3.2 验证流程全景图

下图展示了从代码提交到正式上线的完整防护验证流程，三大支柱按阶段依次介入，形成“左移安全”的闭环。

3.3 三大支柱的协同关系

三大支柱并非孤立运行，它们通过统一的事件驱动引擎串联，形成以下协同模式：

• 数据共享：代码扫描发现的敏感信息（如密钥）会同步给配置审计，用于校验环境变量中是否引用了已泄露的密钥。
• 策略联动：配置审计检测到函数角色权限过大时，会触发流量控制阶段的灰度策略调整，限制该函数的新版本流量比例。
• 结果聚合：三个阶段的结果汇总至统一的防护报告，以 JSON 格式输出，供后续审计和可视化展示。

3.4 验证流程的输入与输出

3.5 防护验证的触发事件类型

流水线中的防护验证由以下事件触发，确保每个环节自动执行：

• 代码推送事件：当开发者向受保护分支（如 main、release）推送代码时，自动触发代码扫描。
• 构建完成事件：CI 构建成功后，触发配置审计阶段，校验 IaC 模板和函数配置。
• 预发布部署事件：函数部署到预发布环境后，触发流量控制验证，执行灰度压测。
• 定时触发：对于长期运行的分支，支持定时触发全量防护验证，确保基线持续合规。

3.6 防护验证的失败处理策略

当任一阶段阻断时，流水线执行以下标准操作：

1. 立即停止：阻断当前流水线运行，禁止后续阶段执行。
2. 发送通知：通过事件总线向开发者、安全团队、运维团队发送阻断详情。
3. 自动回滚：如果阻断发生在流量控制阶段，自动将线上流量切回上一个稳定版本。
4. 生成报告：将阻断原因、涉及资源、修复建议汇总为 Markdown 报告，存入制品库。
5. 记录审计：所有阻断事件写入审计日志，保留至少 90 天。

3.7 防护验证的度量与反馈

为了持续优化防护效果，需要建立以下度量指标：

• 阻断率：被防护验证阻断的发布次数 / 总发布次数。理想范围：5% - 15%（过低说明防护过于宽松，过高说明代码或配置质量差）。
• 误报率：误阻断的发布次数 / 总阻断次数。目标：< 5%。
• 平均修复时间（MTTR）：从阻断到修复完成重新提交的平均时间。目标：< 30 分钟。
• 防护覆盖率：已接入三大支柱的函数数量 / 总函数数量。目标：100%。