Docker官方宣布将Docker强化版镜像免费开源
对于大多数开发者而言，容器已成为通往生产环境的通用路径，而 Docker 一直是该生态系统的守护者。Docker Hub 每月拉取量超过 200 亿次，近 90% 的企业现已在软件交付流程中依赖容器技术。这赋予了我们一份责任：为全球软件供应链提供安全保障。
为何如此？供应链攻击正呈爆发式增长。2025年，此类攻击造成的损失超过600亿美元，较2021年增长三倍。无人能幸免——每种编程语言、每个生态系统、每个构建与分发环节都可能成为攻击目标。
为此，我们在2025年5月推出Docker强化镜像(DHI)——一套安全、精简、可直接投入生产环境的镜像集合。迄今我们已强化目录中逾1000个镜像及Helm图表。今日，我们通过向所有软件开发者免费开放DHI，确立了全新的行业标准。这意味着容器生态系统中2600多万开发者均可受益。DHI完全开放且免费使用、共享与扩展，无任何许可陷阱，并采用Apache 2.0许可证保障。从首次拉取开始，DHI便为全球用户提供安全、精简、可直接投入生产的基础架构。
若您觉得难以置信，请看核心要点：每位开发者和每款应用程序均可(且应当！)无限制使用DHI。当您需要持续安全补丁(7日内完成部署)、受监管行业专用镜像(如FIPS、FedRAMP认证)、在安全构建基础设施上定制镜像，或需要终止支持后的安全补丁时，DHI提供商业化解决方案。简单明了。
自DHI推出以来，Adobe和高通等企业已选择Docker来保障整个企业安全，以满足最严格的合规要求；而Attentive和Octopus Deploy等初创公司则加速了合规进程，成功拓展大型企业客户。
如今，所有应用程序都能从首次docker build开始实现安全构建。不同于其他不透明或专有强化镜像，DHI兼容Alpine和Debian——这些值得信赖且熟悉的开源基础架构，团队无需大幅改动即可采用。当某些供应商为维持扫描结果绿色而隐瞒CVE漏洞时，Docker始终保持透明，即使补丁仍在开发中，因为我们坚信您应随时掌握自身安全态势。成果显而易见：CVE漏洞数量大幅减少(DHI企业版可实现近零漏洞保障)，镜像体积缩减高达95%，同时在不牺牲透明度与信任的前提下实现安全默认配置。
我们还打造了强化版Helm图表，助力Kubernetes环境应用DHI镜像——这些图表同样开源。今日，我们更以强化版MCP服务器拓展这一基础架构。我们将DHI的安全理念引入MCP接口层——这是所有代理应用的核心支柱。即日起，您可运行开发者最常使用的强化版MCP服务器：Mongo、Grafana、GitHub等。这仅仅是开始。未来数月，我们将通过强化库、强化系统包及其他关键安全组件，将强化基础架构扩展至整个软件栈。目标很明确：从main()开始全面守护应用安全。
Docker强化镜像的哲学
基础镜像从底层定义应用安全性，因此必须精准掌控其构成。我们的方法如下：
首要原则：在极简、有主见且安全的镜像中实现全面透明。
DHI采用无发行版运行时，在保留开发者依赖工具的同时缩小攻击面。但安全不仅是极简主义，更需要完全透明。太多供应商通过专有CVE评分、弱化漏洞风险或模糊承诺达到SLSA构建三级来模糊真相。
DHI另辟蹊径：每张镜像均附完整可验证的SBOM清单；每次构建都提供SLSA构建等级3溯源信息；所有漏洞均基于透明公开的CVE数据评估——未修复漏洞绝不隐瞒；每张镜像都附带真实性证明。最终呈现的是值得信赖的安全基石：以清晰构建、凭证据验证、零妥协交付。
其次：迁移至安全镜像需要实际工作，任何人都不能对此视而不见。但正如您对Docker的期待，我们始终致力于打造极简易用的开发体验。正如先前所述，DHI基于全球信赖的开源基础——Debian和Alpine构建，因此团队能以最小阻力完成迁移。 我们正进一步降低迁移门槛：Docker人工智能助手可扫描现有容器，推荐甚至自动应用等效的强化镜像；该功能目前处于实验阶段，但我们将基于实际迁移案例快速实现正式发布。
最后：我们制定了最严格的服务等级协议(SLA)和最长的支持周期，确保DHI的每个组件都能在您需要时提供相应支持。
DHI企业版作为DHI的商业解决方案，承诺在7天内完成关键CVE漏洞修复，并计划将响应时间缩短至1天以内。对于受监管行业和关键任务系统而言，这种信任度是必需的。实现这一目标绝非易事。这需要深度测试自动化能力，以及在补丁被上游接受前维持分支版本的能力。正因如此，多数组织无法独立实现。此外，DHI Enterprise支持组织轻松定制DHI镜像，借助Docker构建基础设施为您管理完整镜像生命周期，确保构建溯源与合规性。例如，组织通常需要添加证书密钥、系统包、脚本等组件。DHI构建服务让这些操作变得轻而易举。
由于补丁服务等级协议(SLA)和构建服务涉及实际运营成本，DHI历来作为商业产品提供。但我们的愿景始终更为宏大——这种级别的安全防护应当普惠大众，时机至关重要。如今随着证据体系、基础设施和行业合作伙伴关系的完善，我们正践行这一愿景。因此今日宣布将Docker强化镜像免费开源。
此举承袭了十余年前定义 Docker 官方镜像的精神内核。我们使其免费开放，持续提供清晰文档、最佳实践和稳定维护。这一基石成为数百万开发者与合作伙伴的起点。
如今我们再次践行这一理念。DHI的免费开放得益于快速壮大的合作伙伴生态：从Google、MongoDB和CNCF提供强化镜像，到Snyk、JFrog Xray等安全平台直接将其集成至扫描器。我们正携手构建统一的端到端供应链，为整个行业树立更高的安全基准。
“Docker将强化镜像以Apache 2.0许可证免费开放，彰显其对开源生态的坚定承诺。众多CNCF项目已入驻DHI目录，向更广泛的社区提供安全可靠的构建模块，将助力我们共同强化软件供应链。见证Docker持续投入开放协作与安全容器基础设施建设，令人振奋。”
Jonathan Bryce
云原生计算基金会执行董事
“软件供应链攻击是行业面临的严峻挑战。让Docker强化镜像免费普及，将使正确之事成为易事，从而推动全行业实现更快速、更安全的软件交付。”
James Governor
RedMonk分析师兼联合创始人
“安全不应是付费功能。通过免费提供强化镜像，Docker让每位开发者(而非仅限大型企业)都能立足更安全的基石。我们热衷于采用能减少噪音和繁琐操作的工具，并已准备好从第一天起就在谷歌云上运行这些安全工作负载。”
瑞安·J·萨尔瓦
谷歌开发者体验产品高级总监
# “MongoDB坚信开源技术在现代软件构建中发挥核心作用，它赋予灵活性、选择权和开发者生产力。因此我们对免费开放的MongoDB强化Docker镜像倍感振奋。这些镜像基于Alpine和Debian等成熟Linux底层，提供可信赖的即用型构建模块，并采用Apache 2.0许可证确保完全开源且免费开放使用。依托 Docker Hub 的全球覆盖范围与 MongoDB 对可靠性及安全性的承诺，我们正致力于打造更便捷的开发环境，让您能够在安全开放的未来基石上充满信心地构建应用。”
Jim Scharf
MongoDB 首席技术官
“我们很高兴与Docker合作，为从开发到生产环境提供安全的企业级AI工作负载。凭借超过5000万用户以及众多财富500强企业信赖Anaconda来保障其企业级安全运营，此次与Docker的合作将同样的基础架构引入Docker强化镜像。这使团队能减少风险管理时间，专注创新，同时缩短从构想到生产的周期。”
David DeSanto
Anaconda首席执行官
“Socket能在安装时拦截恶意软件包，而Docker强化镜像(DHI)为这些软件包提供了可信赖的运行环境。借助免费DHI，团队无需额外操作即可获得双重防护。拉取强化镜像后执行npm install，内置于DHI的Socket防火墙便自动生效。这才是真正的默认安全模式，我们很高兴与Docker合作，在他们的规模体系中实现这一愿景。”
Feross Aboukhadijeh
Socket 创始人兼首席执行官
“使用 Temporal 构建的团队需要协调关键任务工作流，而 Docker 正是他们将这些服务部署到生产环境的途径。免费提供 Docker 强化镜像为用户的工作流奠定了坚实基础，而扩展生命周期支持则帮助他们长期保障系统安全，无需频繁重构平台。”
Maxim Fateev
Temporal首席技术官
“在CircleCI，我们深知团队需要以生成代码同样的速度验证代码——而这始于可信赖的基础。Docker强化镜像通过从源头提供预先加固且持续验证的组件，消除了关键验证瓶颈，助力团队快速交付，信心十足。”
罗布·祖伯
CircleCI 首席技术官
“我们评估了多种强化基础镜像方案，最终选择 Docker 强化镜像(DHI)，因其契合我们的供应链安全策略、开发工具兼容性、Docker 在该领域的成熟度，以及与现有基础设施的集成能力。我们的核心考量在于平衡信任度、可维护性与生态兼容性。”
维克拉姆·塞西
Adobe首席科学家
“开发者理应获得既安全又高效的基础保障。Docker通过免费开放强化镜像，让软件供应链从源头保障安全变得前所未有的简单。这有助于在代码进入生产环境前消除风险，这与LocalStack的使命高度契合。LocalStack团队尤其期待开发者能将这些强化版精简镜像应用于我们的模拟器，助力团队彻底摆脱持续应对CVE漏洞的困境。”
Waldemar Hummer
LocalStack联合创始人兼首席技术官
为每个团队和企业铺就安全之路
如今，DHI为所有人提供了安全的起点。但不同规模的企业往往需要更多保障。合规要求与风险容忍度可能要求在源代码可用时立即部署CVE补丁。企业级或政府机构必须满足FIPS或STIG等严格标准。由于生产环境永不停歇，许多组织需要在上游支持终止后仍能持续进行安全补丁更新。
为此我们推出三种DHI方案，分别针对不同的安全场景：
**Docker强化镜像：**全民免费。DHI是现代软件应有的基石：最小化强化镜像、便捷迁移、完全透明，并基于Alpine和Debian构建开放生态。
**Docker强化镜像(DHI)企业版：**为面临严格安全或监管要求的组织、政府及机构提供可靠保障。支持FIPS认证与STIG标准的镜像，符合CIS基准规范。针对关键CVE漏洞提供7天内修复的SLA保障，且随着我们向1天(或更短)关键修复目标推进，SLA周期将持续缩短。
需要更多控制权的团队，DHI企业版可满足需求：修改镜像、配置运行时环境、安装curl等工具、添加证书。DHI Enterprise赋予您无限定制权限、完整目录访问权，让您在保障安全的前提下按需塑造镜像。
**DHI延长生命周期支持(ELS)：**ELS作为DHI Enterprise的付费扩展服务，专为解决软件领域最棘手的问题而生。当上游支持终止时，补丁停止更新但漏洞持续存在。扫描器发出警报，审计人员要求解答，合规框架期待验证修复方案。ELS通过提供长达五年的额外安全保障、持续的CVE补丁更新、SBOM与溯源信息维护，以及持续签名与合规可审计性，彻底打破这一恶性循环。
更多方案详情请参阅此处。
入门指南
保障容器生态系统的安全是我们共同的责任。今天，我们为全球用户提供了更坚实的基础架构。现在，我们希望每位开发者、每个开源项目、每家软件供应商和每个平台都将强化版Docker镜像设为默认选项。
最后，我们才刚刚起步。若您正在阅读本文并希望共同构建容器安全的未来，我们期待与您相遇。加入我们
本文文字及图片出自 A Safer Container Ecosystem with Docker: Free Docker Hardened Images
> 开源
在哪里？随便举个例子：https://hub.docker.com/hardened-images/catalog/dhi/traefik
好的，源代码在哪里？开源意味着我可以自己构建它，也许是因为我在离线/空气隔离/高合规性环境中工作。
我找到一个“目录”https://github.com/docker-hardened-images/catalog/blob/main/…，但这并非构建文件，而是某种… 专用DHI构建工具？在https://github.com/docker-hardened-images上找不到任何文档指导我自行构建，也找不到任何“dhi”工具。
您好。是的，我们计划全面开放构建工具的访问权限。您看到的构建文件是为实现可重复构建而开发的新格式。这是构建工具集(buildkit)的新前端，可配合docker build使用。团队正全力推进该工具的开放，届时您即可在本地环境创建、构建和修改镜像。该功能预计再过几天即可上线。
使用任何现代容器构建系统(包括Docker)实现可重复构建时，您无需定制化Buildkit前端。
在Stagex项目中，我们仅使用makefile和Containerfile文件，通过原生Docker/Buildkit即可轻松实现镜像的完全可复现构建(生成相同校验值)并支持流程审计。唯一非默认配置是启用Docker发行版自带的containerd后端，这能在不推送至镜像仓库的情况下生成确定性校验值，确保跨所有仓库的镜像校验值一致。
此外，我们的镜像采用容器原生构建模式，即全程“从零开始”构建，完全规避了对Debian或Alpine等上游构建系统的依赖——这些系统存在不可预测的包管理机制，且依赖单点故障的维护者信任链。
近期我们将转向LLVM原生构建，大幅简化多架构镜像的构建复杂性。通过单一镜像即可轻松实现跨平台交叉编译。
坦白说，若Docker直接将这些镜像作为官方镜像白标发布，我们绝不会介意——我们的目标是推动互联网摆脱高风险且难以审计的供应链，而非像当前所有解决方案那样仅关注“最后一公里”的供应链完整性。
https://stagex.tools
哇，“强化镜像”市场快饱和了。Kubecon上至少看到三家公司提供这类服务。
Chainguard是先行者(或许是偶然发现的——他们早有其他产品线，直到意识到用户竟愿意为零漏洞报告的镜像付费(?!!))。
我之前任职时发现，这类服务对初创企业的价值巨大。大型企业交易常因安全团队一句“扫描器显示无漏洞”而告吹。Chainguard提供的零漏洞镜像能彻底消除这种障碍。
例如我曾遭遇的常见高危漏洞——glibc漏洞。尽管我们能充分证明应用未使用该库的漏洞利用方式，但高危漏洞标签本身就足以让多数安全团队止步。迁移到Wolfi镜像后，扫描器显示0漏洞。很酷。
但随着Minimus(Twistlock创始人团队)等机构加入，这个领域即将变得拥挤。
甚至还有名为Ironbank的政府项目，计划为国防部提供类似服务。
这对生态系统是净收益，但我不确定市场能否支撑这么多供应商。
真正的问题不在于市场是否饱和，而在于当Docker免费开放核心价值主张后，这个市场是否还能存在。
鉴于Docker的过往记录，免费策略不会永久持续，此举旨在测评需求并获取潜在客户。
好消息，你现在就能付费使用它 😉
https://docs.docker.com/dhi/features/#dhi-enterprise-subscri…
可能性极大。许多企业只信任付费订阅服务。
为“安全”付费能带来风险规避效益——我们支付X费用换取Y的安全版本，因此若发生“意外事故”便不归咎于己。
反驳观点：大概率不是。关键在于扫描器发现的高危漏洞会引发连锁影响，比如导致SoC2审计失败的风险。一旦这种风险消除，付费订阅的价值主张也就不复存在。
F500企业信赖付费订阅模式，因为这意味着问题可被升级处理——作为付费客户，一旦系统崩溃就能获得支持——同时还能借此转移责任或确保合规。
记得在某家你听说过的大公司担任基础设施主管时，曾耗费整整一个月与采购部门周旋，才为一个CCPA合规项目搞定6个Mirantis/Docker许可证。
我认为此处情况不同。降低CVE数量的真正动机是宣称“我们合规”或“事故非我方责任，我们使用强化镜像”。付费并不能改变本质——SOC2认证关注的是补丁策略而非支出金额，这使得合规勾选变得毫无成本。
差异化定位确实棘手。Chainguard正向虚拟机镜像和编程语言仓库扩展，但强化容器镜像的核心领域已有众多选择。
我更关注的是：在合规要求不高的市场中，这类付费服务究竟存在多少需求…
用户虽青睐低CVE风险的镜像，但愿否为此付费？我认为这恰是Docker方案的优势——免费模式相较商业产品能降低用户尝试门槛。
> 除合规要求严苛的市场外
这涵盖所有希望向美国政府(及可能其他政府)销售产品的企业。
FedRAMP本质上[1]要求使用“强化版”镜像。
[1]：虽非强制要求，但若不采用强化镜像，通过安全扫描和FIPS合规性认证将更为困难。
若向客户分发镜像，避免因无关紧要但足以引发恐慌的CVE漏洞被投诉，将带来巨大优势。
即便是SaaS服务商。部分客户会追问镜像中已知漏洞，若能快速展示修复计划，将显著提升交易成功率。
这取决于企业类型。若在大型传统企业中自建系统却存在漏洞，你将被解雇；若付费购买第三方服务出现漏洞，则可归咎于供应商。
理论上或许如此，但我敢打赌大多数恐龙级机构积压的未修复漏洞多到——光是处理高危漏洞就得开除整个IT部门的人。
> 政府甚至有个名为Ironbank的项目，为国防部提供类似服务。
需注意：使用Iron Bank镜像并非国防部专属。其他组织也可使用，但需注册账户。
许多IronBank镜像存在CVE漏洞，因为它们基于ubi8/9系统——即使部分采用ubi8/9-micro底层，仍存在漏洞。IronBank会处理高危漏洞，用户可通过漏洞追踪工具获取免费报告。
部分镜像(如Vault)功能较为基础(例如不提供shell)。
我是VulnFree的CEO。
虽不确定Chainguard是否首创，但他们确实较早进入该领域。公司初创时我们关注的核心痛点是定价问题，但后来发现市场存在大量未被填补的空白，因此调整了业务方向。
Ironbank其实在Chainguard出现前就已开展此类服务，正如其他用户所言，其服务不仅限于国防部，任何人都可免费使用(需注册账户)。
我们公司开发的竞品本质上是相同功能，且我们(尤其是我本人)深度参与了早期Platform One的建设。虽然我们将其作为产品销售，但它本质上只是现有软件订阅的免费附加组件，作为促成购买的额外诱因，本身并不产生额外费用。
无论如何，我对Docker表示赞赏。这其实是个令人意外地沮丧的过程，因为你无法总是简单地将代码重新基准到预先加固的基础镜像上就让一切正常运行——除非你仔细研究过所交付的应用程序(而这并非你自己的应用)。这始终是我对Ironbank最大的不满之处，也是我不推荐任何人实际使用它的原因。他们频繁破坏容器，因为所谓的强化措施只是将二进制文件从上游镜像复制到每日打补丁的UBI容器中，以确保其永远不存在CVE漏洞。有时这能奏效，但更多时候会出问题——这种情况相当可预测，比如每当Fedora采用RHEL尚未更新的glibc版本时，所有关联链接的程序在跨版本复制时就会开始段错误。我多次指出这些问题，他们却始终不改。更糟的是，他们每日修补相同应用版本时还会破坏标签，而Harbor仅保留三个与标签脱钩的孤立SHA值，导致无法通过SHA值固定版本。
简而言之，我虽不确定具体实施细节，但实际需求确实存在且日益增长——至少在政府及受监管行业中如此，因为政府本身正强制要求更完善的供应链溯源机制。坦白说我认为这并不完全合理。终端客户似乎未能理解： 我们签名容器镜像的意义在于“构建”——即按json文件描述整合tar包序列，但我们交付的应用并非自主开发，运行在同样非自主开发的GNU/Linux基础镜像之上，尽管能保证所有员工均为美国本土公民，我们交付的终究是开源软件。它凝聚着全球各大洲数千人的心血，其贡献历史可追溯至数十年前。
遗憾的是，许多客户和销售人员都不真正理解开源生态系统的运作机制，他们提出并承诺的许多要求本质上根本无法实现。尽管如此，我们至少能提供比应用程序创建者更频繁地修补镜像中非应用组件的价值——毕竟原始镜像是由他们提交到公共仓库的。个人认为这并非巨大价值，但确有价值。我目睹过Ironbank对此的严重误操作，因此正确实施本身就具有价值。
不过我推测，这种服务多数情况下只能作为其他订阅服务的免费附加项存在。很难相信它能独立成为可持续的商业模式。Chainguard或许勉强维持着运营，但感觉他们更像是靠创始人过往声誉撑起的投资宠儿，而非当前产品本身。这相当于容器生态中的企业Linux发行版销售模式——至少Redhat、SUSE和Canonical都成功过，但绝非仅靠发行版本身，而是需要配套产品、技术支持及专业服务。
不过对现有Linux发行版厂商来说，在此基础上拓展业务简直是明智之举。毕竟构建基础设施、组织流程和系统都已就绪。
我是VulnFree的CEO。
我曾与Iron Bank的安全团队有过接触。上次我们深入分析Iron Bank的镜像时，发现其质量远逊于多数供应商的产品——他们只是敷衍地满足了STIG标准。
大家好，我是Docker员工。非常感谢这场深入的讨论。我们很高兴将强化镜像免费开放，因为我们坚信“默认安全”应成为每位开发者的起点，而非后期附加功能。
透明度是我们的核心理念。因此每个镜像都附带VEX声明、详尽的验证报告及完整元数据，助您真正理解运行环境。我们致力于打造值得信赖的基础架构，而非仅提供更轻量化的基础镜像。
我们还将这一理念延伸至基础镜像之外，涵盖MCP服务器及相关组件等内容——因为栈中可验证且默认强化组件越多，对整个生态系统越有利。
有网友质疑此模式的可持续性。简而言之：我们为企业用户提供专属层级服务，涵盖合同级持续补丁SLA、监管行业定制版(如FIPS认证)及具备完整溯源与验证的安全定制方案。这些服务涉及持续性成本，将其纳入企业层级使我们能为社区提供完全免费的强化版目录。
欣喜看到此处展开讨论。我们期待此举能助力团队以更强安全态势和更高信心交付软件。
Dockerfile采用何种格式？例如https://hub.docker.com/hardened-images/catalog/dhi/php/image…？它看起来与我见过的任何Dockerfile都截然不同。是否有工具能据此构建镜像？
这是我们为实现可重复构建而开发的新格式。它是在 buildkit 基础上构建的新前端，可配合 docker build 使用。团队正全力推进该工具的开放，届时您就能在本地环境创建、构建和修改镜像。功能上线仅需数日。
目前虽标榜免费，但正如注册表服务曾标榜“免费”，Docker Desktop也曾免费——直到它们不再免费。我并非反对Docker通过服务盈利(这是理所应当的)，但这种先免费提供服务、待广泛采用后再反悔的模式，让我对采用他们的任何产品都心存顾虑。
但愿此类案例能让企业下次变卦前三思：https://topclassactions.com/lawsuit-settlements/open-lawsuit…
更令人恼火的是，他们阻止用户配置软件以跳过其官方注册表。
红帽为此专门开发了Podman来实现用户需求。
初步观察发现这并非简单的替代方案。首先需要登录验证，令人费解为何必须如此操作，或许暗藏增值销售的意图。
随着Bitnami终止服务，我们近期已转向其他供应商。部分软件我们采用Helm图表部署，而新方案虽提供部分Helm图表，但某些软件仅提供镜像。我本有意尝试，但发现例如Python镜像仅提供各种“(dev)”版本，而指南提及的是非开发版镜像。这需要提前规划。
编辑：深入研究后发现，该方案要求使用PAT，而PAT绑定在个人账户上。我猜想需要企业版才能获得组织支持。但作为初创公司，我不会浪费时间联系他们申请企业版。那些经过CVE加固的镜像，若无法在CICD环境正常运行而只能在开发机上使用，其适用场景是什么？是否存在需要遵循合规规则或需要此类安全保障，却尚未部署CICD的企业？
据我所知Docker for Teams是每月15美元/席位。https://www.docker.com/pricing/
企业级强化镜像许可似乎是针对离线镜像或更严格合规要求的独立方案…
CVE强化镜像的核心价值在于：即便采用CI/CD，大规模环境中仍难以确保个人操作的准确性。团队需自行构建扫描与更新流程，实际操作中常出现版本固定、修复延迟、扫描功能关闭等情况。这套方案堪称简易模式
恰逢Bitnami撤下“免费强化镜像”，此事颇具戏剧性。我同样担忧未来可能发生的(虽迟但必至的)地毯式撤资。Docker公司历来热衷于典型的风投/增长驱动策略：
1. 初期“慷慨”提供服务以建立用户群/生态系统/网络效应
2. “哎呀哎呀，我们不得不开始收费了，抱歉——我们知道你们可能已围绕这个构建了大量基础设施”
3. $$$
我们刚把大量基础设施从Bitnami镜像和Charts迁出；绝不会重蹈覆辙，而Docker正是罪魁祸首。
我是强化镜像公司VulnFree的CEO。
我们认为这主要是Docker为阻断Chainguard发展势头而采取的营销策略。
容器安全领域更深层的问题在于缺乏真正创新。多数产品只是对Chainguard已验证方案的增量改进(且性能更差)。
去年二月Chainguard融资轮引发业界广泛关注后，“安全镜像”领域随即迎来抢滩热潮。我们深有体会——风投机构持续不断地联系我们。这反过来促使Bitnami尝试将历史免费镜像商业化，而Docker则推出免费镜像填补Bitnami商业化后留下的空白。
我们密切关注着Docker的动向，推测他们在推出“Docker强化镜像”后，很快意识到向行业销售这类产品远比最初预想的困难得多。
在这个领域鲜少共享源代码的原因很简单：一旦开源，强化镜像行业的准入壁垒便基本消失。
说实话，按当前定价来看，你付出的费用完全是为提升工作效率买单。根据我掌握的所有公开价格数据，自主构建强化镜像的成本远低于向供应商采购。
VulnFree的技术方案定价虽低于自建成本，但真正的价值在于通过定制化强化镜像满足开发团队的实际需求。
最新动态：Docker强化镜像(DHI)现已全面免费开放。没有理由不使用它们。
为定制镜像提供强化服务，似乎是Docker获取稳定收入的合理途径。银行、保险公司或政府机构等受监管行业可能对此感兴趣。
上次他们将注册服务从近十年的完全免费突然改为收费项目，上演了一出“地毯抽走”的戏码，此后很难再信任任何免费服务。
行业内“诱饵式营销”的套路已屡见不鲜——待用户广泛采用后便突然变卦。
Docker这家企业我实在难以苛责。他们彻底革新了软件部署模式。容器技术势头如此之猛，反而让Docker被时代抛在身后，错失大量商机。在免费服务十年后开始收费，实在称不上“地毯式欺诈”——尤其当业界对Docker注册表的依赖正持续减弱。
我并非憎恨他们，但绝不愿在管理的产品中依赖其服务。
你了解Dagger吗？
这是Docker创始团队当前正在开发的项目
Dagger本是我想青睐的技术，但实际使用体验极其糟糕。
我试过但不喜欢。曾尝试转换我们一个Actions工作流，结果麻烦得要命，最后放弃了。现在这个项目似乎转向了AI领域。
嗯，其中之一。
考虑到他们为整个行业创造的财富和生产力，收取费用实至名归。他们不可能零摩擦地实现这一切。
我完全支持企业对成本投入的产品收费，但宣称免费后又反悔的策略风险极高。即便通过骚扰用户上司或破坏构建流程能卖出些许可用证，对方也绝不会感激你。
感觉他们想把猫放回袋子里，试图挽回注册库事件造成的用户流失。
项目无需支付集线器使用费
这是企业唯一理性的行为方式。但你们承诺过十年免费。许多公司诞生又消亡于十年间，全程享受着免费注册服务。若因政策可能十年后改变就放弃行动，任何事都无法完成。
这是何时的事？
对普通用户不成问题，但像我们这样的小团队——十余人维护约十余个公开镜像——每天部署十几个环境时就会触及拉取上限。我们只能自行缓存所有公共镜像来规避限制。
https://www.docker.com/blog/revisiting-docker-hub-policies-p…
若在临时性本地Kubernetes集群中进行测试，这便会成为问题
这是针对未认证用户的限制。直接登录不就行了？
https://www.docker.com/developers/free-team-faq/
> Docker是否将终止免费团队计划？
> 否。Docker曾于2023年3月14日宣布终止免费团队计划，但该决定已于2023年3月24日撤销。
对于拉取量巨大的开源项目，(免费的) dsos 计划将解除其公共镜像的所有速率限制。此举从未意图影响项目本身，而是针对将 Hub 作为免费托管平台的巨型企业：
https://www.docker.com/community/open-source/application/
我有点困惑，因为尝试拉取镜像时收到401错误。需要登录账号吗？免费镜像居然这么麻烦。
没错，我的docker.com凭证也失效了。
我是VulnFree的CEO。
Docker这纯属无病呻吟。Chainguard的价值远超Docker，这不过是场营销噱头(从开发者给我发消息的数量来看，显然奏效了)。
没有理由不用它们。
其实有充分理由：它们需要登录才能使用，这至少是多余的阻碍。让我瞬间从“哦，试试看”变成“算了，不麻烦了”。
这闻起来像是LLM生成的
Docker必须维护如此复杂的构建指令才能生成这些镜像：https://github.com/docker-hardened-images/catalog/blob/b5c7a…
与此同时，Nix已打包的软件数量已超越任何其他发行版，且其中绝大多数软件都能直接封装为容器镜像——无需额外依赖(即与上述方案同等程度的“强化”)，且完全无需针对每个软件包进行额外定制工作。
Nixpkgs仓库已包含构建与隔离输出的指令，庞大的缓存基础设施已就绪，构建过程高度可复现——Docker若想让自家工具达到同等水平，必须从零构建这些体系…而它背后缺乏Nix这样的强大社区支撑。
这是对Bitnami/VMWare/Broadcom Helm图表的回应吗？
Bitnami/VMWare/Broadcom Helm图表事件指什么？
我猜这是回应“Chainguard发展迅猛，尽管毫无AI业务，三年内仍让风投争相注资数亿美元”的现象。
我同意这个观点
强化镜像确实很酷，但我不太确定具体含义？是指应用最新补丁的系统，还是包含更严格的配置规则？例如：这些镜像能否缓解甚至阻止Shai-Hulud攻击[12]？
Docker强化镜像集成了Socket防火墙，可在构建阶段抵御Shai-Hulud等威胁。合作公告详见：https://socket.dev/blog/socket-firewall-now-available-in-doc…
Docker强化镜像采用最小化软件包从零构建，确保运行环境安全。这些强化镜像不含任何易受Shai-Hulud攻击的漏洞软件包。
https://www.docker.com/blog/security-that-moves-fast-dockers…
注：本人任职于 Docker
没错，但若你通过npm安装软件，安装后脚本是否会被执行？
强化基础镜像不会限制你添加的内容。这正是Docker Scout、Trivy、Grype等扫描工具的作用——它们会审查你构建的完整镜像。
当然？它们只关注基础镜像。你如何使用它完全是你的责任
这就像指望AWS保护你的EC2实例免受安装后脚本的侵害
区别在于这些工具需要额外付费，因此用户希望看到能向管理层证明其价值的效益。当前NPM相关事件引发广泛关注，自然会有人质疑：面对海量安全采购选项，现有方案能否阻断首席信息安全官(CISO)所担忧的风险？Docker员工曾提及一项相关特性：https://socket.dev/blog/socket-firewall-now-available-in-doc…
将类比更新为“类似EC2，但基础操作系统补丁和容器运行时由我们管理”，这就是Fargate。
我访问“强化镜像目录”搜索pgbouncer未果(https://hub.docker.com/hardened-images/catalog?search=pgboun…)
页面有“提交请求”按钮，但链接指向404错误的GitHub地址：https://github.com/docker-hardened-images/discussion/issues
唉，希望其他功能没问题。
感谢反馈，团队正在修复，正确网址应为：https://github.com/docker-hardened-images/catalog/issues/
我是VulnFree的CEO。
我们可以为您强化该镜像。标准配置每月800美元/镜像。欢迎通过联系表单联系我们，我们的自动化系统会立即通知我们，确保您获得快速响应(周末亦然)。
圣诞特惠价750美元即可完成
在$work，我们已将所有镜像迁移至Redhat的ubi镜像(微型版和精简版)。
不过我们已付费购买了技术支持。
Docker这波操作很贴心！
红帽于十月启动了类似计划：https://www.redhat.com/en/technologies/linux-platforms/enter…
比较官方镜像与强化版本的最佳/推荐方法是什么？这些差异能否默认整合到原始镜像中？具体想了解PostgreSQL这类组件的情况。
我欣赏他们的做法，这是其他厂商尚未采取的举措。
若您需要极简的LFS风格、全源代码引导、确定性、多方编译/签名的容器原生镜像，并支持整个依赖图的哈希固定，且永久免费——请关注stagex。
现有替代方案均无法满足我们构建的威胁模型需求(该模型不信任任何单一维护者或计算机)，因此我们从零开始重新打造。
https://stagex.tools
我尝试运行stagex并执行
make命令，在愉快的初始引导阶段之后，却眼睁睁看着它耗费数小时反复尝试下载gnulib(及其他众多GNU软件包)，最终全部超时失败。是否存在整合所有这些软件包的tarball或其他镜像？其大小应该仅相当于小型Linux发行版的源代码包。我还注意到它正在下载同一组软件包的大量不同版本，这对引导构建而言似乎很奇怪。最终我失去耐心终止了进程。当然，实际部署时我可能会从stage3容器开始，但目前亲自尝试的过程实在令人失望。
若我们自行打包所有源代码，谁又能保证我们没有篡改内容？这确实是个两难局面，但我们正与其他发行版合作推进解决方案：建立共享仓库存放这些(往往是遗留的)源代码，并为每个源代码分配通用swhid标识符，将其固定在stagex环境中，从而实现高度防篡改特性。
短期内我们已开始在archive.org和CERN进行归档，希望抓取脚本能尽快实现向这些平台的故障转移。
GNU服务器状况最差，时常数小时无法访问，且存在大量速率限制。
目前直接从上游收集所有源代码的做法虽有助于建立信任，却是最大的痛点。对此深表歉意！
超短期解决方案：加入#stagex:matrix.org频道，任何成员都乐意通过虫洞传输其“fetch”目录。
强化镜像就是移除所有非代码组件及运行代码所需的依赖
从零构建最理想，distroless也是绝佳选择
随后根据需要在容器外部署防火墙
不再需要chainguard/bitnami了吗？
Bitnami深陷博通地狱，没人该用它。
Chainguard的CVE响应速度仍更优，更能确保生产环境扫描器检测不到任何活跃漏洞。
(与两者均无关联，但我们公司用Chainguard，我之前也用过Bitnami直到彻底替换掉)
CVE响应速度难分伯仲，它们都补丁很快。Chainguard能保证零活跃漏洞仅因其掌控漏洞情报源，且在修复前绝不公开任何漏洞。这虽使其表现更优，但实际未必更优
嘿！
我在Chainguard工作。我们不保证零活跃漏洞，但针对CVE扫描结果提供合同级SLA保障(可惜两者并非完全等同)。
我们确实通过多个版本发布漏洞预警源供扫描器集成。传统格式(当时多数扫描器支持)无法包含待处理信息，因此无法纳入其中。
基本流程是：扫描器发现CVE并发出警报，我们发布声明说明修复时间和位置，扫描器理解后就不再显示该漏洞。
所以其实没有地方标注“此漏洞存在”，这是扫描器的职责。不过并非所有扫描器都这样运作，有些只依赖我们的信息流而不做自己的功课，所以效果参差不齐。
我们现已启用采用新版OSV格式的数据源，该数据源完整记录了漏洞检测时间、修复时间等信息。
所有信息均公开展示在控制台，多数内容可在此查阅：https://github.com/wolfi-dev/advisories
以这个示例为例：https://github.com/wolfi-dev/advisories/blob/main/amass.advi…，您可查看我们检测CVE的时间戳、涉及版本号以及修复耗时。
顺便提一句——GitLab上市前大批员工跳槽到了Chainguard，其中不少担任领导职务，最关键的是销售管理层。这些人并不推崇高压销售模式，而是致力于展现产品价值，而非榨取客户利润或单纯追求业绩数字增长。
您可自行判断这些信息。
感谢分享。这类“背景信息”虽不易获取，但(至少对我而言)确实影响着供应商选择。
简而言之
https://github.com/docker-hardened-images/catalog?tab=readme…
请听我说。
没有Docker的容器生态系统能否更安全？
Podman早已解决了无root容器及其他所有问题。
Docker现在只是在追赶潮流。
但你知道吗？它们已经过时了。迟早会步HashiCorp Vagrant的后尘。
如今Docker仅靠企业巨头盈利，而这笔利润终将枯竭。
若你仍在依赖Docker，现在正是迁移的时机。
https://podman-desktop.io/docs/migrating-from-docker
> 若你仍在依赖Docker，现在正是迁移的时机。
最近为某客户服务时，发现他们使用Podman Desktop，开发人员使用Macbook(Mx系列)。
他们尝试在机器上运行amd64镜像。构建某个Docker镜像时，系统出现段错误(segfault)，且错误信息非常笼统，并非特定于某个RUN命令——因为即使逐条注释后续命令，错误仍会出现在下一个命令上。堆栈跟踪显示问题源于Podman Compose的代码库。
经查证这是Podman已知的缺陷，GitHub上存在公开问题报告，影响范围广泛。
我使用Docker十年有余，涵盖Docker Engine、Compose、Desktop、Toolbox等工具，从未遭遇过任何段错误，一次都没有。
有趣的是？在Docker Desktop上运行完全正常。只需安装Docker Desktop，构建并运行即可。十分钟内零问题顺利启动。
那家公司得为我几小时的调试付费，而现在他们正乐此不疲地为Docker Desktop付费——团队许可证成本如此低廉，让所有用户“开箱即用”的成本远低于持续折腾和雇人排查问题的开销。
Docker Desktop 确实非常稳定可靠，绝对值得使用。而且它完全免费，直到你超级成功、年收入达到八位数为止。
> Podman Compose
不该用 Podman Compose。它很脆弱，运行效果差，而且我敢肯定它没有红帽的直接支持。
建议启用 Podman 的 Docker API 兼容套接字，只需将
DOCKER_HOST环境变量指向该接口，即可直接使用常规 Docker 客户端命令(如docker、docker compose及所有调用 Docker API 的命令)。此方案几乎完全兼容，仅少数高级配置场景存在例外。或许你尚未注意到，拥有Podman(及Vagrant)的IBM主要从“企业巨鲸”身上获利。
Podman存在诸多问题。例如Rootless模式下网络速度极慢，据我所知该问题至今未解决。
生产环境中可采用systemd套接字激活机制规避多数网络问题。下方链接的Caddy演示案例详细阐述了该方案能解决的具体问题。
[0] https://github.com/containers/podman/blob/main/docs/tutorial…
[1] https://github.com/eriksjolund/podman-caddy-socket-activatio…
感谢你们在造成所有损害十年后才采取行动。