想象一下这个场景：用CodeBuddy生成了一段数据库操作代码，程序上线前检查时发现，它竟然直接拼接用户输入来构造SQL语句。这可不是小问题——攻击者只要输入' OR 1=1 --，就能轻松绕过登录验证，把整个用户表的数据一览无余。程序上线前，这类漏洞必须立即修复。

识别Codex输出的高危SQL模式

打开CodeBuddy生成的代码文件，逐行扫描SQL执行逻辑，重点排查三类写法。

第一种：只要看到f"SELECT * FROM users WHERE name = '{username}'"或者"WHERE id = " + user_id这类字符串拼接语句——单引号包裹变量，就是高危信号。

第二种：SQL语句中间出现了request.args.get、input()、get_parameter()等用户输入源，但代码中没有调用setString()、execute(query, params)这类参数绑定方法。

第三种：函数名叫get_user、login_check、search_data等业务关键词，但函数体内找不到?、%s、:name这些占位符——这种“看起来能跑通”的代码，往往最危险。

Ja va项目：用PreparedStatement替换拼接SQL

第一步：把原始SQL中的变量部分全部替换成?占位符。比如把"SELECT * FROM users WHERE username = '" + username + "'"改为"SELECT * FROM users WHERE username = ?"。

第二步：获取PreparedStatement对象，而不是用Connection.createStatement()。

第三步：对每个?按顺序调用setString()、setInt()等方法传入对应变量，比如ps.setString(1, username)。

第四步：执行ps.executeQuery()或ps.executeUpdate()，绝不能再调用execute(sql)。这一步如果还用字符串执行，前面所有修改全部白费。

Python项目：强制使用参数化执行

方法一（sqlite3）：必须写成cursor.execute("SELECT * FROM users WHERE name = ?", (name,))。括号不能省——(name,)是元组，(name)是字符串，少个逗号就会导致TypeError或者直接绕过防护。

方法二（PyMySQL/MySQLdb）：改用%s占位符，比如"SELECT * FROM users WHERE id = %s"，然后cursor.execute(sql, (user_id,))。

方法三（SQLAlchemy）：直接写session.query(User).filter(User.name == name)，ORM层自动处理参数绑定，无需手写SQL。

Node.js项目：禁用字符串拼接，改用问号占位

找到所有connection.query("SELECT * FROM users WHERE email = '" + email + "'")这类代码。

替换成connection.query("SELECT * FROM users WHERE email = ?", [email])。

确保所有用户输入都通过数组或对象方式传入第二个参数，严禁在SQL字符串中拼接任何变量。

启用CodeBuddy安全智能体全量扫描

在IDE中右键项目根目录，选择“CodeBuddy → Run Security Scan”。等待扫描完成，查看左侧“Security Issues”面板中的高亮标记项。点击任一漏洞条目，右侧会显示漏洞位置、风险等级、触发示例，以及自动生成的修复补丁代码。