从应用安全到云安全，AWS Continuum帮助客户在SDLC 全生命周期进行安全管理（一）

摘要：本文是”从应用安全到云安全”系列的第一篇，聚焦应用层安全，深度解析 AWS Security Agent 如何借助 Frontier Agent 的多智能体协作架构，将渗透测试从依赖专家、周期性、只覆盖关键应用的传统模式，转变为按需触发、7×24 运行、可嵌入 SDLC 全流程的持续验证能力；文章从传统渗透测试”速度快、挖掘深、覆盖广”难以兼得的困境切入，介绍了其多步骤攻击链模拟、OWASP Top 10 与业务逻辑漏洞全面覆盖、经实际利用验证的极低误报率、开发者友好的修复建议等核心能力，拆解了认证访问、基线扫描、多阶段探索、专用智能体集群、验证与报告五个架构环节，并通过黑盒、灰盒、白盒三种实战场景，展示了 Agent 如何理解应用上下文、串联攻击链并输出高置信度的漏洞发现。

01 一、系列导读

02 二、为什么需要重新思考应用安全？

03 三、AWS Security Agent 核心能力

04 四、多智能体架构深度解析

05 五、三大渗透测试场景实战

06 六、总结

一、系列导读

在当今快速迭代的软件开发环境中，安全不应再是上线前的最后一道”检查站”，而是需要贯穿整个软件开发生命周期（SDLC）的持续能力。亚马逊云科技为此推出了一类全新的 AI Agent——前沿智能体（Frontier Agent），它能够执行复杂推理、多步骤规划和自主执行，并通过 AWS Continuum 这一安全产品品牌落地，帮助客户在 SDLC 的每个阶段实现安全左移。

在展开之前，先简要厘清本系列反复出现的几个核心概念：

Frontier Agent（前沿智能体）：亚马逊云科技提出的一类全新 AI Agent，能够执行复杂推理、多步骤规划与长时间自主执行，可在数小时乃至数天内独立完成复杂任务。它是一种能力类别，而非某个具体产品；本系列涉及的安全智能体均属于这一类别。

AWS Continuum：亚马逊云科技面向安全的产品品牌（”security at machine speed”），统一承载并编排其下的多个前沿智能体，为它们的协同工作提供运行时与治理基础。

AWS Security Agent（本篇主角）：AWS Continuum 下的一员前沿智能体，面向应用安全，覆盖设计（威胁建模）、开发（代码安全审查）到测试（按需渗透测试）等 SDLC 环节，本篇聚焦其自动化渗透测试能力。

AWS DevOps Agent（第二篇主角）：AWS Continuum 下另一员前沿智能体，面向云上运维与基础设施安全，可通过自定义 Skill 对云上资源与日志进行安全审计，是本系列第二篇的核心。

本系列共三篇博客，从应用层到云上基础设施，全面介绍 AWS Continuum 及其前沿智能体如何重新定义安全管理：

第一篇——从应用安全到云安全，AWS Continuum 帮助客户在 SDLC 全生命周期进行安全管理（一）：聚焦应用层安全。深度解析 AWS Security Agent 的多智能体协作架构如何将渗透测试从依赖专家的周期性服务转变为按需调用的持续能力。通过黑盒、灰盒、白盒三种测试场景的实战演示，展示 Agent 如何理解应用上下文、串联攻击链、并以极低误报率输出经过验证的漏洞发现。核心能力为 Security Agent 自动化渗透测试。
第二篇——从应用安全到云安全，AWS Continuum 帮助客户在 SDLC 全生命周期进行安全管理（二）：聚焦云上安全，由 DevOps Agent 通过自定义 Skill 对 Amazon Elastic Compute Cloud（Amazon EC2）审计日志进行审计，同时延伸至中间件安全（如 Amazon Managed Streaming for Apache Kafka，即 Amazon MSK）及数据库安全（Amazon Relational Database Service（Amazon RDS）、Amazon Aurora、Redis 等托管服务开启审计日志），核心能力为 DevOps Agent 云安全管理。
第三篇——从应用安全到云安全，AWS Continuum 帮助客户在 SDLC 全生命周期进行安全管理（三）：覆盖其余全周期安全内容，串联端到端的安全保障体系，核心能力为多 Agent 联动的端到端安全。

二、为什么需要重新思考应用安全？

2.1 传统渗透测试的困境

对于大多数企业而言，理想的渗透测试需要同时做到”速度快、挖掘深、覆盖广”，但在传统模式下这三者往往构成一个难以兼得的不可能三角。落到现实中，具体表现为以下几个难点：

时间长：一次完整的人工渗透测试通常需要 3-6 周
成本高：资深安全专家资源稀缺且昂贵
覆盖窄：受制于资源，往往只能测试最关键的几个应用
频率低：传统渗透测试多为季度或年度一次性活动，无法匹配 SDLC 中高频迭代、持续交付的测试需求。

这意味着大量应用在上线后从未经历过真正的渗透测试。在敏捷开发模式下，每次迭代都可能引入新的安全风险，但安全验证的速度远远跟不上开发速度。

2.2 从“周期性评估”到“持续验证”

AWS Security Agent 代表了一种全新的安全范式——持续验证（Continuous Validation）。它不是在流水线末端添加另一个安全检查点，而是将安全验证直接嵌入到开发团队已有的工作流程中。

作为 AWS Continuum 下的一员前沿智能体（frontier agent），AWS Security Agent 能像人类渗透测试专家一样进行推理：理解应用行为、基于反馈调整策略、理解业务上下文，并执行复杂的多步骤攻击链。

三、AWS Security Agent 核心能力

AWS Security Agent 的能力覆盖 SDLC 的设计、开发和测试三个关键阶段。本文聚焦于按需渗透测试（On-demand Penetration Testing）——Security Agent 最核心、最具突破性的能力。

3.1 多步骤攻击场景模拟

传统的自动化安全扫描工具通常只能逐一检测孤立的漏洞点，而 Security Agent 的按需渗透测试则完全不同。它具备多步骤攻击场景模拟的能力，能够像真实攻击者一样，将多个看似低危的漏洞串联起来，形成完整的攻击链。例如，Agent 可能先利用一个信息泄露漏洞获取内部 API 端点信息，再通过该端点的权限绕过问题提升访问级别，最终达成数据窃取或横向移动的攻击目标。这种组合利用能力让安全团队能够真正理解每个漏洞在实际攻击场景中的真实风险等级，而不是仅仅看到一份按严重程度排序的漏洞清单。

3.2 OWASP Top 10 与业务逻辑漏洞的全面覆盖

在检测范围上，Security Agent 不仅完整覆盖 OWASP Top 10 等标准安全风险类别——包括注入攻击、认证绕过、敏感数据暴露、XML 外部实体攻击、访问控制失效等——更重要的是，它能够理解应用程序的上下文语境，发现传统工具难以捕获的业务逻辑漏洞。业务逻辑漏洞往往不涉及技术层面的代码缺陷，而是源于业务流程设计中的缺陷。例如，一个电商应用可能在技术层面完全安全，但其优惠券使用逻辑中存在的竞态条件或数量校验缺失，则可能被恶意利用造成直接经济损失。Security Agent 通过对应用程序行为模式的深度理解，能够识别这类隐蔽但影响严重的逻辑漏洞。

3.3 验证后的真实漏洞，极低误报率

Security Agent 最显著的差异化优势之一在于其漏洞验证机制。与传统 DAST 或 SAST 工具动辄产生大量误报不同，Security Agent 对每一个发现的潜在漏洞都会执行实际的利用验证（Proof of Exploitation）。只有当漏洞被成功利用、确认可被攻击者实际触发时，才会被标记为有效发现并纳入报告。这一机制带来的直接结果是极低的误报率，安全团队和开发人员不再需要花费大量时间去逐一排查和确认扫描结果的真实性，可以将精力集中在真正需要修复的问题上。

3.4 开发者友好的修复建议

在输出结果的可操作性上，Security Agent 为每个确认的漏洞提供完整的利用复现路径——包括具体的请求序列、参数构造方式和预期响应——让开发人员能够在本地环境中快速复现问题。同时，Agent 还会生成即时可实施的代码修复建议，不是笼统的安全最佳实践，而是针对当前代码库和技术栈的具体修复方案。开发人员可以直接参考甚至采用这些修复代码，大幅降低了从”发现漏洞”到”完成修复”之间的认知负担和时间消耗。

3.5 7×24 按需触发，周期从数周压缩至数小时

传统的渗透测试通常需要数周的准备、执行和报告周期，且受限于安全专家的排期和可用性。Security Agent 彻底打破了这一限制。它支持 7×24 小时按需触发，开发团队可以在任何需要的时间点——无论是新功能上线前的安全验证、重大发布前的全面检查，还是安全事件后的快速评估——立即启动渗透测试。原本需要数周才能完成的测试周期被压缩至数小时，安全验证的频率从季度或月度提升到了与开发迭代同步的节奏。

3.6 CI/CD 原生集成，持续安全验证

最后，Security Agent 提供标准化的 API 接口，能够无缝嵌入客户现有的 CI/CD 流水线。这意味着渗透测试不再是一个独立于开发流程之外的、需要人工协调的安全活动，而是成为代码合并、构建、部署过程中自动执行的一个环节。每次代码变更都可以触发针对性的安全验证，任何引入新安全风险的变更都能在进入生产环境之前被拦截。这种持续安全验证的模式真正实现了”安全左移”的理念——将安全检测嵌入开发的每一个环节，而不是在最后阶段才进行集中式的安全评审。

四、多智能体架构深度解析

AWS Security Agent 的渗透测试能力基于一套精心设计的多智能体协作架构（Multi-Agent Architecture）。传统的安全测试工具通常采用单一引擎逐步执行预定义规则，而 Security Agent 则通过编排多个专用智能体的协同工作来应对复杂的安全挑战——一个智能体负责映射攻击面，另一些则分别负责分析业务逻辑缺陷、验证漏洞发现、以及基于实际可利用性对漏洞进行优先级排序。这种”分而治之”的架构设计使系统能够同时兼顾测试的广度与深度。

4.1 认证与初始访问

渗透测试的第一步是”进入”目标应用。Security Agent 为此设计了一个智能登录组件——结合 LLM 推理和确定性机制，通过内置浏览器工具与应用交互，自动适配不同的应用架构和认证方式：

自动定位登录页面：无论应用使用何种前端框架或路由结构，系统都能自主定位并到达登录界面。这一能力基于 LLM 对页面结构的理解和确定性的 URL 探测机制的结合。
自适应认证处理：支持表单登录和基于 TOTP 的多因素认证。用户可以直接输入凭证，也可以通过 AWS Secrets Manager 安全检索或 AWS Lambda 函数动态生成。对于复杂的认证流程，Agent 通过浏览器工具逐步导航完成整个登录链路。需要注意的是，在多因素认证（MFA/2FA）方面，当前仅支持基于 TOTP 的验证器（Authenticator）方式，SMS 短信、推送通知、硬件密钥等其他 2FA 因子暂不在支持范围内。此外需要澄清的是，OAuth 2.0 / OIDC 是单点登录（SSO）与授权协议，并不属于 2FA 范畴，两者处于不同的认证层面，上述支持范围仅针对第二认证因子而言。
会话维持：认证成功后持续保持会话状态供后续所有测试阶段使用。系统还内置了 Login Optimization 功能——首次运行时学习成功的登录导航路径并记录为 skill file，后续运行直接复用已学习的登录模式，跳过探索阶段，减少重复认证的时间消耗并提升测试稳定性。
自定义登录提示：对于具有非标准登录逻辑的应用，开发者可以在 Agent Space login prompt 中提供自然语言形式的登录指引。例如描述”导航到 /auth/login 页面，在 Email 字段输入用户名，点击 Continue，在下一页输入密码后点击 Sign In”。清晰的步骤化指令能够显著提升 Agent 完成复杂认证流程的成功率。

4.2 基线扫描阶段

认证完成后，系统进入基线扫描阶段，通过并行执行多个专用扫描器建立全面的安全基线覆盖：

网络扫描（动态维度/黑盒测试模式）：网络扫描器对目标应用进行自动化 Web 安全测试，主动发送请求并记录应用响应，生成原始流量交互数据，从中识别可能存在漏洞的候选端点。这部分工作不依赖任何内部信息，完全基于应用的可观察行为来推断安全状态，覆盖的是所有对外暴露的攻击面。
代码扫描（静态维度/白盒测试模式）：当源代码可用时，代码扫描器额外进行深度静态分析，从多个安全维度生成描述性文档。代码接入以 GitHub 为主要且最完整的方式，此外也支持 GitLab、Bitbucket 与 GitHub Enterprise Server，或通过 Amazon Simple Storage Service（Amazon S3）Bucket 上传源代码包（具体支持范围与前置条件以官方文档为准，例如 GitLab 的 Group 级接入需要 Premium/Ultimate 付费订阅）。代码分析的独特价值在于它能发现运行时难以直接观察的风险。举个例子：一个端点的输入校验逻辑在正常使用中表现正常，但源码中这个校验只覆盖了前端提交，API 直接调用的路径完全没有防护——这类问题只有看了代码才知道。
补充扫描器：除上述两个核心扫描器外，系统还部署了额外的专用扫描器从其他维度进行检测，进一步拓宽初始覆盖面。

所有扫描阶段的产出，包括发现的端点信息、流量交互模式和代码分析文档，最终汇聚为后续多阶段探索的情报输入。Guided Explorer 组件会基于这些数据推理出哪些路径值得深入、哪些端点可能存在组合利用的机会，从而生成有针对性的测试计划，而不是盲目地逐一尝试。

4.3 多阶段探索

基线扫描画完了地图，接下来的问题是：怎么用这张地图找到真正的突破口？

Security Agent 在这一阶段采用两种协同策略。第一种叫受管执行（Managed Execution），做的是”该查的都查到”的事情——系统按照预定义的任务清单，对 XSS、IDOR、权限提升等主要风险类别逐一检测。这一步不依赖 AI 的临场推理，而是通过结构化的任务覆盖确保不遗漏标准风险项。

第二种叫引导探索（Guided Exploration），做的是”找到别人找不到的”。这个组件把前面所有阶段的产出汇到一起——哪些端点被发现了、哪些已经确认有问题、代码分析里标记了什么——然后基于这些情报推理当前应用特有的攻击机会。它会先生成一份测试计划，识别还没有被探索的资源和可能存在的漏洞链；然后管理这些动态任务的执行，并根据应用的实际响应持续调整策略。

两者互补：受管执行保底线，引导探索找惊喜。后者是 Security Agent 发现业务逻辑漏洞和复杂攻击链的核心能力。

4.4 专用智能体集群

不管是受管执行还是引导探索，实际干活的都是一组专用的 Swarm Worker Agent。每个 Worker 针对特定风险类型配置，手里有一整套渗透测试工具：代码执行器用来构造和运行 exploit PoC；Web Fuzzer 做模糊测试探边界情况；NVD 数据库接口查已知 CVE 情报判断组件是否有已知漏洞；还有针对特定漏洞类型的专用工具辅助利用。

每个 Worker 有超时管理，到时间没结果就收工，不会无限消耗资源。产出以结构化格式上报，方便后续验证环节处理。

4.5 验证与报告

自动化渗透测试有一个绕不开的问题：LLM 可能”编”出看起来合理但实际不存在的漏洞。Security Agent 用多层验证来解决这件事。

一个潜在发现被标记后，先过确定性验证器做规则级校验——格式对不对、证据链完不完整。然后由专用的 LLM 验证 Agent 尝试主动利用，独立确认这个漏洞是不是真能打通。在此之上还有断言式验证：安全专家把对真实攻击行为的深层理解写成自然语言断言，要求 Agent 提供明确的结构化利用证据。这种方式比纯规则检查更难被绕过——Agent 不能靠”编一个看起来合理的响应”来糊弄过去。

通过验证的漏洞会做 CVSS 评分评估严重性。最终报告包含漏洞类型、影响端点、可复现的利用路径、严重性评分和修复建议。安全团队拿到的是高置信度的、可以直接行动的结果，不需要再花时间排查误报。

五、三大渗透测试场景实战

AWS Security Agent 的渗透测试能力并非”一套规则扫所有”，而是能够根据目标应用的技术栈、认证模式和业务逻辑进行深度适配。系统会动态调整探索策略和攻击链构造方式。以下通过三个典型场景展示其差异化能力，不仅覆盖不同的漏洞类型，更体现了 Agent 如何将多个低危发现串联为高影响力的完整攻击路径。

5.1 黑盒测试：未配置登录凭证的纯外部视角

黑盒测试是最基础的渗透测试模式，也是安全团队最快获得第一份渗透测试报告的路径。在这一场景下，Security Agent 仅拥有目标应用的 URL，不持有任何认证凭证，模拟的是真实世界中外部攻击者的起始状态，无法进入应用的登录后功能区域。

5.1.1 配置与启动

在 AWS Management Console 的 Security Agent 设置中启用渗透测试功能，流程分为四步：配置目标域名、域名所有权验证、可选配置（Amazon Virtual Private Cloud（Amazon VPC）、Amazon CloudWatch、AWS Secrets Manager 等）、保存并启用。对于黑盒测试，可选配置步骤可以全部跳过。

首先配置目标域名，Security Agent 支持同时配置最多 5 个目标域名。

[图 1]

域名所有权验证确保只对自己有权限的应用进行测试。如果域名在 Amazon Route 53 且与 Security Agent 在同一 AWS 账户，可使用一键验证（One-click verification）。

[图 2]

[图 3]

添加域后，一键验证即可自动创建 DNS 记录完成验证。

[图 4]

[图 5]

域名验证通过后进入可选配置阶段，对于黑盒测试可全部跳过。

[图 6]

保存并启用后，Security Agent 验证配置并创建必要的 AWS Identity and Access Management（AWS IAM）资源。

启动测试

在 Security Agent Web Application 中创建渗透测试任务，选择已验证的目标域名作为测试端点，不配置 Authentication credentials 部分，直接提交。

[图 7]

5.1.2 测试过程与发现

Security Agent 首先通过网络扫描器爬取目标应用所有公开可达的页面、API 端点和静态资源，构建完整的攻击面地图。随后，专用的 Swarm Worker Agent 针对发现的每个端点执行系统性检测：探测未设置认证保护的敏感接口、检测安全响应头的缺失或配置错误、识别可被匿名触发的注入点（反射型 XSS、开放重定向、SSRF 等），以及发现服务端信息泄露（错误页面暴露技术栈版本、调试端点外泄、目录遍历等）。

值得强调的是，即便在无认证的黑盒模式下，Security Agent 的多步骤攻击链能力仍然有效。系统不是简单地列出发现的问题清单，而是尝试将多个公开端点的低危发现组合成有实际危害的攻击路径——例如通过信息泄露获取内部 API 结构，再利用发现的未保护端点提取敏感配置。每个确认的漏洞都包含 CVSS 评分、详细的复现步骤和修复建议。

黑盒测试适用于快速评估应用的外部暴露面，特别是在新应用首次上线、接手新项目需要快速了解安全态势、或希望验证 AWS WAF 和 Amazon API Gateway 的防护有效性时。从域名验证到获得第一份漏洞报告，整个过程可以在数小时内完成。

[图 8]

5.1.3 实测报告：靶场渗透测试结果

为验证上述能力，我们搭建了一套包含 DVWA（Damn Vulnerable Web Application）的靶场环境，并使用 AWS Security Agent 对其执行了一次完整的黑盒渗透测试。靶场部署在 Amazon EC2 实例上，通过 Nginx 反向代理对外提供 HTTP 80 端口访问。

Security Agent 采用四阶段方法执行测试：Preflight（连通性验证）、Static Analysis（代码与配置审查）、Penetration Testing（运行时漏洞利用）、Finalizing（验证与报告生成）。整个测试过程中，Agent 共执行了覆盖 SQL Injection、XSS、Command Injection、File Upload、LFI、SSRF、XXE、IDOR、JWT 等多个风险类别的系统性测试任务，所有任务状态均为 Completed。

测试结果摘要——共发现 18 个经过验证的安全漏洞：

1 个 Critical：Vertical Privilege Escalation via Client-Side Security Cookie Tampering Chained with SQL Injection
8 个 High：SQL Injection Authentication Bypass、POST-Based Session-Input SQL Injection、OS Command Injection、Blind SQL Injection、XXE Injection、PHP eval() SSTI、Remote Code Execution via Unrestricted File Upload，以及 Uploaded Files Accessible via Direct Object Reference（即上传文件可被任意/匿名用户通过直接对象引用访问，报告中定级为 High）
9 个 Medium：Local File Inclusion、Reflected XSS（name 参数）、SSRF、Stored XSS（Guestbook）、DOM-Based XSS、Reflected XSS（view\_source.php）、Proxy Disclosure、Directory Browsing（/docs/）、Directory Browsing（/dvwa/ 及子目录）

其中有一个值得关注的细节是，报告中所有 Finding 均被标记为 High confidence（高置信度）。这意味着 Security Agent 对每一个漏洞都完成了实际利用验证后才将其纳入报告，而不是基于特征匹配给出”疑似风险”的判断。对安全团队来说，这一特性带来的实际价值在于，拿到报告后可以直接进入修复排期，无需再投入额外时间做二次确认。

[图 9]

[图 10]

5.2 灰盒测试：配置登录凭证的认证视角

大多数安全漏洞隐藏在应用的认证后区域。用户登录后才能触及的业务功能、数据接口和管理端点，往往是攻击面最大、业务影响最直接的部分。灰盒测试通过配置认证凭证让 Security Agent 进入这些区域，将测试覆盖面从公开攻击面扩展到完整的业务功能层。

5.2.1 配置认证凭证

在创建渗透测试时，用户在 “Authentication credentials” 部分提供登录信息。对于标准 Web 应用，最直接的方式是选择 “Input credentials”，输入用户名、密码，并选择凭证对应的 Access URL。启用了 TOTP 双因素认证的应用，可以额外提供 TOTP Secret，Agent 会在检测到 2FA 提示时自动生成一次性验证码完成验证。

[图 11]

5.2.2 复杂认证场景：多重校验的自动化封装

实际业务中，很多应用的认证机制远不是”填个用户名密码”就能搞定的。以我们为某客户实际准备的测试方案为例，该应用的认证涉及三重防护机制。

第一层：密码非对称加密

登录接口不接受明文密码，要求使用平台指定的 RSA 公钥加密后传输。由于 PKCS#1 padding 包含随机字节，每次加密结果都不同，抓包获取的旧密文无法复用。我们通过分析前端代码定位到加密模块，提取公钥后用 Node.js 原生 crypto 实现了相同的加密逻辑：

function encryptPassword(plain) {
  return crypto
    .publicEncrypt(
     { key: RSA_PUBLIC_KEY, padding: crypto.constants.RSA_PKCS1_PADDING },
      Buffer.from(plain, "utf8")
    )
    .toString("base64");
}

第二层：请求动态签名

每个 API 请求都必须携带一个 sign 参数，其计算方式是将请求 URL、登录 Token、设备标识、随机数、时间戳、用户 ID 按固定顺序拼接后取 MD5 哈希。时间戳一变签名就必须重算，否则请求被拒绝。通过分析前端请求拦截器还原了签名公式：

function calcSign({ url, loginToken, deviceId, nonce, timestamp, userId }) {
  const m = url + (loginToken || "") + deviceId + nonce + timestamp + (userId || "");
  return crypto.createHash("md5").update(m).digest("hex").toUpperCase();
}

第三层：请求头校验与防护适配

该应用的业务接口配置了请求来源校验，不携带正确请求头的调用会被直接拒绝。经过分析发现，需要在请求头中携带正确的 Origin 和 Referer 头才能通过校验：

_headers() {
  return {
    // 关键：缺少这两个头会被 AWS WAF 拦截
    Origin: "https://target-platform.example.com",
    Referer: "https://target-platform.example.com/",
    // 登录后用 cookie 携带凭证
    Cookie: `loginToken=${this.loginToken}; userId=${this.userId}; deviceId=${this.deviceId}`,
  };
}

在我们的方案中，这层请求头构造逻辑已封装在 AWS Lambda 脚本中，AWS Security Agent 发起的每个请求都会自动携带正确的头信息。实际测试过程中，如果目标应用配置了更严格的访问控制策略（如基于行为模式的高级防护），可以通过 AWS Security Agent 的 Amazon VPC 配置从内部网络发起测试，或在测试期间调整访问控制策略的放行规则，确保测试流量不被误拦。

5.2.3 封装为可复用的认证客户端

上述三重逻辑被封装为一个完整的客户端类。登录成功后获取会话 Token，后续任何业务接口只需调用通用方法即可自动完成签名计算和请求构造：

const client = new AuthClient({ deviceId: "auto-generated" });
await client.login("user@example.com", "password");
// 登录后，任何接口调用自动携带签名和认证态
const userInfo = await client.get("/api/userinfo", { targetUserId: "12345" });
const giftList = await client.get("/api/xxx");

将这套脚本部署为 AWS Lambda 函数后，Security Agent 通过 Advanced setting 中的 AWS Lambda credential strategy 调用它。Agent 不需要理解加密或签名的内部细节，只需从 AWS Lambda 获取有效的认证态，即可以已登录用户身份对所有业务接口发起渗透测试。这种方式将认证复杂度和测试逻辑彻底解耦：登录脚本由了解目标应用的安全工程师一次性编写并验证，Security Agent 复用这个能力反复执行测试。

5.2.4 多角色凭证测试权限隔离

灰盒模式的一个关键实践是配置多组凭证覆盖不同用户角色（如标准用户、特权用户、服务账户等），通过在不同权限层级间交叉测试来发现权限提升类漏洞。

以该应用为例，由于签名机制对所有接口通用，只要 Agent 持有有效的会话 Token 和签名能力，就能系统性地测试所有已认证端点的权限边界。Agent 可以用普通用户凭证尝试修改请求中的用户标识符参数访问其他用户的资料和数据，验证水平越权（IDOR）是否存在；同时尝试以普通用户身份调用管理端点或敏感操作接口，验证垂直提权的可能性。

5.2.5 攻击链的实际价值

灰盒测试最能体现 Security Agent “连点成线”的能力。以 AWS 官方博客中的场景为例：一个 CVSS 6.1 的存储型 XSS 如果孤立看待，可能在修复队列中排队数周。但 Security Agent 能识别出该 XSS 可以窃取管理员 Session Cookie，进而利用管理员会话访问暴露数据库凭证的配置端点，将三个独立发现串联成一条 CVSS 9.8 的关键攻击路径。传统工具缺乏这种跨步骤的上下文推理能力，而 Security Agent 通过对应用代码、文档和运行时行为的综合理解，能够发现并验证这类组合利用的真实性。

5.3 白盒测试：配置登录凭证 + 源代码的全量视角

白盒测试在灰盒模式的基础上引入源代码分析，让 Security Agent 不仅能观察应用的运行时行为，更能理解其内部实现逻辑。这种”由内而外”的双重视角提供了最全面的安全覆盖，特别适用于关键业务系统在上线前的深度评估。

5.3.1 关联源代码

源代码的关联在 Agent Space 层面配置，一次设置后可被渗透测试和代码审查两种能力共享。AWS Security Agent 提供两种源代码接入方式：

第一种是通过 GitHub 集成。在 Agent Space 的配置向导中选择 Add，连接已授权的 GitHub Organization 或个人账户，然后勾选需要分析的仓库。连接后 Security Agent 以只读方式访问代码用于分析。除 GitHub 外，系统同样支持 GitLab、Bitbucket 和 GitHub Enterprise Server。如果你希望 Agent 在发现漏洞后直接提交修复代码，可以为对应仓库开启”Code remediation”权限——Agent 会以 Pull Request 的形式提交修复方案，开发者审核合并即可完成闭环。

第二种是通过 Amazon S3 Bucket 上传。在 Agent Space 配置中添加 Amazon S3 URI（支持 Bucket 或 Prefix 级别），将源代码包、配置文件、IaC 模板或其他你希望 Agent 分析的工件上传至指定位置。这种方式适用于无法直接连接代码仓库的场景——比如代码存储在内部 Git 系统中，团队可以通过 CI/CD Pipeline 将代码定期同步到 Amazon S3，Agent 即可获取最新版本进行分析。一个 Agent Space 最多可关联 10 个 Amazon S3 资源。

5.3.2 源代码如何增强渗透测试

源代码关联完成后，当用户在 Web Application 中创建渗透测试任务时，Agent 会自动将代码分析纳入测试流程。这不是简单的 SAST（静态应用安全测试）——而是将静态分析的发现作为动态渗透测试的”情报输入”。

具体而言，代码扫描器在渗透测试启动后并行工作，从多个维度生成分析文档：哪些端点接受外部输入但缺少校验、哪些函数处理了敏感数据但未加密、哪些权限检查逻辑存在绕过可能、哪些第三方依赖存在已知漏洞。这些发现被传递给 Guided Explorer 组件，后者据此生成针对性的测试计划——不再是盲目地对所有端点逐一测试，而是优先验证代码分析中标记的高风险路径。

AWS 官方博客中展示了一个典型的白盒价值场景：代码分析发现 /admin/config 端点返回了包含数据库连接字符串的环境变量，SAST 工具不会标记它（因为”代码按设计运行”），DAST 工具也无法触及它（因为它在管理员认证后的区域）。但 Security Agent 通过理解代码上下文识别出该端点暴露了敏感凭证，然后通过动态测试验证了从普通用户一路到数据库凭证泄露的完整攻击链。

5.3.3 代码修复的自动化闭环

白盒模式的另一个显著优势是修复闭环的自动化。当 Security Agent 确认一个漏洞后，如果对应仓库开启了 Code remediation 权限，Agent 不仅会输出修复建议文本，还会直接在 GitHub 上创建包含修复代码的 Pull Request。开发者在日常 Code Review 流程中审查并合并这些 PR 即可完成修复——安全修复被无缝嵌入现有的开发工作流，无需切换上下文或学习额外工具。

六、总结

安全行业有一个长期存在的结构性矛盾：开发团队以天为单位交付代码，而安全团队以季度为单位完成验证。这个时间差不是任何一方的问题——渗透测试本身的供给就是稀缺的。全球范围内具备高水平渗透测试能力的安全工程师始终供不应求，企业即便预算充足也很难按需获取这种能力。

AWS Security Agent 用多智能体协作的方式给出了一种新的解法。它解决的不是”让工具跑得更快”的问题，而是将渗透测试从一种依赖个体专家的服务，转化为一种可被任何团队按需调用的基础能力——多个专用 Agent 各司其职，从攻击面发现到漏洞验证再到修复建议，形成完整闭环。

这意味着几件事情的根本性改变。

安全验证的覆盖不再由预算决定。过去企业只能把有限的人工测试资源分配给最核心的系统，大量应用常年处于”从未被真正测过”的状态。当渗透测试变成按需能力后，安全覆盖可以从少数关键系统扩展到整个应用组合。正如 HENNGE K.K. 在实际使用中验证的，Agent 发现了他们通过人工测试从未发现的有价值洞察。

安全验证的时机不再受制于排期。新功能上线前即时验证、安全事件后快速评估、合规审计前全面扫描——这些场景在传统模式下要么等不起，要么做不到。当验证周期从数周压缩到数小时，安全团队真正有可能让验证节奏跟上开发节奏。

最关键的是，人工专家的角色从执行者变为决策者。当 Agent 承担了基线覆盖和常规验证的工作量，安全工程师可以把精力集中在真正需要人类判断力的地方：攻击面的战略分析、零日漏洞的创造性研究、以及需要深度业务理解的红队对抗。这不是替代关系，而是让对的人做对的事。

渗透测试的终局不是人或机器，而是两者各归其位后形成的完整安全验证体系。

下篇预告

应用安全是 SDLC 安全的起点，但不是终点。当应用部署到云上之后，基础设施层面的安全挑战同样不容忽视——AWS IAM 权限是否遵循最小特权原则、安全组规则是否存在过度开放、数据存储是否满足加密合规要求。下一篇我们将深入 AWS DevOps Agent，看看它如何从 IaC 模板扫描到运行时态势监控，在基础设施层面实现自动化的安全管理。

本文为”从应用安全到云安全”系列第一篇。

➡️ 下一步行动：

相关产品：

Amazon S3 — 适用于 AI、分析和存档的几乎无限的安全对象存储
AWS Lambda — 无需服务器即可运行代码
Amazon DevOps Agent — 解决和预防事故的代理
Amazon EC2 — 安全且可调整大小的计算容量
Amazon VPC — 隔离云网络

相关文章：

立即咨询 → 从 AI 规划到落地实施，我们的专家团队为你全程护航。

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

本篇作者

AWS 架构师中心：云端创新的引领者

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

亚马逊AWS官方博客