亚马逊AWS官方博客
针对代码漏洞的 AWS Continuum 现已正式推出
今天,我们宣布针对代码漏洞的 AWS Continuum 正式推出。AWS Continuum 是一项安全服务,可发现和验证代码漏洞,然后以补丁的形式提供修复,您可以自动执行修复,或以拉取请求的形式在存储库中提供修复。针对代码漏洞的 AWS Continuum 可确认哪些调查发现可在您的环境中利用,按业务影响对由此产生的问题进行排名,并针对每个问题提出修复方案。每项补救措施都以 Continuum 提出修复方案并在交付前获得人员批准的模式开始。将来,您将能够决定 Continuum 可以在您定义的护栏内自行采取哪些措施。
使用前沿人工智能(AI)模型,威胁行为者可以在几分钟内将漏洞披露转化为有效的漏洞利用代码,而加速开发的相同工具也会增加团队必须处理的调查发现数量。如果您的组织运行大型应用程序资产,则您的扫描器每天可能会产生成千上万个调查发现,其中许多无需采取任何措施。调查发现可能无法触达、无法利用,或者已经被运行时控制所缓解。通用严重性分数并不能告诉您威胁行为者实际可以触达哪些资源,因此,仅用于开发的实用程序的临界分数,看起来与距离支付数据库仅一步的服务的中等分数相同。以前,确认调查发现是否可被利用需要数小时的人工调查,而充满信心地交付修复需要安全、基础设施和应用团队数天的协调,因为如果没有业务背景,就很难评测变更的影响范围。为了缩小这一差距,Continuum 证明了哪些调查发现可以利用,并限制了其提出的每种修复方法的风险。
Continuum 根据两个主要源构建上下文图:您的代码存储库和您的 AWS 环境。对于 AWS,您在运行代码的账户和区域中设置一个收集器。收集器收集资源详细信息,例如 AWS Config 资源和网络配置,这样 Continuum 就可以判断漏洞是否可以通过网络触达以及威胁行为者可以从中获得什么。从这张图中,Continuum 了解哪些系统是业务关键型系统、谁拥有它们、服务如何相互依赖以及每个系统触达哪些数据。它使用该图片来识别您价值最高的系统,例如客户数据存储、支付管线和身份验证服务,然后根据其攻击路径与这些系统的距离对每个问题进行排名。
Continuum 根据您的代码及其环境上下文分析每项调查发现,并分配证据级别,例如通过对漏洞代码路径进行静态分析所证实的判决。为了获得可以重现的调查发现,Continuum 在隔离的沙盒中运行漏洞利用,并在重现步骤中附上概念验证代码。它可以生成攻击路径、支持源分析和影响范围评测,而不仅仅是风险分数。它还会评估您的现有防御措施是否会检测并阻止经过验证的路径。
对于每个已确认的问题,Continuum 都会生成一个修复程序(代码补丁、依赖项升级或配置更改),并将其作为拉取请求在连接的存储库中打开,随时可供审查。每项修复都需要人工批准:您审查并合并拉取请求,因此最终决策由您的团队作出。将来,您将能够建立对特定补救类别的信心,并让 Continuum 在其信任门通过后自动应用这些修复措施,例如测试覆盖范围、范围界限和历史成功率。
针对代码漏洞的 AWS Continuum 的实际应用
为了展示其工作原理,我在控制台中打开 AWS Continuum,然后转到代码漏洞。在我审查问题之前,我先设置了一个环境。我连接一个代码源,要么是 GitHub 集成,要么是 Amazon S3 存储桶,然后创建一个按我选择的时间表对其进行扫描的环境。Amazon S3 源有几个先决条件:存储桶位于我开启 AWS Continuum 的同一个账户和 AWS 区域中,我通过 AWS Continuum 担任的 AWS Identity and Access Management(IAM)角色授予访问权限。我可以选择通过在运行我的代码的账户和区域设置 AWS Continuum 收集器,并授权我的环境使用该收集器来添加 AWS 基础设施上下文。有关完整要求和步骤,请参阅 AWS Continuum 用户指南。
概述页面将这些部分汇集到一个位置,显示我的代码集成、基于它们构建的环境以及任何提供 AWS 资源上下文的 AWS 收集器的状态。

我打开了我的一个环境。问题选项卡列出了经过验证的优先级问题,而不是扫描器的原始输出,每个问题都有严重性、状态和创建时间。我选择了其中一个问题。
概述将其评为“高”严重性,状态为已完成,补救措施已交付给 GitHub。风险评测解释了原因。Continuum 将其可利用性评级为可利用,其证据水平为静态已验证,验证运行状态为已完成。可能性为高,因为攻击者可以触达该服务,不需要身份验证,也不需要用户交互。影响为中等,这意味着攻击者能够修改业务数据,影响范围可以触达同一租户中的其他用户。证明部分包括判决背后的源分析。
补救部分显示了已在 GitHub 中作为拉取请求交付的修复,更改了四个文件,在购物车服务中添加了 50 行,移除了 24 行。Continuum 以名为 Continuum 修复的拉取请求的形式打开该修复,我选择查看拉取请求在 GitHub 中将其打开。控制台明确指出,生成的补丁并不意味着问题已得到修复。我仍然会对其进行审查和合并,这样我的团队才能做出最终决策。贡献调查发现部分列出了构建此问题时所依据的特定扫描器调查发现。
拉取请求描述包含相同的风险评测、补救摘要和来自控制台的证据,因此,无论谁在 GitHub 上对其进行审查,都可以在不离开工作流程的情况下看到证据。
调查发现选项卡列出了整个环境中扫描器的原始调查发现,以及问题所依据的证据。
扫描选项卡显示每次扫描的历史记录及其状态、起源、请求和完成时间,我使用配置扫描频率来更改节奏,或者使用队列扫描改为按需运行。配置选项卡是我管理环境的地方:包括其读取的代码和上下文源、代码集成、Continuum 是否创建补丁等环境设置,以及其用于 AWS 上下文的 AWS 收集器。
在单一工作流程中,我会在每次扫描中按优先顺序处理经过验证的问题,在批准和合并我信任的修复程序之前,审查每个扫描背后的证据和范围。每一次修复都要等待我的批准,所以待办事项不断减少,同时我的团队可以控制交付哪些内容。
现已推出
针对代码漏洞的 AWS Continuum 现已在美国东部(弗吉尼亚州北部)和美国西部(俄勒冈州)区域推出。有关定价,请访问定价页面。
要了解更多信息,请访问针对代码漏洞的 AWS Continuum 产品页面和用户指南。立即在 AWS Continuum 控制台中试用,并通过常用的 AWS Support 联系方式向我们发送反馈。



