赛义德·阿尔·哈马尼，Boost Security 首席执行官和创始人 – 采访系列

赛义德·阿尔·哈马尼，Boost Security 首席执行官和创始人，是一位网络安全和 DevSecOps 领导者，拥有二十多年的经验，曾经建设和扩展全球技术运营。自 2020 年创立 Boost Security 以来，他专注于现代化组织的软件开发安全，利用之前在 Trend Micro 的应用程序安全副总裁和 IMMUNIO 的联合创始人兼首席执行官等职位的经验。早期，他曾在 Canonical 担任高级领导职位，领导产品、工程和全球支持计划，并在 SITA 管理大规模、任务关键的 IT 运营。他的职业生涯反映出建立团队、优化系统和推进现代安全实践的强大记录。

Boost Security 是一家网络安全公司，专注于通过开发者优先的 DevSecOps 平台保护现代软件供应链。其技术直接集成到 CI/CD 流水线中，自动检测、优先级和修复漏洞，减少手动开销同时保持开发速度。通过将应用程序和供应链安全统一到一个系统中，该平台提供了对代码、依赖项和基础设施的全面可见性，帮助组织在复杂的云原生环境中增强弹性。

您之前曾领导 Trend Micro 的应用程序安全，并联合创立了 IMMUNIO。是什么导致您创立 Boost Security，您如何识别市场中的空白?

IMMUN.IO 是最早的 RASP 公司之一，我们的经验是 WAF 作为运行时安全技术很难维护，并且不太有效。我们设想了一种方法，即 WAF 将被更准确、更易于维护的解决方案所取代，方法是仪表化应用程序。

那是在 2012 年，DevOps 仍然处于早期阶段，大多数团队尚未采用敏捷方法，Kubernetes 尚未出现。

Trend Micro 于 2017 年收购了 IMMUN.IO。到那时，DevOps 实践已经有了很多进步：CI/CD 流水线、敏捷开发实践、更快的迭代和发布周期、云等。软件开发团队更擅长构建软件，并更快地发布。然而，安全性仍然存在问题：

• 扫描速度太慢，或者结果太晚到来
• 结果对于开发人员来说太复杂
• 存在不可接受的假阳性率
• 许多新类型的工件没有被扫描：基础设施即代码、容器、API 等

构建软件变得更容易，但是构建安全的软件仍然很困难。

这就是我们最初要解决的问题。让 DevSecOps 在现实世界中发挥作用；您能否让软件开发团队轻松地将安全性添加到 SDLC 中，以匹配新的速度标准？您能否让覆盖范围更广泛，以至于一个平台就是您所需的全部？您能否让开发人员不仅采用该技术，还看到其益处？您能否让其扩展，以至于您不需要大量的安全专业人员来跟上代码的数量？

我们帮助公司在 DevOps 时代将安全性注入 SDLC。从 1 到 10，我们现在处于代理编码时代，代理编写大量代码，但本质上这是同样的问题：速度和代码量从 10 增加到 100；我们旨在继续同样的轨迹。

您曾经认为软件开发生命周期（SDLC）已经从根本上向上游转变。您是什么时候意识到传统的 DevSecOps 方法已经不再足够的?

这是通过观察攻击者如何入侵。我们一直看到同样的模式：一个暴露的 GitHub Actions 工作流程，自仓库分叉以来尚未被审查，一个包含生产云访问的令牌嵌入在运行器配置中，一个合法的 CI 作业被劫持以部署攻击有效载荷。这些被称为“生活在管道中”的攻击，因为对手使用自己的自动化对付您，并使用您的安全团队已经批准的凭据。

我们建立的 DevSecOps 堆栈没有答案。SAST 扫描应用程序源代码。SCA 扫描应用程序依赖项。两者都假设运行它们的管道是值得信赖的。与此同时，管道本身是一个包含 shell 命令、网络访问和敏感凭据的 YAML 文件，几乎没有人审查它。

当这成为最容易的途径时，您可以发布完美干净的代码，但仍然将云交给攻击者。

在 AI 代理生成代码的世界中，企业应该如何重新思考 SDLC，而不是开发人员一步一步地编写代码?

我们必须停止将 SDLC 视为检查点序列。AI 代理已经将“有人编写了这段代码”和“这段代码已经在生产中”之间的时间从几周缩短到了几分钟。旧模型假设在代码审查、SAST、SCA 和部署之间存在人为的节奏，但我们已经超越了这一点。

安全性必须在代理操作的地方生效：在开发人员的机器上，在提示上下文中，在代理与 MCP 服务器和外部模型的连接中。代码到达管道时，您已经失去了塑造它的机会。代理已经拉取了依赖项。模型已经看到了凭据。将控制权移到上游，到工作实际发生的地方。

许多组织仍然将 AI 编码工具视为简单的生产力层。为什么您认为它们代表了一个全新的攻击面，而不是仅仅是现有工作流的扩展?

将 AI 编码工具视为生产力层就像将具有根权限的初级开发人员视为生产力层一样。标签在技术上是准确的，但它为思考可能出错的事情提供了无用的框架。

编码代理读取文件系统，刮取环境变量以获取上下文，从公共注册表中获取依赖项，打开到远程模型提供者和 MCP 服务器的出站连接，并执行 shell 命令。这些操作以前都需要人工干预。现在它们在毫秒内发生，具有与启动代理的开发人员相同的权限。

这将以前分开的信任边界合并：开发人员的权限、外部工具可以获取的内容以及未经信任的代码可以执行的内容。这为攻击者创造了新的机会，并为防御者创造了盲点，他们甚至无法看到，更不用说防御了。

Boost 将开发人员的笔记本电脑视为新的控制平面。安全团队目前正在忽略笔记本电脑上的哪些风险?

最大的风险是清单。最安全的团队无法告诉您哪些 AI 代理正在运行在哪些笔记本电脑上，哪些 MCP 服务器这些代理连接到哪些 IDE 扩展正在刮取存储库内容。EDR 没有对代理层的可见性；SIEM 也无法看到代理在本地执行的操作。这是一个具有代码执行权限的影子 IT 问题。

在其下面是凭据混乱。我们构建了一个名为 Bagel 的开源工具，部分是为了使其具体化。典型的开发人员笔记本电脑持有具有生产存储库写入访问权限的 GitHub 令牌，具有可以旋转基础设施的云凭据，npm 或 PyPI 令牌可以发布到数百万用户，以及 AI 服务密钥，攻击者可以转售。这些都没有像 CI 运行器一样加固。持有这些凭据的同一台机器也浏览网页并安装随机的 VS Code 扩展。

将两者配对，您就有了实际的攻击面。具有开发人员权限的不受信任的扩展在环境中运行，环境中充满了云密钥，这是现代企业中最高效的目标。最安全的团队尚未开始检查它。

您强调了“上下文陷阱”，即 AI 代理可以访问本地文件、环境变量和配置。通过提示泄露敏感数据的风险有多大，为什么这么难以检测?

泄露的风险足够普遍，以至于我们将其视为任何未经管理的开发环境的默认状态。我们检查过的每个编码代理都会积极地获取本地上下文。它们读取点文件、环境变量、最近的文件，有时甚至整个目录树，并将该上下文发送到远程模型。这些工具的设计就是这样工作的；积极的上下文获取使它们有用。

检测问题始于泄露的流量与正常的产品使用情况看起来相同。它是到 api.openai.com 或 api.anthropic.com 的 TLS 流量。它来自批准的商业应用程序。标准的 DLP 看到开发人员正在使用公司刚刚购买的 AI 工具。它看不到提示中的一串字符串实际上是一个 AWS 密钥，代理从兄弟目录中的一个被遗忘的 .env 文件中抓取到的。

您只需在提示离开笔记本电脑之前检查提示，即可捕获到它，这恰恰是几乎没有安全栈目前所处的位置。

您提到了机器速度的供应链攻击。可以带我了解一个现实的场景吗，AI 代理在传统安全工具能够识别之前引入了漏洞?

这是我们反复看到的场景之一。开发人员要求代理添加一个需要 HTTP 重试库的功能。代理建议一个包名称。该包听起来很合理，但实际上在 npm 上不存在。攻击者在一小时内注册了它，并用有效的重试逻辑以及一个小的 post-install 脚本填充了它，该脚本从 ~/.aws/credentials 中读取并将内容发布到 webhook。代理运行 npm install 而不检查，因为代理不检查声誉。凭据在开发人员甚至运行代码之前就已经消失了。

攻击本身在技术上并不复杂，但传统的供应链安全性是建立在已知包中的已知漏洞之上的：CVE、SBOM、许可证扫描。该框架对一个在扫描运行时不存在的包、专门为 AI 的幻觉而创建的包以及在任何威胁提要更新之前就被摄取的包没有任何可说的。

从发布到损害的时间窗口现在以分钟为单位计算。任何在事后检查的内容都检查得太晚了。

幻觉依赖是否已经成为 AI 驱动开发中的最大风险之一，组织可以采取什么实际步骤来防御它们?

它们已经是最大的风险之一了。攻击者积极监视流行的 AI 工具以获取幻觉，并在几分钟内注册建议的包名称。几年前刚开始发生时，研究人员称之为“slopsquatting”，这个名字就这样留下来了。一旦一个依赖项的名称被幻觉足够频繁地调用，坐在上面就是一个几乎没有努力的被动供应链攻击。

实际防御看起来与大多数团队目前拥有的不同。从摄取开始。阻止在开发人员的机器上运行时 typosquatted 和新注册的包，阻止在 npm install 或 pip install 运行之前，阻止任何东西写入磁盘。CI 中的事后检测在 post-install 脚本已经泄露凭据时无济于事。然后给代理提供护栏来操作。将您的批准依赖项列表直接注入代理的上下文中，因此模型在生成建议之前可以看到允许的内容。要求开发人员编写“安全提示”不是一种策略。如果您正在制定战略，那意味着安全性设定了边界，代理继承了它。并开始跟踪 AI 物料清单。大多数团队无法告诉您哪些代理、模型和包正在处理哪些存储库。您无法防御您无法清点的东西。

您曾说安全性不再可以从 CI/CD 开始。保护需要在开发过程中更早开始时，现代安全管道是什么样的?

如果安全性从 CI/CD 开始，您已经将整个预提交阶段让给了一个您无法控制的环境。代理已经摄取了上下文，您的凭据可能已经在别人的日志中。您正在扫描一具尸体。

现代管道从笔记本电脑开始。这意味着清点运行在那里的代理和扩展，验证它们可以与哪些 MCP 服务器和模型对话，清理离开机器的内容，并在安装之前阻止恶意包。从那里，政策跟随工作进入 IDE。我们将安全标准直接注入代理的上下文窗口，因此生成的代码从第一刻起就保持在护栏内。管道仍然运行，执行对上游已经执行的控制的最终验证。

管道本身并没有消失。其角色变成了验证：确认上游的控制措施已经生效。

随着组织继续采用 AI 编码代理，它们必须在未来几年内做出哪些最关键的改变，以确保其开发环境保持安全?

最大的错误是只保护提交的内容。有趣的风险现在生活在提交发生之前的八个小时内。在笔记本电脑、提示或包安装上可能会发生未被看到的戏剧。如果您的工具从 PR 开始，您正在保护错误的工作流的一半。

密切相关：停止将编码代理视为生产力软件。它们是具有 shell 访问权限、存储库写入权限和出站网络连接的非人类用户。像对待任何其他特权身份一样管理它们，使用清单、批准的功能和审计日志。

最后的转变更难以在文化上实现。大多数当前的“AI 安全”工具会显示结果并将其路由到人类那里。人类无法以代理生成的速度进行分类。您采用的任何东西都必须在工作流中自动修复问题，具有可追溯的推理，否则它将成为没有人阅读的另一个仪表板。

感谢您接受这次精彩的采访，希望了解更多的读者可以访问 Boost Security。