8.0
热点
AI SCORE
技术实践2026-10-01 02:23
实测：LLM 能否检出自己帮忙泄露的 Supabase 密钥
dev.to · AI#安全#LLM评测#密钥泄露
Editor brief · 编辑速览
作者在三天内扫描 GitHub 公开仓库发现 60+ 个真实的 service_role 密钥，随后在 Kaggle 上建立基准测试，评估主流 LLM 识别这类凭证的能力。结果显示模型识别率参差不齐，AI 写代码和 AI 查漏洞的能力存在差距。
Kaggle Benchmarking Challenge 投稿
这是 Kaggle Benchmarking Challenge 的一个投稿作品。
我日常工作的一部分是扫描公开的 GitHub 仓库，查找被提交的 Supabase 凭据。在三天的扫描中，我发现了 60 多个仍在使用的 service_role 密钥——这类密钥完全绕过 Row Level Security，对真实的生产数据库拥有完整的读写权限。真实的发现包括：
这让我产生了一个疑问：泄露这些密钥的人经常在使用 AI 助手编写代码。AI 模型本身能否发现它们曾经协助提交的内容？于是我在 Kaggle Benchmarks 上构建了一个基准测试，把模型当作安全审查员来对待：给定一个真实的文件片段，进行分类——是否存在 service_role 密钥（严重）、anon 密钥（中危）、数据库密码，或者什么都没有（仅为占位符/文档）？
这 10 个案例都基于我实际发现的真实泄露模式（基准测试中的每个密钥都是假的、结构有效的 JWT）：
每个模型回答一个严格的 JSON 裁决（has_service_role、has_anon、has_db_password、warning_level、reasoning），任务对每个字段进行断言。得分为完全正确的案例比例。Temperature 为 0。每个参与者只能提交一次，所以这些案例必须足够有区分度。
从 Kaggle Benchmarks 套件中挑选了 9 个模型，覆盖了开发者实际选择的光谱——前沿旗舰模型、廉价/快速的主力模型，以及开源推理模型：
如果你的 AI 助手在上述列表中，这本质上就是在测试"我的助手能否发现它自己泄露的内容"。
核心结论：现代模型在明显案例上表现得出奇地好
在五个"经典"案例（硬编码配置密钥、包含凭据的文档、仅占位符的假阳性陷阱）上，每个前沿模型都拿到了满分。即便是廉价快速的 gpt-5.4-nano 也交出了 5/5 的答卷。如果你把一个包含 SUPABASE_SERVICE_ROLE_KEY=eyJ... 的文件粘贴给这些模型中的任何一个，问"这有问题吗？"，它们都会正确地告诉你：是的，严重，请轮换密钥。
有趣的是它们在哪些地方产生了分歧
DeepSeek-R1 是一个专门的推理模型，得分 0/10——但不是因为它漏掉了密钥。它把所有文件都标红了：每个文件，包括那个仅包含占位符的 DEPLOY.md，都返回了"严重，存在 service_role，存在数据库密码"。在安全分类中，如果一个审查员对每个文件都喊"严重"，那在真正重要的那个文件上他反而会被忽视。仅有召回率而没有精确率，就是多此一举的告警疲劳。
边缘案例充分发挥了作用。gpt-5.4-nano 恰好漏掉了两个隐蔽的案例：注释掉的"旧密钥保留供参考"（它把注释当作死代码——但注释中的秘密仍然有效，而且旧密钥经常会被轮换回来继续使用），以及 base64 混淆的密钥。前沿模型——包括廉价的 Gemini Flash 层级——全部捕获了全部 10 个案例，其中 Gemini 3 Flash 在回答过程中明显解码了 base64 blob 并识别出了 role claim。
这对实际工作的意义
你的 AI 助手不会替你防止秘密被提交——但它可以。测试的每个模型在被问到时都能即时捕获这些泄露。问题在于没有人去问。秘密之所以被提交，是因为审查步骤根本没有发生。
过度标记本身就是一种失败模式。一个审查员（人或者 AI）对每个占位符都喊"严重"，会让团队学会忽视所有告警。在安全分类中，精确率和召回率同样重要。
15 分钟的修复方案胜过任何检测器。在 Supabase 控制台轮换密钥（立即失效），迁移到环境变量，如果想从历史记录中清除就用 git filter-repo。
我接下来想测量的方向
工具调用：给模型一个仓库目录树和搜索工具，看看它们是主动搜寻秘密还是只评判粘贴的文件
多文件上下文：真实世界中的泄露版本分布在 config.php + 部署文档 + docker-compose——当秘密藏在两跳之外时，性能是否会下降？
修复质量：标记只是第一步；模型能否给出正确的修复方案（先轮换，再删除，再清理历史）？
在你自己应用上运行同样的检查
上述 10 个案例只是一个快照。你的代码库里会有你自己的版本。
我放了 9 个只读的 Postgres 查询，覆盖相同的失败类别到一个免费文件中——没有任何数据会离开你的数据库，你在自己的 SQL 编辑器里运行：github.com/cekuu35/supabase-rls-leak-demo - audit/rls-audit.sql
同一个仓库里还有一个红/绿测试套件，演示了跨租户泄露和单文件修复方案。
如果你想要完整的引导版本——写侧检查、角色模拟工具，以及可以直接丢进现有仓库的修复模板——那是 Supabase RLS Audit Kit。它完全针对你自己的目录表运行，$29。
声明：以上两个链接都是我自己的。审计查询和演示是免费的，采用 MIT 许可证。
任务：Kaggle 上的 committed-supabase-key-detection
任务页面展示了每个模型的逐个结果、完整对话记录，以及每个案例的断言分解。假密钥，真模式——可以拿走这些案例来构建你自己的审查清单。
（如果你正在阅读这篇文章，而你的仓库历史里正躺着一个被提交的 Supabase 密钥：现在就去轮换。这只需要 15 分钟，而且我保证你不是唯一一个见过它的人。）