平台
面向严肃 AI 软件交付的安全测试
每一项发现在到达你手上之前,都已在运行中的应用上被确认过——所以这份仪表盘展示的是真实风险,而不是扫描器噪音。
Ciao Security 是平台的应用安全层:静态扫描、依赖项检查与访问控制探测,每一项漏洞在被标记之前都会先在真实应用上得到确认。与那些让团队淹没在大量误报中的原始扫描器输出不同,Ciao 会针对运行中的应用核实每一项发现,并将结果汇总进一份可安全发布仪表盘——团队据此在应用确实安全时才发布。
发布日期 2026-07-03 · 最近更新 2026-07-03
能采取行动的发现,而不是扫描器噪音
应用安全工具存在一个诚实性问题:扫描器会产出成百上千条发现,其中大多数并不重要,团队因此学会了忽略这份报告。与此同时,AI 辅助开发提高了风险的赌注——更多变更、更大的攻击面、访问规则悄悄被削弱的机会也更多。
Ciao Security 与你的注意力订立了一份不同的契约:静态扫描、依赖项检查与访问控制探测持续运行,每一个候选漏洞在被标记之前,都会先在真实应用上得到确认。到达仪表盘上的,都是真实的。
这个页面介绍的是内建于每一个 Ciao 项目中的安全测试。关于 Ciao 作为供应商自身的安全状况——SOC 2 Type II、SSO、数据处理、零保留期模型合约——请参阅安全与合规概览页面。
Security 是如何工作的
安全测试在交付闭环内部持续运行,而不是一个季度一次的活动。
1. 每次变更都进行静态扫描
代码在被编写的同时就被分析——不安全的模式、注入风险与危险的写法,在变更发生的当下就被捕捉到,而不是等到年度审计。
2. 依赖项检查
第三方软件包会被检查是否存在已知漏洞,因此大多数应用中风险最高的代码——团队里没人写过的那部分代码——也会被关注到。
3. 访问控制探测
探测会尝试攻击者会做的事情:跨租户边界读取数据、以普通用户身份调用管理员接口、访问本应要求身份验证的路由。
4. 标记之前先做实时确认
候选问题会先在运行中的应用上被确认,然后才会被标记,从而把可证实的风险,和理论上的噪音区分开来。
5. 可安全发布仪表盘
一个视图回答那个发布相关的问题:这个应用现在能安全发布吗?绿色反映的是已确认的证据,而不是没做过扫描。
6. 修复方案回流进闭环
已确认的发现会附带草拟好的修复方案,并按照每一次变更本该走的方式发布——通过 Builder、按政策要求的 Guardrails 审核、以及 QA 关卡。
为什么这很重要
一项在真实应用上确认过的发现,会改变整个对话的性质。它不再是“扫描器说这种模式可能有风险”,而是“这个请求,针对你正在运行的应用,返回了本不该返回的数据”。团队会去修复这类问题。
而且因为这些检查在交付闭环内部运行,安全能跟上开发的节奏,而不是几个月后才来审计。可安全发布仪表盘让发布决策变得明确:绿色是证据,而不是乐观的猜测。
实时确认还改变了谁能对安全问题采取行动。一项附带证据的已验证发现,不需要安全工程师来解读——负责这个项目的人就能看清发生了什么,并通过审核发布草拟好的修复方案。专业知识依然重要,只是它不再是每一次修复的瓶颈。
谁在使用它
可安全发布仪表盘对不同的读者意味着不同的东西。
- 没有安全职能的团队 — 大多数构建内部工具与门户网站的团队都没有 AppSec 工程师。他们依然获得了持续的测试,发现的问题也早已被验证。
- 向受监管买家销售的工程管理层 — 安全问卷可以用来自运行中产品的证据来回答,而不是来自一份政策文件的美好愿景。
- 代理机构 — 每一个客户应用都被测试到同一标准,“它安全吗”这个问题背后有一个仪表盘作支撑。
- 安全团队 — AI 构建的应用常常是一处盲区。Ciao 让它们持续接受实时验证的标准检验,团队可以随时查阅。
安全与治理说明
- ✓ 静态扫描、依赖项检查与访问控制探测在每个项目上运行。
- ✓ 漏洞在被标记之前会先在真实应用上得到确认。
- ✓ 可安全发布状态在单个项目和 Conductor 中的整个 Fleet 范围内均可见。
- ✓ 发现的问题及其修复方案会被记录进只增不减的审计日志。
- ✓ Supabase 后端中的行级安全会被访问控制探测实际检验。
- ✓ 身份验证与权限发生变更后,探测会重新运行,让回归问题尽早浮现。
- ✓ 供应商侧的合规情况——NDA 下的 SOC 2 Type II 报告、SSO、零保留期合约——在安全概览页面中说明。
原始扫描器输出 vs 实时确认的发现
区别在于哪些内容你可以不经分诊就直接信任。
| 典型扫描器报告 | Ciao Security | |
|---|---|---|
| 数量 | 每次运行成百上千条发现 | 经过真实应用确认的发现 |
| 误报 | 需要你自己去分诊 | 未经确认的候选项不会卡住发布 |
| 访问控制 | 在代码中做模式匹配 | 在运行中的应用上被实际探测 |
| 发布决策 | 凭一份 PDF 做的主观判断 | 可安全发布仪表盘 |
| 修复路径 | 进入待办事项列表的一张工单 | 经过审核与 QA 关卡的草拟修复方案 |
常见问题
这和 /security 页面有什么不同?
那个页面介绍的是 Ciao 作为供应商自身的情况——NDA 下的 SOC 2 Type II 报告、经 SAML 与 OIDC 实现的 SSO、审计日志、零保留期模型合约。这个页面介绍的是平台对你的应用做了什么:扫描、探测并确认漏洞,让每一次发布都能被证明是安全的。
实时确认具体涉及什么?
候选发现会在运行中的应用上被实际执行验证。一次跨租户读取尝试要么返回了数据,要么没有;一次未经身份验证的请求要么到达了那条路由,要么没有。确认会在要求任何人采取行动之前,把一种模式变成一个事实。
这能取代渗透测试吗?
它并不这么声称。持续的、实时确认的测试提升了日常的安全底线,并能在正式的安全评估之间捕捉到回归问题。有合同或监管要求的团队通常仍会定期委托渗透测试——两者是互补的。
当一个真实漏洞被确认后会发生什么?
它会连同确认它的证据一起出现在仪表盘上,并附带一份草拟好的修复方案。修复会按正常闭环发布——按政策要求经过 Guardrails 审核、发布前经过 QA 关卡——审计轨迹会把发现与其解决方案一并记录下来。
我们的安全团队想评估这个功能,该从哪里开始?
预约演示,带上你们的问卷。SOC 2 Type II 报告可通过合规通道在 NDA 下获取,严肃的生产项目起价为每年 10,000 美元。