二进制产物安全分发签名、校验和与可信来源的端到端验证你下载了一个 CLI 工具运行后发现它删了你的硬盘——因为你没有验证这个工具是谁发布的。一、场景痛点你的 CI 流程在构建完成后将二进制产物上传到 S3。用户通过curl | bash的方式下载并安装。某天 S3 的权限配置被错误修改有人上传了一个同名但被篡改的二进制文件。你的用户下载了篡改版本执行后系统被植入恶意脚本。更常见的问题是供应链攻击你依赖的一个 npm 包被劫持发布了一个包含恶意代码的新版本。你的 CI 自动拉取了最新版本构建出的产物包含了恶意代码但你没有任何机制检测这个异常——因为你的构建流程只验证了包能安装没有验证包的来源可信。核心矛盾二进制产物从构建到用户执行中间经过存储、传输、分发多个环节每个环节都可能被篡改——你需要的是端到端的完整性验证不是单点校验。二、底层机制与原理剖析2.1 信任链的端到端验证2.2 签名与校验和的区别验证方式保护对象防篡改能力防伪造能力验证成本SHA256 校验和传输完整性防中间人篡改不能防伪造校验和本身可被篡改低一行命令数字签名cosign构建者身份防任何篡改防伪造私钥不可泄露中需要公钥管理SLSA provenance构建过程防构建环境篡改阴谋攻击需要可信构建平台高需要完整 SLSA 框架校验和只能验证下载的文件与上传的文件一致但无法验证上传的文件是否由可信的人上传。签名既能验证完整性又能验证来源。2.3 Cosign 签名的工作流程Cosign 是 Sigstore 项目的一部分提供无密钥签名Keyless Signing和有密钥签名两种模式有密钥签名CI 用私钥签名产物用户用公钥验证。私钥存储在 CI 的 secret manager 中不暴露给任何人。无密钥签名CI 用 OIDC 身份如 GitHub Actions 的 identity token签名Sigstore 的 Fulcio CA 颁发临时证书。用户验证时检查 OIDC 身份如repo:some-org/some-repo不需要管理公钥。三、生产级代码实现3.1 CI 构建签名流程# .github/workflows/build-and-sign.yaml —— 构建并签名二进制产物 name: Build and Sign on: push: branches: [main] tags: [v*] jobs: build: runs-on: ubuntu-latest permissions: id-token: write # OIDC token用于 cosign keyless 签名 contents: read steps: - uses: actions/checkoutv4 - name: Build binary run: | # 构建二进制产物Go 项目示例 go build -o myapp-linux-amd64 -ldflags-s -w . # 生成校验和文件SHA256 是最安全的哈希算法 sha256sum myapp-linux-amd64 checksums.txt - name: Install cosign uses: sigstore/cosign-installerv3 - name: Sign binary with cosign (Keyless) run: | # 无密钥签名用 GitHub OIDC identity 自动签名 # 签名存储在 Sigstore 的 Rekor 透明日志中任何人可查询 # 验证时检查签名的 OIDC 身份是否匹配仓库 cosign sign-blob myapp-linux-amd64 \ --yes # 自动确认CI 环境无交互 - name: Sign checksums file run: | # 对校验和文件也签名校验和文件本身也需要防篡改 cosign sign-blob checksums.txt \ --yes - name: Generate SBOM uses: anchore/sbom-actionv0 with: image: ${{ env.IMAGE }} format: spdx-json # SPDX 格式的 SBOM - name: Upload to S3 run: | # 上传产物、签名、校验和、SBOM 到 S3 # 四个文件必须一起分发缺任何一个验证链都不完整 aws s3 cp myapp-linux-amd64 s3://releases/myapp/${{ github.ref_name }}/ aws s3 cp checksums.txt s3://releases/myapp/${{ github.ref_name }}/ aws s3 cp myapp-linux-amd64.sig s3://releases/myapp/${{ github.ref_name }}/ aws s3 cp myapp-linux-amd64.sbom.spdx.json s3://releases/myapp/${{ github.ref_name }}/ - name: Verify signature (self-test) run: | # 构建完成后立即验证签名确保签名流程本身没有出错 # 验证 OIDC 身份签名者必须是本仓库的 CI cosign verify-blob myapp-linux-amd64 \ --certificate-identityhttps://github.com/${{ github.repository }}/.github/workflows/build-and-sign.yamlrefs/heads/main \ --certificate-oidc-issuerhttps://token.actions.githubusercontent.com \ --signaturemyapp-linux-amd64.sig \ --certificatemyapp-linux-amd64.cert3.2 客户端下载与验证脚本# install.sh —— 安全下载安装脚本 # 核心原则下载前验证签名执行前验证校验和 set -euo pipefail REPOsome-org/some-repo VERSION${1:-latest} INSTALL_DIR/usr/local/bin BINARY_NAMEmyapp echo Installing ${BINARY_NAME} version ${VERSION}... # 1. 下载二进制产物、签名、校验和 # 四个文件必须从同一来源下载不能用不同 CDN 拿签名和产物 BASE_URLhttps://releases.example.com/${BINARY_NAME}/${VERSION} curl -fSL ${BASE_URL}/${BINARY_NAME}-linux-amd64 -o ${BINARY_NAME} curl -fSL ${BASE_URL}/${BINARY_NAME}-linux-amd64.sig -o ${BINARY_NAME}.sig curl -fSL ${BASE_URL}/${BINARY_NAME}-linux-amd64.cert -o ${BINARY_NAME}.cert curl -fSL ${BASE_URL}/checksums.txt -o checksums.txt # 2. 验证签名确认产物由可信 CI 构建 # 验证两个维度签名有效性 证书身份匹配 if command -v cosign /dev/null; then echo Verifying binary signature... cosign verify-blob ${BINARY_NAME} \ --certificate-identityhttps://github.com/${REPO}/.github/workflows/build-and-sign.yamlrefs/heads/main \ --certificate-oidc-issuerhttps://token.actions.githubusercontent.com \ --signature${BINARY_NAME}.sig \ --certificate${BINARY_NAME}.cert if [ $? -ne 0 ]; then echo ERROR: Signature verification failed! echo The binary may have been tampered with or signed by an unauthorized source. rm -f ${BINARY_NAME} ${BINARY_NAME}.sig ${BINARY_NAME}.cert checksums.txt exit 1 fi echo Signature verified: binary is from trusted CI pipeline. else echo WARNING: cosign not installed, skipping signature verification. echo Install cosign for full security: https://github.com/sigstore/cosign fi # 3. 验证校验和确认下载文件与上传文件一致 # 签名验证了来源可信校验和验证了传输完整 echo Verifying checksum... EXPECTED_HASH$(grep ${BINARY_NAME}-linux-amd64 checksums.txt | cut -d -f1) ACTUAL_HASH$(sha256sum ${BINARY_NAME} | cut -d -f1) if [ ${EXPECTED_HASH} ! ${ACTUAL_HASH} ]; then echo ERROR: Checksum mismatch! echo Expected: ${EXPECTED_HASH} echo Actual: ${ACTUAL_HASH} rm -f ${BINARY_NAME} ${BINARY_NAME}.sig ${BINARY_NAME}.cert checksums.txt exit 1 fi echo Checksum verified: file integrity confirmed. # 4. 安装验证通过后才执行安装操作 chmod x ${BINARY_NAME} mv ${BINARY_NAME} ${INSTALL_DIR}/${BINARY_NAME} # 清理临时文件 rm -f ${BINARY_NAME}.sig ${BINARY_NAME}.cert checksums.txt echo Installation complete: ${INSTALL_DIR}/${BINARY_NAME}3.3 Go 代码中的运行时验证// verify.go —— Go 程序运行时的自检逻辑 package verify import ( crypto/sha256 encoding/hex fmt os strings ) // SelfVerify 程序运行时自检验证自身的校验和是否与预期一致 // 用途防止二进制文件在磁盘上被篡改后执行 // 自检在程序启动时执行不影响正常运行逻辑 func SelfVerify(expectedHash string) error { // 获取自身二进制文件路径 exePath, err : os.Executable() if err ! nil { return fmt.Errorf(cannot get executable path: %w, err) } // 读取自身二进制内容 exeData, err : os.ReadFile(exePath) if err ! nil { return fmt.Errorf(cannot read executable: %w, err) } // 计算 SHA256 校验和 hash : sha256.Sum256(exeData) actualHash : hex.EncodeToString(hash[:]) // 比对校验和不一致说明文件被篡改 if !strings.EqualFold(actualHash, expectedHash) { return fmt.Errorf( self-verify failed: expected %s, got %s\n the binary may have been modified on disk, expectedHash, actualHash, ) } return nil } // VerifyDependency 校验依赖文件的完整性 // 用途程序依赖的配置文件、数据文件也需要防篡改 func VerifyDependency(filePath string, expectedHash string) error { data, err : os.ReadFile(filePath) if err ! nil { return fmt.Errorf(cannot read dependency %s: %w, filePath, err) } hash : sha256.Sum256(data) actualHash : hex.EncodeToString(hash[:]) if !strings.EqualFold(actualHash, expectedHash) { return fmt.Errorf( dependency %s integrity check failed: expected %s, got %s, filePath, expectedHash, actualHash, ) } return nil }四、边界分析与架构权衡4.1 Keyless 签名的信任模型Keyless 签名信任 OIDC 身份而 OIDC 身份由 GitHub/Google 等平台颁发。如果 GitHub 的 OIDC token 被劫持比如 CI 环境变量泄露攻击者可以用合法身份签名恶意产物。对策Keyless 签名的 OIDC 身份必须精确匹配仓库路径分支workflow文件名。CI 环境变量不暴露 OIDC tokentoken 只在 cosign 调用时由 GitHub Actions 自动注入。4.2 SBOM 的实用性SBOM软件物料清单列出了所有依赖的版本和来源但大多数用户不会仔细阅读 SBOM。它的实际价值是当供应链攻击发生时你可以快速扫描 SBOM 找到受影响的依赖版本。代价生成 SBOM 增加了 CI 时间约 30-60 秒SBOM 文件可能几 MB。如果你的依赖很少10 个SBOM 的价值有限。4.3 适用边界与禁用场景适用CLI 工具分发、企业内部二进制部署、安全敏感场景金融/医疗禁用开源库的 npm/pip 包分发这些平台有自己的签名机制、内部开发环境信任内网安全、快速迭代的早期项目签名流程增加 CI 时间4.4 与 SLSA 的关系SLSASupply-chain Levels for Software Artifacts是一个框架定义了四个信任级别SLSA 1构建文档化→ SLSA 2签名构建→ SLSA 3防篡改构建环境→ SLSA 4可重复构建。cosign 签名达到 SLSA 2要达到 SLSA 3-4 需要更多基础设施可信构建平台、hermetic 构建。五、结语二进制产物安全分发的核心是端到端验证从构建签名到下载验证到运行时自检每个环节都需要独立验证。cosign 签名验证来源可信谁构建了这个产物SHA256 校验和验证传输完整下载的文件与上传的一致运行时自检验证磁盘完整执行前文件没有被篡改。Keyless 签名用 OIDC 身份替代密钥管理降低了公钥分发成本。SBOM 提供依赖溯源能力供应链攻击时快速定位受影响版本。信任链不能断签名→校验和→自检缺任何一个环节验证都不完整。