AWS Security Agent 全仓代码扫描实测：配置流程、漏洞修复与 CI/CD 集成

作者： /
AWS 代码安全扫描

传统 SAST 工具经常一次报出上百个 finding。
开发者逐条点开，发现大量结果只是“可能存在风险”。输入源没有问题、上游已经做过过滤、危险函数其实不可达，这些情况都会被报出来。
时间久了，安全扫描就变成发版前的流程项。

AWS Security Agent 在 2026 年 5 月发布了 Full Repository Code Review 预览功能。
它不是只看单个文件，而是对整个代码库做上下文安全分析，包括架构、数据流、模块调用关系和安全。
官方文档也说明，Full Repository Code Review 可以对完整代码库进行静态安全分析，并给出修复指导。

我拿一个 Node.js 后端 + Python数据处理 + Terraform IaC 的内部项目测了一遍，代码量约8万行。
下面记录配置流程、扫描结果、漏洞修复方式和接入CI/CD时要注意的点。

AWS Security Agent 全仓代码扫描是什么

它解决的是传统 SAST 的上下文缺失

传统 SAST 更像是逐文件规则匹配。
它看到 SQL 拼接、命令执行、未校验输入、硬编码密钥，就会先报出来。
问题是它通常不知道这个输入从哪里来，中间经过了什么处理，最终是否真的能触发漏洞。

AWS Security Agent 的全仓扫描更重视代码上下文。
它会把代码库作为一个整体分析，追踪跨文件调用链和数据流。
比如一个参数从路由层进入，在 API 层传递，再进入 query builder，最后流向数据库查询。
这类分析对真实项目更有价值。开发者不需要只看一句“potential SQL injection”，而是能看到输入来源、流转路径、危险位置和推荐修复方式。

适合哪些项目

这个功能适合已经有一定代码规模的项目。单文件脚本、简单 Demo、纯静态页面，使用全仓扫描的价值不高。

更适合的场景是：

项目类型适用原因
Node.js / Python / Java 后端项目接口、数据库、鉴权、输入参数多
多模块服务项目漏洞经常跨文件出现
GitHub 私有仓库可以直接生成修复 PR
有发版流程的团队可以接入 PR Review 和 CI/CD
安全扫描误报太多的团队需要降低无效排查成本

如果项目已经部署在
AWS 上，并且团队后续会持续使用EC2、S3、CloudFront、RDS、IAM等服务，可以把代码安全扫描放进AWS开发流程里统一管理。
账号权限、账单主体、充值续费、资源配额这些问题也要提前处理好。需要免绑卡开户、高权重高配额账号、充值续费赠金的团队，可以在这里自然加入 AWS代理 内链，用来承接购买和账号配置需求。

传统 SAST 和 AWS Security Agent 全仓扫描的区别

分析方式不同

对比项传统 SASTAWS Security Agent 全仓扫描
分析单位单个文件或局部代码整个代码库
上下文理解弱，主要看规则命中会结合架构、调用链和数据流
误报处理需要开发者手动判断会用上下文过滤部分无效结果
修复建议多数是原则性建议可生成具体代码修复
适用阶段本地扫描、CI 扫描全仓审计、PR Review、安全修复
执行成本快，但排查成本高扫描更慢，但结果更可处理

传统扫描的问题在于它给的是“风险提示”。AWS Security Agent 这类全仓扫描给的是“问题链路”和“修复入口”。

以 SQL Injection 为例，传统工具通常只会告诉你某一行存在风险。开发者还要自己查这个参数从哪来、有没有校验、是否能被外部控制。全仓扫描会把这条路径直接列出来，确认成本低很多。

使用前准备

AWS Security Agent 访问权限

开始之前，需要先能访问 AWS Security Agent Web Application，并且在 Agent Space 里连接 GitHub 仓库或 S3 代码来源。
AWS 文档说明，创建 code review 前至少需要一个已连接的 GitHub repository 或 S3 bucket。

如果是团队项目不建议直接用个人 root 权限操作。应该使用单独的 IAM 角色或团队账号权限，把 GitHub 连接、Code Review 配置、CloudWatch Logs 写入权限分开管理。

GitHub 仓库权限

AWS Security Agent 通过 GitHub App 连接仓库。连接时可以选择授权整个组织，也可以只授权指定仓库。
生产环境建议只选择需要扫描的仓库，不要一次性开放所有仓库。

GitHub 集成完成后，可以在 Agent Space 中启用 code review。
AWS 文档说明，AWS Security Agent 支持 cloud-hosted GitHub 和 cloud-hosted GitHub Enterprise，连接后可以对启用的仓库自动分析 Pull Request，并把结果发到 GitHub PR 评论里。

S3 代码来源

AWS Security Agent 也支持 S3 来源，但不是直接扫描任意存储桶里的所有文件。
从已连接到 Agent Space 的 S3 source 中选择代码输入，用于 code review 扫描。

S3 来源适合离线代码包、不能直接连接 GitHub 的项目，或者需要对某个版本归档包做安全审查的场景。
但 S3 来源有一个明显限制：不能自动生成代码修复 PR，后面需要手动按 finding 修改。AWS 官方文档对这个限制写得很明确。

如何创建 Full Repository Code Review

第一步：进入 Code Reviews 页面

进入 AWS Security Agent Web Application，在左侧菜单选择 Code reviews。

如果 Agent Space 里已经连接了 GitHub 仓库或 S3 source，可以直接创建新的 code review。如果还没有连接，需要先回到 AWS Management Console 里配置 Agent Space 和代码来源。

第二步：选择代码来源

创建 code review 时，需要填写一个容易识别的标题，比如：

billing-service-security-review

代码来源可以选择 GitHub repository，也可以选择 S3 source。

如果是 GitHub 仓库，建议先从核心服务仓库开始，不要一次性把所有仓库都接进去。第一次扫描的目的不是追求覆盖率，而是看结果质量、误报数量和修复建议是否能进入开发流程。

第三步：配置日志和自动修复

创建时可以选择 CloudWatch log group 保存执行日志。如果不指定，AWS Security Agent 会创建默认日志组。官方文档显示，code review 运行过程包括 Preflight、Static analysis 和 Finalizing 三个阶段：先验证代码访问和环境，再做静态分析，最后汇总 finding。

自动修复要按代码来源区分：

代码来源修复方式
GitHub 私有仓库AWS Security Agent 可以创建修复 PR
GitHub 公开仓库不直接开 PR，提供可下载 diff
S3 source不支持自动代码修复，需要手动修改

AWS 官方文档写明，私有 GitHub 仓库可以提交 PR，公开 GitHub 仓库提供 downloadable diff，S3 findings 必须手动修复。

第四步：启动扫描

配置完成后，在 code review 详情页点击 Start review。扫描开始后，AWS Security Agent 会先做访问校验，再进入静态分析。
代码量越大，扫描时间越长。我的测试项目约 8 万行代码，扫描耗时 6 分 40 秒。

实测扫描结果

项目环境

本次测试项目结构如下：

项目内容说明
后端Node.js
数据处理Python
基础设施代码Terraform
代码规模约 8 万行
扫描耗时6 分 40 秒

扫描结果按风险等级分布如下：

严重程度数量有修复建议
Critical22
High55
Medium1210
Low83
Info150

Critical 和 High 的修复建议覆盖率最高。Medium 有一部分能给出修复代码。Low 和 Info 更多是提示类问题，需要开发者自己判断是否处理。

Critical 示例：SQL Injection 跨文件追踪

其中一条 Critical finding 是 SQL Injection。它不是只报某个 SQL 执行位置，而是把数据流完整列出来：

{
  "type": "SQL_INJECTION",
  "riskLevel": "CRITICAL",
  "filePath": "src/api/orders.js",
  "startLine": 45,
  "endLine": 47,
  "description": "User input from request.query.filter flows through utils/queryBuilder.js into raw SQL query without parameterization",
  "dataFlow": [
    "src/routes/orders.js:23 → req.query.filter",
    "src/api/orders.js:30 → buildQuery(filter)",
    "src/utils/queryBuilder.js:12 → string concatenation",
    "src/api/orders.js:45 → db.query(rawSql)"
  ]
}

重点是 dataFlow。它说明用户输入从路由层进入，经过 API 层和工具函数，最后进入数据库查询。开发者不用再自己翻完整调用链。

传统 SAST 对这类问题通常只会在 db.query(rawSql) 附近给出一条风险提示。

修复建议示例

AWS Security Agent 给出的修复方向是把字符串拼接改成参数化查询：

// Before
function buildQuery(filter) {
  return `SELECT * FROM orders WHERE status = '${filter}'`;
}

// After
function buildQuery(filter) {
  return {
    text: 'SELECT * FROM orders WHERE status = $1',
    values: [filter]
  };
}

这个修复不是只改一行。调用方也要同步调整，让 db.query() 接收新的query object。
修复PR或diff只能作为起点，合并前仍然要跑单元测试、集成测试和回归测试。
AWS文档也明确提醒，自动生成的代码修复需要在合并或提交前人工审核。

如何接入 GitHub PR Review

PR 触发方式

启用 GitHub code review 后，AWS Security Agent 可以自动分析 Pull Request，并把安全 finding 发到 GitHub PR 页面。Draft PR 不会触发分析，只有 PR 标记为 Ready for review 后才会开始。

分析开始时，PR 里会出现类似提示：

AWS Security Agent is analyzing your code…

分析完成后，结果会集中出现在 PR review 里。
如果没有发现安全问题，会返回 no issues identified。开发者可以直接在 GitHub 里看 finding、修改代码、push 新 commit，再让系统重新分析。

PR Review 适合拦截新增风险

全仓扫描适合做阶段性安全审查。PR Review 更适合日常发版流程。

实际使用时，可以这样分工：

场景建议方式
第一次接入跑 Full Repository Code Review
历史代码审计跑 Full Repository Code Review
日常开发开启 GitHub PR Review
高危问题修复使用修复 PR 或 diff
发布前卡点CI/CD 查询结果后阻断合并

不要指望一次全仓扫描解决所有历史问题。更现实的做法是先处理 Critical 和 High，再把 PR Review 接进开发流程，避免新漏洞继续进入主分支。

如何用 AWS CLI 查询扫描结果

先列出 Code Review

如果要把结果接入内部系统，可以使用 AWS CLI 查询 code review 配置。list-code-reviews 用于返回指定 Agent Space 下的 code review summary。

aws securityagent list-code-reviews \
  --agent-space-id "$AGENT_SPACE_ID" \
  --output json

拿到 codeReviewId 后，可以继续查询该code review 下的job。

查询 Code Review Job

list-code-review-jobs-for-code-review 用于返回某个 code review 配置下的 job summary。

aws securityagent list-code-review-jobs-for-code-review \
  --agent-space-id "$AGENT_SPACE_ID" \
  --code-review-id "$CODE_REVIEW_ID" \
  --output json

如果已经知道job ID，可以用 batch-get-code-review-jobs 获取具体job 信息。
该命令需要传入 –code-review-job-ids 和 –agent-space-id。

aws securityagent batch-get-code-review-jobs \
  --agent-space-id "$AGENT_SPACE_ID" \
  --code-review-job-ids "$CODE_REVIEW_JOB_ID" \
  --output json

查询 Finding 明细

batch-get-findings 不是“列出所有 finding”的命令，它需要传入 finding id。
AWS CLI 文档显示，–finding-ids 和 –agent-space-id 都是必填项，返回字段里风险等级使用 riskLevel，不是 severity。

aws securityagent batch-get-findings \
  --agent-space-id "$AGENT_SPACE_ID" \
  --finding-ids "$FINDING_ID_1" "$FINDING_ID_2" \
  --query 'findings[?riskLevel==`CRITICAL`]' \
  --output json

如果要在CI/CD 里阻断合并，核心逻辑应该是：先拿到本次code review job对应的finding id，再用 batch-get-findings 查明细，最后根据 riskLevel 判断是否失败。

和旧扫描方案的对比

实测结果

同一个项目，旧方案和 AWS Security Agent 的对比如下：

指标旧方案AWS Security Agent
扫描时间3 分 20 秒6 分 42 秒
报告 findings18742
实际有效约 20约 35
有修复代码020
单个问题修复耗时平均 2 小时平均 20 分钟

AWS Security Agent 扫描时间更长，但结果更集中。旧方案的问题是 finding 太多，开发者要先判断哪些是真的，再决定怎么改。
全仓扫描的结果更少，但有效问题更多，部分 finding 还附带修复代码。

多花几分钟扫描，换掉大量无效排查时间，这对团队是划算的。

不能只看 finding 数量

finding 少不一定代表扫描弱，也可能是误报被过滤掉了。
需要关注以下指标：

指标判断意义
Critical / High 数量是否存在必须立即处理的问题
有效 finding 占比扫描结果是否值得开发者投入时间
修复建议覆盖率能不能减少定位和改代码成本
PR 反馈速度是否适合接入日常开发流程
修复后复扫结果漏洞是否真正关闭

安全扫描工具最终要服务开发流程。只堆报告数量，没有修复路径，团队很快就会跳过。

Preview 阶段限制

自动修复有来源限制

GitHub 私有仓库可以生成修复 PR。
GitHub 公开仓库为了避免漏洞细节提前暴露，不会直接开 PR，而是提供可下载 diff。
S3 来源不支持自动代码修复，只能按 finding 描述手动处理。

自动生成的代码不能直接合并

自动修复可以节省时间，但不能替代代码审查。尤其是 SQL 查询、鉴权逻辑、支付流程、权限判断这类核心代码，必须人工确认修改没有改变业务语义。

建议流程是：

步骤操作
1查看 finding 和 data flow
2阅读修复 PR 或 diff
3本地运行测试
4检查是否影响业务逻辑
5合并后重新扫描

IaC 扫描不要过度期待

这次测试项目里包含 Terraform，但实际价值主要体现在应用代码层。
IaC 扫描可以发现一部分配置风险，但如果你的主要需求是云资源合规、IAM 权限审计、网络暴露检查，还需要结合 AWS 原生安全服务和人工审查。

费用说明

AWS Security Agent Full Repository Code Review 目前处于 Preview 阶段。
AWS 官方博客说明，Preview 期间现有 AWS Security Agent 客户使用该功能不额外收费；正式 GA 后的长期计费方式需要以 AWS 后续公布为准。

Preview阶段不额外收费，正式发布后的定价仍需等待AWS公布。

相关文章

滚动至顶部