您的浏览器禁用了JavaScript(一种计算机语言,用以实现您与网页的交互),请解除该禁用,或者联系我们。 [GitGuardian]:2024年实战实录:企业级应用安全机密治理态势白皮书 - 发现报告

2024年实战实录:企业级应用安全机密治理态势白皮书

信息技术 2025-02-19 - GitGuardian 喜马拉雅
报告封面

今天,应用安全和密钥管理已成为全球组织前所未有的关键关注点。非人类身份的普及和现代应用架构的复杂性创造了重大的安全挑战,尤其是在管理敏感凭据方面。这一问题的规模十分庞大: 在平均组织中 , 机器身份现在比人类多 45 比 1 。 仅在 2023 年 , GitHub. com 上就公开了 1280 万个秘密, 比 2022 年增加了 28% 。 “秘密的状态蔓延 2024 ” , GitGuardian 为了更深入地了解这些挑战,CyberArk与GitGuardian共同发布了《实践者之声2024》报告。本研究基于对美国、英国、德国和法国1,000名IT决策者的调查,重点分析当前的应用安全状况,重点关注秘密管理与代码安全。 我们的研究揭示了对秘密蔓延风险日益增长的认识,并且增加了缓解策略的投资。然而,组织的准备程度仍然存在显著差距。本报告旨在基于日常使用或监督这些秘密的人的意见,提供当前IT领域秘密安全状况的见解。 从业者之声 2024 秘密泄漏正在上升 79%的受访者报告称其组织内部曾经历过或知晓过机密泄露的情况,这一数字较上年的75%有所上升。值得注意的是,这些事件中有77%导致了对公司、员工或两者造成实际损害,突显了此类泄露的严重后果。 对秘密管理的投资正在增加 组织正在通过大幅资源分配来应对这些挑战,平均将32.4%的网络安全预算用于密钥管理与代码安全。这一承诺在不同地区差异显著,美国组织的投入比例最高,达到49.8%,而法国仅为25.2%。展望未来,77%的组织计划在2025年前投资于密钥管理工具,其中75%特别关注密钥检测和修复能力。 组织正在走向成熟的战略 尽管74%的组织已经制定了成熟的战略来防止秘密泄露,令人担忧的是,仍有23%的组织依赖于不足的手动审查,或者完全没有定义的战略。这表明从2023年的27%来看,采用了更成熟战略的比例有所提高,显示出逐步的进步。 高自信与现实 尽管有75%的受访者表示对他们的密钥管理能力持有强烈的信心(在美国这一比例高达84%),但运营指标揭示了显著的挑战。泄露的密钥平均修复时间为27天,只有44%的开发人员遵循安全最佳实践,这表明感知与实际安全状况之间存在明显的差距。 研究揭示了组织规模和区域之间在秘密管理成熟度方面的显著差异,大型组织通常表现出更为稳健的做法。然而,平均每家组织存在多个秘密管理实例(6个左右)表明在保持一致的安全控制方面仍面临持续的挑战。 对人工智能和供应链风险的担忧正在增加 该研究指出,对AI驱动的编码助手存在日益增长的担忧,43%的受访者表示关注AI系统学习和复制敏感信息模式所带来的风险。此外,32%的受访者认为软件供应链中硬编码的秘密是关键的风险点。 结果 1 秘密泄漏正在上升 79%的受访者报告称其组织内部发生了或知晓了机密泄露的情况,这一数字较上年的75%有所上升。 其中 , 77% 的人报告说 , 泄漏损害了公司、员工或两者兼而有之。 这凸显了这种安全挑战的日益普遍性。 您是否曾经受到组织内部秘密泄漏的影响或听说过 ? 选择一个 12.6% 20.6% 12.8% 对秘密管理的投资正在增加 在研究进行之时,受访者已经平均将32.4%的网络安全预算分配给秘密管理与代码安全。 法国和德国在应用安全方面的预算相比之下则更加侧重其他领域,平均分配比例分别为25.2%和27.6%,而英国和美国的这一比例分别为35.8%和40.8%。 尽管大约三分之一的安全预算已经分配给了秘密管理与代码安全,但在这一领域的投资仍然是绝大多数实践者的优先事项,这表明他们致力于直接应对这一问题: 77% 的受访者表示 , 他们目前正在投资或计划到 2025 年投资秘密管理工具。 75% 聚焦关于秘密检测和补救工具。 秘密检测和补救 结果 3 组织正在走向成熟的战略 下一个问题作为一个代理来衡量秘密泄漏检测方面的好或坏做法的普遍性。 以下哪一项最好地描述了您捕获潜在秘密泄漏的策略 ? “我们依靠手动审查来检测源代码中硬编码的秘密。9.4% “我们依靠手动审查来检测构建工件中硬编码的秘密。3.8% 我们解读这些回应,认为这反映了持续存在的差距或仅仅是受访者对由硬编码秘密提出的问题的否认。因此,我们得出结论认为,在这项研究中 , 有23.3 %(低于 2023 年的 27 %) 的受访者在机密安全方面表现出相对不成熟的策略这也意味着 76.7% 的样本通过他们的反应表明了良好的成熟度。 为了理解这一现象,重要的是承认手动代码审查在检测源代码中是否嵌入了秘密方面效果不佳,因为这些审查只关注代码库的最新版本,而不检查可能包含秘密的早期修订版本。为什么代码审查无法在源代码中找到秘密 ? 泄漏被防止的原因是我们拥有成熟的秘密管理实践,例如秘密轮换或使用动态秘密,也被认为是对秘密泄漏问题的不足回应:确实,先进的秘密管理实践包括定期秘密轮换或使用短期有效的动态秘密。不能单独替代硬编码秘密检测的系统实现即使组织实施了这些系统,错误和规避行为仍可能发生,从而危及秘密安全策略。 practitioners 声称使用自动化秘密检测扫描所有代码仓库的人员在各国之间存在显著差异: 当被问及当前AppSec工具的主要挑战时,有33%的受访者表示“高误报率”和“扫描速度慢”。 有趣的是,美国受访者是唯一一个将“真阳性警告被忽略”(占比30%,而全球平均水平为27%)评为高于“慢速扫描”(占比25%,而全球平均水平为32%)的群体。这表明美国组织在工具使用方面面临更多的组织挑战而非技术问题。 结果 4 75%的受访者表示对组织检测和防止源代码中硬编码秘密的能力持中等到高度信心,其中42.7%的人表示“非常有信心”。这一信心水平在美国更高,达到84%。 有趣的是,报告称其组织拥有较大软件开发团队的受访者对其组织防止泄露的能力表现出更大的信心,这一现象在团队规模达到100-499人时最为明显。超过这个规模后,信心水平大致保持在约80%左右。 换句话说,较小的组织与较低的泄露缓解能力信心相关,而较大的组织则表现出较高的信心,直到某个阈值。 另一个问题可以突出通过高级轮换能力的整体高信心水平于秘密管理成熟度:平均而言,受访者报告称他们对该方面具有较高的信心。能够每年轮换 36% 的秘密. 轮换是指定期更新秘密的过程。为了确保安全性,最佳安全实践(以及监管机构和审计人员)要求定期轮换秘密,并且尽可能采用自动化方式。这就是为什么可以使用这一比率作为评估秘密安全成熟度的代理指标。 最终,受访者组织的成熟度还可以通过他们对以下问题的回答来评估:“下列选项中哪一项最能描述贵组织在疑似或确认泄露事件时的秘密轮换方法?” 以下哪一项最能描述贵组织在疑似或确认泄露事件中进行密钥轮换的方法?请多选。 “所有可能受影响的秘密都在确认泄漏后旋转 , 即使没有直接泄露。36% “大多数秘密都会按照固定的时间表进行轮换 , 无论是否有可疑的泄漏。34% “我们有系统可以在怀疑有妥协时自动轮换秘密。33% 虽然只有23%的人表示,“机密信息仅在确认泄露后才手动轮换。”然而,这一高水平的信心受到研究某些结果的挑战: 1. 调查受访者估计,平均而言,只有44%的开发人员了解并遵循密钥管理的最佳实践。 开发者是日常操作中主要负责管理密钥的实践者,通常负责安全地创建、共享和存储密钥。因此,受访者之间可能存在信任缺失,这可能表明最佳实践在密钥管理方面的普及程度不高。 有趣的是 , 这个估计会随着软件开发团队中的人数而增长 : The underlying factor explaining this is likely that larger software developerpopulations benefit from a greater number of individuals involved in DevSecOps, Product Security, or AppSec. This increased participation allows formore effective dissemination and enforcement of secrets management bestpractices at scale: 更大的软件开发人员群体可能受益于更多参与DevSecOps、产品安全或AppSec的人士。这种增加的参与度允许在更大规模上更有效地传播和执行密钥管理的最佳实践: 这突显了培养安全文化对从业者的影响是积极的。在组织中注重良好的保密习惯时,安全需要融入开发生命周期,以减少摩擦并打破安全孤岛。有效的安全需要责任分担模式为了实施各种层次的密管理措施、防止泄露,并 remediate 事件。研究还表明,在这一点上仍有显著的改进空间。 2. 三分之二的受访者估计补救是 IT 安全团队的责任 三分之二的受访者表示 , “IT 安全团队 ” 负责泄漏后的补救。 特别地,“Security Engineer”组中有65%的人报告说“IT安全团队”负责此任务,而选择“应用安全”的比例为17%,认为“开发人员”负责的比例仅为5%。 这一结果强调了补救负担被广泛认为是高度分隔化的。过程通常涉及广泛的调查以检查泄露凭证的使用情况,并确定如何在不中断运营的情况下进行轮换。 防止技术或业务中断最有效的方法是实施一个自动化的系统来管理这一过程,或者建立安全人员与不慎泄露敏感信息的个人之间的协作。这种方法强调了在维护保密性方面共享责任的重要性。 结果 5 根据从业者的说法 , 补救泄露秘密的平均时间为 27 天。 平均修复时间(MTTR)是一种事件指标,量化了从检测到事件到修复该事件的时间间隔。它是安全团队最重要的成功指标之一,因为它直接与风险相关联。 一个平均修复时间(MTTR)为27天通常被认为是一个较高的成绩,但必须牢记已泄露的秘密可能会立即构成高影响的风险,尤其是在公共网站上暴露时,它们可以在几分钟内被利用。因此,降低泄露秘密的MTTR对于显著减少风险至关重要。 GitGuardian的数据表明,实施秘密检测和修复解决方案可以显著减少这一时间,在一年内将时间缩短至大约13天。 这一发现也得到了研究结果的支持:70%表示他们在一周内修复泄露秘密的受访者表示会进行自动化和持续的扫描以识别漏洞,而表示他们需要超过一个月来修复泄露秘密的受访者中这一比例为59%。 当组织中使用多个密钥管理系统时,补救工作也会变得更加困难,因为这会使得在安全事件期间撤销密钥变得更加复杂,并增加了确保适当备份和灾难恢复程序的难度。 平均而言 , 受访者宣称6 个不同的秘密管理器实例在他们的组织中使用。 这种分散的方法增加了攻击面,并使在整个实例中维持一致的访问控制、审计轨迹和轮换策略变得更加困难。此外,跟踪哪些人员拥有对哪些密钥的访问权限变得更为复杂,这可能导致不必要的或过时的访问权限仍然保持有效。 对人工智能和供应链风险的担忧正在增加 信息安全从业者越来越关注通过代码助手泄露敏感信息的问题,因为这些AI工具往往会根据训练数据中学到的模式建议代码,这可能会无意中包含硬编码的凭证或内部实现细节。 此外,开发人员在寻求帮助时可能会无意中将敏感信息粘贴到提示中,这可能导致这些数据被暴露给AI服务提供商,或者影响其他用户未来代码建议。由于这些工具的自动化特性,追踪和审核生成代码中可能意外包含的敏感信息变得更加困难,尤其是在开发人员快速接受建议而未进行详细审查的情况下。 当被具体问及“随着编码助手的日益普及,您对代码库中潜在的敏感信息泄露担忧程度如何?”29 % 的受访者表示非常或极其担心代码库泄漏增加的可能性。这一比例在美国受访者中飙升至 48% 。 调查随后询问了所有相关受访者(从轻微到极其严重),他们对AI驱动的编码助手和敏感信息的关注点是什么: 这些调查发现表明,从业者对AI编码助手处理敏