mikesplain/evergreen-containers

# Evergreen Containers [](https://github.com/mikesplain/evergreen-containers/actions/workflows/validate.yml) [](https://github.com/mikesplain/evergreen-containers/actions/workflows/release.yml) [](https://scorecard.dev/viewer/?uri=github.com/mikesplain/evergreen-containers) [](LICENSE) 对稳定的上游容器镜像进行持续刷新、扫描和验证的构建。 Evergreen Containers 在保持应用程序源码稳定的同时，不断刷新其外围打包。 它专为那些实用的上游项目而设计，这些项目的容器发布节奏通常会遗留一些 本可修复的操作系统漏洞。 ## 为什么需要 一个稳定的应用程序版本可以运行多年，但其容器却可能积累已知的漏洞。 使用者往往被迫在旧软件包、无关的源码 fork 或维护完整的下游镜像之间做出选择。 Evergreen Containers 提供了第四种更轻量的选择： 1. 固定确切的上游源码 commit 或镜像 digest； 2. 在公共的 GitHub-hosted runner 上重新构建或修补它； 3. 测试最终生成的应用程序契约； 4. 比较上游和候选版本的漏洞报告； 5. 发布具有唯一标签的 multi-platform 镜像； 6. 根据确切的 registry digest 扫描每个已发布的平台； 7. 仅在发布扫描通过后才对 digest 进行验证。 本项目并不声称较低的 CVE 数量就能保证镜像安全。 它将运行时强化、最小权限、网络隔离以及及时的上游升级作为独立的职责保留下来。 ## 目录 | 镜像 | 模式 | 上游 | 平台 | 状态 | | --- | --- | --- | --- | --- | | Flaresolverr | Exact-source rebuild | [`v3.5.0`](https://github.com/FlareSolverr/FlareSolverr/releases/tag/v3.5.0) | `linux/amd64`, `linux/arm64` | [已验证：12 个高危，0 个严重](https://github.com/mikesplain/evergreen-containers/actions/runs/30560406686) | | democratic-csi | Exact-source rebuild | [`v1.9.5`](https://github.com/democratic-csi/democratic-csi/tree/v1.9.5) | `linux/amd64`, `linux/arm64` | 候选验证中 | | Sockpuppet Browser | Exact-source rebuild | [`0.0.3`](https://github.com/dgtlmoon/sockpuppetbrowser/releases/tag/0.0.3) | `linux/amd64`, `linux/arm64` | 候选验证中；Chromium 119 阻止了晋升 | 目录条目位于 [`catalog/images.json`](catalog/images.json)。自动化目前 使用上游项目自己的 Dockerfile 实现了 exact-source rebuild。 在第一个镜像验证了发布模型之后，计划实现一种基于 [Copacetic](https://project-copacetic.github.io/copacetic/) 的无 Dockerfile OS-package patch 模式。 Flaresolverr 的上游 Dockerfile 目前使用 Debian 12 基础镜像，而 Grype 报告称该镜像已超出其标准支持的生命周期界限。每周的重新构建可降低 可用的软件包风险，但这只是一种过渡性控制措施；[issue #7](https://github.com/mikesplain/evergreen-containers/issues/7) 跟踪了生命周期强制执行和向受支持的基础镜像迁移的进度。 Sockpuppet Browser 当前的上游 Dockerfile 固定了 `zenika/alpine-chrome:119-with-playwright`。候选自动化测量并 测试了该确切源码，但在其 Chromium 基础镜像更新并且对由此产生的漏洞预算 进行审查之前，不得将该镜像晋升以供使用。 ## 发布模型 - 每周发布从受保护的 `main` 分支运行；维护者也可以手动触发发布。 - 更改目录、workflow、script 或测试输入的 Pull Request 会运行 相同的原生候选版本构建、契约测试和漏洞比较， 但没有软件包或验证写入权限。 - 应用程序源码固定为完整的上游 commit。每周的作业不会 静默采用新的应用程序代码。 - 基础镜像和软件包仓库通过 BuildKit 的 `pull` 和 no-cache 构建进行刷新。 - 每个受支持的平台都在可用的原生 GitHub-hosted 架构 runner 上 独立构建、冒烟测试和扫描。 - 候选版本不得使其上游镜像退化，并且必须保持在 审查过的可修复的高危/严重预算范围内。 - 每个受支持的平台都会根据确切的已发布 digest 再次从 GHCR 扫描。 发布 workflow 无法对超出其审查预算的 digest 进行验证。 - 发布的标签是唯一的，包含上游版本、UTC 日期、Actions 运行编号和运行尝试，例如 `v3.5.0-r20260730.42.1`。 - Multi-platform 镜像包含 BuildKit SBOM 和 SLSA provenance attestation， 以及与发布 workflow 相关联的 GitHub artifact provenance。 - 使用者应通过 digest 部署，或通过已审查的 依赖自动化 Pull Request 接受更新。 镜像从该仓库发布到 `mikesplain` 命名空间下的 GitHub Container Registry。 确切的拉取引用和 digest 包含在 每个成功的 workflow 摘要中。 正常的生命周期是 100% GitHub Actions 自动化的：计划重建、 契约测试、漏洞比较、发布、确切 digest 扫描、 attestation 和证据保留。它不需要维护者 工作站、私有 runner 或本地安装的 container engine。 ## 信任与验证 在使用镜像之前，请先验证 GitHub provenance： ``` gh attestation verify \ oci://ghcr.io/mikesplain/evergreen-containers/flaresolverr@sha256:... \ --repo mikesplain/evergreen-containers ``` 然后在部署中固定已验证的 digest： ``` ghcr.io/mikesplain/evergreen-containers/flaresolverr@sha256:... ``` 有关信任边界、威胁模型和发布保证，请参见 [`docs/security-model.md`](docs/security-model.md)。 ## 添加镜像 Evergreen Containers 是经过精心筛选的。在提出镜像建议之前， 请确认： - 上游项目和源码是可验证的； - 更新到较新的官方版本不是更好的解决方案； - 当前问题主要是由陈旧、可修复的 OS 软件包引起的； - 稳定的功能契约可以自动测试； - 上游许可证允许重新分发； - 有人愿意承担兼容性和异常审查的责任。 按照 [`CONTRIBUTING.md`](CONTRIBUTING.md) 中的说明添加目录条目和契约测试。 大多数镜像不需要本地的 Dockerfile。 ## 非目标 - 仅为提高可用性或便利性而镜像。 - Fork 积极维护的应用程序，而不是更新它们。 - 自动重写已编译的应用程序依赖项。 - 发布 `latest` 标签。 - 仅仅为了让徽章变绿而掩盖漏洞。 - 将重新构建的镜像视为运行时隔离的替代品。 ## 许可证 此仓库中的自动化脚本基于 [Apache License 2.0](LICENSE) 授权。重新构建的镜像保留其上游项目的 许可证和声明。

标签：DevSecOps, Google Gemini, GPT, 上游代理, 安全合规, 容器镜像, 开源框架, 持续集成, 漏洞管理, 网络代理, 自定义脚本, 请求拦截, 软件供应链