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

今天，应用安全和密钥管理已成为全球组织前所未有的关键关注点。非人类身份的普及和现代应用架构的复杂性创造了重大的安全挑战，尤其是在管理敏感凭据方面。这一问题的规模十分庞大： 在平均组织中，机器身份现在比人类多45比1。 “2022年身份安全威胁格局”，CyberArk 仅在2023年，GitHubcom上就公开了1280万个秘密 ，比2022年增加了28。 “秘密的状态蔓延2024”，GitGuardian 为了更深入地了解这些挑战，CyberArk与GitGuardian共同发布了《实践者之声2024》报告。本研究基于对美国、英国、德国和法国1000名IT决策者的调查，重点分析当前的应用安全状况，重点关注秘密管理与代码安全。 我们的研究揭示了对秘密蔓延风险日益增长的认识，并且增加了缓解策略的投资。然而，组织的准备程度仍然存在显著差距。本报告旨在基于日常使用或监督这些秘密的人的意见，提供当前IT领域秘密安全状况的见解。 从业者之声2024 执行摘要 秘密泄漏正在上升 79的受访者报告称其组织内部曾经历过或知晓过机密泄露的情况，这一数字较上年的75有所上升。值得注意的是，这些事件中有77导致了对公司、员工或两者造成实际损害，突显了此类泄露的严重后果。 对秘密管理的投资正在增加 组织正在通过大幅资源分配来应对这些挑战，平均将324的网络安全预算用于密钥管理与代码安全。这一承诺在不同地区差异显著，美国组织的投入比例最高，达到498，而法国仅为252。展望未来，77的组织计划在2025年前投资于密钥管理工具，其中75特别关注密钥检测和修复能力。 组织正在走向成熟的战略 尽管74的组织已经制定了成熟的战略来防止秘密泄露，令人担忧的是，仍有23的组织依赖于不足的手动审查，或者完全没有定义的战略。这表明从2023年的27来看，采用了更成熟战略的比例有所提高，显示出逐步的进步。 3 高自信与现实 尽管有75的受访者表示对他们的密钥管理能力持有强烈的信心（在美国这一比例高达84），但运营指标揭示了显著的挑战。泄露的密钥平均修复时间为27天，只有44的开发人员遵循安全最佳实践，这表明感知与实际安全状况之间存在明显的差距。 组织就绪性挑战 研究揭示了组织规模和区域之间在秘密管理成熟度方面的显著差异，大型组织通常表现出更为稳健的做法。然而，平均每家组织存在多个秘密管理实例（6个左右）表明在保持一致的安全控制方面仍面临持续的挑战。 对人工智能和供应链风险的担忧正在增加 该研究指出，对AI驱动的编码助手存在日益增长的担忧，43的受访者表示关注AI系统学习和复制敏感信息模式所带来的风险。此外，32的受访者认为软件供应链中硬编码的秘密是关键的风险点。 4 您是否曾经受到组织内部秘密泄漏的影响或听说过？选择一个 是的，我知道发生了泄漏，并对公司造成了损坏。 是的，我知道发生了泄漏，但我不确定影响是什么 263 55 是的，我知道发生了泄漏，这给员工带来了问题。 222 是的，我知道发生了泄漏，但没有影响 126 是的，我知道发生了泄漏，这对公司和员工都造成了问题 No 206 128 研究结果 结果1 秘密泄漏正在上升 79的受访者报告称其组织内部发生了或知晓了机密泄露的情况，这一数字较上年的75有所上升。 其中，77的人报告说，泄漏损害了公司、员工或两者兼而有之。 这凸显了这种安全挑战的日益普遍性。 5 结果2 对秘密管理的投资正在增加 在研究进行之时，受访者已经平均将324的网络安全预算分配给秘密管理与代码安全。 6 法国和德国在应用安全方面的预算相比之下则更加侧重其他领域，平均分配比例分别为252和276，而英国和美国的这一比例分别为358和408。 尽管大约三分之一的安全预算已经分配给了秘密管理与代码安全，但在这一领域的投资仍然是绝大多数实践者的优先事项，这表明他们致力于直接应对这一问题： 77的受访者表示，他们目前正在投资或计划到2025年投资秘密管理工具。 75聚焦关于秘密检测和补救工具。 7 秘密管理 秘密检测和补救 8 结果3 组织正在走向成熟的战略 下一个问题作为一个代理来衡量秘密泄漏检测方面的好或坏做法的普遍性。 以下哪一项最好地描述了您捕获潜在秘密泄漏的策略？ “我们依靠手动审查来检测源代码中硬编码的秘密。94 “我们依靠手动审查来检测构建工件中硬编码的秘密。38 泄漏被防止，因为我们拥有成熟的安全密钥管理实践，例如密钥轮转或使用动态密钥。72 “我们没有任何策略。”29 我们解读这些回应，认为这反映了持续存在的差距或仅仅是受访者对由硬编码秘密提出的问题的否认。因此，我们得出结论认为，在这项研究中，有 233低于2023年的27的受访者在机密安全方面表现出相对不成熟的策略这也意味着767的样本通过他们的反应表明了良好的成熟度。 9 为了理解这一现象，重要的是承认手动代码审查在检测源代码中是否嵌入了秘密方面效果不佳，因为这些审查只关注代码库的最新版本，而不检查可能包含秘密的早期修订版本。 为什么代码审查无法在源代码中找到秘密？ 泄漏被防止的原因是我们拥有成熟的秘密管理实践，例如秘密轮换或使用动态秘密，也被认为是对秘密泄漏问题的不足回应：确实，先进的秘密管理实践包括定期秘密轮换或使用短期有效的动态秘密。不能单独替代硬编码秘密检测的系统实现即使组织实施了这些系统，错误和规避行为仍可能发生，从而危及秘密安全策略。 10 您当前的AppSec工具面临的主要挑战是什么？最多选择三个 绕过了真正的肯定警告 55 假阳性率高 263 慢速扫描 222 粗糙的CICD集成 126 缺乏监控和警报 128 用户体验差 206 practitioners声称使用自动化秘密检测扫描所有代码仓库的人员在各国之间存在显著差异： 当被问及当前AppSec工具的主要挑战时，有33的受访者表示“高误报率”和“扫描速度慢”。 11 有趣的是，美国受访者是唯一一个将“真阳性警告被忽略”（占比30，而全球平均水平为27）评为高于“慢速扫描”（占比25，而全球平均水平为32）的群体。这表明美国组织在工具使用方面面临更多的组织挑战而非技术问题。 结果4 高信心与现实 75的受访者表示对组织检测和防止源代码中硬编码秘密的能力持中等到高度信心，其中427的人表示“非常有信心”。这一信心水平在美国更高，达到84。 12 有趣的是，报告称其组织拥有较大软件开发团队的受访者对其组织防止泄露的能力表现出更大的信心，这一现象在团队规模达到100499人时最为明显 。超过这个规模后，信心水平大致保持在约80左右。 换句话说，较小的组织与较低的泄露缓解能力信心相关，而较大的组织则表现出较高的信心，直到某个阈值。 13 另一个问题可以突出通过高级轮换能力的整体高信心水平于秘密管理成熟度：平均而言，受访者报告称他们对该方面具有较高的信心。能够每年轮换36的秘密 14 以下哪一项最能描述贵组织在疑似或确认泄露事件中进行密钥轮换的方法？请多选。 所有可能受影响的秘密都在确认泄漏后旋转，即使没有直接泄露 根据可疑确认泄漏的严重程度和范围逐案做出轮换决定 36 30 大多数秘密都会按照固定的时间表进行轮换，无论是否有可疑的泄漏 当怀疑有妥协时，会手动旋转秘密 34 28 只有在确认泄漏后，才能手动旋转秘密 我们有系统可以在怀疑有人妥协时自动旋转机密 23 33 没有定期轮换：我们没有一个标准化的轮换秘密流程 秘密以预定的间隔旋转，如果怀疑泄漏 ，则可以加速 3 31 我不知道 4 轮换是指定期更新秘密的过程。为了确保安全性，最佳安全实践（以及监管机构和审计人员）要求定期轮换秘密，并且尽可能采用自动化方式。这就是为什么可以使用这一比率作为评估秘密安全成熟度的代理指标。 最终，受访者组织的成熟度还可以通过他们对以下问题的回答来评估：“下列选项中哪一项最能描述贵组织在疑似或确认泄露事件时的秘密轮换方法？” 15 这三个回答证实了这种高水平的成熟度： “所有可能受影响的秘密都在确认泄漏后旋转，即使没有直接泄露。36 “大多数秘密都会按照固定的时间表进行轮换，无论是否有可疑的泄漏。34 “我们有系统可以在怀疑有妥协时自动轮换秘密。33 虽然只有23的人表示，“机密信息仅在确认泄露后才手动轮换。”然而，这一高水平的信心受到研究某些结果的挑战： 遵循密钥管理的最佳实践。 1调查受访者估计，平均而言，只有44的开发人员了解并 16 开发者是日常操作中主要负责管理密钥的实践者，通常负责安全地创建、共享和存储密钥。因此，受访者之间可能存在信任缺失，这可能表明最佳实践在密钥管理方面的普及程度不高。 有趣的是，这个估计会随着软件开发团队中的人数而增长： TheunderlyingfactorexplainingthisislikelythatlargersoftwaredeveloperpopulationsbenefitfromagreaternumberofindividualsinvolvedinDevSecOpsProductSecurityorAppSecThisincreasedparticipationallowsformoreeffectivedisseminationandenforcementofsecretsmanagementbestpracticesatscale Sec的人士。这种增加的参与度允许在更大规模上更有效地传播和执行密钥管理的最佳实践： 更大的软件开发人员群体可能受益于更多参与DevSecOps、产品安全或App 17 这突显了培养安全文化对从业者的影响是积极的。在组织中注重良好的保密习惯时，安全需要融入开发生命周期，以减少摩擦并打破安全孤岛。有效的安全需要责任分担模式为了实施各种层次的密管理措施、防止泄露，并remediate事件。研究还表明，在这一点上仍有显著的改进空间。 2三分之二的受访者估计补救是IT安全团队的责任 三分之二的受访者表示，“IT安全团队”负责泄漏后的补救。 特别地，“SecurityEngineer”组中有65的人报告说“IT安全团队”负责此任务，而选择“应用安全”的比例为17，认为“开发人员”负责的比例仅为5 。 这一结果强调了补救负担被广泛认为是高度分隔化的。过程通常涉及广泛的调查以检查泄露凭证的使用情况，并确定如何在不中断运营的情况下进行轮换。 18 防止技术或业务中断最有效的方法是实施一个自动化的系统来管理这一过程 ，或者建立安全人员与不慎泄露敏感信息的个人之间的协作。这种方法强调了在维护保密性方面共享责任的重要性。 结果5 组织就绪性挑战 根据从业者的说法，补救泄露秘密的平均时间为27天。 平均修复时间（MTTR）是一种事件指标，量化了从检测到事件到修复该事件的时间间隔。它是安全团队最重要的成功指标之一，因为它直接与风险相关联。 一个平均修复时间（MTTR）为27天通常被认为是一个较高的成绩，但必须牢记已泄露的秘密可能会立即构成高影响的风险，尤其是在公共网站上暴露时，它们可以在几分钟内被利用。因此，降低泄露秘密的MTTR对于显著减少风险至关重要。 19 GitGuardian的数据表明，实施秘密检测和修复解决方案可以显著减少这一时间，在一年内将时间缩短至大约13天。 这一发现也得到了研究结果的支持：70表示他们在一周内修复泄露秘密的受访者表示会进行自动化和持续的扫描以识别漏洞，而表示他们需要超过一个月来修复泄露秘密的受访者中这一比例为59。 当组织中使用多个密钥管理系统时，补救工作也会变得更加困难，因为这会使得在安全事件期间撤销密钥变得更加复杂，并增加了确保适当备份和灾难恢复程序的难度。 平均而言，受访者宣称6个不同的秘密管理器实例在他们的组织中使用。 20 这种分散的方法增加了攻击面，并使在整个