2024年实战者之声报告

如今，应用安全与密钥管理已在全球范围内成为组织至关重要的关注点。非人类身份的泛滥及现代应用架构的复杂化，带来了严峻的安全挑战，尤其在管理敏感凭证方面。该问题的规模相当庞大： 机器身份在平均组织中现在以45:1的比例超过了人类身份。 《2022 身份安全威胁格局》，作者：CyberArk 2023年仅在GitHub.com上就有1280万个机密被公开，与2022年相比增长了28%。 《GitGuardian 2024 年秘密蔓延状况报告》 为更深入地了解这些挑战，CyberArk和GitGuardian合作发布了《2024年行业专家声音报告》。这项研究基于对美国、英国、德国和法国的1,000名IT决策者的调查，探讨了应用程序安全的现状，重点关注密钥管理和代码安全 我们的研究发现，对于机密蔓延风险的认识日益增长，并增加了对缓解策略的投资。然而，组织准备方面仍存在显著差距。本报告旨在基于那些日常使用或管理机密的人员的观点，提供对IT领域机密安全现状的洞察。 机密泄露呈上升趋势 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%的人将硬编码的密钥识别为其软件供应链中的一个关键风险点。 Result 1 机密泄露呈上升趋势 79%的受访者报告称他们经历过或意识到其组织内的机密泄露，较去年的75%有所上升。 在这些案例中，77%的受访者报告称，泄漏损害了公司、其员工或两者。 这突显了这一安全挑战日益普遍化。 你是否曾受到过或听说过你所在组织内部机密泄露的影响？选择一项。 是的，我知道发生了泄露，并且对公司造成了损害。 26.3% 12.6% 22.2% 是的，我知道发生了泄露，并且这对公司和员工都造成了问题。 20.6% 12.8% 对秘密管理的投资正在增加。 在研究进行的那一刻，受访者平均已经将其安全预算的32.4%分配给了秘密管理和代码安全。 然而，法国和德国的应用安全预算远未集中在这个领域，分别为25.2%和27.6%的平均分配比例，而英国和美国的比例则为35.8%和40.8%。 虽然大约三分之一的网络安全预算已经分配给了秘密管理和代码安全，但向这一领域投资仍然是大多数从业者的一项优先事项，这表明他们致力于直面问题。 77% 的受访者他们说他们目前正在投资或计划到2025年投资于秘密管理工具。 💬75%聚焦关于秘密检测和补救工具。 秘密检测与修复 Result 3 组织正朝着成熟策略发展。 下一个问题用作衡量在秘密泄漏检测方面良好或不良做法普遍程度的一个代理指标。 以下哪项最准确地描述了您应对潜在泄密风险的战略？ 我们依赖人工审核来检测硬编码在源代码中的凭据。9.4% 我们依赖人工审核来检测构建工件中硬编码的秘密。3.8% 我们拥有成熟的秘密管理实践，例如秘密轮换或使用动态秘密，从而防止信息泄露。7.2 % We interpret these responses as revealing persistent gaps or simply a denial of the problem posed by hard-coded secrets by the respondents, which leads us to the conclusion that23.3%（较2023年的27%下降）的受访者在本次研究中揭示，他们在秘密安全方面采取的策略相对不成熟。：这也意味着76.7%的样本通过他们的回应表明了良好的成熟度。 要理解原因，重要的是要承认手动代码审查在检测秘密是否硬编码到源代码中是无效的，因为审查只查看代码库的最新版本，而不是可能包含秘密的早期修订版本。为什么代码审查无法在源代码中发现秘密？ “由于我们有成熟的机密管理实践，例如密钥轮换或使用动态密钥，因此防止了泄露”，也被认为是针对密钥泄露问题的一个不足的回应：实际上，诸如定期密钥轮换或使用动态密钥（短期有效）等高级机密管理实践不能单独替代系统性地实施硬编码密钥检测事实证明，即使组织实施了这些系统，也可能发生错误和规避，从而危及机密安全策略。 声明使用自动化密钥检测扫描所有其代码仓库的从业者，在不同国家之间存在显著差异： 当被问及当前AppSec工具的主要挑战时，受访者的33%表示“高误报率”和“扫描速度慢”： 如果存在任何主要挑战，您的当前AppSec工具是什么？最多选择三个。 有趣的是，美国受访者是唯一一组将“真正积极的警告被绕过”（30% vs全球27%）排在“扫描速度慢”（25% vs 全球32%）之上的群体。这表明美国组织在工具方面面临更多的组织挑战，而不是技术问题。 结果4 75%的受访者表示，他们对组织检测和预防源代码中硬编码密钥的能力有中等至高度的信心，其中42.7%的人表示“非常自信”。这种信心水平在美国甚至更高，达到84%。 有趣的是，那些报告在拥有较大软件开发团队的组织中工作的受访者，在组织预防泄露的能力方面表现出更高的自信，这种自信程度一直持续到团队规模达到100-499人。超过这个规模后，自信水平稳定在约80%。 换句话说，较小的组织与较低的对泄漏缓解能力的信心相关联，而较大的组织则表现出更高的信心，直到达到某个阈值。 另一个问题可能凸显了在高级轮换能力方面对秘密管理成熟度的高度信心：受访者平均报告能够每年轮换36%的秘密. 轮换是指周期性地更新密钥。安全最佳实践（以及监管机构和审计人员）要求定期轮换密钥，并在可能的情况下以自动化方式执行。这就是为什么这个比率可以用作评估密钥安全成熟度的替代指标。 最后，受访者的成熟度还可以通过他们对问题“以下哪项最能描述您组织对密钥轮换的方法，尤其是在怀疑或确认泄露的情况下？”的回答来评估。 以下哪项最能描述您组织对秘密轮换的做法，特别是在疑似或确认泄露的情况下？请选择所有适用项 所有可能受影响的秘密在确认泄露后都会被轮换，即使没有直接遭受入侵。 轮岗决策是根据疑似/确认泄露的严重程度和范围个案处理。 当怀疑存在妥协时，机密信息会手动轮换。 大多数秘密都按照固定的时间表进行常规轮换，无论是否有泄露的嫌疑。 34% 秘密仅在确认泄露后手动轮换。 我们有系统在怀疑存在妥协时自动轮换密钥。 33% 无常规轮换：我们缺乏一个标准化的密钥轮换流程。 秘密在预定的时间间隔内进行轮换，如果怀疑泄露，可能会加速轮换。 31% 所有潜在受影响的秘密在确认泄露后都会进行轮换，即使没有直接遭到妥协。36% 大多数秘密都按固定时间表进行例行轮换，无论是否怀疑有泄露。34% 我们已建立系统，在怀疑遭泄露时自动轮换密钥。33% 在只有23%的人表示“秘密仅在确认泄露后才手动轮换。”然而，这项研究的一些结果对这种高度自信提出了质疑： 1. 受访者估计，平均而言，只有44%的开发人员了解并遵循秘密管理的最佳实践。 开发者是日常运营中管理密钥的主要从业者，通常负责创建、共享和安全存储它们。因此，认为密钥管理最佳实践未被广泛采用的看法可能表明受访者之间缺乏信任。 有趣的是，值得注意的是该估算值随软件开发团队中人员数量的增加而增长： 解释这一现象的潜在因素可能是，规模较大的软件开发者群体受益于更多参与DevSecOps、产品安全或AppSec的人员。这种增加的参与使得在更大范围内有效传播和执行密钥管理最佳实践成为可能： 这突出了在从业者中培养安全文化的积极影响。在组织良好的秘密卫生方面，安全需要嵌入到开发生命周期中，以减少摩擦并打破安全隔阂。有效的安全需要共同责任模式实施管理机密、防止泄露和补救事件的多层措施。该研究还表明，在这一点上，仍有显著改进空间。 2. 三分之二的受访者估计，修复工作是IT安全团队的责任。 三分之二的受访者表示，“IT安全团队”在泄露后负责修复。 具体而言，65%的“安全工程师”群体报告称“IT安全团队”负责，相比之下，17%的人选择了“应用安全”，仅有5%的人表示在泄露后“开发人员”负责轮换。 这一结果强调了，整改负担被广泛认为高度分割。该流程通常涉及大量的工作来调查泄露凭证的使用情况，并确定如何在不妨碍运营的情况下进行轮换。 预防技术或业务中断的最有效方式是实施一个自动化系统来管理这一过程，或是在安全人员与无意中泄露敏感信息的个人之间建立协作。这种方法强调了在维护机密性方面共同责任的重要性。 结果 5 据从业者称，修复泄露机密的平均时间长达27天。 平均修复时间（MTTR）是一个事件指标，用于量化在检测到事件和修复事件之间的平均时间间隔。它是安全团队最重要的成功指标之一，因为它直接与风险相关。 一个27天的MTTR通常被认为是一个高分，但重要的是要牢记，披露的机密可能代表着即时且高影响的风险，尤其是如果它们在一个公开网站被曝光，在那里它们可能在几分钟内被利用。这就是为什么减少泄露机密的MTTR对于显著降低风险绝对至关重要。 GitGuardian的数据表明，实施数据检测和补救解决方案可以在一年内将这一时间显著缩短至约13天。 这一发现也得到了研究结果的支持：70%的受访者表示他们用不到一周的时间来修复泄露的秘密，他们会进行自动化和持续的扫描以识别漏洞，而承认花费超过一个月的人的比例则为59%。 在使用跨组织的多个密钥管理器时，修复工作也变得更加困难，因为它 complicates secret revocation during security incidents and makes it more challenging to ensure proper backup and disaster recovery procedures. On average, respondents declared that6个独特的经理实例秘密在其组织中正在使用。 这种分散的方法增加了攻击面，并且更难以在所有实例中保持一致的访问控制、审计跟踪和轮换策略。此外，追踪谁可以访问哪些密钥变得更加复杂，可能会导致过多或过时的访问权限仍然处于激活状态。 对人工智能和供应链风险的担忧日益加剧。 安全从业者越来越关注通过代码助手泄露敏感信息，因为这些人工智能工具通常根据从训练数据中学习到的模式来提供建议代码，这些模式可能无意中包含了硬编码的凭证或内部实现细节。 此外，开发者在寻求帮助时可能无意中将敏感信息粘贴到提示中，从而可能将这些数据暴露给AI服务提供商或影响未来对其他用户代码建议，而这类工具的自动化特