跳转到主要内容
安全

Blockchain0x的安全性。

代理支付涉及真实资金。保护客户资金的架构选择、当前的审计状态,以及如果您发现问题如何与我们联系。

范围

您可以从此页面期待什么。

我们是一家早期公司,正在交付客户会托付支付权限的基础设施。信任建立在你能验证的内容上,而不是别人告诉你的内容上。本页面记录了客户和安全研究人员可以验证或据以要求我们遵守的四件事:即使其他判断都错了也依然成立的架构保证、我们当前的审计状态(包括尚未完成的部分)、漏洞披露政策的适用范围以及报告者实际获得什么(致谢,不是金钱),以及负责任披露的联系渠道。

What this page is not: a marketing surface designed to look maximally serious about security. We did not invent security certifications we do not hold, did not list "compliance" with frameworks we have not audited against, and did not put trust badges on the page that we did not earn. When we have a SOC 2 attestation or a third-party penetration test report, those will be referenced here with the auditing firm, the date, and the scope. Until then, this page says so plainly.

架构保证

四个由构造保持的属性。

以下保证是架构性的 - 它们是系统构建方式的属性,而不是操作方式的属性。操作安全可能会出现漏洞(密钥泄露、配置错误);架构保证不依赖于日常操作的完美。这些是您即使在最糟糕的操作周也可以依赖的安全故事部分。

平台层的非托管

Blockchain0x 不持有客户资金。钱包由代理拥有(或由客户连接的基础保管提供商拥有,如 Circle 可编程钱包或 Coinbase 智能钱包)。Blockchain0x 服务在这些钱包之上操作开发者界面 - API、仪表板、身份、支出政策 - 并且从不对余额拥有签名权限。

支出政策在服务器端强制执行,而不是在代理中

每日上限、每笔支付上限、对方白名单和时间窗口在每个支付意图结算之前由Blockchain0x钱包API进行评估。代理运行时无法访问政策存储;被注入提示的代理仍然无法提高自己的限制。

收据验证的支付确认

通过 API 显示的支付收据在确认之前会在服务器端与发行交易进行验证。客户端无法在本地伪造收据并将其作为支付证明;收据验证步骤与 Stripe webhook 签名使用的信任模型相同。

Webhook签名,而不是URL中的共享秘密

我们发出的每个Webhook事件都使用针对每个租户的签名密钥对原始主体进行HMAC-SHA256签名。签名密钥从不在URL或查询字符串中发送。客户在接收时验证签名;我们在文档中提供参考实现。

审计态势

老实说,我们今天在哪里。

The table below is the current state of external audits, third-party reviews, and certifications. We update this page when any line changes - dates are real, scopes are real, and "planned" means scheduled with a firm, not aspirational.

第三方渗透测试

计划于2026年第四季度

第一次外部渗透测试计划在下半年进行。范围:Web应用程序、公共API、Webhook表面、仪表板身份验证。完整报告摘要将在完成后发布在这里。

SOC 2 Type I

目标为2027年

我们目前没有进行SOC 2审计。诚实的预期窗口是2027年上半年;类型II将在6到12个月的观察期后进行。

智能合约审计

从上游继承

我们目前不运行自己的 smart contracts。链上 primitives 由 Circle Programmable Wallets、Coinbase Smart Wallet,以及底层的 Base / USDC contracts 构成,且这些组件都拥有发行团队各自独立的 audit reports。如果我们未来发布自己的 contracts(account-abstraction features),它们将在 mainnet deployment 前完成审计。

年度内部安全审查

进行中

季度秘密轮换、依赖扫描审查和访问控制审计。针对客户的预发布加固检查清单记录在我们的[安全您的代理钱包指南](/learn/guides/secure-your-agent-wallet)中;内部版本与之相似。

漏洞披露

我们不运行付费 bug bounty。

明确说明:Blockchain0x 没有 bug-bounty program,也不会为报告的漏洞支付任何金钱、crypto-assets、credits、swag 或其他任何补偿。这里没有严重程度分级,没有奖金区间,也没有任何讨价还价 - 任何告诉你相反说法的人都不是在转述我们的原话。我们宁可把这件事说得直白一些,也不希望研究人员在我们的系统上花一个周末,却期待一张并不存在的支票。

我们实际运行的是无偿的协调披露流程。报告会发送到我们的安全邮箱,并由人工阅读。我们会通过邮件确认每一份报告,而对于我们确认有效的发现,我们会提供一份负责任披露证书,并在你愿意的情况下,将你的姓名或 handle 列入我们的公开致谢名单。这就是我们目前提供的全部内容。如果未来有变化,这个页面也会同步更新。

在范围内

  • 控制台或 API 上的身份验证与会话管理。
  • 同一账户下不同 workspace 或 agent 之间的权限提升。
  • API 中的 server-side request forgery、command injection 或 remote code execution。
  • Webhook 签名绕过或回执验证绕过。
  • 可让代理绕过支出策略,在已配置的上限或 allowlist 之外转移资金。
  • 严重数据泄露(其他租户的交易、机密、审计日志)。

超出范围

  • Self-XSS 或要求受害者在自己的控制台中输入或粘贴恶意内容的攻击。
  • 依赖对员工或承包商进行社工攻击的报告。
  • 针对 Blockchain0x 集成的第三方服务(Coinbase、Circle 等)的报告 - 应提交给第三方自身的项目。
  • 针对测试端点的发现(`sk_test_` 密钥、`*.test.blockchain0x.com`、Base Sepolia)。
  • 缺少安全 header,但未证明其产生了影响。
  • 没有可运行 proof-of-concept 的理论问题。
报告者会获得什么详情
邮件确认每一份报告都会收到来自 [email protected] 的人工回复,无论该发现最终是否有效;等我们完成分诊后,也会告知结果。
负责任披露证书对于已确认、可复现且在范围内的发现:我们会发放一份签名证书,写明你的姓名(或 handle)、问题类别和披露日期。证书在修复上线后发出。
公开致谢在你同意的情况下,问题修复后你的姓名或昵称会被加入本页发布的致谢名单。如果你更希望匿名,也可以 - 直接告诉我们即可。前提是满足下方保密条款。
金钱奖励没有。我们不会为任何严重程度的已报告漏洞支付报酬,提交报告也不会产生任何付款权利。

有效性判断由工程负责人在与创始人沟通后作出,且为最终决定。致谢仅适用于范围内已确认、可复现的问题;同一问题若被多次报告,则以首位报告者为署名对象。提交报告不需要 NDA,以下条件是唯一附加条件。

认可所附条件

负责任披露证书和公开致谢都以你对报告保密为前提。不要在任何媒介中发布该漏洞、报告或其任何细节 - 包括复现步骤、概念验证代码、截图、受影响的端点,或我们就此事的往来通信。这里包括博客文章、技术说明、任何社交网络或论坛上的文字或图片帖子、视频、音频、播客、会议演讲、新闻简报、聊天群组,以及上述内容的 AI 生成衍生物。如果你希望在修复发布后再公开,请先联系我方,我们通常会以书面形式同意一个发布日期和披露细节程度。未经该书面同意而发布,将取消证书和致谢资格,并且我们保留可用的其他一切救济措施。

另外,且无一例外:任何以任何形式向我们勒索金钱或敲诈我们的行为 - 要求付款以扣留、延迟或删除报告,威胁除非我们付款就发布或出售发现结果,或以带有威胁的期限向我们施压 - 都不属于安全研究。我们不会支付。此类行为将严格按照适用法律处理,包括向执法机构报告并全力配合随后可能发生的调查或起诉。善意研究人员无需担心;这一段并不是针对你。

公开致谢

在修复发布后,报告已确认漏洞并要求署名的研究人员会按最新优先列在这里。目前还没有人上榜 - 如果你是第一位,我们会在这里注明你的姓名或昵称以及报告月份。这里的列出信息受上述保密条件约束。

负责任的披露

如何报告安全问题。

请发送邮件到 [email protected],内容包括:问题描述、逐步复现步骤、受影响的 URL 或 endpoint、你观察到的影响,以及你希望写在证书和致谢列表上的姓名或 handle(handle 就够了,不需要真实姓名,也可以要求匿名)。欢迎提交加密报告 - 可按需提供我们的 PGP key。

我们承诺在两个工作日内确认收到你的报告,在五天内完成分流和初步分级,并在三十天内针对已确认问题发布修复或作出风险接受决定(关键问题会更快)。对于遵守负责任披露规范的善意安全研究,我们不会采取法律威胁 - 仅在证明问题所需的最小范围内暴露数据,不导出客户数据,不运行会影响生产用户的破坏性测试,并且在我们就何时以及如何发布达成书面一致前,不发布该发现。

对于非安全问题(一般支持、账单、合作伙伴关系),请使用/contact。安全电子邮件仅监控安全报告。

事件沟通

如果出现问题,我们会说什么。

影响客户资金、客户数据或支付API可用性的生产事件将在解决后的三十天内进行公开事后分析,无论严重性如何。较小的事件(性能下降、部分区域故障)通过状态更新通知受影响的客户,但不一定会进行事后分析。

我们在事后分析中不责怪客户。如果根本原因是我们的,我们也不责怪第三方供应商。我们清楚地列出根本原因,列出我们因此而改变的内容,并将事后分析保持可用状态。客户应该有的期望是,我们会在您询问之前告诉您发生了什么。

安全联系

漏洞报告:[email protected]。PGP key 可按需提供。报告会收到确认,但不支付报酬。