wolfi基础镜像无cve因其通过melange从源码编译并默认禁用非必要功能，剔除未启用代码路径；但仅限wolfi-base及官方包，手动apk add alpine包将引入cve风险。
为什么 Wolfi 的基础镜像真的没有 CVE？
不是营销话术，是构建机制决定的：Wolfi 不用 apk add 从预编译仓库拉包，而是用 melange 从源码实时编译每个包，且默认禁用所有非必要功能（比如 curl 默认不带 HTTP/2、openssl 编译时关掉 FIPS 模式和老旧 cipher）。CVE 往往藏在未启用的代码路径或历史兼容逻辑里——Wolfi 直接不编进去。
但注意：零 CVE 仅针对基础镜像（wolfi-base）及其原生包。一旦你手动 apk add 加入 Alpine 社区包（比如 apk add nginx），就立刻脱离 Wolfi 构建链，CVE 风险回归。
如何安全地安装运行时依赖？别碰 apk add
Wolfi 的包管理不是 Alpine 那套——它没有运行时仓库索引，也不支持 apk add 在容器里动态装包。所有依赖必须在构建阶段通过 melange 声明并编译进镜像。
- 写一个
melange.yaml，在environment.contents.packages下列出你要的包（如curl、ca-certificates），而不是运行时apk add - 确保这些包来自 Wolfi 官方仓库（
https://packages.wolfi.dev），而非https://dl-cdn.alpinelinux.org/alpine/ - 若某个工具 Wolfi 官方没提供（比如新版
jq），不要下载二进制塞进镜像——应提 PR 到wolfi-dev/os仓库，补全melange构建定义
apk 命令在 Wolfi 里还能用吗？能，但很危险
Wolfi 镜像里确实保留了 apk 二进制（为调试和迁移兼容），但它指向的是只读的本地 melange 构建产物数据库，不联网、无远程仓库配置。执行 apk add 会直接报错：ERROR: unable to select packages。
但如果你手动改了 /etc/apk/repositories，强行指向 Alpine 仓库：
-
apk add可能成功，但装上的二进制与 Wolfi 的 musl 版本、符号版本不匹配，运行时报Symbol not found或 segfault - Alpine 包的
APKINDEX.tar.gz里不含 Wolfi 的 SBOM 元数据，CI 扫描工具会漏掉这些包的 CVE 检查 - 同一镜像混用 Wolfi + Alpine 包，
apk info -v输出混乱，无法追溯来源
构建最小化服务镜像的实际步骤
以一个 Go Web 服务为例，目标：只含 ca-certificates 和你的二进制，无 shell、无包管理器残留。
- 在
melange.yaml中设strip-binaries: true，删掉调试符号 - 把
entrypoint设为你的二进制绝对路径（如/usr/bin/myapp），不要依赖/bin/sh - 禁用 shell：构建时加
--run-as root --no-shell，镜像里就不会有/bin/sh或/usr/bin/bash - 验证：运行
docker run --rm <image> ls /bin</image>，输出应为空；apk list应只显示你声明的那几个包
真正麻烦的从来不是“怎么做到零 CVE”，而是守住边界——一旦允许运行时装包、混用仓库、跳过 melange 流程，整套信任链就断了。这点比任何配置都关键。
