AI 生成代码逼迫开发平台重新思考架构设计

很高兴你在这里。你可以期待所有最好的 TNS 内容从周一到周五送达，让你紧跟新闻动态，保持竞争力。

查收确认邮件，你可以调整偏好设置，甚至加入更多群组。

在你喜欢的社交媒体网络上关注 TNS。

在 LinkedIn 上成为 TNS 的追随者。

在等待你的第一份 TNS 新闻通讯时，查看最新的精选和热门故事。

"举手，如果你的团队正在积极使用 AI 来编写和审查代码。如果你认为有相应的安全系统来应对这一情况，那就保持举手。"

这是今年早夏在伦敦 PlatformCon 上安全主题小组讨论的开场方式。对这个问题的常见反应是，聚集在此的数百名平台工程师和工程领导都举起了手，表示他们的团队正在使用 AI 来编写代码。但当被问及是否对现有的安全系统感到放心以应对 AI 生成的代码时，几乎所有人都放下了手，只有两个人保持举手。

这个对比引出了一个问题：如果我们无法以安全的方式跟上 AI 的速度，那我们应该那么快吗？

Isovalent 首席开源官、安全小组讨论成员 Liz Rice 上个月告诉 The New Stack，"威胁格局已经发生了很大变化，因为发现漏洞现在几乎是做无用功。我们在 AI 世界中所做的事情是非确定性的，所以围绕系统能做什么的护栏变得越来越重要，因为我们无法预测模型接下来会做什么。"

"我们在 AI 世界中所做的事情是非确定性的，所以围绕系统能做什么的护栏变得越来越重要，因为我们无法预测模型接下来会做什么。"

扩大风险因素的另一个方面是，比几年前更多的公司员工可能有能力编写会产生安全风险的代码。那么，你公司的每个人都应该被纳入你的内部开发者平台吗？

AI-BOM：潜伏在办公室食堂里的威胁

Shadow AI 是 shadow IT 的更丑陋的表亲，带来更多风险。但它正在推动组织真正审视他们的全公司 IT 采用，并考虑他们需要什么、不需要什么。因为我们知道更多的工具和更多的代码行只不过是复杂性的指标而已。

"AI 将从根本上改变我们对从开发人员一直到平台工程再到硬件的完整技术栈的思考方式，因为已经不存在零日漏洞了，" Broadcom EMEA 区域 CTO Joe Baguley 在小组讨论中表示。"我认为最大的关注点实际上是我们如何进行工程设计，因为 SBOM（软件物料单）在未来将非常重要，以及了解你用什么构建你的产品、你有什么依赖关系。"

"已经不存在零日漏洞了。"

这扩展到 AI 物料单（AI-BOM），用于跟踪所有非确定性的组件，如模型权重、训练数据集和第三方 API，以防止供应链地图中的漏洞、数据污染和监管不合规。

Baguley 还预测公司很快将停止大量采用开源项目，转而选择 fork 并保留他们使用的部分。另一方面，他辩称 AI 驱动的构建自有系统的便利性正在变成弗兰肯斯坦的怪物，举例说明有 17 个不同的人力资源专业人士构建 17 个不同的 AI agent 来解决他们日常工作的不同方面。

Rice 在讨论中补充说，当你考虑到这对员工私人信息的涉及时，这个人力资源场景变得更加令人担忧。

"我预测我们会看到一些恐怖故事，人们编写自己的任意软件，其中会有漏洞。无论你的模型有多好，它可能不会比人类编写更安全的代码，" Rice 表示，她也是《容器安全》和《Learning eBPF》的作者。"假设是来自非技术背景的人；他们可能不知道这是否是安全的做法。所以随着更容易创建更多代码的能力，我们最终可能会看到更多这样的情况。"

"无论你的模型有多好，它可能不会比人类编写更安全的代码。"

如果弗兰肯斯坦的怪物被锁在实验室里，那还是一回事。但如果有人从笔记本电脑上提取那个不安全的 agent 化 AI hack，并与他们不那么精通技术的队友分享呢？

"现在人力资源部有了软件，它可以做一件事；你不需要为 Asana 付费。我现在有了能做 Asana 做的事的东西，但现在它在本地运行，" Cloudsmith 开发者关系主管 Nigel Douglas 向 PlatformCon 观众提议。"我们需要开始将资源消费者视为不再仅仅是训练有素的开发人员。"

那么答案是每个人——来自各个部门的每个人和 agent——都应该被纳入内部开发者平台吗？还是这需要更传统的命令控制型 IT 平台？

我们必须再次改变平台的方式吗？

在这个后 Mythos 时代，补丁不能足够快速地应用。

忘记对未来的预测吧；今天的 AI 模型可以自主发现、链接和大规模利用软件漏洞，这就是为什么 Rice 告诉 The New Stack，"组织需要运行时保护在有时间应用补丁之前保护自己。"

运行时保护，通常基于 eBPF，可以保护文件系统、防止权限提升并监控网络访问。它们是动态的，比缓存等传统被动措施更快速实施，后者需要软件重建和重新部署。这些保护作为临时措施，对已知漏洞或意外行为提供即时保护。

"我们可以防止权限提升；我们可以检查网络访问，我们可以为各种不同的条件构建保护，无论是以护栏的形式来阻止临时编码行为变得意外失控，还是以 CVE 特定的运行时保护形式来检测特定的漏洞或问题行为，" Rice 说。

这并不意味着你不会重新补丁和重建，但在 AI 的速度下，已经疲惫不堪的安全和网站可靠性工程师跟不上。仅在 2025 年，就发布了创纪录的 48,185 个常见漏洞和暴露（CVEs），其中 20% 被评为关键或高严重性。同时，EdgeScan 漏洞统计报告发现平均修补或解决时间为 55 天。

这让 PlatformCon 小组成员最担忧的是这些 n-day 威胁，即公开、已知、可修复的威胁，但还没有人处理过。

"我们正在考虑的是如何构建可以立即修补并继续针对这种即时 n-day 威胁进行更新的平台，" Baguley 在小组讨论中沉思，就像 iPhone 更新一样，普通用户不关注它做什么。

当归结到最后，已经没有低级漏洞了。

"我们进入了一个世界，不仅仅关于如何控制 agent，而是关于你如何重新思考平台重建。我们不能使用 20 年前围绕安全的流程，" Baguley 说。

"这是同时向下和向左的转变。你需要思考如何让你的平台更精简、更强硬、更快速。"

你的平台团队如何找到方法在安全地跟上 AI 创新和创新性 AI 攻击的步伐？在 LinkedIn 上与我联系，这样你的经验教训、修复方案和人-agent 协作可以成为 The New Stack 的下一个案例研究。