赛义德·阿尔·哈马尼，Boost Security 的 CEO 和创始人 – 采访系列

赛义德·阿尔·哈马尼，Boost Security 的 CEO 和创始人，是一位拥有二十多年经验的网络安全和 DevSecOps 领导者，曾经建设和扩展过全球技术运营。自 2020 年创立 Boost Security 以来，他专注于现代化组织的软件开发安全，利用之前在 Trend Micro 的应用安全副总裁和 IMMUNIO 的联合创始人兼 CEO 的经验。早期，他曾在 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 密钥，该密钥是代理从 sibling 目录中一个半遗忘的 .env 文件中抓取的。

您只需通过在提示离开笔记本电脑之前检查提示来捕获它，这正是几乎没有安全堆栈当前所在的位置。

您提到了机器速度的供应链攻击。可以带我了解一个现实场景，AI 代理引入了漏洞，传统安全工具无法及时识别它吗？

这里有一个我们反复看到的例子。开发人员要求代理添加一个需要 HTTP 重试库的功能。代理建议一个包名。该包名听起来很合理，但实际上在 npm 上不存在。在一小时内，攻击者注册了它，用有效的重试逻辑填充了它，并添加了一个在安装后读取 ~/.aws/credentials 并将其发布到 webhook 的小脚本。代理在没有检查的情况下运行 npm install，因为代理不检查声誉。凭据在开发人员甚至运行代码之前就已经泄露了。

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

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

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

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

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

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

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

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

管道本身并没有消失。其角色变成了验证：确认上游的控制措施得到了执行。

随着组织继续采用 AI 编码代理，为了确保开发环境在未来几年内保持安全，他们必须做出的最关键的改变是什么？

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

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

最后的转变更难以文化适应。大多数当前的“AI 安全”工具会将发现的内容呈现给人类，并将其路由到人类。人类无法以代理生成的速度进行分类。您采用任何东西都必须在工作流中自动解决问题，具有可追溯的推理，否则它将成为另一个没有人读的仪表盘。

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