NautilusTrader 发布流水线安全架构威胁模型、信任根与工件验证实战指南【免费下载链接】nautilus_traderProduction-grade Rust-native trading engine with deterministic event-driven architecture项目地址: https://gitcode.com/GitHub_Trending/na/nautilus_traderNautilusTrader 是一个生产级的 Rust 原生交易引擎事件驱动、确定性架构其发布安全模型覆盖从源码提交到包索引、容器镜像与 GitHub Release 的完整链路。本文以 安全架构文档 为核心结合仓库内 SECURITY.md、发布指南、CI/CD 总览 及.github/workflows/与scripts/ci/中的真实实现系统讲解 NautilusTrader 的发布威胁模型、信任根、发布时序、工件完整性/出处记录以及面向消费者的端到端验证命令。读完本文你将掌握如何独立校验 Python wheel/sdist、PyPI 发布出处、Rust crates 与 Docker 镜像的真实性与完整性并理解其背后的 OIDC Trusted Publishing、Sigstore 与 SLSA 设计。一、发布流水线的安全目标NautilusTrader 的发布流水线有四个核心安全目标全部围绕可审计、可验证、最小化长期凭据展开每个官方工件都必须来自经过评审的仓库提交reviewed repository commit确保代码即事实。发布 Python 与 Rust 包时不得使用长期有效的包注册表令牌通过 PyPI / crates.io Trusted Publishing 以 OIDC 短期身份替代。在发布 GitHub Release 之前先附加校验和、清单与出处证明provenance使完整性记录先于公开可见。向用户提供足够的公开数据使其能验证下载的工件与发布内容一致即消费者侧可复现 CI 的校验结论。GitHub Release 是整个链路完整性的锚点anchor稳定版发布时wheels 与 sdist 会先以资产形式挂到draft草稿GitHub Release上然后才开始向包索引发布流水线随后发布包索引、并对照 GitHub Release 资产逐一核验索引内容最后附加最终完整性资产并正式发布 GitHub Release。这种先挂草稿、后发索引、再验索引、最后发布的时序配合 GitHub 对已发布 Release 资产与标签的不可变性构成了完整性的闭环。二、威胁模型防御什么不防御什么2.1 流水线主动防御的威胁威胁防御机制仓库证据第三方 GitHub Actions 被入侵或可变Actions 全部以完整 commit SHA固定版本build.yml 中step-security/harden-runner05e31511...、actions/checkout3d3c42e...等均带 SHA 与注释标签OVERVIEW.md 要求外部 Action 注明来源 URL、记录对应 release tag且发布至少两周后才可采纳从错误的 workflow / 分支 / 环境误发布OIDC publisher 严格绑定仓库nautechsystems/nautilus_trader、build.yml与release环境见下方信任根一节长期包注册表令牌失窃PyPI 与 crates.io 均启用 Trusted Publishing无持久 token发布作业仅需id-token: write见 build.yml 的publish作业权限声明注册表传播延迟或部分重跑导致状态不一致发布与校验脚本幂等且容忍重试见 verify-published-registries.bash跳过已存在版本、等待 sparse index 同步注册表被替换或上传漂移将 PyPI / crates.io 工件与发布清单及注册表元数据逐项比对见 verify-published-registries.bash 与dist-manifest.json、crates-manifest.json静默手工恢复 crate强制显式声明CRATES_IO_MANUAL_PUBLISH_EXCEPTIONS并在crates-manifest.json中记录例外见 verify-published-registries.bash 对例外条目的校验逻辑2.2 流水线明确不防御的范围文档明确划定了边界避免虚假安全感有权修改发布 workflow 并审批发布的恶意维护者信任模型不防内部恶意的最终权威GitHub、PyPI、crates.io 或 Sigstore信任根自身被攻破可伪造用户依赖的信任根用户机器在验证执行前已被入侵交易所、券商、数据提供商或用户交易策略的运行时被攻破wheels/sdist 的逐位可复现构建漂移——当前保证的是出处provenance与摘要验证而非可复现构建reproducible builds。三、信任根Trust Roots流水线依赖以下六类信任根层层递进GitHub 仓库规则rulesets保护受审源码、发布分支与发布标签受保护的master分支与不可变的v*发布标签是相关记录。对应实现见 CODEOWNERS 与仓库 rulesets。GitHub Actions OIDC 颁发者从https://token.actions.githubusercontent.com提供短期工作流身份。GitHubrelease部署环境限制部署仅针对master并要求评审者审批是所有包发布与 Release 审批的门禁。PyPI Trusted Publishing发布 wheels 与 sdist 无需持久 token绑定仓库nautechsystems/nautilus_trader、workflowbuild.yml、环境release。crates.io Trusted Publishing绑定 ownernautechsystems、仓库nautilus_trader、workflowbuild.yml、环境release。crates.io 各 crate 的发布配置要求见 releases.md 中的表格Owner / Repository / Workflow / Environment 四字段。Sigstore Fulcio / Rekor / TUF将工件绑定到 OIDC 身份与透明日志。GitHub artifact attestations、PyPI publish attestations 与 Docker cosign 签名均依赖此根。GitHub Release 不可变性已发布的 Release 资产与 release tag 不可替换防止发布后被篡改。补充实现事实部署环境隔离不仅用于release还扩展了r2-develop、r2-nightly两个发布环境见 OVERVIEW.md发布/包发布作业使用作用域化的部署环境使发布凭据与 OIDC trusted-publisher 身份与测试、lint、纯构建作业隔离。四、发布流程Release Flowsecurity.md给出了完整的 mermaid 时序图本文以文字形式完整保留并补充源码依据流程关键点与源码对照先审后发master分支上的发布提交进入build.yml先跑发布门禁——Rust 测试套件、cargo-deny、cargo-vet、Cargo publish 预检与 docs/features 预检见 releases.md 的稳定发布工作流。同时 security-audit.yml 以workflow_call方式被build.yml调用作为发布门禁的一部分。门禁顺序约束tag-release必须依赖security-audit保证审计失败时不能继续打稳定版标签见 releases.md 的时序规则清单。先草稿后发布先创建 tag 与 draft GitHub Releasewheels 与 sdist 资产必须先挂到 draft 上再向packages.nautechsystems.io、PyPI、crates.io 发布发布完成后由publish-release-integrity先生成清单、再对照清单核验注册表、核验通过后才附加最终完整性资产publish-github-release必须是稳定发布的最后一个作业发布后校验 GitHub 的 release attestation同一节中列出了全部时序约束。Docker 独立但同模型Docker 工作流docker.yml与包发布工作流相互独立但采用相同的身份模型——镜像签名与 SBOM attestation 将镜像 digest 绑定到预期的 GitHub Actions workflow 身份。五、工件记录Artifact Records不同工件类别使用不同的完整性与出处记录组合工件发布目标完整性记录出处记录Python wheelsGitHub Releases、PyPI、Nautech Systems 包索引packages.nautechsystems.ioSHA256SUMS、每资产.sha256文件、dist-manifest.jsonGitHub artifact attestations、PyPI publish attestations、.sigstore包、.intoto.jsonlDSSE 信封Python sdistGitHub Releases、PyPI与 wheels 相同的记录与 wheels 相同但不发布到仅限 wheel 的包索引Rust cratescrates.iocrates.io checksum、crates-manifest.jsoncrates.iotrustpub_data除非存在显式手工例外Docker 镜像GitHub Container Registry镜像 digestSigstore cosign 签名、SPDX SBOM attestationGitHub Release 记录GitHub Releases已发布资产 不可变 tagGitHub release attestation关于crates-manifest.json的生成可从源码确认脚本 verify-published-registries.bash 会读取 crates.io API 的trustpub_dataprovider / repository / sha与本地校验和逐 crate 生成 JSONL 并汇总为crates-manifest.json其中每项包含trusted_publishing与release_status例如manual_token_publish字段。六、消费者验证映射Consumer Verification Mapsecurity.md声明详细命令位于 SECURITY.md 的 Verifying releases 一节仓库中对应 SECURITY.md并给出每类消费者应验证的公开数据清单与示例命令。以下完整继承并补全。6.1 Python wheels 与 sdist应验证工件 digest 与SHA256SUMS、每资产.sha256文件或dist-manifest.json一致GitHub artifact attestation 身份匹配nautechsystems/nautilus_trader/.github/workflows/build.yml的master或nightly分支PyPI publish attestation 报告仓库nautechsystems/nautilus_trader、workflowbuild.yml、环境release。示例命令完整保留原文档脚本并补充环境变量说明: ${VERSION:?Set VERSION to the Python package version} : ${ARTIFACT:?Set ARTIFACT to the release asset filename} TAGv$VERSION REPOnautechsystems/nautilus_trader ISSUERhttps://token.actions.githubusercontent.com IDENTITY^https://github\.com/nautechsystems/nautilus_trader/\.github/workflows/build\.ymlrefs/heads/(master|nightly)$ # 1) 从 GitHub Release 下载资产与其 .sha256 侧车文件 gh release download $TAG --repo $REPO --pattern $ARTIFACT --pattern $ARTIFACT.sha256 # 2) 校验本地摘要与发布记录一致 sha256sum -c $ARTIFACT.sha256 # 3) 校验 Sigstore 出处身份必须来自 build.yml 且分支为 master 或 nightly gh attestation verify $ARTIFACT \ --repo $REPO \ --cert-identity-regex $IDENTITY \ --cert-oidc-issuer $ISSUERSECURITY.md 补充了两点实用细节GitHub CLI 默认从 GitHub API 拉取 attestations也可改用--bundle artifact.sigstore校验本地下载的 Sigstore bundlegh attestation verify每次调用只接受一个 subject因此多个 wheel 应循环验证该文件中给出了for whl in nautilus_trader-*.whl的循环写法。6.2 PyPI 发布出处应验证PyPI 文件哈希与dist-manifest.json一致PyPI provenance 暴露预期的 GitHub publisher 身份pypi-attestations verify接受下载文件的 URL。示例命令: ${VERSION:?Set VERSION to the Python package version} : ${ARTIFACT:?Set ARTIFACT to the release asset filename} # 从 PyPI JSON API 解析出对应文件名的下载 URL PYPI_URL$(curl -sS https://pypi.org/pypi/nautilus_trader/$VERSION/json | \ jq -r --arg artifact $ARTIFACT .urls[] | select(.filename $artifact) | .url) # 用隔离环境中的 pypi-attestations 校验出处仓库将 pypi-attestations 固定为 0.0.30见 tools.toml uv run --no-project --no-build --with pypi-attestations -- \ pypi-attestations verify pypi \ --repository https://github.com/nautechsystems/nautilus_trader \ $PYPI_URL6.3 Rust crates应验证crates.io 版本的 checksum 与下载的.crate文件一致trustpub_data.provider为githubtrustpub_data.repository为nautechsystems/nautilus_traderpublished_by为null除非crates-manifest.json记录了显式的manual_token_publish例外。示例命令CRATE${CRATE:-nautilus-core} : ${VERSION:?Set VERSION to the crate version} REPOnautechsystems/nautilus_trader # 从 crates.io API 取版本元数据提取 checksum 与 trustpub_data VERSION_JSON$(curl -sS https://crates.io/api/v1/crates/$CRATE/versions | \ jq -c --arg version $VERSION .versions[] | select(.num $version)) CRATE_SHA256$(printf %s\n $VERSION_JSON | jq -r .checksum) # 断言Trusted Publishing 身份正确且非手工 token 发布 printf %s\n $VERSION_JSON | jq -e --arg repo $REPO \ .trustpub_data.provider github and .trustpub_data.repository $repo and .published_by null # 下载 .crate 并比对摘要 curl -sSL https://static.crates.io/crates/$CRATE/$CRATE-$VERSION.crate -o $CRATE-$VERSION.crate test $(sha256sum $CRATE-$VERSION.crate | cut -d -f 1) $CRATE_SHA2566.4 Docker 镜像应验证可变 tag 解析到你想运行的 digestcosign 签名身份匹配 Docker workflowSPDX SBOM attestation 绑定到同一镜像 digest。示例命令export IMAGE_BASEghcr.io/nautechsystems/nautilus_trader # 关键先把可变 tag 解析为不可变 digest后续 pull/run/校验均基于同一 digest export DIGEST$(crane digest $IMAGE_BASE:latest) export IMAGE$IMAGE_BASE$DIGEST export ISSUERhttps://token.actions.githubusercontent.com export IDENTITY^https://github\.com/nautechsystems/nautilus_trader/\.github/workflows/docker\.ymlrefs/heads/(master|nightly)$ # 校验 cosign 签名证明镜像由 NautilusTrader CI workflow 构建 cosign verify $IMAGE --certificate-identity-regexp $IDENTITY --certificate-oidc-issuer $ISSUER # 校验 SPDX SBOM attestation 绑定同一 digest cosign verify-attestation \ --type https://spdx.dev/Document/v2.3 \ $IMAGE \ --certificate-identity-regexp $IDENTITY \ --certificate-oidc-issuer $ISSUERSECURITY.md 补充GitHub CLI 也能校验 SBOM attestationgh attestation verify oci://${IMAGE} --predicate-type https://spdx.dev/Document/v2.3 ...但它不检查cosign 镜像签名因此只能作为cosign verify的补充而非替代。七、手工恢复姿态Manual Recovery Posture正常发布只走 Trusted Publishing。手工发布带 token 发布是部分发布失败后的最后兜底恢复路径且受到严格约束优先重跑注册表或 Sigstore 验证器失败时优先重跑失败的 job 或 workflow而不是手工干预发布后不可变更不得替换已发布的 release tag 或 GitHub Release 资产禁止静默接受不得静默接受手工发布的 crate显式声明例外若必须用 token 恢复某 crate须将每个crateversion列入CRATES_IO_MANUAL_PUBLISH_EXCEPTIONS记录例外在发布说明与crates-manifest.json中记录release_status设为manual_token_publish。从实现看脚本对例外条目的校验是双向的格式非法或未被使用的例外条目都会使作业失败见 verify-published-registries.bash且后发布验证只有在 crates.io 显示该 crate 版本由本仓库 trusted-published 时才视为previously_published否则即使列入例外也需要逐项核对见 releases.md 的 crates.io publishing 一节。结论没有任何常规发布路径依赖长期有效的 PyPI 或 crates.io token。八、事件响应姿态Incident Response Posturesecurity.md为每类可检测异常定义了明确的响应动作检测到的异常响应动作PyPI publisher 漂移由 PyPI provenance 验证器发现停止发布、修复 PyPI Trusted Publisher、重跑验证crates.io publisher 漂移由 trusted-publishing 检查或注册表验证器发现修复 crate publisher 设置并重跑仅在部分恢复时使用手工例外GitHub Release 资产不匹配由校验和或清单验证发现发布前停止发布若资产已随发布外发则发布安全通告advisorySigstore / Rekor / TUF 延迟表现为可重试的透明日志错误有界退避重试若延迟持续则暂停发布密封release sealingSigstore 信任根疑虑当 attestation 验证变得不明确时出现暂停发布、对照注册表记录核验、在支持时轮换信任根Workflow 身份不匹配由 GitHub、PyPI 或 cosign 身份检查发现在审查完成前按配置漂移或入侵处理手工 crate 发布例外当 crates.io 显示published_by而非trustpub_data时发现记录显式例外、记录受影响的 crates、保留审计线索九、SLSA 姿态SLSA PosturePython 发布工件通过GitHub artifact attestations 与 PyPI publish attestations携带构建出处Docker 镜像携带Sigstore 签名与 SPDX SBOM attestationRust crates 依赖crates.io Trusted Publishing 元数据与发布时的crates-manifest.json。文档明确本文不对所有工件类别断言某一具名 SLSA 级别。任何未来的 SLSA 级别声明都必须引用本架构、指明其覆盖的工件类别并在 CI 中加入验证——即校验已发布出处可解析为所声明的 predicate 类型。这是一条先验证、后声明的严谨边界。十、从源码看发布安全的实现支柱除security.md本身外仓库中的以下文件是上述安全设计的落地证据可继续深入阅读SECURITY.md消费端完整验证命令含 wheel 循环验证、Docker SBOM 的gh attestation补充校验、漏洞报告流程、OpenSSF Scorecard、依赖冷却期Python 7 天exclude-newer、Rust 3 天冷却、no-build-packagewheel-only 安装、运行时密码学选型TLS 与多数运行时密码学使用aws-lc-rsEd25519 使用ed25519-dalekAWS-LC 以非 FIPS 模式运行的原因以及已处理的第三方 advisory 记录。releases.md三分支模型develop/nightly/master、稳定发布工作流的完整 mermaid 时序、crates.io Trusted Publishing 配置字段表、发布清单与发布说明规范。.github/OVERVIEW.mdCI 侧约束——CODEOWNERS 评审要求、Action 采用冷却期、Docker 基础镜像与 service container 的 digest 固定、最小权限GITHUB_TOKEN、网络出口白名单step-security/harden-runner默认egress-policy: block、SECURITY_GATE_OVERRIDE门禁覆盖机制格式UTC expiryfull commit SHA、过期时间不得超过未来两小时、失败关闭。deny.tomlcargo-deny配置——只允许 crates.io 作为注册表unknown-registry deny、unknown-git deny、禁止通配符版本、多版本重复检测、LGPL-3.0 兼容许可证白名单与带理由的 advisory 忽略清单。security-audit.ymlzizmorGitHub Actions 审计 supply-chain 双作业的变更感知审计path-filteredaudit-result聚合门禁cargo audit、cargo-deny、cargo-vet、pip-audit、OSV-Scanner、Zizmor 全部纳入。verify-published-registries.bashcrates-manifest.json的实际生成与注册表核验逻辑trustpub_data解析、CRATES_IO_MANUAL_PUBLISH_EXCEPTIONS双向校验、逐 crate 生成 JSONL 清单。tools.toml 与 rust-toolchain.toml工具链版本固定含pypi-attestations 0.0.30、nightly/miri 固定版本支撑可复现的 CI 与验证环境。结语NautilusTrader 的发布安全架构用一句话概括以受审提交 OIDC 短期身份 草稿 Release 先行 注册表对照核验 Sigstore/SLSA 出处记录 GitHub Release 不可变性组成纵深防御链。对消费者而言核心理念是先验后用——通过本文第六节的四组命令任何人无需信任发布方即可独立确认所获工件的完整性与出处。若需进一步阅读可依次查阅 SECURITY.md消费端命令全集、releases.md发布时序约束与 .github/OVERVIEW.mdCI 控制细节。【免费下载链接】nautilus_traderProduction-grade Rust-native trading engine with deterministic event-driven architecture项目地址: https://gitcode.com/GitHub_Trending/na/nautilus_trader创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 NautilusTrader 发布流水线安全架构：威胁模型、信任根与工件验证实战指南
NautilusTrader 发布流水线安全架构威胁模型、信任根与工件验证实战指南【免费下载链接】nautilus_traderProduction-grade Rust-native trading engine with deterministic event-driven architecture项目地址: https://gitcode.com/GitHub_Trending/na/nautilus_traderNautilusTrader 是一个生产级的 Rust 原生交易引擎事件驱动、确定性架构其发布安全模型覆盖从源码提交到包索引、容器镜像与 GitHub Release 的完整链路。本文以 安全架构文档 为核心结合仓库内 SECURITY.md、发布指南、CI/CD 总览 及.github/workflows/与scripts/ci/中的真实实现系统讲解 NautilusTrader 的发布威胁模型、信任根、发布时序、工件完整性/出处记录以及面向消费者的端到端验证命令。读完本文你将掌握如何独立校验 Python wheel/sdist、PyPI 发布出处、Rust crates 与 Docker 镜像的真实性与完整性并理解其背后的 OIDC Trusted Publishing、Sigstore 与 SLSA 设计。一、发布流水线的安全目标NautilusTrader 的发布流水线有四个核心安全目标全部围绕可审计、可验证、最小化长期凭据展开每个官方工件都必须来自经过评审的仓库提交reviewed repository commit确保代码即事实。发布 Python 与 Rust 包时不得使用长期有效的包注册表令牌通过 PyPI / crates.io Trusted Publishing 以 OIDC 短期身份替代。在发布 GitHub Release 之前先附加校验和、清单与出处证明provenance使完整性记录先于公开可见。向用户提供足够的公开数据使其能验证下载的工件与发布内容一致即消费者侧可复现 CI 的校验结论。GitHub Release 是整个链路完整性的锚点anchor稳定版发布时wheels 与 sdist 会先以资产形式挂到draft草稿GitHub Release上然后才开始向包索引发布流水线随后发布包索引、并对照 GitHub Release 资产逐一核验索引内容最后附加最终完整性资产并正式发布 GitHub Release。这种先挂草稿、后发索引、再验索引、最后发布的时序配合 GitHub 对已发布 Release 资产与标签的不可变性构成了完整性的闭环。二、威胁模型防御什么不防御什么2.1 流水线主动防御的威胁威胁防御机制仓库证据第三方 GitHub Actions 被入侵或可变Actions 全部以完整 commit SHA固定版本build.yml 中step-security/harden-runner05e31511...、actions/checkout3d3c42e...等均带 SHA 与注释标签OVERVIEW.md 要求外部 Action 注明来源 URL、记录对应 release tag且发布至少两周后才可采纳从错误的 workflow / 分支 / 环境误发布OIDC publisher 严格绑定仓库nautechsystems/nautilus_trader、build.yml与release环境见下方信任根一节长期包注册表令牌失窃PyPI 与 crates.io 均启用 Trusted Publishing无持久 token发布作业仅需id-token: write见 build.yml 的publish作业权限声明注册表传播延迟或部分重跑导致状态不一致发布与校验脚本幂等且容忍重试见 verify-published-registries.bash跳过已存在版本、等待 sparse index 同步注册表被替换或上传漂移将 PyPI / crates.io 工件与发布清单及注册表元数据逐项比对见 verify-published-registries.bash 与dist-manifest.json、crates-manifest.json静默手工恢复 crate强制显式声明CRATES_IO_MANUAL_PUBLISH_EXCEPTIONS并在crates-manifest.json中记录例外见 verify-published-registries.bash 对例外条目的校验逻辑2.2 流水线明确不防御的范围文档明确划定了边界避免虚假安全感有权修改发布 workflow 并审批发布的恶意维护者信任模型不防内部恶意的最终权威GitHub、PyPI、crates.io 或 Sigstore信任根自身被攻破可伪造用户依赖的信任根用户机器在验证执行前已被入侵交易所、券商、数据提供商或用户交易策略的运行时被攻破wheels/sdist 的逐位可复现构建漂移——当前保证的是出处provenance与摘要验证而非可复现构建reproducible builds。三、信任根Trust Roots流水线依赖以下六类信任根层层递进GitHub 仓库规则rulesets保护受审源码、发布分支与发布标签受保护的master分支与不可变的v*发布标签是相关记录。对应实现见 CODEOWNERS 与仓库 rulesets。GitHub Actions OIDC 颁发者从https://token.actions.githubusercontent.com提供短期工作流身份。GitHubrelease部署环境限制部署仅针对master并要求评审者审批是所有包发布与 Release 审批的门禁。PyPI Trusted Publishing发布 wheels 与 sdist 无需持久 token绑定仓库nautechsystems/nautilus_trader、workflowbuild.yml、环境release。crates.io Trusted Publishing绑定 ownernautechsystems、仓库nautilus_trader、workflowbuild.yml、环境release。crates.io 各 crate 的发布配置要求见 releases.md 中的表格Owner / Repository / Workflow / Environment 四字段。Sigstore Fulcio / Rekor / TUF将工件绑定到 OIDC 身份与透明日志。GitHub artifact attestations、PyPI publish attestations 与 Docker cosign 签名均依赖此根。GitHub Release 不可变性已发布的 Release 资产与 release tag 不可替换防止发布后被篡改。补充实现事实部署环境隔离不仅用于release还扩展了r2-develop、r2-nightly两个发布环境见 OVERVIEW.md发布/包发布作业使用作用域化的部署环境使发布凭据与 OIDC trusted-publisher 身份与测试、lint、纯构建作业隔离。四、发布流程Release Flowsecurity.md给出了完整的 mermaid 时序图本文以文字形式完整保留并补充源码依据流程关键点与源码对照先审后发master分支上的发布提交进入build.yml先跑发布门禁——Rust 测试套件、cargo-deny、cargo-vet、Cargo publish 预检与 docs/features 预检见 releases.md 的稳定发布工作流。同时 security-audit.yml 以workflow_call方式被build.yml调用作为发布门禁的一部分。门禁顺序约束tag-release必须依赖security-audit保证审计失败时不能继续打稳定版标签见 releases.md 的时序规则清单。先草稿后发布先创建 tag 与 draft GitHub Releasewheels 与 sdist 资产必须先挂到 draft 上再向packages.nautechsystems.io、PyPI、crates.io 发布发布完成后由publish-release-integrity先生成清单、再对照清单核验注册表、核验通过后才附加最终完整性资产publish-github-release必须是稳定发布的最后一个作业发布后校验 GitHub 的 release attestation同一节中列出了全部时序约束。Docker 独立但同模型Docker 工作流docker.yml与包发布工作流相互独立但采用相同的身份模型——镜像签名与 SBOM attestation 将镜像 digest 绑定到预期的 GitHub Actions workflow 身份。五、工件记录Artifact Records不同工件类别使用不同的完整性与出处记录组合工件发布目标完整性记录出处记录Python wheelsGitHub Releases、PyPI、Nautech Systems 包索引packages.nautechsystems.ioSHA256SUMS、每资产.sha256文件、dist-manifest.jsonGitHub artifact attestations、PyPI publish attestations、.sigstore包、.intoto.jsonlDSSE 信封Python sdistGitHub Releases、PyPI与 wheels 相同的记录与 wheels 相同但不发布到仅限 wheel 的包索引Rust cratescrates.iocrates.io checksum、crates-manifest.jsoncrates.iotrustpub_data除非存在显式手工例外Docker 镜像GitHub Container Registry镜像 digestSigstore cosign 签名、SPDX SBOM attestationGitHub Release 记录GitHub Releases已发布资产 不可变 tagGitHub release attestation关于crates-manifest.json的生成可从源码确认脚本 verify-published-registries.bash 会读取 crates.io API 的trustpub_dataprovider / repository / sha与本地校验和逐 crate 生成 JSONL 并汇总为crates-manifest.json其中每项包含trusted_publishing与release_status例如manual_token_publish字段。六、消费者验证映射Consumer Verification Mapsecurity.md声明详细命令位于 SECURITY.md 的 Verifying releases 一节仓库中对应 SECURITY.md并给出每类消费者应验证的公开数据清单与示例命令。以下完整继承并补全。6.1 Python wheels 与 sdist应验证工件 digest 与SHA256SUMS、每资产.sha256文件或dist-manifest.json一致GitHub artifact attestation 身份匹配nautechsystems/nautilus_trader/.github/workflows/build.yml的master或nightly分支PyPI publish attestation 报告仓库nautechsystems/nautilus_trader、workflowbuild.yml、环境release。示例命令完整保留原文档脚本并补充环境变量说明: ${VERSION:?Set VERSION to the Python package version} : ${ARTIFACT:?Set ARTIFACT to the release asset filename} TAGv$VERSION REPOnautechsystems/nautilus_trader ISSUERhttps://token.actions.githubusercontent.com IDENTITY^https://github\.com/nautechsystems/nautilus_trader/\.github/workflows/build\.ymlrefs/heads/(master|nightly)$ # 1) 从 GitHub Release 下载资产与其 .sha256 侧车文件 gh release download $TAG --repo $REPO --pattern $ARTIFACT --pattern $ARTIFACT.sha256 # 2) 校验本地摘要与发布记录一致 sha256sum -c $ARTIFACT.sha256 # 3) 校验 Sigstore 出处身份必须来自 build.yml 且分支为 master 或 nightly gh attestation verify $ARTIFACT \ --repo $REPO \ --cert-identity-regex $IDENTITY \ --cert-oidc-issuer $ISSUERSECURITY.md 补充了两点实用细节GitHub CLI 默认从 GitHub API 拉取 attestations也可改用--bundle artifact.sigstore校验本地下载的 Sigstore bundlegh attestation verify每次调用只接受一个 subject因此多个 wheel 应循环验证该文件中给出了for whl in nautilus_trader-*.whl的循环写法。6.2 PyPI 发布出处应验证PyPI 文件哈希与dist-manifest.json一致PyPI provenance 暴露预期的 GitHub publisher 身份pypi-attestations verify接受下载文件的 URL。示例命令: ${VERSION:?Set VERSION to the Python package version} : ${ARTIFACT:?Set ARTIFACT to the release asset filename} # 从 PyPI JSON API 解析出对应文件名的下载 URL PYPI_URL$(curl -sS https://pypi.org/pypi/nautilus_trader/$VERSION/json | \ jq -r --arg artifact $ARTIFACT .urls[] | select(.filename $artifact) | .url) # 用隔离环境中的 pypi-attestations 校验出处仓库将 pypi-attestations 固定为 0.0.30见 tools.toml uv run --no-project --no-build --with pypi-attestations -- \ pypi-attestations verify pypi \ --repository https://github.com/nautechsystems/nautilus_trader \ $PYPI_URL6.3 Rust crates应验证crates.io 版本的 checksum 与下载的.crate文件一致trustpub_data.provider为githubtrustpub_data.repository为nautechsystems/nautilus_traderpublished_by为null除非crates-manifest.json记录了显式的manual_token_publish例外。示例命令CRATE${CRATE:-nautilus-core} : ${VERSION:?Set VERSION to the crate version} REPOnautechsystems/nautilus_trader # 从 crates.io API 取版本元数据提取 checksum 与 trustpub_data VERSION_JSON$(curl -sS https://crates.io/api/v1/crates/$CRATE/versions | \ jq -c --arg version $VERSION .versions[] | select(.num $version)) CRATE_SHA256$(printf %s\n $VERSION_JSON | jq -r .checksum) # 断言Trusted Publishing 身份正确且非手工 token 发布 printf %s\n $VERSION_JSON | jq -e --arg repo $REPO \ .trustpub_data.provider github and .trustpub_data.repository $repo and .published_by null # 下载 .crate 并比对摘要 curl -sSL https://static.crates.io/crates/$CRATE/$CRATE-$VERSION.crate -o $CRATE-$VERSION.crate test $(sha256sum $CRATE-$VERSION.crate | cut -d -f 1) $CRATE_SHA2566.4 Docker 镜像应验证可变 tag 解析到你想运行的 digestcosign 签名身份匹配 Docker workflowSPDX SBOM attestation 绑定到同一镜像 digest。示例命令export IMAGE_BASEghcr.io/nautechsystems/nautilus_trader # 关键先把可变 tag 解析为不可变 digest后续 pull/run/校验均基于同一 digest export DIGEST$(crane digest $IMAGE_BASE:latest) export IMAGE$IMAGE_BASE$DIGEST export ISSUERhttps://token.actions.githubusercontent.com export IDENTITY^https://github\.com/nautechsystems/nautilus_trader/\.github/workflows/docker\.ymlrefs/heads/(master|nightly)$ # 校验 cosign 签名证明镜像由 NautilusTrader CI workflow 构建 cosign verify $IMAGE --certificate-identity-regexp $IDENTITY --certificate-oidc-issuer $ISSUER # 校验 SPDX SBOM attestation 绑定同一 digest cosign verify-attestation \ --type https://spdx.dev/Document/v2.3 \ $IMAGE \ --certificate-identity-regexp $IDENTITY \ --certificate-oidc-issuer $ISSUERSECURITY.md 补充GitHub CLI 也能校验 SBOM attestationgh attestation verify oci://${IMAGE} --predicate-type https://spdx.dev/Document/v2.3 ...但它不检查cosign 镜像签名因此只能作为cosign verify的补充而非替代。七、手工恢复姿态Manual Recovery Posture正常发布只走 Trusted Publishing。手工发布带 token 发布是部分发布失败后的最后兜底恢复路径且受到严格约束优先重跑注册表或 Sigstore 验证器失败时优先重跑失败的 job 或 workflow而不是手工干预发布后不可变更不得替换已发布的 release tag 或 GitHub Release 资产禁止静默接受不得静默接受手工发布的 crate显式声明例外若必须用 token 恢复某 crate须将每个crateversion列入CRATES_IO_MANUAL_PUBLISH_EXCEPTIONS记录例外在发布说明与crates-manifest.json中记录release_status设为manual_token_publish。从实现看脚本对例外条目的校验是双向的格式非法或未被使用的例外条目都会使作业失败见 verify-published-registries.bash且后发布验证只有在 crates.io 显示该 crate 版本由本仓库 trusted-published 时才视为previously_published否则即使列入例外也需要逐项核对见 releases.md 的 crates.io publishing 一节。结论没有任何常规发布路径依赖长期有效的 PyPI 或 crates.io token。八、事件响应姿态Incident Response Posturesecurity.md为每类可检测异常定义了明确的响应动作检测到的异常响应动作PyPI publisher 漂移由 PyPI provenance 验证器发现停止发布、修复 PyPI Trusted Publisher、重跑验证crates.io publisher 漂移由 trusted-publishing 检查或注册表验证器发现修复 crate publisher 设置并重跑仅在部分恢复时使用手工例外GitHub Release 资产不匹配由校验和或清单验证发现发布前停止发布若资产已随发布外发则发布安全通告advisorySigstore / Rekor / TUF 延迟表现为可重试的透明日志错误有界退避重试若延迟持续则暂停发布密封release sealingSigstore 信任根疑虑当 attestation 验证变得不明确时出现暂停发布、对照注册表记录核验、在支持时轮换信任根Workflow 身份不匹配由 GitHub、PyPI 或 cosign 身份检查发现在审查完成前按配置漂移或入侵处理手工 crate 发布例外当 crates.io 显示published_by而非trustpub_data时发现记录显式例外、记录受影响的 crates、保留审计线索九、SLSA 姿态SLSA PosturePython 发布工件通过GitHub artifact attestations 与 PyPI publish attestations携带构建出处Docker 镜像携带Sigstore 签名与 SPDX SBOM attestationRust crates 依赖crates.io Trusted Publishing 元数据与发布时的crates-manifest.json。文档明确本文不对所有工件类别断言某一具名 SLSA 级别。任何未来的 SLSA 级别声明都必须引用本架构、指明其覆盖的工件类别并在 CI 中加入验证——即校验已发布出处可解析为所声明的 predicate 类型。这是一条先验证、后声明的严谨边界。十、从源码看发布安全的实现支柱除security.md本身外仓库中的以下文件是上述安全设计的落地证据可继续深入阅读SECURITY.md消费端完整验证命令含 wheel 循环验证、Docker SBOM 的gh attestation补充校验、漏洞报告流程、OpenSSF Scorecard、依赖冷却期Python 7 天exclude-newer、Rust 3 天冷却、no-build-packagewheel-only 安装、运行时密码学选型TLS 与多数运行时密码学使用aws-lc-rsEd25519 使用ed25519-dalekAWS-LC 以非 FIPS 模式运行的原因以及已处理的第三方 advisory 记录。releases.md三分支模型develop/nightly/master、稳定发布工作流的完整 mermaid 时序、crates.io Trusted Publishing 配置字段表、发布清单与发布说明规范。.github/OVERVIEW.mdCI 侧约束——CODEOWNERS 评审要求、Action 采用冷却期、Docker 基础镜像与 service container 的 digest 固定、最小权限GITHUB_TOKEN、网络出口白名单step-security/harden-runner默认egress-policy: block、SECURITY_GATE_OVERRIDE门禁覆盖机制格式UTC expiryfull commit SHA、过期时间不得超过未来两小时、失败关闭。deny.tomlcargo-deny配置——只允许 crates.io 作为注册表unknown-registry deny、unknown-git deny、禁止通配符版本、多版本重复检测、LGPL-3.0 兼容许可证白名单与带理由的 advisory 忽略清单。security-audit.ymlzizmorGitHub Actions 审计 supply-chain 双作业的变更感知审计path-filteredaudit-result聚合门禁cargo audit、cargo-deny、cargo-vet、pip-audit、OSV-Scanner、Zizmor 全部纳入。verify-published-registries.bashcrates-manifest.json的实际生成与注册表核验逻辑trustpub_data解析、CRATES_IO_MANUAL_PUBLISH_EXCEPTIONS双向校验、逐 crate 生成 JSONL 清单。tools.toml 与 rust-toolchain.toml工具链版本固定含pypi-attestations 0.0.30、nightly/miri 固定版本支撑可复现的 CI 与验证环境。结语NautilusTrader 的发布安全架构用一句话概括以受审提交 OIDC 短期身份 草稿 Release 先行 注册表对照核验 Sigstore/SLSA 出处记录 GitHub Release 不可变性组成纵深防御链。对消费者而言核心理念是先验后用——通过本文第六节的四组命令任何人无需信任发布方即可独立确认所获工件的完整性与出处。若需进一步阅读可依次查阅 SECURITY.md消费端命令全集、releases.md发布时序约束与 .github/OVERVIEW.mdCI 控制细节。【免费下载链接】nautilus_traderProduction-grade Rust-native trading engine with deterministic event-driven architecture项目地址: https://gitcode.com/GitHub_Trending/na/nautilus_trader创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考