Copacetic：容器镜像直接打补丁，不重建镜像也能修漏洞

获取下载链全程约 1 分钟

打开微信，搜索「软件教程管家」关注，或长按下方二维码关注
回复关键词 copacetic
公众号自动回复网盘链接，点击即可保存下载

打开微信扫一扫关注
或搜索【软件教程管家】

项目	Copacetic（工具名 Copa）
仓库	github.com/project-copacetic/copacetic
开发语言	Go
开源协议	Apache-2.0
Star 数	1750（2026-11-12 实测）
一句话定位	基于 BuildKit 的容器镜像直接补丁工具

容器镜像扫出高危漏洞，上游基础镜像却迟迟不发布新版，这时候是等，还是整镜像重建？Copacetic（命令行工具名 Copa）给出了第三种选择：直接给容器镜像打补丁。它基于 Go 和 BuildKit，在原镜像之上生成一个补丁层，只更新有漏洞的软件包，不用完整重建镜像，适合放进 DevSecOps 流程里应急修漏洞。

Copacetic（Copa）是什么

Copacetic 是一个命令行工具，名字里的 Copa 就是它的可执行文件名。它直接操作容器镜像：读取漏洞扫描结果，定位镜像里需要更新的操作系统软件包，然后用 BuildKit 生成一个只包含更新内容的补丁层，叠加在原镜像之上，产出一个可以重新部署的补丁镜像。

和常规的 Dockerfile 重建不同，打补丁不重新执行构建步骤，不重新拉取基础镜像，也不会因为某一层变化导致后续层缓存全部失效。补丁层只包含被更新的软件包，镜像体积增长有限，分发成本也更低。

适用场景

漏洞应急修复：扫描发现操作系统软件包存在高危漏洞，上游镜像还没发布修复版，先打补丁止血，再等上游更新。
第三方应用镜像：镜像维护者尚未发布更新，但业务等不及重建，团队自己给镜像打补丁后重新部署。
多层基础镜像：漏洞来自镜像的多层基础镜像，逐层重建成本高，一次补丁直接覆盖。
减少重建开销：完整重建会丢层缓存、重新分发整个镜像，补丁方式只多一层，CI 时间和带宽都省。

打补丁怎么用：三步上手

Copa 的典型用法是配合漏洞扫描工具，整个流程分三步。运行前需要准备好目标容器镜像、BuildKit 环境，以及一份漏洞扫描报告。

扫出漏洞报告：用 Trivy 扫描目标镜像并导出报告，例如 trivy image --format json -o report.json 目标镜像:标签，报告里会列出存在漏洞的软件包清单。
执行打补丁：用 Copa 根据报告生成补丁镜像，例如 copa patch -i 目标镜像:标签 -r report.json -t 目标镜像:patched，Copa 会基于 BuildKit 生成补丁层并产出新镜像。
验证并重新部署：对补丁后的镜像重新扫描确认漏洞已修复，再跑一遍冒烟测试，确认应用能正常启动，然后按原有发布流程重新部署。

除了报告驱动的更新，Copa 也支持综合更新：对保留完整 dpkg 状态文件的 Ubuntu 镜像，可以直接把系统包更新到最新；对原生的 Ubuntu Chiseled 镜像，则根据 manifest.wall 做综合更新。

注意事项

先分清两种更新方式：原生 manifest.wall 的 Chiseled 镜像只支持综合更新，不能用报告驱动的方式；Trivy 无法从 manifest.wall 文件提取操作系统软件包清单，这类镜像不要硬套报告驱动流程。
Chiseled 镜像来源有限：Ubuntu Chiseled 镜像的初始支持只覆盖公开软件包归档，其他软件包来源要结合文档或源码确认是否支持。
自定义 Chisel release 要固定引用：使用自定义 Chisel release 时，公开 HTTPS Git 地址必须带有固定的提交或标签引用，不要用会漂移的分支名，否则补丁结果不可复现。
补丁不是重建的替代品：Copa 解决的是操作系统软件包的漏洞修复，应用依赖升级、配置变更、需要完整可复现构建的场景，仍应走 Dockerfile 重建。
升级后要重新验证：升级 Copa、BuildKit、Trivy 或基础镜像后，重新验证补丁结果和镜像运行行为；Chiseled 镜像还要按 manifest.wall 机制单独测试。

方案	做法	适合谁
Copacetic（Copa）	在原镜像上叠加补丁层，只更新有漏洞的系统包	需要快速应急修复、不想等上游重建的团队
Dockerfile 完整重建	换新基础镜像、重新执行全部构建步骤	要求完整可复现构建、有应用依赖要同步升级的场景
基础镜像升级	等上游发布修复版基础镜像后重新构建	不着急、上游响应及时的常规发布流程
仅扫描不修复	Trivy 等工具只出报告，不改镜像	只需要发现漏洞、修复走其他流程的团队