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) - ResultString, 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 喂给 AIAI 会输出类似这样的审计报告[ { 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 经常翻车的点Send/Sync 的隐式约束AI 不知道某个第三方 crate 的类型是不是Send可能漏掉并发安全问题生命周期与 unsafe 的组合拳AI 在分析这段 unsafe 代码是否安全地维护了生命周期不变量时经常出错宏展开后的安全问题AI 审计源代码但 proc macro 展开后的真实代码可能完全不同FFI 边界Rust 调用 C 代码的安全审计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: OptionString, // 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 辅助安全审计当前最佳实践是**人机协作**模式AI 做广度扫描快速覆盖常见漏洞模式不漏掉低级错误人做深度分析业务逻辑、权限模型、并发安全这些需要人工判断CI 集成每次 PR 自动扫一遍把安全问题挡在合并之前持续优化 Prompt根据误报/漏报反馈不断调优审计 prompt作为 Rust 开发者编译器已经帮我们解决了内存安全问题AI 可以帮我们扫掉一部分应用层安全漏洞。但最终的安全责任还是在我们自己身上。工具再好判断力不能外包。保持学习保持输出你在做代码 review 时用过 AI 辅助吗评论区聊聊你的体验参考资料OWASP Code Review GuideLLM-Assisted Vulnerability Detection (Research Paper)RustSec Advisory DatabaseGitHub Copilot Code Review