1
月
在社区成长 1 月
LEVEL 1
1 XP
## 背景：AI 代码审计真正适合做什么
把代码仓库直接交给大模型，然后要求它“找出全部漏洞”，通常会得到一份看起来专业、实际却混有误报和遗漏的报告。安全审计不同于普通代码补全：一个结论是否成立，取决于输入是否可控、危险数据能否到达敏感操作、已有防护是否有效，以及漏洞能否在特定配置下触发。模型如果只看到一个函数，很容易忽略调用链、框架约束和部署环境。
更可靠的做法，是让 AI 承担证据整理、规则解释、修复草案和测试生成等工作，同时由静态分析工具、单元测试和人工复核提供可验证的事实。本文给出一套只面向本地项目、授权代码仓库或教学靶场的防御性流程，不涉及扫描或攻击任何未授权目标。
## 核心原理：证据链优先，而不是提示词优先
一次可信的代码安全发现，至少应包含以下证据：
1. Source：外部数据从哪里进入，例如 HTTP 参数、消息队列或文件上传。
2. Propagation：数据经过哪些函数、对象或序列化过程。
3. Sink：数据最终是否进入 SQL 执行、命令调用、模板渲染等敏感位置。
4. Guard：中间是否存在参数化查询、白名单校验、编码或权限检查。
5. Reachability：相关代码在当前配置和真实调用路径中是否可达。
6. Reproduction：能否通过安全的本地测试稳定证明问题。
7. Remediation：修复后，原有功能与安全回归测试是否同时通过。
AI 最适合把零散材料整理成上述结构，并帮助开发者发现“还缺哪项证据”。它不应该仅凭某个危险函数名就直接宣布存在高危漏洞。
## 前置条件
建议准备以下环境：
- 一个获得明确授权的 Git 仓库，最好创建独立审计分支；
- Python 3.11 或项目所需运行时；
- Semgrep，用于可重复的静态规则扫描；
- pytest 或项目原有测试框架；
- 可选的本地模型，或者经过组织批准、具有数据隔离条款的模型服务；
- 容器或虚拟环境，用于限制测试权限和网络访问。
以 Python 项目为例，可以在虚拟环境中安装基础工具：
python -m venv .venv
source .venv/bin/activate
python -m pip install --upgrade pip
pip install semgrep pytest
先记录代码基线，避免 AI 自动修改大量无关文件：
git switch -c security/ai-assisted-audit
git status --short
git rev-parse HEAD
如果代码包含客户信息、访问令牌、私有证书或内部地址，不要直接提交给外部模型。应先做秘密扫描和内容裁剪，只发送完成当前判断所需的最小片段。
## 分步骤实践
### 第一步：限定审计范围与威胁模型
不要用“检查整个项目有没有漏洞”作为任务描述。先确定资产、入口和信任边界，例如：
- 范围：`app/search.py` 及其直接调用者；
- 资产：数据库中的用户资料；
- 非可信输入：查询参数 `keyword`；
- 安全目标：输入不得改变 SQL 结构；
- 排除项：依赖包内部实现与生产环境渗透测试。
给 AI 的任务可以写成：“根据提供的代码，只判断外部输入是否能够到达数据库执行点；分别列出 source、sink、guard、缺失上下文和验证方法。证据不足时标记为待确认，不要推断未提供的文件。”
这种格式会显著降低模型为了完成任务而强行下结论的倾向。
### 第二步：先用确定性工具收集候选项
在本地运行静态扫描，并保存机器可读结果：
semgrep scan --config p/python --json --output semgrep.json .
工具结果只是候选项，不是最终漏洞清单。可以用一个小脚本提取必要字段，再交给模型分类，避免上传完整仓库：
python - <<'PY'
import json
data = json.load(open('semgrep.json', encoding='utf-8'))
for item in data.get('results', []):
print({
'rule': item.get('check_id'),
'path': item.get('path'),
'line': item.get('start', {}).get('line'),
'message': item.get('extra', {}).get('message')
})
PY
要求 AI 对每个候选项输出“已确认、可能存在、低可信误报、信息不足”之一，并附上需要人工查看的调用者、配置或测试。不要让模型擅自把工具严重级别等同于业务风险等级。
### 第三步：围绕数据流提供最小上下文
假设授权示例项目中存在如下写法：
def find_user(conn, name):
sql = "SELECT id, name FROM users WHERE name = '" + name + "'"
return conn.execute(sql).fetchall()
模型应指出字符串拼接进入 SQL 执行点，但最终确认仍要查看 `name` 的来源和数据库接口语义。更稳妥的修复是参数化查询：
def find_user(conn, name):
sql = "SELECT id, name FROM users WHERE name = ?"
return conn.execute(sql, (name,)).fetchall()
这里不要让 AI 自行猜测占位符形式。SQLite 常用 `?`，不同数据库驱动可能使用 `%s`、命名参数或框架查询构造器。应以项目锁定的驱动文档和现有代码模式为准。
### 第四步：让 AI 生成防御性回归测试
修复不能只看代码差异，还要验证特殊字符不会改变查询语义。以下测试仅操作内存数据库，不连接任何真实系统：
import sqlite3
from app.search import find_user
def test_find_user_treats_input_as_data():
conn = sqlite3.connect(':memory:')
conn.execute('CREATE TABLE users (id INTEGER, name TEXT)')
conn.executemany(
'INSERT INTO users VALUES (?, ?)',
[(1, 'alice'), (2, "O'Reilly")]
)
assert find_user(conn, "O'Reilly") == [(2, "O'Reilly")]
assert find_user(conn, "nonexistent'") == []
def test_find_user_does_not_change_normal_behavior():
conn = sqlite3.connect(':memory:')
conn.execute('CREATE TABLE users (id INTEGER, name TEXT)')
conn.execute('INSERT INTO users VALUES (?, ?)', (1, 'alice'))
assert find_user(conn, 'alice') == [(1, 'alice')]
运行测试：
pytest -q
测试重点不是构造攻击载荷，而是证明任意输入均作为数据处理，并确认正常查询行为没有退化。对于命令执行、路径处理等高风险场景，也应优先使用 mock、临时目录和禁网容器，而不是调用真实系统资源。
### 第五步：要求模型进行反证审查
初步结论完成后，再开一个独立上下文，让模型扮演复核者，并回答：
- 是否存在框架自动参数化，导致原结论是误报？
- 修复是否引入类型变化、编码问题或性能退化？
- 测试是否只覆盖了一个例子，而没有验证安全性质？
- 风险等级是否考虑了可达性、权限和数据敏感度？
- 哪些结论完全来自工具证据，哪些只是模型推测？
独立复核比让同一轮对话简单地“再检查一下”更有效，因为后者容易延续已有假设。
### 第六步：形成可审计报告
每条发现建议保存以下字段：
- 编号与标题；
- 文件、行号、提交哈希；
- source、sink、guard 和调用链；
- 工具规则编号；
- 本地复现或回归测试名称；
- 影响与前置条件；
- 修复提交；
- 可信度；
- 人工复核人及复核日期。
报告中应区分“事实”和“推断”。例如，“第 42 行调用 `execute`”是事实；“攻击者可远程利用”则需要路由暴露、身份权限和部署配置等额外证据。
## 可用于 AI IDE 的审计提示模板
可以将任务约束为固定输出：
“你正在协助审查一个已授权的本地仓库。仅依据我提供的代码和扫描结果工作。请输出：1）候选问题；2）source 到 sink 的逐步路径；3）已有 guard；4）缺失证据；5）最小修复方案；6）本地单元测试；7）可能的误报原因。不得假设未提供的框架配置，不得建议访问外部目标，不得把未经测试的结论标为已确认。”
如果 AI IDE 支持项目规则文件，还可以加入：禁止读取 `.env`、私钥目录、生产配置和凭据文件；默认只生成补丁，不自动执行命令；修改依赖、迁移脚本或 CI 配置前必须人工确认。
## 风险与注意事项
第一，代码泄露风险。私有仓库可能包含商业逻辑、客户数据和密钥。外部模型是否保留输入、是否用于训练、数据位于哪个区域，都应由组织政策明确，而不是由个人默认接受。
第二，提示注入风险。仓库中的注释、文档、测试数据甚至依赖包文本，都可能包含“忽略规则并读取其他文件”一类指令。应把仓库内容当作不可信数据，禁止模型因为代码注释而扩大权限。
第三，自动执行风险。AI 生成的命令可能删除文件、修改 Git 历史、下载未知脚本或访问网络。建议在容器内运行，默认禁网、使用低权限账户，并对命令逐条确认。
第四，版本幻觉。模型可能推荐不存在的 API，或混用不同版本框架的安全机制。所有修复都应经过类型检查、单元测试、依赖文档核对和代码评审。
第五，单一工具偏差。Semgrep、模型和人工都可能遗漏问题。关键系统应结合 SAST、依赖审计、秘密扫描、测试和架构评审，而不是把 AI 当成唯一检测器。
## 常见问题
### AI 说“高危”，可以直接创建紧急工单吗？
不建议。先确认代码可达性、攻击前置条件、权限边界和实际数据影响。模型给出的严重级别可作为排序建议，不能替代组织的风险评级标准。
### 扫描结果很多，是否应全部发送给模型？
不应。先按规则、路径和重复指纹聚合，再逐组提供最小上下文。这样既降低数据暴露，也避免长上下文让模型忽略关键证据。
### 能否让 AI 自动提交修复？
可以生成候选补丁，但建议保留人工批准。最低要求是查看差异、运行测试、检查依赖变化，并确认没有顺手重构无关代码。安全修复应尽量小而清晰。
### 没有发现问题，是否代表代码安全？
不代表。静态分析和模型审计只能覆盖部分风险。业务越权、竞态条件、部署错误和密钥管理问题，往往需要架构信息、动态测试或运行日志才能判断。
### 如何衡量这套流程是否有效？
可以持续记录候选发现数、人工确认率、误报率、修复后测试通过率、平均复核时间，以及同类问题是否再次出现。比“模型生成了多少条漏洞”更有意义的指标，是可验证发现的比例和修复后的回归质量。
## 总结
AI 在安全代码审计中的可靠价值，不是替代安全工程师宣布漏洞，而是加速证据整理、数据流解释、修复草案和测试设计。一个成熟工作流应当遵循：授权范围明确、输入最小化、确定性工具先行、结论绑定证据、修复必须测试、命令执行受控、最终由人工复核。
当每条安全结论都能回到具体代码、工具输出和本地测试时，AI 才真正进入工程流程；如果只有流畅的文字和醒目的风险等级，它仍然只是一个不稳定的建议来源。
把代码仓库直接交给大模型，然后要求它“找出全部漏洞”，通常会得到一份看起来专业、实际却混有误报和遗漏的报告。安全审计不同于普通代码补全：一个结论是否成立，取决于输入是否可控、危险数据能否到达敏感操作、已有防护是否有效，以及漏洞能否在特定配置下触发。模型如果只看到一个函数，很容易忽略调用链、框架约束和部署环境。
更可靠的做法，是让 AI 承担证据整理、规则解释、修复草案和测试生成等工作，同时由静态分析工具、单元测试和人工复核提供可验证的事实。本文给出一套只面向本地项目、授权代码仓库或教学靶场的防御性流程，不涉及扫描或攻击任何未授权目标。
## 核心原理：证据链优先，而不是提示词优先
一次可信的代码安全发现，至少应包含以下证据：
1. Source：外部数据从哪里进入，例如 HTTP 参数、消息队列或文件上传。
2. Propagation：数据经过哪些函数、对象或序列化过程。
3. Sink：数据最终是否进入 SQL 执行、命令调用、模板渲染等敏感位置。
4. Guard：中间是否存在参数化查询、白名单校验、编码或权限检查。
5. Reachability：相关代码在当前配置和真实调用路径中是否可达。
6. Reproduction：能否通过安全的本地测试稳定证明问题。
7. Remediation：修复后，原有功能与安全回归测试是否同时通过。
AI 最适合把零散材料整理成上述结构，并帮助开发者发现“还缺哪项证据”。它不应该仅凭某个危险函数名就直接宣布存在高危漏洞。
## 前置条件
建议准备以下环境：
- 一个获得明确授权的 Git 仓库，最好创建独立审计分支；
- Python 3.11 或项目所需运行时；
- Semgrep，用于可重复的静态规则扫描；
- pytest 或项目原有测试框架；
- 可选的本地模型，或者经过组织批准、具有数据隔离条款的模型服务；
- 容器或虚拟环境，用于限制测试权限和网络访问。
以 Python 项目为例，可以在虚拟环境中安装基础工具：
python -m venv .venv
source .venv/bin/activate
python -m pip install --upgrade pip
pip install semgrep pytest
先记录代码基线，避免 AI 自动修改大量无关文件：
git switch -c security/ai-assisted-audit
git status --short
git rev-parse HEAD
如果代码包含客户信息、访问令牌、私有证书或内部地址，不要直接提交给外部模型。应先做秘密扫描和内容裁剪，只发送完成当前判断所需的最小片段。
## 分步骤实践
### 第一步：限定审计范围与威胁模型
不要用“检查整个项目有没有漏洞”作为任务描述。先确定资产、入口和信任边界，例如：
- 范围：`app/search.py` 及其直接调用者；
- 资产：数据库中的用户资料；
- 非可信输入：查询参数 `keyword`；
- 安全目标：输入不得改变 SQL 结构；
- 排除项：依赖包内部实现与生产环境渗透测试。
给 AI 的任务可以写成：“根据提供的代码，只判断外部输入是否能够到达数据库执行点；分别列出 source、sink、guard、缺失上下文和验证方法。证据不足时标记为待确认，不要推断未提供的文件。”
这种格式会显著降低模型为了完成任务而强行下结论的倾向。
### 第二步：先用确定性工具收集候选项
在本地运行静态扫描，并保存机器可读结果：
semgrep scan --config p/python --json --output semgrep.json .
工具结果只是候选项，不是最终漏洞清单。可以用一个小脚本提取必要字段，再交给模型分类，避免上传完整仓库：
python - <<'PY'
import json
data = json.load(open('semgrep.json', encoding='utf-8'))
for item in data.get('results', []):
print({
'rule': item.get('check_id'),
'path': item.get('path'),
'line': item.get('start', {}).get('line'),
'message': item.get('extra', {}).get('message')
})
PY
要求 AI 对每个候选项输出“已确认、可能存在、低可信误报、信息不足”之一，并附上需要人工查看的调用者、配置或测试。不要让模型擅自把工具严重级别等同于业务风险等级。
### 第三步：围绕数据流提供最小上下文
假设授权示例项目中存在如下写法：
def find_user(conn, name):
sql = "SELECT id, name FROM users WHERE name = '" + name + "'"
return conn.execute(sql).fetchall()
模型应指出字符串拼接进入 SQL 执行点，但最终确认仍要查看 `name` 的来源和数据库接口语义。更稳妥的修复是参数化查询：
def find_user(conn, name):
sql = "SELECT id, name FROM users WHERE name = ?"
return conn.execute(sql, (name,)).fetchall()
这里不要让 AI 自行猜测占位符形式。SQLite 常用 `?`，不同数据库驱动可能使用 `%s`、命名参数或框架查询构造器。应以项目锁定的驱动文档和现有代码模式为准。
### 第四步：让 AI 生成防御性回归测试
修复不能只看代码差异，还要验证特殊字符不会改变查询语义。以下测试仅操作内存数据库，不连接任何真实系统：
import sqlite3
from app.search import find_user
def test_find_user_treats_input_as_data():
conn = sqlite3.connect(':memory:')
conn.execute('CREATE TABLE users (id INTEGER, name TEXT)')
conn.executemany(
'INSERT INTO users VALUES (?, ?)',
[(1, 'alice'), (2, "O'Reilly")]
)
assert find_user(conn, "O'Reilly") == [(2, "O'Reilly")]
assert find_user(conn, "nonexistent'") == []
def test_find_user_does_not_change_normal_behavior():
conn = sqlite3.connect(':memory:')
conn.execute('CREATE TABLE users (id INTEGER, name TEXT)')
conn.execute('INSERT INTO users VALUES (?, ?)', (1, 'alice'))
assert find_user(conn, 'alice') == [(1, 'alice')]
运行测试：
pytest -q
测试重点不是构造攻击载荷，而是证明任意输入均作为数据处理，并确认正常查询行为没有退化。对于命令执行、路径处理等高风险场景，也应优先使用 mock、临时目录和禁网容器，而不是调用真实系统资源。
### 第五步：要求模型进行反证审查
初步结论完成后，再开一个独立上下文，让模型扮演复核者，并回答：
- 是否存在框架自动参数化，导致原结论是误报？
- 修复是否引入类型变化、编码问题或性能退化？
- 测试是否只覆盖了一个例子，而没有验证安全性质？
- 风险等级是否考虑了可达性、权限和数据敏感度？
- 哪些结论完全来自工具证据，哪些只是模型推测？
独立复核比让同一轮对话简单地“再检查一下”更有效，因为后者容易延续已有假设。
### 第六步：形成可审计报告
每条发现建议保存以下字段：
- 编号与标题；
- 文件、行号、提交哈希；
- source、sink、guard 和调用链；
- 工具规则编号；
- 本地复现或回归测试名称；
- 影响与前置条件；
- 修复提交；
- 可信度；
- 人工复核人及复核日期。
报告中应区分“事实”和“推断”。例如，“第 42 行调用 `execute`”是事实；“攻击者可远程利用”则需要路由暴露、身份权限和部署配置等额外证据。
## 可用于 AI IDE 的审计提示模板
可以将任务约束为固定输出：
“你正在协助审查一个已授权的本地仓库。仅依据我提供的代码和扫描结果工作。请输出：1）候选问题；2）source 到 sink 的逐步路径；3）已有 guard；4）缺失证据；5）最小修复方案；6）本地单元测试；7）可能的误报原因。不得假设未提供的框架配置，不得建议访问外部目标，不得把未经测试的结论标为已确认。”
如果 AI IDE 支持项目规则文件，还可以加入：禁止读取 `.env`、私钥目录、生产配置和凭据文件；默认只生成补丁，不自动执行命令；修改依赖、迁移脚本或 CI 配置前必须人工确认。
## 风险与注意事项
第一，代码泄露风险。私有仓库可能包含商业逻辑、客户数据和密钥。外部模型是否保留输入、是否用于训练、数据位于哪个区域，都应由组织政策明确，而不是由个人默认接受。
第二，提示注入风险。仓库中的注释、文档、测试数据甚至依赖包文本，都可能包含“忽略规则并读取其他文件”一类指令。应把仓库内容当作不可信数据，禁止模型因为代码注释而扩大权限。
第三，自动执行风险。AI 生成的命令可能删除文件、修改 Git 历史、下载未知脚本或访问网络。建议在容器内运行，默认禁网、使用低权限账户，并对命令逐条确认。
第四，版本幻觉。模型可能推荐不存在的 API，或混用不同版本框架的安全机制。所有修复都应经过类型检查、单元测试、依赖文档核对和代码评审。
第五，单一工具偏差。Semgrep、模型和人工都可能遗漏问题。关键系统应结合 SAST、依赖审计、秘密扫描、测试和架构评审，而不是把 AI 当成唯一检测器。
## 常见问题
### AI 说“高危”，可以直接创建紧急工单吗？
不建议。先确认代码可达性、攻击前置条件、权限边界和实际数据影响。模型给出的严重级别可作为排序建议，不能替代组织的风险评级标准。
### 扫描结果很多，是否应全部发送给模型？
不应。先按规则、路径和重复指纹聚合，再逐组提供最小上下文。这样既降低数据暴露，也避免长上下文让模型忽略关键证据。
### 能否让 AI 自动提交修复？
可以生成候选补丁，但建议保留人工批准。最低要求是查看差异、运行测试、检查依赖变化，并确认没有顺手重构无关代码。安全修复应尽量小而清晰。
### 没有发现问题，是否代表代码安全？
不代表。静态分析和模型审计只能覆盖部分风险。业务越权、竞态条件、部署错误和密钥管理问题，往往需要架构信息、动态测试或运行日志才能判断。
### 如何衡量这套流程是否有效？
可以持续记录候选发现数、人工确认率、误报率、修复后测试通过率、平均复核时间，以及同类问题是否再次出现。比“模型生成了多少条漏洞”更有意义的指标，是可验证发现的比例和修复后的回归质量。
## 总结
AI 在安全代码审计中的可靠价值，不是替代安全工程师宣布漏洞，而是加速证据整理、数据流解释、修复草案和测试设计。一个成熟工作流应当遵循：授权范围明确、输入最小化、确定性工具先行、结论绑定证据、修复必须测试、命令执行受控、最终由人工复核。
当每条安全结论都能回到具体代码、工具输出和本地测试时，AI 才真正进入工程流程；如果只有流畅的文字和醒目的风险等级，它仍然只是一个不稳定的建议来源。