AI代码自查:安全突破还是潘多拉魔盒?

Thenewstack

Anthropic近期为其Claude Code平台引入的自动化安全审查功能,在技术专家中引发了广泛讨论。此举被普遍视为迈向“AI原生开发”的关键一步,同时也引发了关于其对传统安全工具的影响以及AI生成代码本质的疑问。

Scotiabank工程总监Abhishek Sisodia认为,这些新功能,包括基于终端的/security-review命令和自动化的GitHub拉取请求扫描,代表着一次重大转变。他将其视为AI原生开发演进过程中的关键时刻,强调了其将安全从被动措施转变为开发过程中固有部分,从而彻底改变安全的潜力。Sisodia指出,在拉取请求阶段进行安全检查,而非仅限于传统的渗透测试或季度审计,能够更早地识别和纠正漏洞,此时修复成本最低。他解释说,这种方法意味着开发人员不再需要成为安全专家,因为Claude可以直接在代码中标记SQL注入、跨站脚本和身份验证缺陷等常见漏洞,甚至提出补救措施。

Cloudsmith首席执行官Glenn Weinstein对此表示赞同,称赞Anthropic的“安全设计”理念。他指出,这些功能补充了工件管理平台在扫描和识别二进制包依赖项中已知漏洞的作用。Weinstein强调了早期检测的重要性,指出在拉取请求合并和持续集成/持续交付(CI/CD)构建之前捕获问题是理想的情况。

然而,AI驱动开发工具的迅速普及也引发了担忧。The Futurum Group分析师Brad Shimmin指出了两个主要风险:一是创建未经严格安全、性能或合规性审查的软件;二是AI系统可能生成大量琐碎或不准确的“肤浅的拉取请求”。Arcjet首席执行官David Mytton强调了一个根本性挑战,他观察到AI加速代码编写的能力意味着经验不足的人员将产出更多代码,这不可避免地导致更多安全问题。尽管他认为自动化安全审查是防范暴露的秘密或不安全数据库等“低垂果实”式安全问题的宝贵保障,但Mytton也提出了一个发人深省的问题:“如果它正在审查自己AI生成的代码,那么AI审查自身就有些奇怪了!为什么不让模型从一开始就避免安全问题呢?”

网络安全专家兼Vulnerable U创始人Matt Johansen对AI审查自身输出的固有局限性持有类似的保留意见。他承认AI有可能利用额外的上下文或工具,但强调其能力仍受自身设计的限制。尽管有这些警告,Johansen对供应商将安全功能直接嵌入其产品表示乐观,认为这是安全被视为增值而非障碍的积极信号。

此次发布还引发了关于其对传统安全工具公司影响的辩论。Sisodia认为竞争格局正在发生变化,他指出,如果像Claude这样的AI原生平台能够比传统的静态和动态应用程序安全测试(SAST/DAST)工具更快、更具成本效益地执行其功能,并更深入地集成到开发人员工作流中,那么行业标准已被显著提高。他预测,老牌安全供应商将需要重新评估用户体验、开发人员集成以及如何在单纯检测之外叠加价值。

然而,Johansen淡化了对安全行业的生存威胁,他将这种情况比作微软内置安全工具并未消除对端点检测与响应(EDR)系统的需求。他强调,复杂问题将始终需要专门的解决方案。Weinstein强化了这一观点,他指出,防止漏洞进入生产系统需要多层方法,不仅要检查源代码,还要检查语言包、容器、操作系统库和其他二进制依赖项。

Shimmin将Anthropic的倡议视为更广泛行业变革的潜在催化剂,将其与Anthropic早期在模型透明度方面的工作如何影响其他支持性努力进行了类比。Sisodia认为这些功能不仅仅是产品更新;对他而言,它们标志着“AI优先软件安全”的出现,迈向一个“默认安全”不再是愿望,而是与正确AI助手编码的自然结果的未来。

尽管专家们普遍对AI驱动的安全工具表示乐观,但普遍认为没有任何单一解决方案能够解决所有安全挑战。Weinstein对多层方法的强调反映了行业对纵深防御的普遍信念。未来的问题不是AI是否会在软件安全中发挥作用——这一点似乎很清楚——而是传统安全供应商将如何适应,以及随着AI继续重新定义开发格局,会出现哪些新问题。正如Johansen恰当地指出,开发人员无论如何都会拥抱这些AI工具,因此从一开始就内置适当的保障措施至关重要,而不是事后补救。行业对Anthropic新安全功能的反应,凸显了随着AI加速软件开发,安全工具需要迅速演进。