随着大模型技术的崛起，为行业提供了突破安全防护新高度的可能性。在我们的探索之旅中，大模型技术已被引入到安全领域的多个垂直应用中，我们将其沉淀成一系列关于大模型应用实践的文章。作为本系列的第二篇，本文聚焦于密钥硬编码的问题，分析了传统检测策略的缺陷，并详细介绍了大模型在该场景下的优势、检测实施方案和效果。我们将继续推出更多关于大模型在研发安全、网络安全、威胁情报等领域的应用探索与总结，敬请期待，欢迎持续关注本公众号。
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）广泛影响：泄露后可访问各类云资源，潜在破坏严重。
密钥硬编码泄露风险在实际运营和工单处置中痛点较多，给业务和安全运营均带来巨大的挑战。据统计，2023年Github开源仓库中敏感帐密明文硬编码数量达到12,778,599，比2022年增长28%！更糟糕的是，有的用户需要处理多达上千条帐密告警工单，简直让人眼花缭乱，压力山大。
然而，传统的密钥硬编码检测策略效果并不理想，误报率高。这意味着，在你努力修复那些真实的安全风险时，还要花费大量时间和精力去应对那些千奇百怪的误报。有时候，甚至需要联系人工客服，逐一确认这些误报信息。这不仅耗时耗力，还严重影响了开发同事的工作效率。
2）"规则太细"——漏水多，业务帐密明文检测需求适配性差
正则表达式用于精确匹配帐密明文时，虽准确但易漏报。因规则匹配的密钥模式太严格，策略运维需不断人工补充新规则，由于事先无法穷举易引发漏报。
// 泄露敏感帐密的代码private static final String db_key = "jdbc.data_db.password";env.setProperty(db_key, "password@123456");
上面所述案例是一个人工看起来很明显但检测策略却极易漏水的密钥明文风险。
一眼就能发现是密钥，为什么会漏水呢？仔细分析可知，大多数敏感帐密硬编码检测是基于固定规则，当代码出现规则之外的硬编码逻辑时，就会导致漏水。以知名的密钥硬编码开源检测工具detect-secrets为例，其基于关键字检测规则'db_?key'会匹配到第2行而告警，导致误报；反而第3行真实的密钥硬编码检测不出来。
因此，仅依赖关键字匹配策略，在准确性和漏报率上无法兼得，进而导致漏水case始终无法得到有效收敛。有些“耍小聪明”的小伙伴为了贪图一时便利，甚至刻意尝试利用字符串反转、拼接等手段刻意躲避和对抗工具审查。例如，下述代码示例中通过关键字拆分、AKSK密钥值拼接绕过传统的策略检测规则。
殊不知，这样会导致代码安全风险隐藏更深，更难以检测和收敛。日积月累之后，等到“定时炸弹”被引爆的时刻，给业务带来的危害更大。
利用大模型强大的代码语义理解和语言泛化能力，我们通过泛化检测规则，提升检出同时保障高准确率，让业务更多精力聚焦于真实密钥硬编码风险，提升业务风险处置效率。
图4 啄木鸟嵌入大模型升级后的敏感帐密泄露检测和运营流程
引入大模型能力进行策略升级后，啄木鸟的检测流程如上图所示：
(1) 首先，策略不再局限于严谨的精确匹配规则编写，可以通过宽泛正则、语法分析、数据流分析等识别代码中可能包含敏感密钥明文的风险代码；
(2) 其次，将识别的疑似密钥风险详情（文件、代码行）构造prompt后给到大模型进行判定；
(3) 最后，若大模型判定为正报，则展示给用户进行推修；若判定为误报，则直接丢弃结果； 若判定为不确定，则通过人工运营并优化这部分case，再优化大模型的prompt。
策略：突破传统密钥检测规则限制，实现高检出、低误报
针对测试代码片段，利用大模型的代码语义理解能力，可准确识别敏感密钥明文。进一步地，在CI流程中，为提高效率，我们采用泛化规则或SAST技术提取变量上下文依赖，筛选出可疑代码片段交由大模型判断，避免直接通过大模型检测所有扫描代码文件，规避检测效率、数据敏感性和大模型上下文token限制等问题。通过该方案，可兼顾高检出的同时，实现低误报。帮助业务提前发现和修复问题，避免被动应对。
例如，针对下面“变异”的敏感密钥明文，可以先匹配new COS(*)规则过滤出可能存在密钥风险的代码片段后，再利用大模型结合代码上下文，对密钥值类型、使用场景、是否为示例密钥等进行综合分析，相比让大模型直接判断原始代码是否存在密钥风险的方案，准确性会更高。
图5 利用大模型代码上下文摘要分析精准识别敏感帐密明文
此外，我们尝试了多种prompt策略进行优化。发现相比直接让大模型给出是否存在敏感密钥明文的判断，大模型更擅长对代码逻辑和语义进行分析和总结。因此，我们在prompt设计时，通过让大模型回答多个问题，再对问题进行汇总和分析，从而判断是否存在敏感密钥明文，最终模型准确率得到大幅提升。
我们总结了两种主要影响业务处置效率的场景：①误报case，即没有敏感密钥明文却提示对应风险；②示例密钥/密码，即使泄露也不会产生危害。
为解决上述问题，我们利用大模型根据上下文判断是否为示例或假密钥以及密钥的可利用度进行评分，以此过滤误报case以及示例密钥，专注于推送真实的密钥明文风险。这将使业务团队能够将更多精力投入到有效风险修复中，而非风险误报确认和示例密钥修复。
在740例密钥硬编码风险测评集上，相比传统规则，通过大模型，在无漏报情形下，密钥硬编码检测准确率提升33pp，达到97%。
图7 密钥硬编码检测场景引入大模型能力相比传统规则提升效果对比图
本文主要介绍了在密钥硬编码检测场景，通过将混元大模型能力和传统检测策略有效结合，相比传统密钥硬编码检测策略，准确率有较大提升。
当然，当前模型还存在部分待优化的地方。例如，在示例密钥、模板密钥和测试密钥场景还存在部分识别不准的情况，我们将继续尝试进一步优化。
此外，我们也在尝试将敏感密钥明文检测左移到编码和CR阶段——即基于Copilot & AI CR，提前在用户编码时自动发现代码是否存在敏感密钥明文，争取做到实时编码，实时检测，最终彻底杜绝敏感密钥明文泄露问题！
随着大模型技术的快速迭代，我们将持续深入探索大模型与代码安全的结合点，打破原有技术能力边界，为业务解决安全风险问题的同时，提供更贴心的安全产品服务体验。
立即咨询 JOTO
JOTO 提供覆盖企业智能体规划与搭建、AI 平台私有化部署、RAG 知识工程、AI 安全治理、FDE 驻场共创及持续运营优化的全周期 AI 落地服务，帮助企业把验证中的 AI 能力转化为安全、可控、可持续迭代的生产力。 联系 JOTO 获取 AI 落地咨询
