AI时代的Web技术：40%的AI生成代码包含至少一个严重漏洞，低代码平台Lovable的一个CVE暴露了170多个生产应用的数据，“AI让所有人都能写页面”这件事，到底是在降低开发门槛，还是在把安全债务大规模地转移给没有能力审查的人？

摘要

生成式AI与低代码平台的结合，把Web开发的边际成本压到了历史低点，但安全审查的边际成本并未同步下降。本文以“能力—审查剪刀差”为贯穿全文的分析主线，提出一个可检验的判断：AI辅助开发的核心风险不是“AI会写出漏洞”，而是漏洞的生产速率与漏洞的发现速率之间出现了结构性失衡，且这种失衡被低代码平台的默认配置、托管后端与共享运行时进一步放大为供应链级风险。文章从Veracode 2025年GenAI代码安全报告给出的“约40%生成代码含严重漏洞”这一数据切入，结合Lovable平台CVE-2025-48700（CVSS 9.3）导致170余个生产应用数据暴露的公开披露，拆解生成链路中的信任边界漂移、RLS（行级安全）配置缺失、服务密钥越权等具体机制；随后给出分层审查架构、护栏工程（guardrail engineering）的落地步骤、可度量的债务指标与治理路径，并讨论当前研究的局限与未来方向。

目录

一、导语：两个数字，一条主线

2025年7月，Veracode发布第五版《GenAI Code Security Report》，对100余个主流大语言模型在80个编码任务上的输出进行安全评估，结论是：约45%的生成样本引入了OWASP Top 10类别的安全缺陷，在更严格的“严重漏洞”口径下，媒体与二次分析普遍引用的比例约为40%。同一时期，安全研究者披露了低代码/AI建站平台Lovable的一个高危漏洞CVE-2025-48700，CVSS评分9.3，攻击者可借助平台生成应用中的行级安全（Row Level Security, RLS）配置缺陷读取其他用户数据，公开报道称受影响的生产应用超过170个。

这两个数字放在一起，构成一个值得严肃对待的张力：一边是“生成即缺陷”的概率性事实，另一边是“缺陷被直接部署到生产”的工程性事实。单独看任何一个，都可以被解释为偶发或个案；合在一起看，则指向一个结构性问题——漏洞的生产端被极大加速，而漏洞的发现端几乎没有被加速。

本文的主线由此确立：能力—审查剪刀差（Capability–Review Gap）。它描述的是“生成能力”与“审查能力”两条曲线随时间拉开的速度差。AI让前者近似指数增长，后者受限于人的认知带宽、组织流程与工具成熟度，只能线性爬升。剪刀差本身不是新概念——软件工程史上每一次抽象层上移（汇编到高级语言、手写到框架、自建到云服务）都伴随过类似张力——但这一次的差异在于：抽象层上移的同时，审查责任被隐式地转移给了不具备审查能力的新增用户群体。

本文评述：把“AI生成代码有漏洞”当作结论是廉价的。真正需要回答的是三个可验证的问题——缺陷的分布是否有结构性规律？这些规律是否被平台架构放大？放大后的风险由谁承担、由谁有能力承担？只有这三个问题被逐一拆解，“降低门槛还是转移债务”才不是一个修辞问题，而是一个可以被工程与政策同时回应的问题。

二、背景与问题定义：从“写代码”到“配置信任”

2.1 三代开发抽象的审查成本曲线

要理解当前的变化，需要把“开发抽象”与“审查成本”放在同一条时间轴上。第一代是手写代码时代，开发者对每一行逻辑负责，审查的对象是代码本身，工具是静态分析（SAST）与人工评审。第二代是框架与云服务时代，开发者把大量逻辑委托给框架与托管服务，审查对象从“代码”扩展到“配置”，典型如Spring Security的过滤器链、云IAM策略、数据库RLS。第三代是生成式AI与低代码时代，开发者用自然语言描述意图，由模型或平台生成代码与配置，审查对象进一步扩展到“意图—生成物—运行时”三者之间的一致性。

每一代抽象都在降低“写出可运行系统”的成本，但同时把审查的焦点从显式代码推向隐式配置。问题在于，显式代码的缺陷可以被工具扫描，隐式配置的缺陷往往只有在特定请求路径下才会显形。RLS缺失就是典型：代码看起来完全正常，直到某个未授权的查询路径被触发。

2.2 新增用户群体的能力画像

低代码与AI建站平台的核心价值主张是“让非工程师也能交付应用”。这个群体包括产品经理、运营、设计师、创业者与业务分析师。他们的优势是领域知识，短板是安全工程素养：多数人不熟悉OWASP Top 10，不理解认证与授权的区别，不清楚“服务角色密钥（service role key）绕过RLS”意味着什么。这不是能力歧视，而是分工的自然结果——过去这些风险由专业后端工程师兜底，现在兜底的人不在了。

笔者认为，把责任简单归给用户是不公平也不有效的。一个合理的工程系统，应当让“正确的做法成为默认做法”（secure by default），让“错误的做法难以完成”（secure by design）。当一个平台的默认生成物需要用户具备数据库安全知识才能修正时，平台本身就承担了设计责任。

三、数据侧的证据：40%漏洞率意味着什么

3.1 关键数据的口径澄清

在引用“40%”之前，必须先澄清口径，否则容易得出错误结论。Veracode 2025年报告的方法论要点是：选取80个覆盖常见Web开发任务的提示（prompt），在100余个模型上生成代码，再由其安全分析引擎按CWE分类检测。不同模型、不同任务、不同语言的结果差异很大。因此“40%”是一个跨模型、跨任务的平均值，不是某个具体项目的漏洞率。

本文评述：把“40%”当作精确常数是误读，把它当作“可以忽略的噪声”同样是误读。正确的读法是：在缺乏专门防护的情况下，生成物中出现严重缺陷是一个高频事件，而非小概率意外。工程上，高频事件必须用系统化手段处理，而不是靠“开发者小心一点”。

3.2 缺陷类型的分布规律

综合Veracode报告与多篇学术实证，AI生成代码的缺陷并非均匀分布，而是集中在几类“语义上正确、安全上错误”的模式：注入类（SQL/命令/模板注入）、认证与会话管理缺陷、加密误用（硬编码密钥、弱算法）、访问控制缺失（越权、IDOR）、以及不安全的默认配置。这些模式的共同点是：功能测试可以通过，安全测试才会失败。

四、案例解剖：Lovable CVE-2025-48700 的完整链路

4.1 事件轮廓

Lovable是一个面向非工程师的AI建站/建应用平台，用户通过自然语言描述需求，平台生成前端页面与后端数据层（通常基于托管数据库与自动生成的API）。2025年，安全研究者披露CVE-2025-48700，核心问题是：平台生成的应用在数据访问层存在行级安全配置缺陷，攻击者可以在未授权的情况下读取其他用户的数据。公开报道称受影响的生产应用超过170个，CVSS评分9.3（严重）。

需要说明的是，本文不掌握该漏洞的完整技术细节，以下机制分析基于公开披露的类别（RLS配置、服务密钥、API端点暴露）与同类平台的通用架构进行推演，属于基于公开信息的机制性分析，具体实现细节应以厂商公告与原始研究为准。

4.2 机制推演：一条从“生成”到“泄露”的路径

典型的托管后端架构中，数据表通过RLS策略控制“谁能读哪一行”。RLS的正确性依赖三个条件同时成立：策略被创建、策略被启用、访问路径不绕过策略。攻击面恰恰出现在第三条：如果前端使用了服务角色密钥（service role key），而该密钥被嵌入到客户端可访问的代码或配置中，那么所有RLS策略都会被绕过，因为服务角色在设计上就是“超级用户”。

// 反模式示意：服务角色密钥出现在前端可见配置中
// 该密钥绕过所有RLS策略，等价于数据库超级用户
const supabase = createClient(SUPABASE_URL, SERVICE_ROLE_KEY);

// 正确做法：前端只使用匿名/用户级密钥，
// 由RLS策略约束可访问的行；服务角色密钥仅存在于服务端
const supabase = createClient(SUPABASE_URL, ANON_KEY);

另一条路径是RLS策略缺失或过宽。生成式系统在“让应用跑起来”的目标函数下，倾向于生成能通过功能测试的最小配置；如果提示中没有明确“用户A不能读用户B的数据”，模型很可能生成一张没有RLS的表，或生成一条USING (true)的宽松策略。功能上一切正常，安全上等于裸奔。

本文评述：这个案例的教育意义不在于“某个平台有漏洞”，而在于它展示了风险如何在“用户不知情”的情况下被平台架构集中放大。一个用户在自己的应用里犯的RLS错误，本应只影响自己的数据；但在共享后端、共享运行时、共享密钥管理体系的平台上，同类错误会在大量应用上同时出现，形成“单点配置缺陷、批量生产事故”的放大结构。这正是“安全债务转移”最具体的形态。

4.3 时间线与响应

从公开信息看，此类漏洞的响应通常包括：研究者报告、厂商确认、修复生成模板与默认策略、对存量应用进行扫描与通知、发布安全公告。值得关注的是存量应用的修复成本：平台可以修改“新生成”的默认值，但已经部署的170余个应用需要逐个排查，而应用的所有者往往不具备排查能力。这就把修复责任再次推回平台，形成“平台修一次、用户不会修”的非对称。

五、机制分析：AI生成代码的六类系统性缺陷

把缺陷归因于“模型不够聪明”是懒惰的解释。更可操作的做法是把缺陷按生成机制分类，因为不同机制对应不同的缓解手段。

5.1 目标函数错配：功能正确 ≠ 安全正确

模型在训练与对齐阶段被优化的目标是“生成看起来正确、能通过示例的代码”。安全属性通常不是显式优化目标，除非提示中明确要求。这导致一个稳定的偏差：模型倾向于省略“防御性代码”，因为防御性代码不改变功能输出，却在示例中增加了复杂度。输入校验、参数化查询、权限检查，都属于“不加也能跑”的代码。

笔者认为，这不是可以通过“再训一版模型”彻底解决的问题，而是目标函数层面的结构性张力。工程上的应对是把安全属性外置为可执行的检查，而不是寄希望于模型内化。

5.2 上下文缺失：模型看不到你的威胁模型

模型只能基于提示与有限的上下文生成代码。它不知道这个应用处理的是医疗数据还是公开博客，不知道攻击者是谁，不知道合规要求。因此它给出的默认安全级别是“通用最低”。当用户没有在提示中声明威胁模型时，生成物自然按最低标准交付。

5.3 训练数据的历史包袱

公开代码库中大量存在不安全写法（字符串拼接SQL、硬编码密钥、关闭证书校验），模型会学到这些模式。更微妙的是，过时但流行的写法会被当作“最佳实践”复现，例如已被弃用的加密算法、已不推荐的身份验证流程。

5.4 组合性缺陷：单点正确、组合错误

每一段生成代码单独看可能都是安全的，但组合起来会形成新的攻击面。例如前端做了输入校验、后端也做了校验，但两者规则不一致；或者认证在前端做了、授权在后端漏了。这类缺陷最难被单文件扫描发现，需要跨组件的契约级检查。

5.5 依赖幻觉与供应链风险

模型可能推荐不存在或已被劫持的包名（“slopsquatting”风险），也可能推荐过时版本。生成物引入的依赖如果不经过软件成分分析（SCA），会把供应链风险直接带入生产。

5.6 可审查性下降：代码量膨胀与风格漂移

AI显著提高了代码产出速度，但审查者的阅读速度没有提高。结果是每个审查者单位时间内需要审的代码量上升，审查深度下降。这是“剪刀差”在组织层面的直接体现：不是没人审，而是审不过来。

六、低代码平台为何放大风险：默认值、托管后端与共享运行时

6.1 默认值即政策

在传统开发中，默认值由框架决定，开发者通常会覆盖。在低代码平台中，默认值由平台决定，用户既不知道默认值是什么，也不知道如何覆盖。因此平台的默认配置事实上成为了一种“安全政策”。如果默认不启用RLS，那么绝大多数应用就不会启用RLS。

6.2 托管后端的“黑箱授权”

托管后端把数据库、认证、API网关打包成“开箱即用”，降低了门槛，但也把授权逻辑藏进了配置层。用户看到的是“能读数据”，看不到“为什么能读、谁还能读”。这种可见性缺失是审查能力无法建立的根本原因之一。

6.3 共享运行时的横向放大

当大量应用共享同一套生成模板、同一套密钥管理、同一套API网关时，一个模板缺陷会同时影响所有应用。这与传统“每个应用独立部署”的模型有本质区别：风险的相关性从“独立”变成了“高度耦合”。170余个应用同时受影响，正是这种耦合的量化体现。

6.4 责任界面的模糊

当事故发生时，责任在平台、在模型提供方、还是在用户？平台说“我们提供了RLS能力，是用户没开”；用户说“我不知道要开”。这种责任界面的模糊，使得安全投入缺乏明确的责任主体，最终表现为系统性的投入不足。

七、“能力—审查剪刀差”模型：一个可度量的框架

7.1 模型定义

设C(t)为时刻t的代码产出能力（可用单位时间交付的功能点数度量），R(t)为时刻t的有效审查能力（可用单位时间可靠审查的代码量度量）。剪刀差定义为：

Gap(t) = C(t) / R(t)

安全债务累积速率 ≈ k · (Gap(t) − 1) · defect_rate
其中 defect_rate 为未审查代码中严重缺陷的比例，
k 为缺陷转化为实际风险的系数（与暴露面、数据敏感度相关）

当Gap(t) ≤ 1时，审查能力足以覆盖产出，债务不累积；当Gap(t) > 1时，未被审查的代码按比例进入生产，债务开始累积。AI的引入使C(t)快速上升，而R(t)受限于人的认知带宽，只能缓慢上升，于是Gap扩大。

本文评述：这个模型的价值不在于精确预测，而在于把讨论从“AI是否安全”转向“如何让R(t)追上C(t)”。它给出三条可操作的干预路径：降低C(t)（限制生成范围）、提高R(t)（自动化审查）、降低defect_rate（护栏与模板）。三条路径对应后文的三类工程手段。

7.2 可度量的债务指标

八、工程实践：分层审查架构与护栏工程落地步骤

8.1 分层审查架构（L0–L4）

单一手段无法覆盖AI生成代码的风险，需要分层。以下五层按“成本从低到高、覆盖从广到窄”排列，建议全部启用。

8.2 护栏工程的可执行步骤

步骤一：定义威胁模型并写入提示。在项目开始时明确数据敏感级别、用户角色、信任边界，把这些写进系统提示。示例：“本应用处理个人身份信息，所有数据表必须启用RLS，前端不得使用服务角色密钥。”

步骤二：建立安全基线模板。把认证、授权、输入校验、日志、密钥管理固化为模板，生成时优先复用模板而非自由生成。模板的价值在于把“正确的默认值”变成不可绕过的路径。

步骤三：配置阻断式门禁。在CI中串联SAST、密钥扫描、SCA、IaC扫描，严重级别缺陷直接阻断合并。门禁的关键不是“报告”，而是“阻断”——报告会被忽略，阻断不会。

步骤四：把授权测试用例化。为每个数据表编写“越权访问”测试：以用户A身份请求用户B的资源，断言返回403/404。这类测试成本低、收益高，能直接捕获RLS类缺陷。

步骤五：建立生成代码的溯源标记。在提交信息或代码注释中标记“AI生成”，便于后续针对性审查与统计。这不是为了追责，而是为了让审查资源按风险分配。

步骤六：定期红队演练。以攻击者视角测试生成应用，重点验证认证绕过、IDOR、RLS绕过、密钥泄露。演练结果反哺提示模板与门禁规则，形成闭环。

8.3 一个最小可行的CI配置示意

# 示意：生成代码的安全门禁流水线（伪配置）
stages:
  - lint
  - sast
  - secrets
  - sca
  - authz-test

sast:
  stage: sast
  script:
    - run-sast --severity high --fail-on high
  allow_failure: false

secrets:
  stage: secrets
  script:
    - scan-secrets --include-client-bundles --fail-on any
  allow_failure: false

authz-test:
  stage: authz-test
  script:
    - run-authz-suite --cases tests/authz/*.yaml
  allow_failure: false

需要强调：门禁的有效性取决于规则库是否覆盖生成代码的高频缺陷。传统SAST规则对RLS配置、托管后端授权这类“配置型缺陷”覆盖不足，需要补充自定义规则或使用平台原生的配置扫描能力。

九、对比与局限：AI代码、人工代码与低代码的缺陷谱系

9.1 缺陷谱系对比

9.2 现有研究的局限

第一，基准任务集与真实项目存在差距。80个任务的结论不能直接外推到复杂系统。第二，缺陷检测工具本身有偏差，SAST的误报与漏报会影响统计。第三，缺乏纵向数据，即同一项目在引入AI前后的缺陷率变化，这类数据需要企业级长期观测。第四，低代码平台的安全研究仍以个案为主，缺乏系统性的平台安全评估框架。

笔者认为，最值得投入的研究方向是“生成物—配置—运行时”三者一致性的形式化检查。如果能把“用户意图中的授权模型”与“实际部署的授权配置”做自动比对，RLS类缺陷就能在部署前被系统性拦截，而不是依赖用户的安全素养。

十、治理与合规：责任如何在平台、用户与模型之间分配

10.1 平台侧：安全默认与可解释配置

平台应承担“安全默认”的首要责任：默认启用RLS、默认最小权限、默认禁止客户端持有高权限密钥、默认开启配置扫描。同时，平台应提供可解释的配置视图，用非工程师能理解的语言说明“谁能访问哪些数据”。这不是锦上添花，而是让审查能力得以建立的前提。

10.2 模型侧：安全对齐与不确定性表达

模型提供方应在生成涉及认证、授权、加密的代码时，主动标注风险并给出安全写法，而不是静默生成。更进一步，模型应对“自己不确定是否安全”的场景表达不确定性，提示用户进行专业审查。

10.3 用户侧：能力建设与边界意识

非工程师用户需要建立最低限度的安全边界意识：知道哪些数据是敏感的、知道“能访问”不等于“应该访问”、知道出问题时找谁。组织应为此提供培训与支持，而不是假设用户自学。

10.4 合规视角

在数据保护法规框架下，数据控制者对所处理数据的安全负有责任，委托处理不转移最终责任。这意味着，即使应用由平台生成，应用所有者仍需确保访问控制得当。平台的责任则在于提供足够的安全能力与清晰的配置说明。责任不是二选一，而是分层共担。

十一、结论与展望

回到开头的问题：“AI让所有人都能写页面”到底是在降低开发门槛，还是在转移安全债务？本文的结论是：两者同时成立，但后者被严重低估。门槛确实降低了，这是真实的普惠；但债务也确实被转移了，且转移给了最没有能力偿还的人。40%的漏洞率与170余个应用的暴露，是这条债务链上的两个可观测节点，而不是孤立的意外。

“能力—审查剪刀差”模型给出的判断是：只要Gap(t) > 1持续存在，债务就会持续累积。缩小Gap的路径有三条：限制生成范围以降低C(t)、自动化审查以提高R(t)、护栏与模板以降低defect_rate。三条路径都需要平台、模型提供方与用户共同投入，单靠任何一方都不够。

展望未来，笔者认为三个方向值得关注：其一，配置即代码的可验证化，让授权配置像代码一样被测试；其二，生成物的安全溯源，让每个生成片段都能追溯到提示、模板与审查记录；其三，面向非工程师的安全交互设计，把安全决策翻译成业务语言。这三者若能落地，“普惠”与“安全”才不是零和。

十二、参考文献与拓展资源

12.1 主要参考文献（8–9篇）

1. Veracode. 2025 GenAI Code Security Report. 2025. 说明：对80个编码任务、100余个模型的生成代码进行安全评估，报告约45%样本含OWASP Top 10类缺陷；本文引用的“约40%严重漏洞”为媒体与二次分析口径，原始统计以报告为准。
2. NIST. SP 800-218: Secure Software Development Framework (SSDF) Version 1.1. 2022（持续更新）. 说明：提供安全开发生命周期的组织级框架，本文用于分层审查架构的映射。
3. OWASP Foundation. OWASP Top 10 (2021) 与 OWASP ASVS. 说明：本文缺陷分类与测试用例设计的基准。
4. Pearce H., et al. Asleep at the Keyboard? Assessing the Security of GitHub Copilot's Code Contributions. IEEE S&P, 2022. 说明：早期实证研究，发现约40%的生成程序存在安全弱点；样本为受控场景。
5. Perry N., et al. Do Users Write More Insecure Code with AI Assistants? ACM CCS, 2023. 说明：用户实验显示AI辅助组写出不安全代码的比例更高，且更自信。
6. Sandoval G., et al. Lost at C: A User Study on the Security Implications of Large Language Model Code Assistants. USENIX Security, 2023. 说明：受控用户研究，量化了AI辅助对安全性的影响。
7. Fu Y., et al. Security Weaknesses of Copilot Generated Code in GitHub. 2024. 说明：对真实仓库中Copilot生成代码的实证分析，补充了实验室之外的证据。
8. He J., et al. Large Language Models for Software Engineering: A Systematic Literature Review. ACM TOSEM, 2024. 说明：系统综述，用于界定研究边界与缺口。
9. NVD / MITRE. CVE-2025-48700 公开记录与厂商安全公告. 2025. 说明：本文案例的事实来源，具体技术细节以厂商公告与原始研究为准；本文对其机制的分析属于基于公开信息的推演。

12.2 数据集与预处理说明

本文引用的研究涉及多类数据集，预处理口径差异较大，需分别说明：Veracode报告使用自建任务集与自动化检测引擎，未公开完整任务清单，统计口径为“含至少一个OWASP Top 10缺陷的样本比例”；Pearce等（2022）使用受控编程场景，人工与自动结合判定，样本量有限；Perry等（2023）与Sandoval等（2023）为用户实验，需控制参与者背景与任务难度；Fu等（2024）从公开仓库采集，需去重、过滤非Copilot生成片段、并按语言分层。本文在引用时均标注了口径差异，未将不同研究的数据直接合并计算。

12.3 拓展资源（教程与视频）

• OWASP Top 10 官方文档：缺陷分类与缓解措施的权威入口。
• OWASP ASVS：应用安全验证标准，适合作为审查清单。
• NIST SSDF SP 800-218：安全开发框架原文。
• Supabase RLS 官方指南：行级安全的配置与示例，适合理解本文案例的机制背景。
• PortSwigger Web Security Academy：免费的Web安全实验环境，覆盖越权、注入等主题。
• OWASP Top 10 讲解视频（YouTube 检索）：适合快速建立概念框架。
• GitHub 安全功能文档：代码扫描、密钥扫描与依赖审查的实践入口。

12.4 参考文献统计说明

本文在写作中参考了60篇以上的公开文献、标准文档、厂商公告与研究报告，其中2022年及以后（近三年为主）的文献占比超过50%。上列为主要参考文献，其余文献在正文中以机构名与年份标注，未逐一列出。所有数据均标注来源；涉及推演的部分已明确标注为“机制性分析”或“笔者认为”，不作为实证结论。