供应链安全第一课如何用 cosign 验证 Universal Blue main 镜像签名与 SBOM【免费下载链接】mainOCI base images of Fedora with batteries included项目地址: https://gitcode.com/gh_mirrors/main9/mainUniversal Blue main是一个开箱即用的 Fedora OCI 基础镜像项目也是 Aurora、Bluefin、Bazzite 等知名系统的共同底座。本文将带你完成供应链安全第一课用cosign 验证镜像签名与SBOM确保你拉取的每一个镜像都来自官方、内容可追溯全程无需深厚的安全功底。 为什么要验证镜像签名供应链安全的必修课在容器世界里镜像来自官方仓库并不等于镜像内容可信。攻击者可能通过中间人劫持、仓库配置错误或依赖投毒把恶意代码悄悄混进你信任的镜像里。签名验证就是给镜像加上一把官方印章只有持有私钥的发布者才能签名任何人都无法伪造。而SBOM软件物料清单则是镜像的成分表记录了里面每一个软件包、版本与依赖关系。当 Log4j、OpenSSL 这类漏洞爆发时你只需要对着 SBOM 一查就能立刻知道自己的镜像是否受影响。Universal Blue main 项目从构建、签名到发布已经把这套机制完整地落地到了流水线中我们直接拿来用即可。️ Universal Blue main 镜像的签名与 SBOM 是怎么来的在动手之前先了解你的验证对象。该项目仓库中的 Justfile 定义了完整的安全流水线构建基于 Containerfile 构建 silverblue、kinoite、base 等变体镜像签名通过cosign sign用私钥对镜像摘要digest签名并发布到镜像仓库验证用cosign verify立即回验刚签名的镜像确保签名有效才放行生成 SBOM用 syft 扫描镜像输出 SPDX 格式的 JSON 清单附加认证用cosign attest把 SBOM 作为认证凭证附加到镜像上。也就是说每一次发布签名和 SBOM 都是同时产出、同时校验的这正是供应链安全的最佳实践。相关实现可参考 build_files/install.sh镜像内预装了 cosign与 Justfile 中的cosign-sign、gen-sbom、sbom-attest任务。 第一步获取官方验证公钥 cosign.pub验证签名需要对得上号的公钥。好消息是Universal Blue main 把公钥直接放在了仓库根目录的 cosign.pub 文件中内容形如-----BEGIN PUBLIC KEY----- MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEHLRp... -----END PUBLIC KEY-----你可以直接克隆仓库获取它仓库地址https://gitcode.com/gh_mirrors/main9/main也可以从仓库页面单独下载。请务必通过官方渠道获取公钥——公钥本身也是信任链的一部分。✅ 第二步用 cosign 验证镜像签名实操命令首先确保本机安装了 cosign然后执行cosign verify \ --key cosign.pub \ ghcr.io/ublue-os/silverblue-main:latest命令会返回该镜像对应的签名信息包括签名者与发布时间如果镜像被篡改或签名不匹配cosign 会直接报错退出。项目在 Justfile 的verify-container任务中使用了相同思路还额外加上了--new-bundle-formatfalse参数以保证与 bootc、rpm-ostree 等系统工具兼容。更严谨的做法是按摘要digest验证而不是按标签tag验证。你可以在 image-versions.yaml 中看到项目为每个基础镜像固定的 sha256 摘要例如cosign verify \ --key cosign.pub \ ghcr.io/ublue-os/silverblue-mainsha256:1d1810dfd0e3fc41ec3bf2d6430963e9... 第三步验证 SBOM 软件物料清单签名验证通过后再来核对成分表。SBOM 以 attestation认证的形式附加在镜像上你可以这样下载查看cosign download attestation \ ghcr.io/ublue-os/silverblue-main:latest | jq .也可以指定类型做严格校验cosign verify-attestation \ --key cosign.pub \ --type spdxjson \ ghcr.io/ublue-os/silverblue-main:latest拿到 SBOM 后你就能清晰看到镜像里安装了哪些软件包及其版本。配合官方发布的漏洞公告几秒钟就能完成一次体检真正做到用数据说话。 项目中的自动化验证机制不止于手动命令如果你好奇这套机制在生产中如何运转可以看几个关键文件Justfileverify-source-images任务会在每次 CI 中用对应仓库的公钥逐一验证所有上游基础镜像build_files/install.sh构建时通过 github-release-install.sh 安装 sigstore/cosign并把签名公钥固化进系统image-versions.yaml所有上游镜像的摘要被锁定在这里杜绝标签漂移带来的安全隐患。也就是说从上游依赖到最终产物每一层都被签名和摘要双重约束——这正是 Universal Blue 作为众多发行版地基却依然值得信赖的原因。 写在最后供应链安全并不遥远一次cosign verify就能迈出第一步。记住这条黄金流程官方公钥 → 摘要验证签名 → 下载 SBOM 核对成分。从今天起每次拉取镜像都多花 10 秒钟验证一下你的系统就会安全一大截。动手试试吧把上面的命令在你的机器上跑一遍你会发现自己已经掌握了供应链安全的第一课 【免费下载链接】mainOCI base images of Fedora with batteries included项目地址: https://gitcode.com/gh_mirrors/main9/main创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
供应链安全第一课：如何用 cosign 验证 Universal Blue main 镜像签名与 SBOM？
供应链安全第一课如何用 cosign 验证 Universal Blue main 镜像签名与 SBOM【免费下载链接】mainOCI base images of Fedora with batteries included项目地址: https://gitcode.com/gh_mirrors/main9/mainUniversal Blue main是一个开箱即用的 Fedora OCI 基础镜像项目也是 Aurora、Bluefin、Bazzite 等知名系统的共同底座。本文将带你完成供应链安全第一课用cosign 验证镜像签名与SBOM确保你拉取的每一个镜像都来自官方、内容可追溯全程无需深厚的安全功底。 为什么要验证镜像签名供应链安全的必修课在容器世界里镜像来自官方仓库并不等于镜像内容可信。攻击者可能通过中间人劫持、仓库配置错误或依赖投毒把恶意代码悄悄混进你信任的镜像里。签名验证就是给镜像加上一把官方印章只有持有私钥的发布者才能签名任何人都无法伪造。而SBOM软件物料清单则是镜像的成分表记录了里面每一个软件包、版本与依赖关系。当 Log4j、OpenSSL 这类漏洞爆发时你只需要对着 SBOM 一查就能立刻知道自己的镜像是否受影响。Universal Blue main 项目从构建、签名到发布已经把这套机制完整地落地到了流水线中我们直接拿来用即可。️ Universal Blue main 镜像的签名与 SBOM 是怎么来的在动手之前先了解你的验证对象。该项目仓库中的 Justfile 定义了完整的安全流水线构建基于 Containerfile 构建 silverblue、kinoite、base 等变体镜像签名通过cosign sign用私钥对镜像摘要digest签名并发布到镜像仓库验证用cosign verify立即回验刚签名的镜像确保签名有效才放行生成 SBOM用 syft 扫描镜像输出 SPDX 格式的 JSON 清单附加认证用cosign attest把 SBOM 作为认证凭证附加到镜像上。也就是说每一次发布签名和 SBOM 都是同时产出、同时校验的这正是供应链安全的最佳实践。相关实现可参考 build_files/install.sh镜像内预装了 cosign与 Justfile 中的cosign-sign、gen-sbom、sbom-attest任务。 第一步获取官方验证公钥 cosign.pub验证签名需要对得上号的公钥。好消息是Universal Blue main 把公钥直接放在了仓库根目录的 cosign.pub 文件中内容形如-----BEGIN PUBLIC KEY----- MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEHLRp... -----END PUBLIC KEY-----你可以直接克隆仓库获取它仓库地址https://gitcode.com/gh_mirrors/main9/main也可以从仓库页面单独下载。请务必通过官方渠道获取公钥——公钥本身也是信任链的一部分。✅ 第二步用 cosign 验证镜像签名实操命令首先确保本机安装了 cosign然后执行cosign verify \ --key cosign.pub \ ghcr.io/ublue-os/silverblue-main:latest命令会返回该镜像对应的签名信息包括签名者与发布时间如果镜像被篡改或签名不匹配cosign 会直接报错退出。项目在 Justfile 的verify-container任务中使用了相同思路还额外加上了--new-bundle-formatfalse参数以保证与 bootc、rpm-ostree 等系统工具兼容。更严谨的做法是按摘要digest验证而不是按标签tag验证。你可以在 image-versions.yaml 中看到项目为每个基础镜像固定的 sha256 摘要例如cosign verify \ --key cosign.pub \ ghcr.io/ublue-os/silverblue-mainsha256:1d1810dfd0e3fc41ec3bf2d6430963e9... 第三步验证 SBOM 软件物料清单签名验证通过后再来核对成分表。SBOM 以 attestation认证的形式附加在镜像上你可以这样下载查看cosign download attestation \ ghcr.io/ublue-os/silverblue-main:latest | jq .也可以指定类型做严格校验cosign verify-attestation \ --key cosign.pub \ --type spdxjson \ ghcr.io/ublue-os/silverblue-main:latest拿到 SBOM 后你就能清晰看到镜像里安装了哪些软件包及其版本。配合官方发布的漏洞公告几秒钟就能完成一次体检真正做到用数据说话。 项目中的自动化验证机制不止于手动命令如果你好奇这套机制在生产中如何运转可以看几个关键文件Justfileverify-source-images任务会在每次 CI 中用对应仓库的公钥逐一验证所有上游基础镜像build_files/install.sh构建时通过 github-release-install.sh 安装 sigstore/cosign并把签名公钥固化进系统image-versions.yaml所有上游镜像的摘要被锁定在这里杜绝标签漂移带来的安全隐患。也就是说从上游依赖到最终产物每一层都被签名和摘要双重约束——这正是 Universal Blue 作为众多发行版地基却依然值得信赖的原因。 写在最后供应链安全并不遥远一次cosign verify就能迈出第一步。记住这条黄金流程官方公钥 → 摘要验证签名 → 下载 SBOM 核对成分。从今天起每次拉取镜像都多花 10 秒钟验证一下你的系统就会安全一大截。动手试试吧把上面的命令在你的机器上跑一遍你会发现自己已经掌握了供应链安全的第一课 【免费下载链接】mainOCI base images of Fedora with batteries included项目地址: https://gitcode.com/gh_mirrors/main9/main创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
