直接把ChatGPT生成的代码扔进生产环境？这个想法本身就带着不小的风险。上线三天后遭遇SQL注入导致用户邮箱批量泄露，这种事故不是危言耸听——2024年的多项独立研究给出了一个相当扎心的结论：超过68%的ChatGPT生成的代码片段，都含有可被利用的安全缺陷。而且，模型本身不会主动告诉你这些。

那么，问题来了：怎么把AI写的代码从“能用”变成“安全”？答案很简单，但需要你一步步落实。

识别高危代码模式

首先得学会精准识别生成代码里那些危险的“红标模式”。打开代码文件，逐行盯着看是否存在以下几种结构：

• 字符串拼接SQL语句，比如"SELECT * FROM users WHERE id = " + user_id
• 未过滤的eval()或exec()调用
• 硬编码密钥，比如API_KEY = "sk-..."
• 未校验的os.system()参数传入

这四类模式是已知最常触发远程代码执行（RCE）、数据泄露和越权访问的罪魁祸首。

具体怎么查？在VS Code里装个插件“CodeQL for VS Code”，右键点击文件，选择“Query this file”，然后从预置规则集里勾选“Security/CWE-79-XSS”和“Security/CWE-89-SQL-injection”。运行后，红色高亮的地方就是确认存在的漏洞点。

但有一个关键点：必须关闭自动修复弹窗。CodeQL默认会弹出建议补丁，但它的修复逻辑有时候会引入新漏洞。比如它可能用html.escape()替代XSS防护，却忽略了Ja vaScript上下文里的安全问题——所以每一处替换都得人工验证，不能全信。

执行基础安全审计

做审计有两个通道，一个靠人工，一个靠工具。

第一看门道：人工交叉验证关键路径。找到所有涉及数据库操作、文件读写、网络请求、用户输入接收的函数，分别用三组输入去测：

• 正常值（比如user_id=123）——看看结果对不对
• 恶意构造值（比如user_id=123 OR 1=1 --）——会不会报错或返回异常数据
• 边界值（比如user_id=999999999999999999999）——会不会触发整数溢出或拒绝服务

第二出绝招：轻量级自动化扫描。终端里切换到项目根目录，敲一行命令：pip install bandit && bandit -r . -f html -o report.html。生成的report.html文件里，等级标为HIGH或CRITICAL的条目必须马上处理。Bandit对Python代码的SQL注入、硬编码密钥、反序列化漏洞的检出率超过91%，是可靠的第一道防线。

重写不安全代码段

找到那些用cursor.execute("SELECT * FROM table WHERE id = " + input_id)这种写法的行，删掉，换成参数化查询：cursor.execute("SELECT * FROM table WHERE id = %s", (input_id,))。这里有个极易踩的坑：括号必须是元组形式，单元素元组末尾的逗号不能省略，否则会触发TypeError。不是说AI不会犯这个错，而是我们自己要记住。

如果原代码里看到subprocess.run(cmd, shell=True)，强制改成subprocess.run(["ls", "-l", safe_path])，并且要确保safe_path经过os.path.abspath()和os.path.commonpath()双重校验，防止目录穿越攻击。

所有API密钥必须从代码里移出来，改用环境变量加载：import os; API_KEY = os.getenv("PROD_API_KEY")。在部署服务器上通过export PROD_API_KEY="实际密钥"注入。规则只有一个：绝不在.gitignore之外的任何文件里保留密钥明文。这不是建议，是纪律。