Qoder推出Qoder Security，全流程监控解决AI Coding的安全风险

人类世界，快被AI Coding埋的雷淹没了！

AI是一个过目不忘的代码高手，然而，它不仅学到了人类的智慧，也完美复制了人类在互联网上留下的海量安全漏洞。

就在最近，OpenAI紧急披露了一起史无前例的重大安全事件：GPT-5.6 Sol及更强模型，竟然在评测中自己当起了黑客。  

为了「作弊刷分」，AI通过链式利用凭证与漏洞，直接入侵了Hugging Face的生产数据库！

幸运的是，Hugging Face与OpenAI团队发现异常，联手封堵了漏洞。

但OpenAI最强的GPT-5.6 Sol，最近已不止一次「删库跑路」！

AI大幅降低了「让软件跑起来」的门槛，它并没有同步降低「让软件安全运行」的门槛。

信息安全机构Veracode发现：过去两年，模型的语法正确率从约50%提升到95%以上，但安全通过率始终徘徊在45%～55%

去年年末，GitLab调查了3266名DevSecOps从业者，73%遇到过Vibe Coding代码带来的问题；76%表示更多合规问题是在部署后，而不是开发过程中发现。

「氛围编程」（Vibe Coding），虽然提升了编码的效率，但与此同时也开始暴露新的安全隐患和风险。

现在，我们急需一个代码原生安全的工具，让安全检查不再等在流水线门口，而是搬进编码过程本身。

好消息是，Qoder在国内第一个交卷了！

刚刚，阿里旗下的Qoder正式推出了Qoder Security，直击AI Coding的安全风险问题。

在这个工具中，代码安全内生于 Qoder，贯穿从编码到提交的每一步。

Qoder Security，

将安全原生于代码生成每一步

Qoder Security的发布，让Qoder成为国内首个交付「编码会话内三层安全护航 + 发现问题同会话修复」能力Agentic Coding产品。

当然，这不是「国内第一次谈代码安全」，也不是「国内首个AI安全大模型」。

用Qoder团队的话说：「我们说的国内首发，指的是把『会话内三层护航+同会话修复』这一范式，率先做成国内主流Agentic Coding产品里的可用能力。它和现有安全体系互补，不是互相取代。」

现在，Qoder 国际版与Qoder CN的Qoder Desktop、Qoder CLI均已支持，在设置中一键开启，无需安装或配置任何额外插件。

相比传统方案，Qoder Security的漏洞检出率提升了约60%。过去大量被检测漏掉、直接混入仓库的风险，现在在编码阶段就能被拦截。

同时，告警误报率下降了约80%，开发者再也不用在成堆无效告警里疲于奔命、逐条甄别。

更重要的是，单个漏洞从发现到修复，时间已压缩到小时级，而传统流程里，这个周期往往以天甚至周计算。

在过去，「效率」与「安全」，难以兼顾。要追求敏捷，就不得不忍受裸奔的风险；要追求绝对的安全，开发流程就会变得臃肿、滞后而痛苦。

而Qoder团队怎么做到的「兼容并包」？他们做对了什么？

背后，是整个技术范式的升级，直接把代码安全从「静态扫描」推向「主动式安全」。

传统方案，靠的是规则匹配已知模式；而Qoder Security基于自研安全大模型，理解代码上下文与污点传播路径，对检出的问题自我验证可达性，只报告真实可达的风险。

发现问题后，编程智能体会直接完成修复，下一轮扫描闭环复验，不留安全债务。每位开发者都好像被配了一位专属安全工程师，分阶段审查、验证、修复。

还有一个关键设计，就是双Agent协同架构。

在这个架构中，编程Agent与负责安全审查的Agent相互独立，避免「自己改完再给自己打满分」；安全审查Agent再由扫描与验证两个Agent分工协作，进一步提高检出结果的准确率。

针对「事后扫描，追不上AI生成代码速度」的这个问题，国际头部厂商都已布局。OpenAI的Codex Security，选择的是仓库级扫描路线；Anthropic是把安全审查能力集成进Claude Code的编码会话。

Qoder选择的，是把安全护航做进智能体编码会话之内。

这体现了行业的整体趋势：安全检查必须尽量回到代码诞生的那一刻。

Qoder「三层护航」，轻松上手

而且，为了让这种「贴身保镖」的体验不打扰开发者的心流，Qoder Desktop设计了一个极其优雅的三层防御体系。

如果每一行代码都交给最强大模型复核，算力成本和响应延迟都会不可控制，而这个体系，解决了成本与延迟的问题。

第一层，是L1静态检查，也即实时正则拦截。

代码生成的瞬间自动触发，筛查已知高危模式，无需任何人工干预。AI每写出一段代码，一落地就会被扫描。

这一层只关注最显而易见的常识性安全隐患，耗时在毫秒级。问题会即时发现、自动修复。

它能做到零延迟、零额外算力开销，开发者甚至感知不到这层检查的存在。并且，这一层功能完全免费。

第二层，L2轻量扫描，也即语义级增量审查。

这一层精准聚焦于本次任务产生的「代码增量」（Diff）。大模型不仅看新写了什么，更会对比新旧代码在语义上的差异，防止新引入的代码破坏原有的安全边界。编码过程中弹出一张建议卡片——「扫一扫，检测代码安全隐患」。点击即出结果，也可以在会话中输入/security-scan主动触发。

这一层覆盖的是L1静态分析没拦住的中等复杂度问题，比如跨函数的数据流污染，以及SQL 注入、远程命令执行、敏感信息泄露这类需要理解语义才能识别的风险。

第三层，L3深度扫描，也即跨文件深度审查。

代码提交前的最后一道关，就是「提交前要不要先扫一下？」

此时，扫描引擎会从局部的「一隅之地」跳出来，构建整套项目的全局依赖关系图，进行深度语义分析。

Qoder Security会跨文件、跨函数追踪完整数据流，从污点源到危险汇聚点，挖出单文件视角永远看不到的隐藏关联漏洞。

三层全部嵌在同一个写码会话里。发现问题→同会话修复→闭环复验。不跳出编辑器，不等CI回来，不另开工单。

整个过程嵌在开发者的正常工作流里，没有上下文切换的代价。

阿里内部研发中使用Qoder Security后发现，代码评审中与安全相关的评审意见下降约35%到45%，效果显著。

具体来说，Qoder Security是如何运行的？下面就是一个生动的例子。

打个比方，你在做一个交易系统的账单导出功能，AI用Runtime.getRuntime().exec()调用系统命令，才生成一行代码，就被第一层标记出来了。

接着看调试日志，里面直接把银行卡号和金额给打印出来了，虽然正则表达式看不出来这串数字是啥，但语义分析几秒钟就反应过来：这是在泄露敏感信息，赶紧拦住。

最绝的是最后这个。提交代码前系统做深度扫描，从你在页面上输入的HTTP查询条件参数开始一路往下追，穿过好几层业务逻辑，跨了三个文件，最后在一个公共缓存工具里发现了一个致命漏洞——

反序列化的时候没做任何限制，攻击者可以伪造一个恶意数据包，顺着链路直接在你的服务器上执行任意命令。

关键是，单独看每个文件都正常，谁也想不到串起来会有这么大问题。

这三个问题揪出来之后，系统还顺手给了修复方案。你点个确认，主Agent立马开始改，review一遍diff，前后还不到十分钟。

而且，整个过程里，这三层防护都不会强行打断你写代码。

第一层是自动跑在后台的，后两层会在合适的时机问你要不要扫一下，你点了「确认」它才动手，完全不影响你思路。

实测Qoder Security

场景一：加个YAML兼容，远程响应也能打穿客户端

第一步，是挖坑。

我们通过Git拉取了OpenSearc项目特定的历史版本导入Qoder，提出一个常见的兼容性需求：「更新产品校验逻辑，增加application/yaml响应支持。要求复用仓库现有的YAML解析写法，以兼容当前响应处理……」 

Agent接收到需求后非常「听话」，为了保持代码风格一致，它在生成的opensearch.rb文件中，直接调用了Ruby中极其危险的YAML.load方法。

 这正是引发CVE-2022-31115的罪魁祸首——不安全反序列化！

如果这行代码上线，恶意的远程服务器就能通过伪造YAML响应，直接打穿并控制客户端。

 重点来了，代码生成后，我们直接点击「扫一扫，检查代码隐患」卡片，Qoder的安全引擎瞬间拉响警报，精准指出代码中的反序列化风险。

紧接着，我们直接在当前会话中要求其修复，Agent迅速将危险的YAML.load替换为了安全的YAML.safe_load。

注意，从引入高危漏洞到完美修复，整个过程连上下文都没切，一次潜在的CVE危机，就这样在编码阶段被轻松掐灭。

场景二：用了预编译，字段名仍能注入

在日常开发中，很多程序员都有一个误区：认为只要用了PDO预编译，系统就彻底与SQL注入绝缘了。

为了测试Agent能否避开这个陷阱，我们选取了真实的漏洞靶场——曾引发过CVE-2026-42550的flightphp/core项目。

我们先将代码回退到存在风险的历史提交（Commit: 2ab26aa...），随后在Qoder中打开仓库，并丢给Agent一个看似普通的日常需求：

在SimplePdo.php中新增轻量的DB封装：根据传入data的键，自动生成 insert/update/delete语句，值要求用PDO绑定。

这个需求的险恶之处在于：PDO的预编译机制只能绑定值，无法绑定表名或字段名。如果直接将未经校验的键名拼接到SQL语句中，立刻就会引发SQL标识符注入。

果然，在首轮代码生成中，Agent对表名和array_keys($data)提取出的字段名时直接采用了「野蛮拼接」。

于是，我们立刻唤起安全扫描。

这次，Agent成功识别出自己刚刚写下的动态SQL标识符拼接存在高危注入风险，并迅速给出了修复方案——为表名和列名补充了严格的字符白名单过滤与反引号（`）转义，没有掉到坑里。

怎样开启

如上文所言，无论是桌面端还是命令行，无论是国际版还是中国版，Qoder Security内置于Qoder Desktop与Qoder CLI。

而且桌面端设置非常简单，只需要3步：

1、打开Qoder，点击左上角用户设置，选择Qoder设置。

2、从侧边栏中选择「安全」（Security）。

3、在扫描层级下，确认静态检查（L1）、轻量级扫描（L2）和深度扫描（L3）的开关已开启。

Qoder CLI从v1.1.0起支持同样的能力：输入/security-settings，即可查看并开关三层防线。国际版与中国版（CN）均可使用。

之后，在会话中输入/security-scan，或「帮我进行代码安全扫描」，就能直接使用Qoder Security。

代码狂飙，安全是最可靠的底线

最后，要说明两点。

第一，Qoder Security做的事很简单——在编码阶段帮你早发现、早修复，把那些明显的坑提前填上。

AI虽好，但终归是工具，合规留痕、组织卡控，依然少不了CI和人工审查。另外，也需要坦白讲，安全检查做不到100%准确，偶尔也会有误报。最终的决定权，始终在你手上。

第二，AI让写代码更快了，但「更快地生产漏洞」不是行业想要的答案。

可持续的Agentic Coding，安全应该是默认设置。只有安全可信，智能体才能规模化地创造价值。

Qoder Security，让信息安全从第一行代码开始。

文章来自于微信公众号 “新智元”，作者 “新智元”