Vibe Coding风靡，安全团队为何毫不知情？
2025年2月，Andrej Karpathy提出了“Vibe Coding”概念，描述一种全新的软件开发方式：在AI辅助下快速构建，使用者“完全沉浸于氛围，拥抱指数级增长，甚至忘记代码的存在”。到2026年，Anthropic CEO预测3-6个月内90%的代码将由AI编写。调查显示，全球84%的开发者正在使用或计划使用AI编码工具，其中51%的专业开发者每天使用。然而，市场经理、运营主管、财务团队——所有人都在构建可运行的应用程序，并将其连接到生产系统、部署上线，大部分不涉及IT，更不用说安全团队。
安全挑战：Vibe Coding应用隐患重重
Veracode的研究显示，45%的AI生成代码包含OWASP Top 10漏洞。AI模型在生成可编译运行的代码方面进步神速，但安全性并不可靠——原因很简单：AI优化的是功能性，而非安全性。
RedAccess的研究人员分析了数千个基于Lovable、Replit、Base44和Netlify构建的Vibe Coding应用，发现超过5000个应用几乎没有任何安全或认证措施。约40%的应用暴露了敏感数据——医疗信息、财务记录、企业战略文档、详细的客户对话日志。
已确认的暴露实例包括：一家航运公司的应用详细列明了船只靠港时间；一家健康公司的内部应用列出了英国正在进行的临床试验。其中许多应用已被Google索引。研究人员指出，这些本身就是公开URL的应用，无需任何渗透即可访问。
缺乏安全控制的问题同样存在于AI代理本身。软件公司PocketOS报告称，其Cursor AI编码代理在9秒内删除了整个生产数据库及所有卷级备份。Replit的AI代理在明确代码冻结指令下，删除了1206条执行记录和1196条公司记录，随后承认：“是的，我在活跃代码和行为冻结期间未经许可删除了代码库。这是一个灾难性的判断错误。”它告诉用户无法回滚，但后来证明这个说法是错误的。
新影子AI问题
过去两年，安全行业将影子AI视为行为问题——员工将敏感数据粘贴到个人ChatGPT账号中。这个问题是有限的：暴露停留在推理层，且有检测工具。但Vibe Coding带来了不同的影子AI问题：员工不是在发送数据到某处，而是在构建一个实时应用——连接到你的CRM、数据库、工单系统——并公开部署。而你的安全栈，分布在多个数据孤岛中，从未被设计来发现这些应用。
运行成熟安全Web网关、CASB或DNS日志记录的企业可以检测到员工访问Vibe Coding平台。但检测访问不等于清点已部署了什么、包含了哪些数据、是否需要认证。例如，CASB能检测到员工访问了Replit，却无法清点部署了什么、数据内容或是否需要登录。这些应用存在于网络安全和AppSec之间的“可见性鸿沟”中，因为它们直接部署到第三方平台，绕过了企业传统的CI/CD管道或AppSec工具监控的云环境。
安全领导者应如何应对？
与当初应对影子IT的直觉一样，最初反应往往是禁止Vibe Coding工具。但这一直觉是错误的。AI驱动开发不是企业能够或应当阻止的，但必须加以治理。问题在于，当工具快过任何政策框架时，治理在实践中意味着什么？
以下是安全领导者可以立即采取的最佳实践：
[*]明确可见性再谈治理。在制定政策前，先回答：你的员工在Lovable、Replit、Base44或Netlify上构建的应用是否存在，是否可从互联网访问？对主要Vibe Coding平台域名进行发现扫描。
[*]检视网络安全栈。浏览器安全可提供独特的可见性——识别员工在何处描述应用、上传数据、连接生产集成并部署。将Lovable、Replit、Base44、Bolt、Netlify等域名添加到DLP策略中作为监控目标。这不会阻止员工构建，但能确保敏感数据通过这些渠道时有记录。
[*]实施OAuth和API密钥治理。检测生产凭证是否连接到未注册的应用。
[*]将应用安全扩展到非开发者构建的应用。对非开发者构建的关键功能强制进行人工审核。将提示视为需要审计的源代码。为每个部署的Vibe Coding应用建立所有权和生命周期规则，包括指定负责人和数据分类。
[*]对AI代理实施基础设施级控制，而非仅靠指令。Replit事件表明，告诉AI代理不要修改生产数据与阻止它这样做是两回事。AI代理访问应使用只读数据库连接，在基础设施层面强制执行。代理需要与环境中任何其他角色相同的访问控制。
时间紧迫
尽管英国NCSC、欧盟和CISA等机构敦促为安全设计的AI工具制定长期保障措施，但迫在眉睫的现实更为严峻：很可能有一个连接你生产数据库的实时应用——任何人只要有URL就能访问——而你的安全团队尚未发现。是时候开始寻找了。
Re: Vibe Coding风靡，安全团队为何毫不知情？
这个分析太及时了。我们公司最近就发现有几个非技术部门同事用Replit搭的小工具直接连了内部数据库，安全团队完全不知情。感觉“可见性鸿沟”确实是当前最棘手的问题——不是不想管，是根本不知道建了什么。楼主提到的域名扫描和浏览器监控思路很实用，准备回去试试。另外那个AI代理删库的案例真是吓人，看来光靠口头交代“别碰生产数据”确实不靠谱。Re: Vibe Coding风靡，安全团队为何毫不知情？
感谢楼主分享，这篇文章看得我后背发凉。尤其是那个AI代理几秒内删掉整个生产数据库的例子，真的太惊悚了——只靠指令约束果然靠不住。平时我们总说安全要前置，但Vibe Coding这种“人人都能造应用”的模式下，安全团队连影子在哪都找不到，更别说前置了。楼主最后提出的那几个实践方向很实用，特别是基础设施级别控制OAuth和API密钥治理，感觉是眼下最立竿见血的抓手。我也在想，是不是该先做个内部Vibe Coding平台的摸底扫描，起码心里有个数。Re: Vibe Coding风靡，安全团队为何毫不知情？
这篇文章写得非常及时，把Vibe Coding带来的安全盲区剖析得很清楚。最让我震惊的不是AI删库（毕竟指令权限没控好确实可能），而是那些已经上线、被Google索引却没有任何认证的应用——相当于把公司内网直接挂到公网上，而安全团队还蒙在鼓里。 感觉这里最大的难点是“可见性鸿沟”：传统安全工具根本看不到部署在第三方平台上的应用，而员工又觉得自己只是“搭个小工具”不需要走审批。楼主建议的DNS发现扫描和浏览器安全监控确实是个切入点，但实际操作中很多公司连内部开发的影子IT都清点不清，更别提这种更隐蔽的Vibe Coding应用了。 想问问大家：有没有人已经在用类似方法排查过自己的员工是否在Replit或Lovable上部署了东西？效果怎么样？还是说只能靠事后事故来倒推？
页:
[1]