北京
BrassCoders在分析中指出：“你让AI生成的.env.example文件里的秘密，在下游攻击者看来就是真正的密钥。”这家安全工具开发商目前可检测约20种规范秘密格式，包括AWS访问密钥、GitHub个人访问令牌、OpenAI密钥、Stripe实时密钥、JWT令牌、PEM编码私钥、Anthropic密钥、Slack令牌、NPM认证令牌、SendGrid密钥、Mailgun密钥、DigitalOcean令牌和Twilio凭据等，并用高熵回退机制捕捉尚未编目的格式。
之所以需要这样一套检测能力，是因为AI编程助手在生成配置文件、示例脚本和测试夹具时，经常输出与真实密钥高度相似的字符串。大模型在训练中见过数百万个代码示例，自然也见过数百万个嵌入其中的API密钥、令牌和密码；如果在生成时缺少显式的安全策略，模型就会把凭据形态的字符串当作一种合理的占位填充，产生的“假凭据”对自动扫描工具而言几乎无法区分。
BrassCoders把这种内嵌秘密的幻觉视为已知的AI故障模式，并归纳出三类高发上下文。第一种是示例代码生成：当开发者要求AI给出“Stripe + SendGrid + AWS配置的.env示例文件”时，模型会输出以sk_live_开头的Stripe密钥、以SG.开头的SendGrid密钥和以AKIA开头的AWS访问密钥。这些密钥语法完全正确，初级开发者可能在未察觉的情况下就直接提交，而AI生成的凭据足以骗过安全自动化。第二种是测试夹具生成：要求AI“编写一个验证认证的测试”，模型会凭空造出一个JWT令牌、一段PEM编码的RSA私钥或一个会话Cookie值，它们通常高熵且结构正确，被当作“测试数据”提交后，几周后就会触发安全扫描告警。第三种是补全上下文泄露：如果编辑器会话中同时打开着真实的.env文件且AI拥有上下文，补全操作就可能借鉴邻近的内容生成凭据形态字符串，有时候仿照真实的凭据稍加变异，看上去依然逼真——这类模式在GitGuardian年度《Secrets Sprawl》报告中已被列为导致公开仓库秘密泄漏增长的因素之一。
面对这种结构性风险，BrassCoders提出的缓解措施是：扫描每一处代码差异，检查其中是否包含凭据形态的字符串。其方案结合了约20种已知格式的精确匹配，以及基于熵值的回退检测，能发现尚未编目的格式；同时采用双重边界脱敏机制，确保检测器自身不会成为新的泄漏面。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
