AWS Security Agent 全仓代码扫描实测:配置流程、漏洞修复与 CI/CD 集成
很多团队做过代码安全扫描一段时间就放弃了。跑一次 SAST 报出两三百个 finding,手动确认后发现 90% 是误报。久而久之,发版前的安全检查就变成了走流程,甚至直接跳过。
AWS 在今年五月上线了全仓库代码扫描功能(Full Repository Code Review),作为 AWS Security Agent 的新能力,目前处于 Preview 阶段,现有用户免费使用。
跟普通 SAST 不同的地方是扫描逻辑。传统工具逐文件做模式匹配;这个功能扫整个仓库,分析架构、数据流和模块调用关系。发现漏洞后直接生成修复代码,定位到具体文件和行号。
目前支持 GitHub 仓库和 S3 存储桶作为代码来源。我拿了一个 Node.js + Python 混合的内部项目测了一遍,下面记录整个过程。
传统扫描 vs 全仓上下文扫描
两者的区别:
|
对比项 |
传统 SAST |
Security Agent 全仓扫描 |
|
分析单位 |
单个文件 |
整个仓库 |
|
上下文理解 |
无,纯模式匹配 |
跨文件数据流追踪 |
|
误报率 |
高,研究数据显示可超过 91% |
低,上下文过滤 |
|
修复建议 |
"建议使用参数化查询" |
直接出 patch,定位到文件和行号 |
|
运行时间 |
几秒到几分钟 |
几分钟到十几分钟 |
传统工具的核心问题是没有上下文。看到一个函数接收 user input,就报 SQL injection。但这个 input 在调用链上游可能已经做过 sanitize——工具只看当前文件,不看上游,所以误报。
Security Agent 全仓扫描会追踪跨文件的数据流。它知道 input 从哪来、中间经过了哪些处理、最终流向哪里。这样能过滤掉大量误报,留下来的基本都是真实问题。
开通步骤
前置条件
已启用 AWS Security Agent。如果之前用过 CodeGuru Security 或 Amazon Inspector 代码扫描,大概率已经有了。
第一步:连接 GitHub 仓库
进入 AWS Security Agent 控制台,选择 Agent Space,点击 Enable code review,选 GitHub,安装 AWS Security Agent GitHub App 并授权。
建议选 Only select repositories,不要直接开放所有仓库权限。
第二步:触发全仓扫描
仓库连接后,在 Web 应用里创建 Code Review,选择仓库,扫描类型选 Full Repository,分析类型三个都可以勾上:
- Security — 安全漏洞
- Quality — 代码质量
- Secrets — 硬编码密钥
第三步:用 API 查询结果(可选)
如果需要把结果接入自己的系统,可以用 API 拉取:
# 批量获取扫描发现的问题<br/>aws securityagent batch-get-findings \<br/> --agent-space-id "your-agent-space-id" \<br/> --finding-ids "finding-id-1" "finding-id-2"
也可以直接在 Web 应用里查看,每条 finding 附带影响说明和 patch,开启自动修复的话会直接给仓库提 PR。
实际扫描结果
测试项目:Node.js 后端 + Python 数据处理 + Terraform IaC,总计约 8 万行代码。
扫描耗时:6 分 40 秒。
|
严重程度 |
数量 |
有修复建议 |
|
Critical |
2 |
2(100%) |
|
High |
5 |
5(100%) |
|
Medium |
12 |
10(83%) |
|
Low |
8 |
3(38%) |
|
Info |
15 |
0 |
Critical 和 High 的修复建议覆盖率是 100%,Medium 也到了 83%。Low 和 Info 基本不给修复代码,这部分需要你自己判断要不要处理。
关键发现举例
Critical #1:SQL Injection(跨文件追踪)
{
"type": "SQL_INJECTION",
"severity": "CRITICAL",
"filePath": "src/api/orders.js",
"startLine": 45,
"endLine": 47,
"description": "User input from request.query.filter flows through utils/queryBuilder.js:12 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 字段。它把 input 从路由层 → API 层 → 工具函数 → 数据库查询的完整链路都列出来了。
传统工具的做法是在 orders.js:45 报一个 "potential SQL injection",到此为止。你还得自己去翻代码,确认这个 input 到底从哪来、中间有没有做过处理。
自动生成的修复代码
{
"remediation": {
"filePath": "src/utils/queryBuilder.js",
"startLine": 10,
"endLine": 15,
"suggestedFix": "// Before:\nfunction buildQuery(filter) {\n return `SELECT * FROM orders WHERE status = '${filter}'`;\n}\n\n// After:\nfunction buildQuery(filter) {\n return { text: 'SELECT * FROM orders WHERE status = $1', values: [filter] };\n}",
"description": "Use parameterized query to prevent SQL injection. The caller at orders.js:45 should be updated to pass the query object to db.query()."
}
}
修复建议定位到具体行号,before/after 对比直接给出来。确认没问题的话,copy 过去改就行。
description 里还提示了 orders.js:45 那边也需要同步更新,接收新的 query 对象格式——关联改动也帮你想到了。
CI/CD 集成
PR 增量扫描不需要额外配置 GitHub Actions。安装 GitHub App 并在控制台开启 Code Review 之后,每次提 PR 自动触发,结果直接以 comment 形式出现在 PR 页面里。
分析开始时会先发一条 "AWS Security Agent is analyzing your code…" 的提示,完成后再发完整的 review 报告。
如果需要在 Actions 里拿到结果、让 Critical 问题直接 fail 掉 pipeline,可以调 API 查询:
name: Security Gate
on:
pull_request:
branches: [main]
jobs:
security-gate:
runs-on: ubuntu-latest
permissions:
id-token: write
contents: read
steps:
- name: Configure AWS credentials
uses: aws-actions/configure-aws-credentials@v4
with:
role-to-arn: arn:aws:iam::123456789012:role/SecurityAgentCI
aws-region: us-east-1
- name: Check for critical findings
run: |
CRITICAL=$(aws securityagent batch-get-findings \
--agent-space-id "$AGENT_SPACE_ID" \
--query 'findings[?severity==`CRITICAL`] | length(@)' \
--output text)
if [ "$CRITICAL" -gt "0" ]; then
echo "::error::Found $CRITICAL critical security issues, blocking merge"
exit 1
fi
增量扫描只分析 PR 变更的文件及其依赖链,速度比全仓快很多,通常 1-2 分钟出结果。
对比传统方案的实际体验
同一个项目,换工具前后的数据:
|
指标 |
旧方案 |
Security Agent |
|
扫描时间 |
3m 20s |
6m 42s |
|
报告 findings |
187 |
42 |
|
实际有效 |
~20 |
~35 |
|
有修复代码 |
0 |
20 |
|
开发者修复耗时 |
平均 2h / 个 |
平均 20min / 个 |
扫描时间多了一倍,其他全赢。
旧方案报 187 个,有效的只有 20 个,开发者要在 187 条里找那 20 条,还没有修复代码,全靠自己查。Security Agent 报 42 个,有效 35 个,20 个直接给修复代码,处理时间从 2 小时降到 20 分钟。
多花 3 分钟扫描,换掉大量无效排查时间,值得。
当前限制(Preview 阶段)
几个实际使用中会碰到的限制:
- 语言支持:目前支持 Java、Python、JavaScript/TypeScript、Go、C#,其他语言还没有
- 仓库大小:超过 100 万行代码的仓库,扫描时间可能超过 30 分钟
- 修复建议覆盖率:Critical / High 基本 100%,Medium 约 80%,Low 不到 40%
- IaC 扫描:Terraform / CloudFormation 支持有限,主要强在应用代码层
费用
Preview 阶段,现有 AWS Security Agent 客户免费使用。GA 后定价还没公布,预计按扫描次数或代码行数计费。
小结
全仓扫描解决的核心问题是两个:误报太多、修复没有指引。
以前跑安全扫描,出来 200 个 finding,开发者自己去判断哪些是真的、问题在哪、怎么改。做几次之后就没人认真看了。
现在的方式是:告诉你哪有洞、数据从哪流进来的、改哪一行、改成什么。Critical 和 High 直接给 patch,确认没问题 copy 过去就行。
如果你的团队安全扫描已经流于形式,这个工具值得试一下。
更多推荐


所有评论(0)