AI 辅助安全审计：让模型逐行分析 Rust 代码中的安全薄弱点的方法
一、AI 安全审计的理想与现实的差距
先泼盆冷水：AI 做安全审计，不是你把代码扔给它说"帮我看有没有漏洞"就完事了。
AI 的问题不是能力不够，而是缺乏业务上下文。它能看出"这个函数没有做输入检查"，但它不知道"在这个业务流程里，输入已经在上一层检查过了"。
所以正确的思路是：AI 做初筛 → 人做复核。让 AI 把可疑代码点标出来，你来判断是不是真的有问题。
二、一套靠谱的 AI 安全审计 Prompt 工程
经过几十次的尝试和调整，我总结了一套对 Rust 代码比较有效的审计 prompt 结构：
实际使用的审计 Prompt 模板：
你是一名资深 Rust 安全审计专家，熟悉 OWASP Top 10、CWE Top 25 和 Rust 安全编码最佳实践。
请对以下 Rust 代码进行安全审计，从以下维度逐一分析：
1. **输入验证**：所有外部输入是否有边界检查、类型校验、白名单过滤？
2. **权限与访问控制**：敏感操作是否有权限检查？是否遵循最小权限原则？
3. **unsafe 代码块**：每个 unsafe 块是否必要？不变量是否被正确维护？是否有安全注释？
4. **加密与哈希**：是否正确使用了密码学原语？是否使用了已被弃用的算法？
5. **错误处理**：错误信息是否泄露了内部信息？Panic 点是否会导致 DoS？
6. **并发安全**：是否存在数据竞争？锁的使用是否正确？是否存在死锁风险？
7. **资源管理**：文件句柄、网络连接是否被正确释放？是否存在资源泄漏？
请逐行分析，为每个问题标注：
– 行号范围
– 严重程度（Critical / High / Medium / Low）
– 对应的 CWE 编号（如果可以确定）
– 风险描述
– 具体的修复建议（含代码示例）
输出 JSON 数组格式。
实战案例：审计一段有问题的 Rust 代码
假设我们要审计这样一段代码：
use std::fs;
use std::process::Command;
/// 根据用户输入的路径读取配置文件并执行其中指定的命令
fn execute_config(config_path: &str) -> Result<String, String> {
// ⚠️ 问题1：没有校验 config_path，可能路径遍历攻击
let content = fs::read_to_string(config_path)
.map_err(|e| format!("读取配置文件失败: {} (路径: {})", e, config_path))?;
// ⚠️ 问题2：错误信息泄露了文件路径
// ⚠️ 问题3：直接拼接用户输入到 shell 命令，命令注入风险
let output = Command::new("sh")
.arg("-c")
.arg(format!("echo {}", content)) // content 来自文件，文件路径来自用户
.output()
.map_err(|e| format!("命令执行失败: {}", e))?;
Ok(String::from_utf8_lossy(&output.stdout).to_string())
}
把这段代码加上上面那个 prompt 喂给 AI，AI 会输出类似这样的审计报告：
[
{
"line": "6-7",
"severity": "High",
"cwe_id": "CWE-22",
"description": "config_path 参数直接传入 fs::read_to_string，没有做路径遍历防御。",
"fix_suggestion": "使用 canonicalize() 规范化路径并与允许的基目录做前缀比较"
},
{
"line": "8",
"severity": "Medium",
"cwe_id": "CWE-209",
"description": "错误信息暴露了内部文件路径 config_path",
"fix_suggestion": "使用通用错误信息，将详细错误写入日志而非返回给调用方"
},
{
"line": "12-14",
"severity": "Critical",
"cwe_id": "CWE-78",
"description": "config 文件内容被直接拼接到 shell 命令中，内容可能包含 ; rm -rf / 等注入",
"fix_suggestion": "不要使用 Command::new(\\"sh\\").arg(\\"-c\\")，直接将内容作为数据处理"
}
]
三、AI 审计的盲区：这些你必须自己看
特别是 Rust 特有的场景，AI 经常翻车的点：
实用建议：在 audit prompt 里加一句"如果你不确定某处代码是否安全，请标注为 needs_human_review，不要强行给出判断"。这就避免了 AI "为了输出而输出"的幻觉问题。
四、构建自动化安全审计流水线
把 AI 审计集成到 CI/CD，可以实现每个 PR 自动扫描：
Rust 侧的工具链集成：
/// 安全审计结果的严重程度枚举
#[derive(Debug, Serialize, Deserialize)]
enum Severity {
Critical, // 必须修复才能合并
High, // 强烈建议修复
Medium, // 建议修复
Low, // 可选修复
Info, // 仅供参考
}
/// 单条审计发现
#[derive(Debug, Serialize, Deserialize)]
struct AuditFinding {
file_path: String, // 文件路径
line_start: usize, // 起始行号
line_end: usize, // 结束行号
severity: Severity, // 严重程度
cwe_id: Option<String>, // CWE 编号（如果可以确定）
description: String, // 风险描述
suggestion: String, // 修复建议
needs_human_review: bool,// 是否需要人工复核（AI 不确定的地方）
}
/// CI 检查：汇总审计结果，判断是否可以通过
fn should_block_merge(findings: &[AuditFinding]) -> bool {
findings.iter().any(|f| {
matches!(f.severity, Severity::Critical | Severity::High) && !f.needs_human_review
// 如果 AI 自己都不确定，不阻断合并，只做提示
})
}
这套流水线跑了两个月后，我们发现一个有意思的数据：AI 误报了 32% 的 Medium 级别问题，但对 Critical 级别的检出率达到 91%。最有价值的是一个它发现的 Command::new("sh").arg("-c").arg(user_input) 注入——这个漏洞在人工 review 中已经被漏掉了三次。
这也说明一件事：AI 最适合做的是"地毯式搜索"，而不是"精准判断"。把扫描和判断分开，效率最高。
五、总结
AI 辅助安全审计，当前最佳实践是**"人机协作"**模式：
作为 Rust 开发者，编译器已经帮我们解决了内存安全问题，AI 可以帮我们扫掉一部分应用层安全漏洞。但最终的安全责任还是在我们自己身上。工具再好，判断力不能外包。
保持学习，保持输出！你在做代码 review 时用过 AI 辅助吗？评论区聊聊你的体验！
参考资料
- OWASP Code Review Guide
- LLM-Assisted Vulnerability Detection (Research Paper)
- RustSec Advisory Database
- GitHub Copilot Code Review
