文章总结： VibeCoding通过自然语言生成应用降低了软件开发门槛，但导致新一代影子应用激增，引发严重安全风险。核心问题在于责任断层与安全治理缺失，常见漏洞包括鉴权缺失、密钥硬编码、数据库配置宽松及供应链风险。建议安全团队建立应用登记机制、分级治理策略、安全模板嵌入，并加强主动发现能力，而非简单禁止。 综合评分： 87 文章分类： 安全建设,应用安全,安全意识,解决方案,供应链安全

---

Vibe Coding 正在制造新一代影子应用

原创

NowSec NowSec

NowSec

2026年6月24日 08:00 陕西

在小说阅读器读本章

去阅读

过去，企业安全团队最头疼的影子 IT，可能是一张没人登记的 Excel 表、一个临时搭建的共享网盘、一个业务部门自己买的 SaaS 工具，或者一个没有经过审批的低代码平台。

这些东西的问题很明确： 不在资产台账里，不在权限体系里，不在审计范围里，也不在安全团队的视野里。

但现在，新的变化出现了。

业务人员不再只是偷偷买一个 SaaS，也不只是用低代码平台搭一个表单。 他们开始用 AI 直接生成应用。

这就是 Vibe Coding 带来的新问题。

它让任何人都可以用自然语言描述需求，然后快速生成一个能跑起来的网站、后台、表单、数据看板、自动化脚本，甚至是一个完整的小型业务系统。

这听起来像一次生产力释放。

但从安全角度看，它也可能正在制造新一代影子应用。

---

一、Vibe Coding 真正改变的不是写代码，而是「谁能生产软件」

过去，软件开发有门槛。

哪怕只是做一个简单的后台页面，也需要有人懂前端、后端、数据库、部署、鉴权、日志、接口、异常处理。

这套门槛虽然降低了效率，但也形成了一种天然的安全缓冲。

因为只要进入正式开发流程，至少会经过一些基本环节：

• 需求评审；
• 技术设计；
• 代码仓库；
• 测试环境；
• 上线流程；
• 账号权限；
• 监控告警；
• 安全扫描；
• 运维交接。

这些流程不一定完美，但至少让软件进入了组织的管理视野。

Vibe Coding 改变了这一点。

它让「写代码」这件事从专业开发者手里扩散到了更多普通用户手里。

市场人员可以生成一个活动报名系统。 运营人员可以生成一个数据录入后台。 财务人员可以生成一个报表汇总页面。 产品经理可以生成一个原型工具。 安全人员也可以生成一个日志分析脚本。

从效率角度看，这很诱人。

但问题在于： 当软件生产能力被下放之后，软件治理能力有没有同步下放？

答案通常是没有。

会写提示词，不代表懂安全架构。 能让页面跑起来，不代表知道怎么做鉴权。 能连接数据库，不代表知道怎么保护数据。 能部署到公网，不代表知道暴露面意味着什么。

这就是 Vibe Coding 的核心矛盾：

它降低了软件生产门槛，却没有同步降低安全治理门槛。

---

二、新一代影子应用，比过去的影子 IT 更危险

传统影子 IT 的风险主要来自「未经批准使用外部工具」。

比如员工私自使用网盘、在线表格、协作平台，把企业数据传到外部服务里。

安全团队至少还能从几个方向治理：

• 识别访问域名；
• 管控 SaaS 使用；
• 限制文件外传；
• 做 CASB 或 DLP；
• 做账号统一认证；
• 做终端和网关审计。

但 Vibe Coding 生成的影子应用更复杂。

因为它不是一个固定的外部 SaaS，而是一个被快速生成、随时修改、随时部署的小型系统。

它可能部署在：

• 个人云服务器；
• Vercel、Netlify、Cloudflare Pages；
• GitHub Pages；
• Firebase、Supabase；
• 企业内部测试服务器；
• 某台开发机；
• 一个临时容器；
• 一个没人知道的二级域名。

更麻烦的是，这些应用可能不是孤立的。

它们会连接真实业务数据。

例如：

• 连接企业数据库；
• 读取内部 API；
• 调用飞书、企业微信、钉钉接口；
• 连接 CRM、ERP、BI 系统；
• 存储客户信息；
• 处理订单数据；
• 上传合同、发票、身份信息；
• 保存 API Key、Token、Cookie。

过去的影子 IT，很多时候是「数据被搬到了外部工具」。

现在的影子应用，则可能是「一个未知系统接入了内部数据」。

这类风险更难被发现，也更难被评估。

因为它不是简单的工具使用问题，而是一个完整的软件系统生命周期问题。

---

三、Vibe Coding 最大的问题不是「代码烂」，而是「责任断层」

很多人讨论 Vibe Coding 安全风险时，喜欢说 AI 生成的代码不安全。

这当然是事实的一部分。

AI 可能生成 SQL 注入、XSS、弱鉴权、硬编码密钥、错误的权限控制、错误的 CORS 配置、错误的文件上传逻辑。

但如果只讨论代码质量，问题就被说浅了。

真正的问题是责任断层。

传统开发中，一个系统上线后，通常能找到责任链：

需求是谁提的？
代码是谁写的？
谁做的测试？
谁批准上线？
谁负责运维？
谁处理漏洞？
谁负责数据安全？

而 Vibe Coding 生成的影子应用，责任链经常是断的。

一个业务人员可能只是想解决一个临时问题：

「帮我做一个可以上传 Excel 并统计结果的小工具。」

AI 很快生成了页面、接口和数据库结构。 用户觉得能跑，就部署了。 同事觉得好用，就开始使用。 数据越积越多，功能越改越多。 最后它从「临时工具」变成了「事实上的业务系统」。

但没人真正回答这些问题：

• 这个系统是否应该存在？
• 数据应该保存多久？
• 谁能访问？
• 有没有权限分级？
• 有没有日志？
• 有没有备份？
• 有没有漏洞扫描？
• 有没有依赖管理？
• 出问题谁负责？
• 离职后谁接手？
• 如果泄露客户数据，谁承担后果？

影子应用最危险的地方，不是它一开始有多复杂。

而是它一开始看起来太简单。

简单到所有人都觉得没必要走流程。 简单到它可以绕过安全团队。 简单到它悄悄长成了一个没人管理的生产系统。

---

四、AI 生成应用常见的安全问题

Vibe Coding 生成的应用，最常见的问题并不新。

它们大多还是传统 Web 安全问题，只是出现得更快、更分散、更难治理。

1. 没有真正的鉴权

很多 AI 生成的应用，默认只实现「看起来能登录」的逻辑。

例如：

• 前端判断是否登录；
• 后端接口没有校验；
• 任意用户可以访问管理接口；
• 用户 ID 可以被直接修改；
• 只有页面隐藏，没有权限控制；
• 管理员入口没有额外保护。

这类问题属于典型的访问控制缺陷。

它不一定显眼，但一旦应用接入真实数据，风险就很大。

---

2. API Key 和 Token 硬编码

Vibe Coding 很容易生成「为了快速跑通」的代码。

为了方便，它可能把密钥直接写进：

• 前端代码；
• 配置文件；
• GitHub 仓库；
• 环境变量示例；
• 日志输出；
• 浏览器本地存储；
• 客户端请求参数。

这在原型阶段似乎问题不大，但一旦部署到公网，就可能直接变成凭证泄露。

尤其是当应用连接大模型 API、云数据库、对象存储、企业内部接口时，一个泄露的 Key 可能带来真实成本和数据风险。

---

3. 数据库规则过宽

很多 Vibe Coding 工具喜欢搭配 Firebase、Supabase、MongoDB Atlas 等云数据库。

问题在于，非专业用户经常不理解数据库访问规则。

他们只关心：

页面能不能读到数据？

表单能不能提交成功？

为了让功能跑通，规则可能被设置得非常宽松。

例如：

所有人可读
所有人可写
登录用户可读所有数据
前端直接操作数据库

这类配置在演示时很方便，在生产环境则非常危险。

---

4. 缺少输入校验

AI 生成的代码很容易只覆盖「正常输入」。

用户输入什么，系统就按什么处理。

结果就是：

• SQL 注入；
• 命令注入；
• XSS；
• SSRF；
• 任意文件上传；
• 路径穿越；
• 模板注入；
• 反序列化风险。

这些不是新漏洞。

但 Vibe Coding 会让这些老问题以更低成本、更高频率出现在大量小应用里。

---

5. 没有日志和审计

很多 Vibe Coding 应用只关注功能完成，不关注运行后的可观测性。

一旦出问题，很难回答：

• 谁登录过？
• 谁导出了数据？
• 谁修改了配置？
• 谁删除了记录？
• 哪个 IP 访问了后台？
• 哪个接口被异常调用？
• 哪个版本引入了问题？

没有日志，就没有调查能力。

对安全团队来说，一个没有日志的系统，几乎就是一个黑盒。

---

6. 依赖和供应链不可控

AI 生成代码时，经常会引入第三方库。

用户可能并不知道这些库是什么、谁维护、是否过期、是否有漏洞、是否存在恶意包风险。

更现实的问题是：

• AI 可能推荐已经废弃的库；
• 可能生成错误的安装命令；
• 可能引入不必要的依赖；
• 可能没有锁定版本；
• 可能忽略许可证风险；
• 可能把测试依赖带到生产环境。

当每个业务人员都能生成应用时，每个人都可能无意间引入一条新的供应链风险。

---

五、为什么安全团队很难发现这些影子应用？

Vibe Coding 生成的影子应用很难治理，因为它绕开了传统安全团队的监控路径。

第一，它不一定经过代码仓库

很多组织的安全扫描依赖 Git 仓库、CI/CD 流水线、制品仓库。

但影子应用可能直接在 AI 工具里生成，然后复制到云平台部署。

没有仓库，就没有代码扫描。 没有流水线，就没有安全门禁。 没有制品管理，就没有版本追踪。

---

第二，它不一定使用企业域名

安全团队可以监控企业主域名和备案资产，但影子应用可能挂在第三方平台的随机域名下。

例如：

xxx.vercel.app
xxx.netlify.app
xxx.pages.dev
xxx.firebaseapp.com

这些域名不一定出现在企业资产台账里。

但它们可能正在处理企业数据。

---

第三，它不一定有标准流量特征

传统安全设备更容易识别明确的业务系统、固定域名、固定 API。

影子应用可能访问量很小，只被几个部门内部人员使用。

它没有明显攻击流量，也没有大规模访问特征。

但正因为小，它更容易长期潜伏在组织外部。

---

第四，它可能被认为「不是正式系统」

这是最常见的治理盲区。

业务部门会说：

只是一个临时工具。

只是内部几个人用。

只是一个测试页面。

只是一个数据看板。

没有真正上线。

但安全风险并不关心你怎么定义它。

只要它处理真实数据、连接真实系统、暴露在真实网络里，它就是一个真实资产。

---

六、Vibe Coding 不是问题本身，失控才是问题

批判 Vibe Coding 很容易。

但完全禁止 Vibe Coding 并不现实，也不一定正确。

因为它确实解决了很多真实问题：

• 原型验证更快；
• 小工具开发成本更低；
• 业务人员可以自助解决问题；
• 开发资源不再被大量低价值需求占用；
• 个人和小团队的创造力被释放。

真正的问题不是「业务人员不该做工具」。

真正的问题是：

组织还在用旧的软件治理方式，面对新的软件生产方式。

过去，安全团队默认软件来自开发团队。 现在，软件可能来自任何一个会写提示词的人。

过去，安全团队守的是代码仓库和上线流程。 现在，安全团队还要关注 AI 工具、云端托管平台、低代码平台、个人自动化脚本和临时应用。

过去，影子 IT 主要是「私自使用工具」。 现在，影子 IT 变成了「私自生成系统」。

这就是变化的本质。

---

七、安全团队应该怎么应对？

Vibe Coding 的治理，不能只靠一句「不允许」。

越是禁止，越容易转入地下。

更合理的思路是： 允许创新，但要把创新纳入边界。

1. 建立「AI 生成应用登记机制」

不要一上来要求所有小工具都走完整研发流程。

这会让业务部门直接绕开安全。

更可行的是建立轻量登记机制：

• 应用名称；
• 创建人；
• 使用部门；
• 部署位置；
• 访问地址；
• 是否公网可访问；
• 是否处理敏感数据；
• 是否连接内部系统；
• 是否有登录鉴权；
• 是否有负责人。

先看见，再治理。

没有资产可见性，一切安全策略都是空谈。

---

2. 按数据敏感度分级治理

不是所有 Vibe Coding 应用都需要同样严格的安全控制。

可以按数据和权限分级：

低风险：不联网、不存储数据、只做个人本地工具
中风险：内部使用、处理一般业务数据
高风险：公网访问、处理客户数据、连接内部系统
极高风险：涉及财务、身份、医疗、交易、生产变更

不同等级对应不同要求。

低风险可以备案即可。 中风险需要基础安全检查。 高风险必须做鉴权、日志、扫描和审批。 极高风险不应由非专业人员直接 Vibe Coding 上线。

---

3. 给业务人员提供安全模板

如果组织不给安全路径，用户就会自己找路。

与其禁止业务人员使用 AI 生成应用，不如提供安全模板。

例如：

• 标准登录模板；
• 权限控制模板；
• 数据库访问模板；
• 日志审计模板；
• 文件上传模板；
• API Key 管理模板；
• 安全部署模板；
• 前后端分离基础框架。

让 AI 在安全模板里生成代码，比让它从零自由发挥更可控。

安全团队不应该只做审批者，也应该成为安全能力提供者。

---

4. 把安全检查嵌入 AI 开发流程

Vibe Coding 的节奏很快。

如果安全检查还停留在上线前人工评审，就一定跟不上。

更合理的方式是把安全检查前置到 AI 生成过程中。

比如要求用户在提示词中加入：

请检查这个应用是否存在鉴权缺失、越权访问、输入校验不足、密钥硬编码、敏感数据泄露和不安全 CORS 配置。

但仅靠提示词还不够。

更稳妥的是结合工具：

• 代码扫描；
• 依赖扫描；
• Secret 扫描；
• 容器扫描；
• API 安全测试；
• Web 漏洞扫描；
• 配置基线检查。

AI 可以生成代码，但安全门禁不能只依赖 AI 自己说安全。

---

5. 对公网发布设置硬门槛

本地工具和公网应用不是一个风险级别。

一个 Vibe Coding 应用如果只在本机运行，风险通常有限。 但只要它发布到公网，就应该触发更高等级的检查。

公网发布前至少要确认：

• 是否需要登录；
• 是否存在默认账号；
• 是否暴露管理接口；
• 是否存在测试数据；
• 是否硬编码密钥；
• 是否允许任意文件上传；
• 是否存在调试接口；
• 是否开启 HTTPS；
• 是否配置访问控制；
• 是否有基本日志。

「能跑起来」不能等于「能放出去」。

---

6. 建立影子应用发现能力

安全团队需要主动发现这些应用。

可以从几个方向入手：

• 监控企业邮箱注册的第三方开发平台；
• 发现员工创建的 Vercel、Netlify、Firebase 项目；
• 监控企业数据接口的异常调用来源；
• 识别访问企业 API 的未知前端；
• 检查 GitHub 公开仓库中的企业域名、密钥、接口地址；
• 通过 ASM 发现未知子域名和云端托管资产；
• 在代理和网关日志中识别未知 AI 开发平台流量。

Vibe Coding 的治理，第一步不是封堵，而是发现。

---

八、开发者也需要重新理解「能跑」和「能用」的区别

Vibe Coding 很容易制造一种错觉：

页面出来了，功能跑通了，应用就完成了。

但真正的软件工程并不是这样。

能跑，只代表代码在某个场景下没有立即失败。 能用，则意味着它能在真实环境中稳定、安全、可维护地运行。

中间差了很多东西：

• 异常处理；
• 权限控制；
• 数据保护；
• 日志审计；
• 性能边界；
• 依赖管理；
• 错误恢复；
• 备份策略；
• 升级机制；
• 安全加固；
• 运维责任。

Vibe Coding 擅长生成「看起来完成」的东西。

但安全和可靠性往往藏在看不见的地方。

这也是为什么很多 AI 生成应用在演示时效果很好，一进入真实环境就开始暴露问题。

---

九、Vibe Coding 会改变安全团队的角色

安全团队不能只停留在过去的模式里：

等项目立项 → 等代码提交 → 等安全测试 → 等上线审批

因为 Vibe Coding 的出现意味着，很多应用可能根本不会经过这些流程。

安全团队需要从「关卡型安全」转向「平台型安全」。

也就是说，不只是拦截，还要提供能力。

例如：

• 提供安全提示词模板；
• 提供安全应用脚手架；
• 提供统一鉴权组件；
• 提供日志接入模板；
• 提供密钥管理服务；
• 提供自动化扫描流水线；
• 提供轻量应用登记入口；
• 提供风险分级发布策略。

过去安全团队问的是：

这个系统能不能上线？

未来安全团队还要问：

业务人员自己生成系统时，怎样才能默认安全？

这是一种角色变化。

安全不再只是最后一道门，而应该成为 AI 开发过程中的默认能力。

---

十、Vibe Coding 最终会走向哪里？

Vibe Coding 不会消失。

原因很简单： 它确实太方便了。

只要业务需求还在增长，只要开发资源仍然有限，只要 AI 工具继续进步，越来越多的人就会用自然语言生成软件。

这不是安全团队能单方面阻止的趋势。

真正的问题是，组织能不能建立新的治理模式。

未来可能会出现三类应用：

第一类：个人本地工具

这类应用风险较低，主要解决个人效率问题。

例如脚本、数据处理工具、本地可视化页面。

治理重点是避免敏感数据外传和密钥泄露。

第二类：团队内部工具

这类应用风险中等，可能处理部门数据，服务多个用户。

治理重点是鉴权、权限、日志、数据分级和负责人机制。

第三类：事实生产系统

这类应用风险最高，可能连接真实业务系统，处理客户数据，甚至影响交易和生产流程。

这类系统不能仅靠 Vibe Coding 个人维护，必须纳入正式研发、安全和运维体系。

关键不在于它是不是 AI 生成的。

关键在于它承担了什么业务责任。

只要承担了真实责任，就必须接受真实治理。

---

结语：新一代影子应用已经出现

Vibe Coding 最大的价值，是让更多人拥有了创造软件的能力。

但它最大的风险，也是让更多人拥有了创造软件的能力。

过去，软件开发的门槛挡住了一部分效率，也挡住了一部分风险。 现在，门槛降低了，效率释放了，风险也开始扩散了。

新一代影子应用不会总是以「黑客工具」的样子出现。

它可能是一个很好看的报名页面。 可能是一个临时数据看板。 可能是一个自动生成日报的小工具。 可能是一个连接数据库的内部后台。 可能是一个业务部门自己做的客户查询系统。

它们一开始都很小。 小到没人审批。 小到没人登记。 小到没人觉得它是资产。

但只要它连接了真实数据、暴露在真实网络里、承载了真实业务流程，它就不再只是一个「小工具」。

它就是一个系统。

而系统，就必须被治理。

Vibe Coding 不是洪水猛兽。

真正危险的是： 组织已经进入人人都能生成软件的时代，但安全治理还停留在只有开发团队才会写代码的时代。

这才是新一代影子应用的根源。

---

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：NowSec NowSec NowSec《Vibe Coding 正在制造新一代影子应用》