从风险到责任:Ahmad Shadid 关于构建安全的AI辅助开发工作流程

简要概述

“Vibe编码”正在快速普及,但专家警告传统工具对企业代码存在安全性和保密性风险,强调需要加密的硬件支持“机密AI”解决方案。

From Risk To Responsibility: Ahmad Shadid On Building Secure AI-Assisted Development Workflows

近年来,“vibe编码”——一种以AI为先的工作流程,开发者利用大型语言模型(LLMs)和代理工具生成并优化软件——逐渐获得关注。同时,多份行业报告指出,虽然AI生成的代码具有速度快、便利性强的优势,但也带来了严重的安全和供应链风险。

Veracode的研究发现,近一半由LLMs生成的代码存在关键漏洞,AI模型经常生成不安全的实现,忽视注入漏洞或弱验证等问题,除非明确提示。近期一项学术研究也指出,基于代理的系统中的模块化AI“技能”可能携带漏洞,可能导致权限提升或暴露软件供应链。

除了不安全的输出外,还有一个常被忽视的系统性保密风险。目前的AI编码助手在共享云环境中处理敏感内部代码和知识产权,提供商或运营商在推理过程中可能访问数据。这引发了在大规模暴露专有生产代码的担忧,对于个人开发者和大型企业来说都是一个重大问题。

AI编码助手中的敏感企业代码会发生什么,为什么存在风险?

大多数现有编码工具只能在一定程度上保护数据。企业代码在传输到提供商服务器时通常会被加密,通常通过TLS。但一旦代码到达服务器,就会在内存中被解密,以便模型读取和处理。此时,诸如专有逻辑、内部API和安全细节等敏感信息以明文形式呈现在系统中。这就是风险所在。

代码可能会经过内部日志、临时内存或调试系统,这些系统客户难以看到或审计,即使提供商保证不保存数据,数据在处理过程中暴露的风险依然存在,而这短暂的窗口足以形成盲点。对于企业而言,这可能导致敏感代码被滥用的潜在风险,缺乏专有控制。

为什么你认为主流AI编码工具从根本上不适合企业开发?

大多数流行的AI编码工具并非为企业风险模型设计,它们只优化速度和便利性,因为它们主要在包含已知漏洞、过时模式和不安全默认值的公共仓库上训练。因此,除非经过彻底审查和修正,否则它们生成的代码通常存在漏洞。

更重要的是,这些工具没有正式的治理结构,不能在早期阶段强制执行内部安全标准,这导致软件的编程方式与后续审计或保护之间存在脱节。这最终使团队习惯于使用他们几乎不理解的输出,而安全性逐步滞后。这种缺乏透明度和技术隐患的结合,使得在安全优先领域运营的组织几乎无法获得标准支持。

如果提供商不存储或训练客户代码,为什么这还不够?需要哪些技术保障?

保证政策与技术保障截然不同。用户数据在计算过程中仍会被解密和处理,即使提供商保证不会存储。调试过程中产生的临时日志仍可能成为泄露路径,政策无法防止或证明安全性。从风险角度来看,没有验证的信任是不够的。

企业应更关注可以在基础设施层面建立的承诺。这包括机密计算环境,不仅在传输时对代码进行加密,还在使用过程中保持加密。一个很好的例子是硬件支持的可信执行环境(TEE),它创建了一个加密环境,即使基础设施运营商也无法访问敏感代码。模型在这个安全环境中处理数据,远程验证允许企业以密码学方式确认这些安全措施已激活。

这些机制应成为基本要求,因为它们将隐私转变为可衡量的属性,而不仅仅是承诺。

在本地或私有云中运行AI是否能完全解决保密风险?

在私有云中运行AI有助于降低部分风险,但不能完全解决问题。除非采取额外保护措施,否则在处理数据时,数据仍然非常容易被看到和受到威胁。因此,内部访问权限、配置不当以及网络内部的数据流动仍可能导致泄露。

模型行为也是一个关注点。虽然私有系统会记录输入或存储测试数据,但如果没有强隔离,这些风险依然存在。企业仍然需要加密处理。实现硬件基础的访问控制和明确的数据使用限制,对于安全保护数据至关重要,否则只是规避风险而非解决问题。

“机密AI”对编码工具到底意味着什么?

机密AI指在计算过程中管理数据安全的系统。它允许在隔离的环境中处理数据,比如硬件支持的可信执行环境(TEE),但在明文状态下让模型处理数据。硬件隔离的执行确保平台运营商、主机操作系统或任何外部方都无法访问,同时提供密码学验证的隐私保护,而不影响AI的功能能力。

这彻底改变了编码平台的信任模型,使开发者可以在不将专有逻辑暴露在共享或公共系统中的情况下使用AI。该过程还增强了责任追踪,因为访问边界由硬件而非政策建立。一些技术还结合了加密计算和历史追踪,输出可以在不暴露输入的情况下进行验证。

虽然这个术语听起来抽象,但其含义很简单:AI辅助不再要求企业牺牲保密性以追求效率。

目前使用机密AI的权衡或限制有哪些?

最大的权衡是速度。隔离在可信执行环境中的AI系统可能会比未保护的结构有一些延迟,主要由于硬件级别的内存加密和验证。好消息是,随着新硬件的推出,这一差距正在逐步缩小。

此外,还需要更多的设置工作和合理规划,因为系统必须在更受限制的环境中运行。成本也是一个考虑因素。机密AI通常需要特殊硬件——比如NVIDIA H100和H200等专用芯片——以及相关工具,这会增加初期投入。但这些成本应与代码泄露或不合规可能带来的潜在损失相权衡。

机密AI尚未成为普遍的系统要求,团队应在隐私和责任最为关键的场景中使用它。许多限制将随着技术发展而得到解决。

你是否预期监管机构或标准很快会要求AI工具在处理过程中保持所有数据加密?

像欧盟AI法案和美国国家标准与技术研究院(NIST)AI风险管理框架等监管框架已高度强调风险管理、数据保护和高影响力AI系统的责任。随着这些框架的发展,设计上暴露敏感数据的系统变得越来越难以在既定治理预期下合理。

标准组织也在制定更明确的规则,规定AI在使用过程中应如何处理数据。这些规则在不同地区的推行速度可能不同,但企业应预料到对处理明文数据的系统的压力会增加。这样,机密AI不再是猜测未来,而是与现有法规的方向保持一致。

“负责任的vibe编码”目前对开发者和IT领导意味着什么?

负责任的vibe编码就是对每一行代码保持问责,从审查AI建议到验证安全隐患,再到考虑每个边界情况。对于组织而言,这需要明确的政策定义,包括特定工具的批准和敏感代码的安全路径,同时确保团队理解AI辅助的优势与局限。

对于监管者和行业领导者来说,任务是制定明确规则,让团队能轻松识别哪些工具被允许使用、在哪些场景下可以使用。敏感数据应仅输入符合隐私和合规要求的系统,同时培训操作员和用户理解AI的能力和限制。合理使用AI可以节省努力和时间,但若使用不当,也会带来高昂的风险。

展望未来,你如何看待AI编码助手在安全方面的演变?

AI编码工具将从单纯的建议逐步演变为在编写代码时实时验证,确保遵守规则、授权库和安全约束。

安全性也将深入融入这些工具的运行设计中,比如设计加密执行和清晰的决策记录作为常规功能。随着时间推移,这将把AI助手从潜在风险转变为安全开发的支持工具。最优的系统将是速度与控制相结合的系统。信任的建立将取决于工具的实际表现,而非开发者的承诺。

ON1.66%
查看原文
此页面可能包含第三方内容,仅供参考(非陈述/保证),不应被视为 Gate 认可其观点表述,也不得被视为财务或专业建议。详见声明
  • 赞赏
  • 评论
  • 转发
  • 分享
评论
0/400
暂无评论
交易,随时随地
qrCode
扫码下载 Gate App
社群列表
简体中文
  • 简体中文
  • English
  • Tiếng Việt
  • 繁體中文
  • Español
  • Русский
  • Français (Afrique)
  • Português (Portugal)
  • Bahasa Indonesia
  • 日本語
  • بالعربية
  • Українська
  • Português (Brasil)