getbrik/brik-images

专为 Brik 构建的 CI runner 镜像。
预装了 bash + yq + jq + git 以及你的技术栈工具链。已签名、已认证、已扫描，且支持多架构。
不再需要为每个 CI 任务进行引导初始化。

[](https://github.com/getbrik/brik-images/actions/workflows/build.yml) [](https://github.com/getbrik/brik-images/attestations) [](#verifying) [Brik](https://github.com/getbrik/brik) CI/CD runner 的官方 Docker 镜像。 ## 这些镜像解决的问题 原生的编程语言镜像（`node:24-slim`、`python:3.13-slim`）非常适合开发环境，但它们并不是为 CI 构建的： - 每个 CI 任务都会重新安装相同的 `bash 5+`、`yq`、`jq`、`git` 和 `curl`。每条流水线中的每个任务都要耗费 30 到 40 秒。 - 没有签名、没有出处证明、没有 SBOM。你只能盲目相信维护者所声称的镜像内容。 - CVE 补丁严重滞后。原生镜像按照维护者的节奏进行重建，而不是根据你的节奏。 - 缺少专用于 CI 的工具。对于 SAST、SCA、机密扫描和容器 lint：你需要自行准备并在每次任务中手动安装。 brik-images 是 CI runner 镜像。彻底告别初始化引导。出处已签名。每次推送时，都会实时发布每个镜像的 CVE 安全状况。扫描器和分析工具已预装在专用镜像中。 ## 这些镜像的独特之处 ### 🔐 已签名并认证 每个镜像都使用 [cosign](https://github.com/sigstore/cosign)（无密钥，OIDC）进行签名，并携带 SLSA 构建出处证明，你可以使用 `gh attestation verify` 进行验证。杜绝供应链信任缺口。具体命令请参阅[验证](#verifying)。 ### 🔍 真实透明的扫描 在[可用镜像](#available-images)表中提供实时的 CVE 数量，而不是一个静态的“0 个漏洞”徽章。构建过程**仅在存在可用上游修复的严重级别 CVE 时**才会强制失败。其他所有漏洞都会被记录下来，在[安全标签页](https://github.com/getbrik/brik-images/security/code-scanning)中可见，并被视为已知的安全状况而非隐藏风险。完整状况记录在[当前 CVE 状况](#current-cve-posture)中。 ### 🔄 持续重建 每次构建都会应用基础镜像待处理的 OS 安全更新（`apt-get upgrade`）。每周重建会刷新基础镜像。[Renovate](https://github.com/renovatebot/renovate) 会自动合并摘要更新。被抑制的 CVE 会在每周一由自动生成的 [CVE 抑制审查 issue](https://github.com/getbrik/brik-images/issues?q=is%3Aissue+label%3Acve-suppression-review) 进行审查，确保没有任何问题被悄然遗忘。 ### 🧱 专为 Brik 构建 每个镜像都预装了 `bash 5+`、`yq`、`jq`、`git` 和 `curl`。技术栈镜像额外增加了各自的工具链。Brik runtime 本身会在 CI 运行时由共享库的 `before_script` 进行克隆，这使得镜像发布与 Brik 版本发布解耦。 ## 包含内容 每个镜像都包含： - **bash** (5.x) - **yq**：YAML 处理器 - **jq**：JSON 处理器 - **git**：版本控制工具 - **curl**：HTTP 客户端 技术栈镜像还额外包含它们各自的工具链（node/npm、python/pip、java/maven、rust/cargo、dotnet/sdk）。所有捆绑工具的精确锁定版本都在 [`versions.json`](versions.json) 中。 ### 分析镜像与扫描器镜像 扫描工具根据其运行时要求被拆分到两个镜像中： - **analysis**：包含 Python/Ruby runtime，用于深度 SAST 分析、许可证合规性检查和 IaC 扫描。 - **scanner**：仅包含静态编译的 Go 二进制文件，拉取速度快，用于漏洞扫描、机密检测、Dockerfile lint 和容器扫描。 #### Analysis 镜像 (~1.7 GB) | 工具 | 用途 | |------|---------| | semgrep | 静态分析 (SAST) | | checkov | 基础设施即代码扫描 | | scancode-toolkit | 许可证与来源检测 | | license_finder | 许可证合规性检查 | #### Scanner 镜像 (~500 MB) | 工具 | 用途 | |------|---------| | grype | 漏洞扫描 (SCA) | | syft | SBOM 生成 | | osv-scanner | 开源漏洞扫描 | | hadolint | Dockerfile lint | | gitleaks | 机密/凭证泄露检测 | | trufflehog | 机密扫描（基于熵和特征匹配） | | dockle | Docker 镜像最佳实践 lint | ### Deploy 镜像 `brik-runner-deploy`（FROM base）包含了 Brik 的 CD 流程中 deploy-class runner 所使用的 CD 工具链。它在部署工具的基础上增加了 cosign 和 oras，使得流程可以在部署前验证已解析摘要上的签名证明。 | 工具 | 用途 | |------|---------| | helm | Kubernetes 包管理器 | | kubectl | Kubernetes CLI | | argocd | GitOps CD 控制器 CLI | | cosign | 验证镜像签名和出处证明 | | oras | OCI 制品传输（取证） | ## 可用镜像 | 镜像 | 版本 | 安全性 | 拉取命令 | |-------|---------|----------|--------------| | `brik-runner-base` | `3.23` |  | `docker pull ghcr.io/getbrik/brik-runner-base` | | `brik-runner-node` | `22` |  | `docker pull ghcr.io/getbrik/brik-runner-node:22` | | `brik-runner-node` | `24` |  | `docker pull ghcr.io/getbrik/brik-runner-node:24` | | `brik-runner-python` | `3.13` |  | `docker pull ghcr.io/getbrik/brik-runner-python:3.13` | | `brik-runner-python` | `3.14` |  | `docker pull ghcr.io/getbrik/brik-runner-python:3.14` | | `brik-runner-java` | `21` |  | `docker pull ghcr.io/getbrik/brik-runner-java:21` | | `brik-runner-java` | `25` |  | `docker pull ghcr.io/getbrik/brik-runner-java:25` | | `brik-runner-rust` | `1` |  | `docker pull ghcr.io/getbrik/brik-runner-rust:1` | | `brik-runner-dotnet` | `9.0` |  | `docker pull ghcr.io/getbrik/brik-runner-dotnet:9.0` | | `brik-runner-dotnet` | `10.0` |  | `docker pull ghcr.io/getbrik/brik-runner-dotnet:10.0` | | `brik-runner-analysis` | `1` |  | `docker pull ghcr.io/getbrik/brik-runner-analysis` | | `brik-runner-scanner` | `1` |  | `docker pull ghcr.io/getbrik/brik-runner-scanner` | | `brik-runner-deploy` | `1` |  | `docker pull ghcr.io/getbrik/brik-runner-deploy` | 所有镜像均支持多架构：`linux/amd64` 和 `linux/arm64`。 ## 安全性 每个镜像都经过扫描、签名，并持续重建： - ✅ 每次构建时都使用 [Grype](https://github.com/anchore/grype) 进行扫描。构建**仅在存在可用上游修复的严重级别 CVE 时**才会强制失败。上游尚未修复的严重和高危 CVE 会被记录下来，但不会阻断流程。 - ✅ 扫描结果上传至[安全标签页](https://github.com/getbrik/brik-images/security/code-scanning)，实现针对每个镜像的全面可见性。 - ✅ 使用 [Syft](https://github.com/anchore/syft) 生成 CycloneDX 格式的 SBOM。 - ✅ 使用 [cosign](https://github.com/sigstore/cosign)（无密钥，OIDC）对镜像进行签名。 - ✅ 每次构建都会应用基础镜像待处理的 OS 安全更新；每周重建会刷新基础镜像；[Renovate](https://github.com/renovatebot/renovate) 自动合并摘要更新。 ### 当前 CVE 状况 **我们能控制的：** 内置工具（`yq`、`jq`、`git` 以及扫描器/分析二进制文件）均锁定为最新版本并定期升级；如果存在修复补丁，遇到严重级别的 CVE 时构建会自动阻断。 **我们无法控制的：** 编程语言 runtime 本身以及静态链接的 Go 二进制文件中的 CVE；这些只有在 runtime 或工具上游发布修复版本后才会被清除。在生产环境中使用时，请通过摘要固定镜像版本，并根据你自身的风险策略执行扫描门禁检查。 ### 被抑制的 CVE **实时状态**（各工具的细分情况，以及是否已发布修复版本）显示在会自动刷新的 [CVE 抑制审查 issue](https://github.com/getbrik/brik-images/issues?q=is%3Aissue+label%3Acve-suppression-review) 中，该 issue 会在每周一由 [`scripts/review-cve-suppressions.sh`](scripts/review-cve-suppressions.sh) 重新生成。当某工具发布了基于已修复 Go 版本的更新时，请在 [`versions.json`](versions.json) 中升级该工具版本，并从 `.grype.yaml` 和 [`.cve-suppressions.json`](.cve-suppressions.json) 中移除其对应条目。 ### 验证 每个镜像都使用 cosign（无密钥）进行签名，并携带 SLSA 构建出处证明。要自行验证已拉取的镜像（可根据需要调整 tag）： ``` # cosign signature cosign verify ghcr.io/getbrik/brik-runner-node:24 \ --certificate-identity-regexp 'https://github.com/getbrik/brik-images/.*' \ --certificate-oidc-issuer https://token.actions.githubusercontent.com # GitHub build-provenance attestation gh attestation verify oci://ghcr.io/getbrik/brik-runner-node:24 --owner getbrik ``` 每份证明也都列在[证明页面](https://github.com/getbrik/brik-images/attestations)上。 ## Tag 命名规范 每个镜像在发布时都带有多个 tag： ``` ghcr.io/getbrik/brik-runner-node:22 # stack version (mutable) ghcr.io/getbrik/brik-runner-node:latest # latest LTS (mutable) ghcr.io/getbrik/brik-runner-node:sha-a1b2c3d # immutable git SHA ghcr.io/getbrik/brik-runner-node:22@sha256:... # digest pin (most secure) ``` ## 使用方法 你无需手动选择镜像，也不需要在其中安装 `brik`。`init` 任务会从你的 `brik.yml` 中读取 `project.stack` 和 `project.stack_version`，并将每个阶段解析为对应的 `ghcr.io/getbrik/brik-runner-:`；共享库会在任务开始时将 Brik runtime 克隆到容器中。 ### GitLab CI 引入 Brik 模板即可。完整的流水线配置如下： ``` # .gitlab-ci.yml include: - project: 'brik/gitlab-templates' ref: v0.7.0 file: '/templates/brik-integrate.yml' ``` 如果在 `brik.yml` 中设置了 `project.stack: node` 和 `stack_version: "22"`，各阶段任务将在 `ghcr.io/getbrik/brik-runner-node:22` 上运行；而扫描、分析和部署阶段将自动在其专用镜像上运行。 ### Jenkins Brik 共享库并调用协调器即可。与前面一样，会自动从 `brik.yml` 中解析镜像： ``` // Jenkinsfile @Library('brik') _ brikIntegrate() ``` ### 本地环境 只要在主机上安装了 Brik CLI，你就可以直接在项目目录中运行流程。Brik 会驱动与 CI 相同的容器化引擎，为每个阶段生成一个 brik-runner 容器（镜像将从你的 `brik.yml` 中解析）： ``` brik integrate # full CI flow locally, one container per stage brik stage build # or run a single stage in its runner image ``` ### 使用你自己的镜像（镜像站、私有 registry、自定义 runner） 每个 runner 类别都映射到 runner 类别映射表中的一个镜像。如果需要从镜像站、气隙 registry 或扩展了内部工具的自定义 runner 中拉取，请使用 `BRIK_RUNNER_CLASSES_FILE` 流水线变量（在 GitLab 中是 CI 变量，在 Jenkins 中是构建参数）将 Brik 指向备用映射表，而无需编辑你的 CI 文件： ``` # my-runner-classes.yml，已提交到您的 repo classes: base: { image: registry.example.com/acme/brik-runner-base, tag: "1.4.0" } scanner: { image: registry.example.com/acme/brik-runner-scanner, tag: "1.4.0" } analysis: { image: registry.example.com/acme/brik-runner-analysis, tag: "1.4.0" } deploy: { image: registry.example.com/acme/brik-runner-deploy, tag: "1.4.0" } stack: { image_env: BRIK_CI_IMAGE } # stack image stays resolved from brik.yml ``` 然后为流水线设置 `BRIK_RUNNER_CLASSES_FILE=my-runner-classes.yml`。 ## 本地构建 ### 快速开始 ``` # 构建所有镜像（multi-arch，无 push） ./scripts/build-local.sh # 构建并加载到本地 Docker（仅限 native arch） ./scripts/build-local.sh --load # 构建特定 stacks（扩展至所有版本） ./scripts/build-local.sh --load node python # 构建特定 targets ./scripts/build-local.sh --load analysis-1 scanner-1 ``` ### build-local.sh 选项 | 选项 | 描述 | |--------|-------------| | (无参数) | 构建所有镜像（多架构） | | `` | 构建指定技术栈的所有版本（例如：`node` 会构建 `node-22` + `node-24`） | | `` | 构建指定的目标（例如：`node-22`、`quality-1`） | | `--load` | 将镜像加载到本地 Docker 中（强制使用本机架构） | | `--platform PLAT` | 覆盖目标平台（例如：`linux/amd64`） | | `--no-cache` | 禁用 Docker 构建缓存 | | `--regenerate` | 在构建前重新生成 `docker-bake.hcl` | | `--push` | 将镜像推送到 registry（需要身份验证） | | `--list` | 列出所有可用的目标和栈 | | `--dry-run` | 仅显示命令而不实际执行 | ### 示例 ``` # 列出可用的 targets ./scripts/build-local.sh --list # 从头重新构建 analysis 镜像，单架构 ./scripts/build-local.sh --load --no-cache analysis-1 # 针对特定平台构建 ./scripts/build-local.sh --platform linux/amd64 scanner-1 # 重新生成 bake 文件并构建所有内容 ./scripts/build-local.sh --regenerate --load # 预览命令而不运行它 ./scripts/build-local.sh --dry-run node java ``` ### 其他脚本 ``` # 从 version matrix 生成 bake 文件 ./scripts/generate-bake.sh # 在已构建的镜像上运行 smoke tests ./scripts/smoke-test.sh # Lint Dockerfiles hadolint images/*/Dockerfile ``` ## 版本矩阵 所有工具和栈版本均在 `versions.json` 中定义（唯一事实来源）。要添加或更新版本，请执行： 1. 编辑 `versions.json` 2. 运行 `./scripts/generate-bake.sh`（或在执行 `build-local.sh` 时使用 `--regenerate` 参数） 3. 提交并推送代码；剩下的工作交给 CI 处理 ## 路线图 Brik runtime 目前是在运行时克隆的（由 GitLab 和 Jenkins 适配器以及本地引擎执行），而不是直接预装在镜像中，这使得镜像发布与 Brik 自身的开发解耦。因此，目前你需要使用主机上安装的 CLI 来运行 Brik（参见[本地环境](#local)）。一旦 Brik 进入稳定的版本发布节奏，runtime 将会被预装到镜像中，从而实现在无需主机安装的情况下进行零配置使用（`docker run ghcr.io/getbrik/brik-runner-node:22 brik stage build`）以及完全离线的流水线。 ## 许可证 MIT

标签：Docker, LLM防护, 安全防御评估, 容器镜像, 请求拦截