文章总结： DockerHub上发现超过1万个镜像包含泄露的密钥，影响100多家组织，包括财富500强公司。AIAPI密钥是最常泄露的凭证类型，42%的受影响镜像包含5个或更多凭据。许多泄露来自影子IT账户，且75%的泄露密钥未被撤销。建议组织避免在容器中存储密钥，使用短期认证，集中管理密钥，实施持续扫描，并教育开发者提高安全意识。
综合评分： 91
文章分类： 漏洞分析,云安全,安全意识,数据安全,安全建设

---

Docker Hub上数千泄露密钥正将企业置于风险之中

Dubito

云原生安全指北

2025年12月12日 08:35
江苏

注：本文翻译自 Flare – Assaf Morag 的文章《Thousands of Exposed Secrets Found on Docker Hub, Putting Organizations at Risk》[1]，可点击文末“阅读原文”按钮查看英文原文。

全文如下：

一、引言

多年来，安全界一直流传着一句话：“黑客已经无需再黑，密钥会盛在银盘里被直接奉上。” 但这真的属实吗？

正是这个问题，促使我们开始研究 Docker Hub 上暴露的凭据（secrets）。我们设计了一套方法来分析泄露的凭证，验证哪些是真实的，并调查其来源：

• • 它们属于谁
• • 它们能访问何种环境
• • 对受影响的组织乃至整个生态系统的潜在爆炸半径

在本报告中，我们还将探讨缓解策略，并解释 Flare 的客户如何从这项研究中受益——通过使用自动化的基于 API 的扫描引擎和平台内的检测工作流，来识别并防范凭据泄露。

二、关键发现

• • 仅一个月的扫描就发现，超过 1w 个 Docker Hub 镜像包含泄露的凭据，其中包括生产系统的实时有效凭证。
• • 超过 100 家组织受到影响，包括一家《财富》500 强公司和一家大型国家银行，但许多组织对此次泄露事件一无所知。
• • 42% 的受影响镜像各自包含五个或更多的凭据（secrets），这意味着单个容器就可能解锁整个云环境、CI/CD 流水线（pipeline）和数据库。
• • AI 大语言模型（LLM）的 API 密钥是泄露最频繁的凭证类型，近 4,000 个被暴露，这揭示了 AI 应用的快速普及已远超安全控制措施的速度。
• • 相当大一部分泄露来自影子 IT 账户（shadow IT accounts）——即个人或承包商拥有的registries，这些完全处于企业监控的视野之外。
• • 开发者通常会从容器中移除泄露的凭据，但其中 75% 的人未能撤销或轮换底层的密钥，导致组织暴露风险持续数月甚至数年。
• • 这些发现证实了一种新的攻击范式：攻击者无需“黑入”，而是“验证进入”——利用公司自己意外发布的密钥进行认证。

三、密钥在现代软件开发生命周期中的位置

在现代企业的软件开发生命周期中，密钥（secrets）是数字供应链的连接组织。它们实现了跨云提供商、CI/CD pipelines、消息平台和开发工具的认证、自动化、服务间通信以及机器对机器信任。

从基础设施供应到制品发布的各个环节，都依赖于密钥、令牌和证书。随着企业采用微服务、临时基础设施、无服务器架构和联邦开发模式，流通中的密钥数量呈爆炸式增长。

单个应用程序就可能需要数十个 API 密钥，涉及 AWS、GitHub、Slack、Stripe、GCP 和内部服务等多个供应商。通常，即使在开发者离开项目或公司很久之后，这些凭证仍然有效。

然而，尽管密钥是自动化的基石，但它们同时也极其脆弱。其权限之大常超出可见性范围。许多组织拥有成千上万个活跃的密钥，却从未进行过审计、扫描、轮换或集中管理。实际上，密钥往往散落在：

• • 源代码中
• • 配置文件里
• • 开发者笔记本电脑上
• • 构建流水线内
• • 容器镜像里
• • 个人云账户中

其中一些密钥权限极深，可控制生产环境、云账户，甚至公司的核心。这形成了一条静默的攻击路径：一个被暴露的令牌就能绕过 MFA、规避边界防御，直接获取生产系统的特权访问权限。本质上，密钥既是现代工程实践的润滑剂，也是组织安全的阿喀琉斯之踵——因为它们易于使用、易于被遗忘，且一旦暴露后果将极为严重。

四、攻击场景与潜在影响

纵观媒体广泛报道的这些事件，一个清晰的模式显现：攻击者无需利用零日漏洞或破解复杂加密。相反，他们只需等待组织自己泄露密钥，然后凭借这些凭证直接进入代码仓库、CI 工作流，甚至生产云账户。

无论是 Shai-Hulud 从被入侵的软件包中窃取开发者令牌，被植入后门的 GitHub Action 窃取 CI/CD 密钥，还是像微软和丰田这样的公司意外将云凭证提交到公共仓库，其根本原因是一致的：密钥被当作静态且永生的，而非动态且短期的；并且，在凭证泄露发生时，缺乏足够的自动检测机制。

这一模型表明，如今的供应链和云安全事件并非随机发生——它们在结构上是可预测、可预防的，并总是通过最薄弱的一环，即凭证管理不当，进行传播。

Docker Hub 暴露利用示意图

4.1 Shai-Hulud 2.0 NPM 蠕虫

Shai-Hulud 1.0 最初是一种恶意的 NPM 供应链蠕虫。它通过感染合法软件包的安装后脚本，窃取开发者密钥，并利用被入侵的 NPM/GitHub 凭证进行传播，将恶意代码推送到下游生态系统中，并将私有仓库公开。

防御者起初通过清除缓存、轮换凭证和审查 GitHub 活动来缓解。但于 2025 年 11 月发动的 Shai-Hulud 2.0 引入了更为高级的能力：将执行阶段转移到预安装脚本，使用基于 Bun 的载荷来规避检测，扩大至感染数百个软件包和数万个仓库，通过创建公共 GitHub 仓库改进了密钥外泄方式，并实现了跨受害者的横向传播。

这一演变使 Shai-Hulud 从一个巧妙的凭证窃取者，转变为一个高度自适应的全球供应链蠕虫。更多详情请见此处[2]（译文见Shai-Hulud 2.0 事后报告：趋势、受害者分析与影响评估）。

4.2 GitHub Actions tj-actions/changed-files 供应链泄露事件

2025年3月中旬，GitHub 发生了一起大规模的供应链泄露事件。流行的 GitHub Action tj-actions/changed-files 被植入后门，其代码被修改为直接将 CI/CD secrets（个人访问令牌/PATs、密钥、registry令牌、云凭证等）打印到工作流日志中，从而悄无声息地将其从成千上万的流水线中外泄。

调查人员随后将此次入侵溯源至一个泄露的 SpotBugs 个人访问令牌。攻击者利用一个有漏洞的工作流，通过此令牌获得了写入权限，提升了特权，并横向渗透到相关的依赖仓库和 Actions。这次攻击最初的目标是 Coinbase 的开源 agentkit，这突显了攻击者的策略：入侵一个关键的 CI/CD 环节，大规模窃取secrets，并利用暴露的软件开发生命周期基础设施，为更深层次的下游入侵创造条件。

此事例说明了攻击者如何利用单个密钥，对整个开发生态系统产生巨大影响。更多详情请见此处[3]。

4.3 微软 Azure SAS 密钥泄露——内部 AI 数据未授权访问

2023至2024年间，微软面临一起重大的云安全暴露事件。一个 GitHub 仓库意外包含了一个权限过大的 Azure SAS（共享访问签名）令牌，该令牌授予了对用于存储 AI 训练数据的内部存储账户的完全访问权限。

该令牌使任何发现它的人都能浏览私有数据集、下载机密资料，甚至能在微软的 Azure 环境内部写入或修改存储容器和 Blob。此次暴露迫使微软迅速轮换了受影响的访问凭证，并实施了更严格的内部管控，包括仓库扫描、密钥管理和密钥治理，以防止未来再次发生泄漏。

4.4 丰田 AWS 凭证暴露——持续多年的静默云访问

在同一时期，丰田也遭遇了自身具有破坏性的云安全失误。其 AWS 凭证被意外推送到一个公共 GitHub 仓库，无意中授予了对该公司云托管车辆远程信息处理系统的访问权限。

威胁行为者利用这些密钥访问了超过200万丰田车主的数据，包括基于位置的车联网数据、GPS信息和安全相关记录。据报道，该密钥在数年内持续有效，这意味着此次暴露很可能导致了长期的未授权访问，同时也突显了丰田在软件开发生命周期实践和云安全态势方面存在的系统性凭证管理问题。

五、研究方法论

我们定义了涵盖软件开发生命周期、云基础设施凭证和 AI 模型访问令牌的 15 种不同类型的密钥。这些关键类型最初是作为代表性样本（非详尽）选择的，而研究使我们能够迅速将此列表扩展到数百乃至数千种在野外流通的其他已暴露凭证类型。

事实上，我们的发现直接丰富了我们的检测模型，并增强了我们发现并进一步定位其他已暴露密钥的能力。

以下是我们关注的具体密钥类型集合：

1. 1. SDLC 与源代码控制凭证：
   GITHUB_TOKEN、BITBUCKET_APP_PASSWORD、ECR_SECRET_ACCESS_KEY、NPM_TOKEN、PYPI_API_TOKEN
2. 2. 云服务提供商凭证：
   AWS_SECRET_ACCESS_KEY、GOOGLE_OAUTH_ACCESS_TOKEN、AZURE_CLIENT_SECRET
3. 3. AI 与模型访问令牌：
   OPENAI_API_KEY、OPENAI_TOKEN、HF_TOKEN、HUGGINGFACE_API_KEY、ANTHROPIC_API_KEY、GEMINI_API_KEY、GROQ_API_KEY

所有扫描均在 Docker Hub 上过去一个月内（2025年11月1日至11月30日）上传的容器镜像上进行。我们总共识别出 10,456 个容器镜像 包含一个或多个已暴露的密钥。在过滤掉严重性低于高和关键的发现后，我们在 Docker Hub 上留下了 205 个独立的命名空间。

我们选择 Docker Hub 是因为我们采用了双重索引方法：

1. 1. 我们索引 Docker Hub 清单（manifests），这与其他组织类似。
2. 2. 我们还拉取并解包容器镜像，提取其中的文件，扫描它们以查找敏感数据，然后对这些发现进行索引。据我们所知，没有其他供应商在此规模上进行深度的文件级提取和密钥扫描。

在我们的调查过程中，我们分析了这 205 个命名空间，并成功地将其中 101 个与可识别的公司（各种规模）关联起来，主要是中小型企业，尽管数据集中也出现了一些大型企业，甚至包含一家《财富》500强企业。

识别工作是通过将命名空间所有权与已知公司实体进行关联来完成的；其余命名空间被归类为个人账户。有趣的是，我们发现了多起案例，其中创始人、承包商、自由职业者或员工从个人的 Docker Hub 账户推送容器镜像，在此过程中无意间暴露了公司密钥。

以下是 101 家已识别公司所属行业的细分情况：

101家暴露公司的行业分布

在检查已暴露的密钥时，一个特别令人担忧的发现显现出来：大约 42% 的泄露容器镜像包含五个或更多敏感值。 这些多密钥暴露事件代表了严重的风险，因为它们通常能提供对云环境、Git 仓库、CI/CD 系统、支付集成及其他核心基础设施组件的完全访问权限。

按暴露密钥数量划分的暴露规模分布

下方是发现密钥的进一步细分：

| 类别 | Docker Hub 账户数 | 含义 |
| — | — | — |
| AI | 191 | AI API（如 Grok/Gemini/Anthropic 等） |
| CLOUD | 127 | AWS/Azure/GCP/Cosmos/RDS 等云服务密钥 |
| DATABASE | 89 | Mongo / Postgres / Neon / ODBC / SQL 凭证 |
| ACCESS | 103 | JWT / SECRET_KEY / APP_KEY / 加密密钥 |
| API_TOKEN | 157 | 通用的第三方 API 密钥 |
| SCM_CI | 44 | GitHub / Bitbucket / NPM / Docker 等密钥 |
| COMMUNICATION | 31 | SMTP / Sendgrid / Brevo / Slack / Telegram 密钥 |
| PAYMENTS | 21 | Stripe / Razorpay / Cashfree / SEPAY 等支付密钥 |

此外，一项针对 AI 密钥的比较搜索显示，仅基于对过去一个月（2025年11月1日至11月30日）内 Docker Hub 镜像的扫描，并只筛选高和严重级别的风险，就暴露出 近 4,000 个 AI 密钥。

此外，我们还识别出 10 个 NPM 访问密钥，其中三个与拥有大量 NPM 包下载量的中型公司相关联。

5.1 识别公司身份

• • 将 Docker Hub 账户关联到一家公司，可能非常简单，也可能完全不可能，这取决于registry中可用和隐藏的数据。最简单的方法是检查 Docker Hub 上的详细信息：有时账户就属于某个公司，那么你就能看到邮箱、网站等更多信息。
• • 名称可能具有指示性：即使账户不直接显示为公司，但如果名称是“Company X Ltd”，也能指引你找到对应的公司。
• • 深入挖掘：验证过程则更长、更严谨，基于几个强指标，如域名、IP 地址、命名空间以及代码内部的其他标识符。如果我们的置信度低于 80%（基于我们定义的各种因素），我们会设定身份；否则，将其标记为未知。

六、研究发现的反思

关于账户所有者身份，我们可以将发现分为三大类：

1. 1. 泄露密钥的组织和公司
2. 2. 泄露个人密钥的个人账户
3. 3. 泄露公司密钥的个人账户

6.1 公司层面的暴露

现代软件开发生命周期工作流依赖大量密钥来支持高度自动化、分布式的开发流水线。开发者常规性地使用云密钥、API 令牌、模型访问凭证、数据库连接字符串和 CI/CD 令牌，以实现工具与环境间的无缝集成。容器已成为这一生态系统的支柱，它将依赖项、运行时和微服务打包成可移植单元，在开发、构建、测试和生产阶段之间流转。

以一个现实案例为例：一家专门为客户定制 AI 模型以满足其独特业务和技术需求的公司。在此案例中，该组织不慎将 GitHub 令牌直接嵌入到 Docker Hub 容器清单中，从而导致其泄露。

该暴露的 GitHub 令牌并非受限令牌，它在公司的所有仓库、组织和软件包注册表中拥有完全的管理员权限。其权限范围包括高风险操作，如 write:packages、delete:packages、repo、delete_repo、admin:org，甚至 admin:enterprise。凭借此级别的访问权限，攻击者可以推送或删除软件包、更改 GitHub Actions 流水线、删除仓库以及修改关键的组织配置。实际上，该令牌授予了对源代码、CI/CD 工作流、密钥和供应链制品的完全“上帝级”控制权。

其影响远不止于被暴露的组织本身。如此规模的入侵可能为攻击者提供进入下游客户环境的初始立足点——特别是那些消费通过受影响仓库分发的模型、软件包或自动化工作流的客户。换言之，一个泄露的令牌可能成为供应链风险的放大器，在整个组织的客户生态系统中产生连锁影响。

6.2 个人密钥的暴露

有许多案例是个人账户用于兼职项目或私有环境。这些通常的特点是，要么暴露单个密钥，要么暴露大量密钥，这使个人及其技术栈面临严重风险。

6.3 与公司相关的个人账户暴露

虽然公司内部的registry通常会利用密钥扫描器、SAST、SCA 和其他工具进行严密监控，但那些包含公司密钥的外部账户，或更准确地说是影子 IT 账户，却几乎不受监控。这可能导致密钥暴露数年之久，而公司却无从知晓，也无力发现和修复这种情况。以下是我们研究期间发现的一些实际案例：

在其中一个案例中，我们关联了一个 Docker Hub 公共账户和一个承包商开发者的个人网站。他是一名自由职业者，为小型企业提供基于项目的网站或应用程序开发服务。该 Docker Hub 账户包含 70 个仓库，其中约 45% 的容器镜像持续更新，包括过去 30 天内；约 35% 在去年内更新过；其余的则更早。

这些容器的结构是相同的：在容器的文件系统中，有一个特定文件包含了数十个环境相关的密钥和secrets。

通常，这些密钥包括：云账户访问密钥（主要是 AWS）、S3 存储桶密钥（可访问整个项目的活动日志和制品）、数据库（通常是 PostgreSQL）凭证、应用程序的 API 密钥和机密、Google Analytics 密钥以及 OpenAI 密钥。

这些都属于组织的密钥，它们不属于自由职业承包商，但却完全脱离了组织的安全管控和监测范围。

在另一个引人注目的案例中，我们识别出一家《财富》500 强公司，其密钥通过一个个人公开的 Docker Hub 账户（很可能属于一名员工或承包商）被暴露。没有明显的标识将该仓库与个人或组织联系起来，但容器清单中包含了对多个内部环境具有访问权限的高度敏感凭证。此案例突显了一个严峻的现实：组织面临的风险越来越多地并非来自其受监控的官方基础设施，而是源于完全处于企业可见性、治理和安全控制之外的影子及个人仓库。

我采访了一位资深 DevOps 工程师，他作为自由职业者，在过去十多年里一直提供定制化的基础设施和软件开发生命周期解决方案。他描述了自己的工作流程：“我通常通过一家大型的承包供应商工作，他们为不同组织（从大型科技企业到新兴初创公司）提供经过审查的自由职业工程师。”

当我向他展示我们研究中发现的、经过脱敏处理的密钥样本时，他立刻反应道：“哦，这很糟糕。我合作的公司绝不会发生这种情况。他们会给你分配一个完整的组织身份，并且只在加固过的环境中提供访问密钥。很多公司甚至会给你一台加固过的公司笔记本电脑，强制 VPN 路由，部署终端监控和严格的安全控制。”

我们的发现中还揭露了另一个特别令人担忧的案例：某大型国家银行的首席软件架构师个人拥有的容器registry。该registry包含数百个容器镜像，其中几个包含已暴露的 AI API 令牌。虽然仅存在 AI 相关密钥就可能造成损害，但更令人担忧的问题是，与这家银行相关的超过 430 个容器镜像都是公开可见的，没有任何有效的访问控制、审计或验证机制。实际上，这意味着不仅该架构师的实验性或个人项目（还可能包括核心基础设施组件）暴露在全球互联网上，这为进入该国最重要的金融机构之一开辟了一条高价值的攻击路径。

七、从开发者/DevOps 视角解析这些发现

本文描述的所有泄露密钥都是在公共 Docker Hub 仓库中发现的。以下示例反映了一种典型的构建和推送 Docker 容器镜像的开发工作流程模式，更重要的是，它揭示了那些无意中暴露敏感信息的常见错误。

我们观察到的最常见错误之一是：在本地开发期间使用 .env 文件存储环境变量和密钥。开发者通常会创建一个 .env 文件，其中包含运行项目所需的数据库凭证、云访问密钥、令牌和其他认证材料。对于大型应用程序，此文件可能包含数十个涉及多个外部集成的密钥。一个典型的项目目录可能如下所示：

而一个 .env 文件的内容可能是这样的：

随后，你会使用 Dockerfile 将其构建到 Docker 容器镜像中。

在整个项目目录被复制到 Docker 构建过程中时，.env 文件常常被无意包含进去，从而将其中的所有密钥直接嵌入到容器文件系统中。

即使生成的镜像存储在私有registry中，这仍然是一种高风险做法；一旦该registry被入侵，这些密钥将立即暴露，并使攻击者能够在组织内横向移动。

一个更危险的场景是，无论有意还是无意，此类镜像被推送到公共仓库。这就是为什么在发布容器镜像前对其进行密钥扫描和清理至关重要，无论这些镜像是打算私用还是公开。

我们同样在其他文件类型中反复观察到类似的泄露模式。例如，Python 应用程序文件以明文形式硬编码了 AI API 令牌。这些凭证没有经过任何有意义的加密、混淆或保护。

我们发现的另一个常见暴露载体是密钥直接存在于 Dockerfile 本身中。在这些情况下，密钥可能最终不会进入容器内部，但它们仍然会通过镜像清单（manifest ）暴露，并且在 Docker Hub 上可见，实际上使任何获取镜像元数据的人都能公开访问它们。

当密钥被嵌入 Dockerfile 或容器构建上下文中时，它们通常会直接在 Docker Hub 页面上可见，实际上暴露给整个互联网，并且经常被自动扫描器、机器人以及搜索初始访问途径的威胁行为者所收集。

但是，当这种暴露是意外发生时，会发生什么呢？我们的研究表明，大约 25% 的开发者会在 1-2 天内从他们的容器或清单中移除已暴露的密钥。虽然这种反应令人鼓舞，但仍然不够，因为在大多数情况下，相关的凭证并未被撤销，这意味着即使可见的泄露被“修复”，该密钥仍然完全有效且可利用。开发者通常认为事件已经补救，仅仅是因为他们删除了引用——而实际上，密钥本身仍在有效运行，并仍掌握在攻击者手中。

一种好得多的做法是：完全避免在构建时嵌入密钥。相反，仅在运行时通过环境变量注入它们，例如：

这种方法消除了容器或清单内部的静态凭证存储，显著降低了意外暴露的风险——因为密钥根本不存在于registry或制品中。

八、将攻击活动映射到 MITRE ATT&CK 框架

我们的研究展示了过去的攻击者如何利用密钥来攻击组织。作为密钥暴露的一部分，攻击者在获取密钥后会利用一些实际和潜在的常见技术。以下我们将博文中出现的每个组成部分映射到MITRE ATT&CK 框架[4]的相应技术：

| 初始访问 | 执行 | 凭证访问 | 发现 | 影响 |
| — | — | — | — | — |
| 有效账户 (T1078) | 命令和脚本解释器：Windows (T1059.003) | 不安全凭证 (T1552) | 系统信息发现 (T1082) | 数据销毁 (T1485) |
| 供应链攻击 (T1195) | 命令和脚本解释器：Unix Shell (T1059.004) | 来自密码存储的凭证 (T1555) | 文件和目录发现 (T1083) | 数据加密 (T1486) |
| 外部远程服务 (T1133) | 命令和脚本解释器：Python (T1059.006) | 创建或修改系统进程 (T1543.002) | 云服务发现 (T1082) | 服务停止 (T1489) |
| N/A | N/A | N/A | N/A | 资源劫持 (T1496) |

九、使用 Flare 的定制化解决方案

由于 Flare 正在索引来自开源、深网和暗网的多个数据流，包括 GitHub、Docker Hub 和 Pastebin 网站。此外，Flare 还会扫描各种文件、S3 存储桶以及容器镜像各层内的 Docker Hub 文件，这为发现潜在的密钥暴露创建了完美的多源信息融合，无论这些密钥是来自组织仓库、承包商、自由职业者还是员工。

您可以登录平台并开始处理告警。如果您的组织规模较小，密钥和令牌不多，可以遵循以下简短流程来设置告警。

1. 1. 选择标识符。在主面板中，您应选择”标识符”。

1. 2. 您可以创建标识符。您可以选择 Azure 租户开箱即用的选项，并定义您的租户 ID。

如下方截图所示，定义一个关键词，可以是 GitHub 令牌、AWS 密钥或任何您想要的内容。

最后，您将获得一个如下方截图所示的标识符列表。

1. 3. 创建通知渠道。转到”告警”并选择创建告警。如果您尚未定义通知渠道（告警将发送到此处），系统会要求您创建一个。我们选择将告警发送到公司安全团队的邮箱。

1. 4. 创建告警。在此阶段，您可以定义告警并选择合适的严重级别。当告警并非针对特定的密钥、secrets或域名时，我们建议使用高或严重级别。但是，如果您正在为组织特有的特定值（如特定密钥、secrets或内部域名）配置告警，您可以根据操作需要分配任何严重级别。

然而，一个更现实的场景是组织需要管理数百甚至数千个 API 密钥、令牌和唯一标识符。通过利用 Flare 的 API，您可以注册一个 API 密钥，并大规模自动化搜索组织的敏感值。例如，您可以编写一个脚本，从您的 AWS、Azure、GCP 和其他secrets保险库中收集密钥，然后查询 Flare API 以检查是否有任何密钥已出现在公开环境中。这种方法提供了持续、可编程的监控，用于在外部威胁环境中探测凭证泄露情况。

十、给安全团队的缓解建议

我们的研究揭示了一个核心事实：密钥泄露并非罕见事故——它是可预测的、结构性的系统性问题。因此，缓解措施也必须是系统性的，涵盖文化实践、技术控制和架构重新设计。

10.1 切勿在容器中存储密钥

任何密钥都不应存在于容器镜像内部。杜绝。

以下是一些常包含密钥的文件类型：

• • .env 文件
• • Python 文件
• • config.json 文件
• • YAML 配置文件
• • Dockerfiles
• • 工作区目录
• • Docker Hub 上的组件清单

如果一个容器镜像包含密钥，它就已经处于被入侵状态。容器只应在运行时外部引用密钥。

10.2 停止使用静态、长期有效的凭证

转向基于会话的短期认证。长期有效的令牌是持续性风险的根源。现代的防御模式是使用临时身份。组织应替换以下凭证：

• • AWS_SECRET_ACCESS_KEY
• • 长期有效的 GITHUB_TOKEN
• • AZURE_CLIENT_SECRET
• • service_account_key.json

改用基于会话的访问模型，例如：

• • 使用 IAM Identity Center 的 AWS SSO
• • 结合 MFA 的 AWS STS AssumeRole
• • GCP Workforce Identity Federation
• • Azure AD 托管标识
• • Keycloak OpenID Connect
• • Okta / Auth0 的临时访问令牌

这些方法支持即时访问、时限性密钥，并能防止凭证持久化。

10.3 集中化管理密钥

开发者通常将密钥存储在便利之处。相反，组织必须采用集中化的密钥库，例如：

• • AWS Secrets Manager
• • GCP Secret Manager
• • Azure Key Vault
• • HashiCorp Vault
• • 1Password Connect
• • CyberArk Conjur

10.4 实施持续扫描

密钥可能在构建、调试、CI/CD 流水线、本地测试、容器化等过程中泄露。

组织必须跨多个供应商、平台和技术扫描各种环境。有时，犯错的操作员会删除泄露内容，但它通常会保留在镜像仓库、爬虫数据库等地方。因此，您需要覆盖源代码仓库、容器镜像、软件包注册表、提交历史、构建日志和临时环境。

因此，像 Flare 这种提供广泛可见性和历史记忆功能的、基于 API 的密钥检测工具，为此类情况提供了更优的解决方案。

一旦发现，密钥应在攻击者发现之前就被检测到并撤销，而不是之后。

10.5 强制执行即时撤销与轮换流程

当密钥泄露时，计时便已开始，攻击者会持续扫描——以分钟而非天计。因此，最佳实践是：

• • 自动撤销泄露的密钥
• • 自动轮换新生成的凭证
• • 使旧会话失效
• • 审计日志以查找未授权访问

我们研究中的一个关键失败模式是：大约 25% 的开发者从 Docker Hub 移除了泄露的密钥，但并未撤销底层凭证。他们以为自己安全了——实则不然。

10.6 获取影子 IT 的可见性

监控个人 registry 和承包商账户。我们的研究表明这是一个主要的盲点。

公司密钥经常通过以下途径暴露：

• • 员工的个人 Docker Hub 账户
• • 承包商的代码仓库
• • 自由职业开发者的资产
• • 未经管理的外部命名空间

组织需要：

• • 外部命名空间监控
• • 身份关联启发式分析
• • 跨 registry 监控
• • 泄露的域名、API 和内部路径的关联分析
• • 实时发现”非官方”的制品流水线

Flare 正是通过扫描外部容器，并将暴露的密钥与公司身份进行关联来实现这一点——即使这些密钥源自官方基础设施之外。

10.7 教育开发者

随着组织必须不断适应思维模式转变和责任归属，安全左移在持续进行。在容器中发布密钥不仅仅是技术错误，更是思维模式错误。

必须对开发者进行培训：

• • 切勿将密钥嵌入代码
• • 切勿将其存储在磁盘上
• • 切勿为了方便而将其粘贴到文件中
• • 默认假设所有环境都可能已被入侵

十一、使用 Flare 监控泄露的密钥

若想更深入地了解这些发现，并学习如何保护您的组织免受大规模凭证泄露的影响，请参加我们即将举行的认证从业者专场会议：

Docker Hub 上的大规模密钥暴露：关键发现与您需要了解的信息
12月18日，东部时间上午 9:00–9:30 | Flare Academy Discord 服务器

尚未认证？通过 Flare Academy 成为认证社区成员[5]，以获取独家研究报告、从业者培训和实战资源。

已经认证？该活动已列在 Flare Academy Discord[6] 中，并在认证频道中持续更新。我们期待与您相见。

引用链接

[1] 《Thousands of Exposed Secrets Found on Docker Hub, Putting Organizations at Risk》: https://flare.io/learn/resources/docker-hub-secrets-exposed/
[2] 详情请见此处: https://www.wiz.io/blog/shai-hulud-2-0-aftermath-ongoing-supply-chain-attack
[3] 详情请见此处: https://www.aquasec.com/blog/github-action-tj-actions-changed-files-compromised/
[4] MITRE ATT&CK 框架: https://attack.mitre.org/
[5] 成为认证社区成员: https://try.flare.io/become-a-verified-community-member/
[6] Flare Academy Discord: https://flare.io/discord

交流群

---

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：云原生安全指北 Dubito《Docker Hub上数千泄露密钥正将企业置于风险之中》