Rubrik Code Guardian 扩展 Project Hourglass，但其安全声明面临现实检验

Rubrik 于 10 月 9 日推出 Rubrik Code Guardian，将 Project Hourglass 的能力从运行时控制扩展至检查代码仓库中的可利用攻击链。据该公司称，这项处于私有预览阶段的服务在隔离测试环境中使用 Anthropic 模型。它瞄准了软件开发中日益加剧的矛盾：AI 编程工具提升产出，而安全团队难以以同样速度审查这些产出。

此次扩展使 Rubrik 更接近应用安全市场；在这一市场中，扫描工具早已能够在部署前标记存在漏洞的代码。Rubrik 作出了不同的承诺。Code Guardian 并非再生成一长串可能的缺陷，而是旨在关联文件、服务、身份和云边界之间的弱点，并优先处理可能造成实质性业务损害的路径。

这种方法也为 Project Hourglass 带来了核心考验。AI 系统能够跨大型代码仓库进行推理，但企业仍需要证据证明其发现准确、可复现，并且比它所审查的代码更安全。Code Guardian 尚未正式全面推出，Rubrik 也明确表示，其功能和性能仍可能发生变化。

Rubrik Code Guardian 将 Project Hourglass 延伸至代码库

Project Hourglass 正从在运行时控制编程智能体，扩展为审查这些智能体协助产出的软件。

Rubrik 最初推出 Project Hourglass，是为了帮助全球系统集成商围绕 Anthropic 的 Claude Code 部署 Rubrik Agent Cloud。最初的架构聚焦于 AI 编程智能体在运行期间的行为。

其控制措施包括行为护栏、提示上下文保护以及 Agent Rewind。Rubrik 将 Agent Rewind 描述为一种撤销智能体非预期操作的方式。这些功能旨在应对这样一种运营风险：允许软件智能体读取文件、修改代码仓库、调用工具并与企业系统交互。

Rubrik Code Guardian 增加了第二层能力。它会在气隙环境中检查客户源代码仓库的克隆副本，这意味着该副本与生产系统和外部网络隔离。Rubrik 表示，这种设计让团队能够开展高强度安全测试，同时避免使在线应用或敏感源代码面临不必要的运营风险。

根据该公司的 Code Guardian 发布公告，该系统通过专用安全框架使用 Claude Mythos 5。该模型旨在推理多步骤威胁场景，而非将每个文件作为独立单元进行检查。

这一差异十分重要，因为危害性漏洞往往源于多个原本看似不严重的弱点组合。某项服务可能接受不安全输入，某个身份角色可能拥有过多权限，而某项云资源则可能通过被忽略的路径被访问。传统工具可能会分别报告这些情况，却无法说明攻击者会如何将它们串联起来。

Rubrik 表示，Code Guardian 将跨源文件、服务、身份角色和云边界查找此类攻击链。随后，它会测试可疑路径是否确实可被利用，并按业务重要性对发现进行评分。

其目标并不只是发现更多告警，而是通过帮助工程团队判断哪些告警值得立即关注，来减少告警疲劳。

这标志着 Rubrik 安全定位的重要转变。该公司传统上强调数据韧性、受保护备份以及遭受攻击后的恢复能力。Code Guardian 将其介入点前移至软件生命周期更早阶段，即易受攻击的应用进入生产环境之前。

Project Hourglass 也正成为更广泛的交付联盟。AHEAD、Trace3 和 World Wide Technology 加入了现有参与者 Cognizant、Deloitte、LTM、HCLTech、NTT DATA 和 Wipro。这些合作伙伴能够帮助企业评估架构、运行受控测试，并将该技术纳入现有开发和安全流程。

Rubrik 在印度果阿举行的 GSI Summit 上宣布了这一扩展。地理地点不如交付模式重要。大型企业通常通过系统集成商购买安全方案，而不是通过由单个开发团队管理的孤立产品试用来采购。

因此，合作伙伴可能决定 Rubrik Code Guardian 会成为一项运营控制措施，还是停留在有趣的私有预览演示阶段。他们需要将其结果与工单系统、软件流水线、身份控制及现有应用安全工具连接起来。

私有预览标签为这项公告设定了明确限制。Rubrik 表示，该服务以“现状”基础向选定的设计合作伙伴提供。它尚未全面可用，且公司不保证每项所述能力都会进入商业版本。

这一限定是报道的核心。Rubrik 勾勒出了一套雄心勃勃的架构，但客户目前尚无法通过大规模部署数据、独立基准测试或稳定的生产版本来评估它。

为什么 AI 代码安全正成为企业瓶颈

压力源于自动化代码生成与人工安全审查之间不断扩大的速度差距。

AI 编程助手可在数分钟内生成功能、测试、配置文件和基础设施代码。这种速度改变了开发的经济性，却并未消除审查需求。相反，它可能增加安全团队必须在发布前评估的代码量。

风险并不在于每个 AI 生成的函数都含有漏洞。问题在于，看似合理的代码可能通过快速的视觉审查，同时保留了对权限、输入、依赖项或系统边界的不安全假设。

Veracode 在 2025 年的一项评估报告称，受测模型在其任务结果中有 45% 引入了可检测的 OWASP Top 10 漏洞。该公司的 代码安全研究 使用了受控编程任务，其中实现方式可能遵循安全或不安全模式。

这一数字不应被视为所有生产软件的漏洞率。受控任务与持续维护的企业代码仓库不同，结果还取决于编程语言、提示词、模型及测试方法。不过，该研究说明了为何功能正确性不能替代安全验证。

风险还延伸到生成的源代码之外。编程智能体可以访问代码仓库、终端、问题跟踪器、包管理器和部署工具。嵌入检索内容中的有害指令可能误导权限过高的智能体，而普通失误也可能扩散至许多文件。

OWASP 将过度自主权描述为一种情形：模型被赋予不必要的功能、权限或自主性。其 过度自主权指南 建议限制工具访问、最小化权限、对具有重大后果的操作要求批准，并在执行前验证输出。

这些控制措施聚焦于智能体被允许做什么。Code Guardian 则处理一个相关但不同的问题：在人类和智能体共同贡献后，代码库中存在哪些安全弱点？

Rubrik 引用其自身的 Zero Labs 研究来说明紧迫性。该公司表示，86% 的受访网络安全和 IT 领导者预计，AI 智能体的采用速度将在一年内超过其组织的安全护栏。由于该数字来自 Rubrik 的研究，读者应将其视为客户担忧的证据，而非 Code Guardian 有效性的独立证明。

更广泛的担忧已有充分依据。自主智能体能够使用机器身份、凭证和工具权限运行，也能以快于人工逐步审查的速度完成一连串操作。

这使软件代码仓库只是攻击面的一部分。安全团队还必须保护模型上下文、智能体权限、生成的代码、部署流水线，以及失败操作可能影响的数据。

Project Hourglass 现在尝试覆盖其中多个层面。Rubrik Agent Cloud 聚焦智能体行为和恢复。Code Guardian 聚焦代码仓库分析与攻击链发现。若预防和运行时控制失效，Rubrik 现有的韧性产品则提供恢复层。

这种端到端定位在商业上颇具吸引力，但也带来了整合问题。企业已经在使用静态应用安全测试、软件成分分析、密钥检测、云安全态势工具和人工渗透测试。

Code Guardian 必须证明，它能高效提供这些产品无法提供的价值。发现一个假设性的弱点并不足够。该服务需要解释攻击者如何到达该弱点、哪些资产会因此暴露，以及为何该发现应优先于其他修复工作。

这正是 AI 代码安全成为优先级排序问题的原因。若扫描器在不改善决策的情况下将告警数量翻倍，反而会拖慢安全计划。有效的推理系统必须减少不确定性，而不只是生成更长的报告。

对工程负责人而言，眼前的启示很务实。更快的代码生成要求在代码仓库、身份和运行时层面实施更强控制。团队还需要保留架构决策、威胁假设和修复工作的持久记录。

可搜索的工程知识库可以在安全、开发和运维团队之间保留这些上下文。它不能替代代码测试，但能帮助审查人员理解敏感组件为何以特定方式设计。

Project Hourglass 让攻击链推理与告警数量正面交锋

Rubrik 的核心押注是，AI 在确定现实攻击路径的优先级方面，能够优于孤立审查弱点的工具。

传统静态分析在不执行应用的情况下评估源代码。它可以识别已知的不安全模式，例如未净化的输入、危险函数调用或薄弱的加密选择。软件成分分析则检查外部软件包及依赖项中的已知漏洞。

这些方法仍然不可或缺，因为它们可重复、为人熟悉，并适用于自动化开发流水线。然而，它们可能产生误报，或生成缺乏业务上下文的孤立发现。

无法访问的测试组件中的警告，与面向互联网的身份验证服务中可被利用的缺陷，风险并不相同。然而，除非由人工或其他系统重建周边架构，否则两者可能出现在同一待处理队列中。

Rubrik Code Guardian 旨在完成更多这类重建工作。该公司表示，其模型能够跨文件和服务进行推理，纳入身份关系，并考虑云边界。预期生成的输出将描述一条攻击链，而非彼此脱节的缺陷。

设想这样一个企业应用：它存在三处薄弱环节。某个 API 接受了验证不充分的参数。一个服务身份可以读取敏感存储桶。一项后台工作程序信任来自该 API 的消息。

文件级扫描器可能会生成三张工单。而攻击链分析则会追问：攻击者能否利用参数缺陷控制一条消息、触发工作程序、继承服务身份，并最终访问存储桶？如果这一链条能够在隔离副本中成立，安全团队就能更清晰地确定修复优先级。

这正是 Rubrik 业务影响主张背后的机制。模型的价值并不只是能阅读更多代码；只有当它能区分可信的攻击链与理论上的组合，并向人工审查人员解释结论时，才真正具备实用价值。

Anthropic 已将模型辅助漏洞发现展示为高级编程模型的一项防御性用途。2026 年 2 月，该公司表示 Claude Code Security 已在生产环境中的开源项目里发现了 500 多个漏洞。其安全研究公告描述了一套结合模型分析、人工审查和协调披露的流程。

Anthropic 还发布了一个漏洞仪表盘，用于记录经过外部分类和维护者审查后的发现。这一工作流很重要，因为模型的初步怀疑并不等同于已确认的漏洞。

Rubrik 正将这种通用能力带入受控的企业环境。Code Guardian 的目标并非扫描公开的开源代码库，而是通过参与合作伙伴审查客户的私有代码。

气隙隔离克隆可带来两项潜在优势。第一，它可以降低专有代码泄露到外部服务或触及在线生产系统的风险。第二，它让测试过程能够在不影响客户或业务运营的前提下进行更积极的探测。

隔离并不能解决所有安全问题。企业仍需要了解代码库副本如何创建、模型推理在何处进行、结果如何保留，以及哪些合作伙伴人员能够访问发现结果。

“气隙隔离”一词也可能涵盖不同的技术安排。物理隔离环境、严格受限的私有云和逻辑隔离网络提供的保障并不完全相同。Rubrik 的公开公告没有提供足够的架构细节，无法比较这些模型。

竞争的考验将集中在证据质量上。成熟的应用安全厂商可以在现有扫描器中加入 AI 解释和上下文排序。云安全厂商则可以借助生产遥测数据，关联身份、服务和可访问资产。

Rubrik 带来的则是不同的资产。它在受保护企业数据、恢复工作流和网络韧性领域拥有客户关系。Project Hourglass 还为其带来了系统集成商合作伙伴，能够将代码分析与更广泛的基础设施决策结合起来。

Rubrik 战略最强的版本会将这些资产结合起来：Code Guardian 识别攻击链，Agent Cloud 约束智能体行为，而 Rubrik 的恢复控制则在事件发生后恢复受影响的代码或数据。

较弱的版本则只是增加了一个充斥重叠告警的控制台。私有预览客户需要判断自己看到的是哪一种结果。

最难的部分：验证 AI 审查者

由 AI 系统审查 AI 辅助编写的代码，会形成一个无法仅凭模型置信度解决的验证闭环。

Rubrik 表示，Code Guardian 将验证发现是否具备实际可利用性。这一主张比识别可疑模式要求更高。可利用性取决于配置、部署状态、可达输入、身份权限和环境控制。

克隆的代码库可能并不包含复现生产环境所需的全部事实。基础设施设置可能位于独立系统中。运行时身份可能与声明的角色不同。网络策略也可能在克隆创建后发生变化。

这意味着，系统识别出的攻击路径在逻辑上可能自洽，却依然无法在生产环境中实现。相反的问题同样存在：以代码库为重点的测试，可能会遗漏由运行时漂移、未记录的集成或遭入侵的凭据造成的危险路径。

因此，私有预览试验衡量的不能只是发现问题的数量。还应跟踪已确认的可利用攻击链、被否决的发现、重复告警、验证耗时、修复耗时，以及系统遗漏的缺陷。

独立比较将尤为重要。设计合作伙伴应将 Code Guardian 与现有扫描器和渗透测试流程并行运行。这样才能建立基线，判断该服务发现的是独有风险，还是仅仅重新包装了已知发现。

安全团队还需要可复现的证据。一份有价值的报告应识别相关代码路径、所需权限、前置条件、受影响资产，以及用于验证该攻击链的步骤。审查人员必须能够质疑模型的推理，而不必接受黑箱式风险评分。

Rubrik 尚未公布有关误报率、漏报率、代码库覆盖范围、分析时间或漏洞类别的基准结果。其公告也未披露，在大型单体代码库或较少见的编程语言中，性能会如何变化。

对于早期预览而言，这些缺失可以理解，但也限制了企业能够得出的结论。Code Guardian 是一种拟议中的安全控制措施，而不是已经过独立验证、可替代现有应用安全测试的方案。

底层模型还带来了另一种集中风险。Rubrik 正依赖 Anthropic 技术检查可能由 Claude Code 或其他 AI 助手创建的代码。能力强大的模型仍可能与生成代码的系统共享盲点。

模型多样性不会自动解决这一问题，但独立的测试方法能够有所帮助。确定性扫描器、人工渗透测试人员、运行时观察和不同模型，均可对不同假设提出挑战。

OWASP 更广泛的智能体安全框架将智能体系统视为模型、工具、身份、记忆和外部服务的组合。这一视角表明，不应依赖任何单一自动化审查者。

这里还存在治理问题。只有获得关于业务重要性的准确信息，模型才能将某条路径标记为业务关键。仅凭代码库，未必能看出哪项服务处理受监管数据、支持重要客户，或控制关键运营工作流。

合作伙伴需要提供这些背景信息。这要求应用负责人、安全团队、云管理员、身份团队和业务领导者之间协作。

系统集成商能够协调这些群体，这也有助于解释 Rubrik 的联盟优先战略。然而，如果实施实践存在差异，由合作伙伴主导的交付可能产生不均衡的结果。认证和直接工程支持或许能减少这种差异，但 Rubrik 尚未公布运营结果数据。

公司的恢复定位同样值得审视。即时代码库恢复可以在发生非预期变更后还原已知良好的文件，但恢复代码并不会自动逆转所有后果。

遭入侵的智能体可能泄露机密、触发外部交易、改动第三方系统，或修改生产数据。这些影响需要超出代码库回滚范围的事件响应。

因此，应将 Project Hourglass 评估为分层控制，而非某种保证。护栏可以减少危险操作；代码测试可以发现脆弱路径；恢复可以限制损害。它们都无法消除最小权限访问、人工审批、安全开发实践和事件规划的必要性。

这正是核心权衡。AI 推理能够审视基于规则的工具难以关联的关系，但推理本身也需要验证。只有当验证负担小于被自动化的问题时，企业才能真正获得速度优势。

Rubrik Code Guardian 现在需要通过三项考验

接下来的证据必须来自部署结果、独立比较和定义清晰的生产架构。

第一个信号是设计合作伙伴成果的质量。AHEAD、Trace3、WWT 以及现有的 Project Hourglass 参与者，能够接触到拥有复杂代码库和成熟安全项目的企业。

最有价值的结果不会是宣称发现了“更多”风险的宣传表述。买家需要看到匿名案例：现有工具遗漏了哪些攻击链、Code Guardian 如何验证这些攻击链，以及团队完成修复的速度。

已确认的发现将强化 Rubrik 关于基于模型的推理能够改善优先级排序的论点。高否决率或庞大的审查工作量则会削弱这一论点。

第二个信号是从私有预览走向正式发布的路径。Rubrik 当前版本明确警告，Code Guardian 可能会发生变化、延迟推出，或者永远不会正式发布。

生产版本应明确支持的语言、代码库规模限制、部署模式、数据处理方式、模型更新政策、保留控制，以及与开发流水线的集成方式。它还应说明客户如何审计测试期间采取的操作。

正式发布本身并不能证明有效性。然而，稳定的文档和合同层面的安全承诺，将表明 Rubrik 已准备好超越受控实验阶段。

第三个信号是竞争对手的反应。应用安全和云安全厂商已经拥有代码扫描器、漏洞数据库、依赖情报和生产环境上下文。它们有明确动力加入智能体攻击链分析。

如果这些厂商通过客户已在使用的工具提供可比的推理能力，Rubrik 就需要通过恢复、隔离或合作伙伴交付来实现差异化。如果竞争对手难以将代码与身份及业务影响关联起来，Project Hourglass 将获得更强的切入机会。

Anthropic 自身的安全产品也是另一个参考点。Claude Code Security 表明，这家模型提供商将漏洞发现视为直接的产品类别。Rubrik 必须说明，其安全测试框架、企业上下文和恢复架构如何在获得底层模型能力之外进一步创造价值。

在将 Rubrik Code Guardian 视为成熟控制措施之前，开发人员和企业买家都应关注这些信号。该公告识别了一个真实问题，并提出了可信的机制，但证据仍处于初步阶段。

对于开发团队，实际的应对措施不应等待某一家厂商发布产品。应盘点编程智能体的运行位置，限制其凭据，记录具有重要后果的变更，并为敏感操作保留人工审批。即使已有 AI 审查者，也应继续使用确定性扫描器和独立测试。

安全负责人还应提出一个更棘手的问题：新工具是否缩短了从发现问题到完成验证修复的路径？一个能够发现复杂攻击链却让审查人员不堪重负的系统，并没有解决运营瓶颈。

如果 Project Hourglass 能将模型推理转化为工程师可以据此行动的可重复证据，Rubrik Code Guardian 就将具有重要意义。它的私有预览是这项检验的开始，而不是结果。未来几个月，买家应关注已验证的攻击链、透明的错误率，以及能够保护被检查代码的生产架构。