HashiCorp 警告称传统密钥扫描工具日渐落伍

HashiCorp 发出了警告，称传统的密钥扫描工具未能跟上现代软件开发的现实情况。

在一篇新的博客文章中，该公司认为当前的方法——通常依赖于提交后的检测和脆弱的模式匹配，留下了危险的空白地带。

它呼吁组织专注于预防为主的策略，这些策略可以直接集成到开发人员工具、CI/CD 管道和事件响应系统中，以减少暴露窗口并提高修复速度。

这一警告是在近年来一系列高调的凭证暴露事件之后发出的，凸显了即使是成熟的组织也可能容易受到攻击。

在 2023 年，一个配置错误的Azure共享访问签名（SAS）令牌嵌入了在公共 GitHub 仓库中，授予了对包含 38TB 内部数据的微软存储账户的完全控制权，这些数据包括了私钥、密码和 Teams 消息。

在 2024 年，Dropbox 披露了其 Dropbox Sign 平台的一次违规行为，事件暴露了一个服务账户，允许攻击者访问 API 密钥、OAuth 令牌、哈希密码和用户元数据。这起事件显然反映出了一个更广泛的行业模式：GitHub报告称，同年在公共和私有仓库中暴露了超过 3900 万个密钥，尽管它们广泛采用了扫描和推送保护功能。

HashiCorp 表示，传统的密钥扫描工具对于现代开发环境来说已不再够用。他们指出了几个关键限制，包括高误报率、错过自定义密钥的检测，以及提交后扫描引入的延迟。他们还注意到，许多工具缺乏对 CI/CD 管道、容器镜像和开发人员协作平台等领域的可见性。

这些空白可能导致警报疲劳、不一致的修复和超出版本控制的密钥暴露。它还凸显了一些与云原生系统相关的挑战，如短暂的基础设施和多云认证格式，这可能会让检测变得更复杂。

为了应对这些挑战，HashiCorp 概述了一套它认为对现代密钥管理至关重要的能力。这些能力包括在开发人员 IDE 中实时检测、具有上下文感知绕过选项的预提交扫描，以及在 CI/CD 管道、容器和开发人员通信平台上扩大覆盖范围。

该组织将这些能力框架视为提高开发体验和实现更快响应的必要条件。更广泛的建议是从提交后检测转向与现代开发速度更好地对齐的，以集成、预防为主的策略。

这些担忧并非 HashiCorp 才有。近年来，GitHub 也采取了类似的立场，将其密钥扫描功能扩展到提交后检测之外的场景。推送保护功能现在在推送被提交之前积极阻止已知的密钥类型。该工具直接集成到 GitHub CLI 和支持的 IDE 中。而像 Gitleaks 和 Talisman 这样的开源工具也在以类似的方式不断演变。

像 Trivy 这样的工具在构建容器镜像时进行扫描，一些组织，如 Target，如果认为风险高，会将这些扫描的结果直接路由到事件响应平台。

与此同时，一些组织正在通过减少对密钥的需求来根除检测漏洞。基于 OIDC 的负载身份在 CI/CD 管道和 Kubernetes 集群中越来越受欢迎，允许负载使用短暂的令牌而不是静态凭证进行身份验证。

像 Azure 这样的云提供商现在在 AKS 等服务中本地支持这种模型。与此同时，像 HashiCorp Vault 这样的工具倡导动态密钥和自动轮换，以限制暴露窗口并减少凭证管理的运维负担。

虽然实现方式各不相同，但这些响应反映了一个日益增长的趋势，即最小化暴露面，并在开发生命周期的早期集成密钥管理。

原文链接：HashiCorp Warns Traditional Secret Scanning Tools Are Falling Behind