我要投稿

AI助力！明文密码泄漏无处遁形【大模型应用实践系列二】

发布日期：2025-04-28 20:59:45 浏览次数： 1644

作者：腾讯安全应急响应中心

微信搜一搜，关注“腾讯安全应急响应中心”

‍

随着大模型技术的崛起，为行业提供了突破安全防护新高度的可能性。在我们的探索之旅中，大模型技术已被引入到安全领域的多个垂直应用中，我们将其沉淀成一系列关于大模型应用实践的文章。作为本系列的第二篇，本文聚焦于密钥硬编码的问题，分析了传统检测策略的缺陷，并详细介绍了大模型在该场景下的优势、检测实施方案和效果。我们将继续推出更多关于大模型在研发安全、网络安全、威胁情报等领域的应用探索与总结，敬请期待，欢迎持续关注本公众号。

2024年1月，一位开发者在浏览代码时，意外发现了一串神秘的认证密钥，这串密钥似乎能打开某个公司内部的宝库——源码仓库。这可不是小事，因为黑客通过这串密钥能解锁的不仅仅是代码，还有可能是数据库连接、云访问密钥、设计蓝图、API密钥等关键企业敏感信息...经细查这串密钥来自一名车企员工，他在代码中无意识嵌入了自己的明文密码，导致本次泄漏事件。此事惊心点在于密钥在23年9月29日就已泄漏，该公司的GitHub Enterprise Server可能在未察觉的情况下，暴漏在公网上长达3个多月才修复...

硬编码密钥：泄露速度快，被利用后风险高

注：密钥硬编码指的是在源代码中直接嵌入明文的密码或其他敏感密钥信息，如SSH密钥，API密钥等。密钥硬编码泄露是各公司面临的重大安全威胁之一，其风险量级一直居高不下，是其他风险总和的数倍。

腾讯啄木鸟代码安全团队依托混元大模型强大的代码语义理解和语言泛化能力，在密钥硬编码泄露检测场景，实现高检出和低误报，让业务聚焦于有效密钥硬编码泄露风险，提升业务风险处置效率。

部分开发者在开发和测试阶段为了提高效率，无意之中将敏感密钥明文直接嵌入在代码里。然而，一旦代码库遭泄露，敏感密钥可能被恶意利用来窃取对应资源。相比其他安全漏洞（如SQL注入、命令注入等），密钥泄露利用简单且迅速，从被发现到被利用的时间极短，极大地增加了系统被非法入侵和数据泄露的危害。例如，近期Clutch Security的研究人员进行了一项测试，发现泄露到GitHub的AWS 密钥在几分钟内就被攻击者利用。

以AK/SK（Access Key ID/Secret Access Key）密钥为例，云服务提供商使用AK/SK进行身份验证和授权，其泄露后果严重，原因在于：

1）广泛攻击面：云资源公开暴露，AK/SK可直接访问，增加攻击面。

2）即时利用：泄露后可立即使用，无需复杂登录验证。

3）匿名性：攻击者可匿名利用AK/SK，难以追踪。

4）广泛影响：泄露后可访问各类云资源，潜在破坏严重。

图1 敏感帐密泄露危害

密钥硬编码泄露的解决难点

密钥硬编码泄露风险在实际运营和工单处置中痛点较多，给业务和安全运营均带来巨大的挑战。

1）"量级大"：高误报导致用户处置成本高

据统计，2023年Github开源仓库中敏感帐密明文硬编码数量达到12,778,599，比2022年增长28%！更糟糕的是，有的用户需要处理多达上千条帐密告警工单，简直让人眼花缭乱，压力山大。

然而，传统的密钥硬编码检测策略效果并不理想，误报率高。这意味着，在你努力修复那些真实的安全风险时，还要花费大量时间和精力去应对那些千奇百怪的误报。有时候，甚至需要联系人工客服，逐一确认这些误报信息。这不仅耗时耗力，还严重影响了开发同事的工作效率。

图2 用户面对大量密钥硬编码风险困扰

2）"规则太细"——漏水多，业务帐密明文检测需求适配性差‍‍‍‍

正则表达式用于精确匹配帐密明文时，虽准确但易漏报。因规则匹配的密钥模式太严格，策略运维需不断人工补充新规则，由于事先无法穷举易引发漏报。

// 泄露敏感帐密的代码private static final String db_key = "jdbc.data_db.password";env.setProperty(db_key, "password@123456");

上面所述案例是一个人工看起来很明显但检测策略却极易漏水的密钥明文风险。

一眼就能发现是密钥，为什么会漏水呢？仔细分析可知，大多数敏感帐密硬编码检测是基于固定规则，当代码出现规则之外的硬编码逻辑时，就会导致漏水。以知名的密钥硬编码开源检测工具detect-secrets为例，其基于关键字检测规则'db_?key'会匹配到第2行而告警，导致误报；反而第3行真实的密钥硬编码检测不出来。

因此，仅依赖关键字匹配策略，在准确性和漏报率上无法兼得，进而导致漏水case始终无法得到有效收敛。

3）"策略对抗"——代码逻辑千变万化，难收敛‍‍

有些“耍小聪明”的小伙伴为了贪图一时便利，甚至刻意尝试利用字符串反转、拼接等手段刻意躲避和对抗工具审查。例如，下述代码示例中通过关键字拆分、AKSK密钥值拼接绕过传统的策略检测规则。

图3 策略对抗案例

殊不知，这样会导致代码安全风险隐藏更深，更难以检测和收敛。日积月累之后，等到“定时炸弹”被引爆的时刻，给业务带来的危害更大。

解放规则限制，大模型来助力风险检测！

利用大模型强大的代码语义理解和语言泛化能力，我们通过泛化检测规则，提升检出同时保障高准确率，让业务更多精力聚焦于真实密钥硬编码风险，提升业务风险处置效率。

图4 啄木鸟嵌入大模型升级后的敏感帐密泄露检测和运营流程

引入大模型能力进行策略升级后，啄木鸟的检测流程如上图所示：

(1) 首先，策略不再局限于严谨的精确匹配规则编写，可以通过宽泛正则、语法分析、数据流分析等识别代码中可能包含敏感密钥明文的风险代码；

(2) 其次，将识别的疑似密钥风险详情（文件、代码行）构造prompt后给到大模型进行判定；

(3) 最后，若大模型判定为正报，则展示给用户进行推修；若判定为误报，则直接丢弃结果；若判定为不确定，则通过人工运营并优化这部分case，再优化大模型的prompt。

结合大模型能力的具体检测方法和优势如下。

策略：突破传统密钥检测规则限制，实现高检出、低误报‍‍‍‍‍‍‍‍

针对测试代码片段，利用大模型的代码语义理解能力，可准确识别敏感密钥明文。进一步地，在CI流程中，为提高效率，我们采用泛化规则或SAST技术提取变量上下文依赖，筛选出可疑代码片段交由大模型判断，避免直接通过大模型检测所有扫描代码文件，规避检测效率、数据敏感性和大模型上下文token限制等问题。通过该方案，可兼顾高检出的同时，实现低误报。帮助业务提前发现和修复问题，避免被动应对。

例如，针对下面“变异”的敏感密钥明文，可以先匹配new COS(*)规则过滤出可能存在密钥风险的代码片段后，再利用大模型结合代码上下文，对密钥值类型、使用场景、是否为示例密钥等进行综合分析，相比让大模型直接判断原始代码是否存在密钥风险的方案，准确性会更高。