CodeGraph验证发布体系npm Provenance与SLSA构建证明完全指南【免费下载链接】codegraphPre-indexed code knowledge graph, auto syncs on code changes, for Claude Code, Codex, Gemini, Cursor, OpenCode, AntiGravity, Kiro, CoPilot, and Hermes Agent — fewer tokens, fewer tool calls, 100% local项目地址: https://gitcode.com/GitHub_Trending/co0degr/codegraphCodeGraph 是一个 100% 本地运行的代码知识图谱工具为 AI 编程助手提供精准的代码上下文。但工具再好如果你无法确认装进电脑里的版本确实来自官方仓库风险依然存在。本文带你完整理解 CodeGraph 的验证发布体系npm provenance来源证明、OIDC 可信发布与 SLSA 构建证明并学会 3 条命令亲自验证你安装的版本是否可信。为什么要验证你安装的 npm 包想象一下供应链攻击的典型场景攻击者拿到你的长期 API 令牌向 npm 仓库推送了一个看起来一模一样的恶意版本。你npm install时毫无察觉。CodeGraph 的解法很直接——让令牌被偷这件事变得无意义官方不再保存任何长期 npm 令牌发布权限由 CI 工作流的身份在发布瞬间临时换取每个发布版本都附带一份可公开验证的密码学证明写明这个包由哪个仓库、哪个提交、哪次工作流运行构建。这套机制在 README.md 的 Verified releases 一节中有官方声明每个制品都由公开的 Release 工作流构建并发布——绝不来自某台笔记本。第一道防线OIDC 可信发布没有令牌可偷CodeGraph 的发布入口是手动触发的 release.yml 工作流。注意它只申请了一个特殊权限permissions: id-token: write # OIDC token用于 npm --provenance 与 Sigstore 签名所谓OIDC 可信发布Trusted Publishing发布时npm 官网不验证你持有我的令牌而是验证你是那个被登记的仓库工作流。工作流从 GitHub 获取一个短时效身份令牌用它向 npm 换一个一次性发布凭证。这意味着三件事仓库 secrets 里没有 NPM_TOKEN偷仓库等于偷空气即使攻击者拿到你的 GitHub 账号也无法在别的仓库/分支上发布每个平台包codegraph-darwin-arm64、codegraph-win32-x64……都在 npm 上单独登记了这个可信发布者新平台包不登记就不能发。 一个小细节可信发布要求 npm ≥ 11.5而 Node 22 自带的 npm 是 10所以 release.yml 里专门加了一步升级 npm。第二道防线npm Provenance把版本绑死到精确提交发布步骤在 release.yml 第 249-271 行npm publish --access public --provenance--provenance参数让 npm 为每个包生成一份来源证明attestation内容回答三个问题问题证明里写了什么谁构建的官方仓库 release.yml 工作流的某次运行用什么源码精确到 commit SHA在哪构建的官方 CI 环境而非任何人的本地机器为了让这份证明成立scripts/pack-npm.sh 在打包时会给每个平台包的 package.json 写入正确的repository字段——注释里写得很直白npm --provenance refuses to publish unless this matches the repo仓库不匹配就拒绝发布。如何验证你装的东西在项目中运行一条命令npm audit signatures它会列出当前项目里所有带 provenance 声明的包并对每份声明做密码学校验。看到 ✅ 且仓库/提交与官方一致就说明这个版本确实出自官方流水线。第三道防线SLSA 构建证明GitHub Release 下载包如果你不走 npm而是下载安装脚本或 GitHub Release 里的压缩包CodeGraph 用了另一套证明SLSA v1.0 Build Level 2。SLSASecure Software Supply Chain Levels是 Google 牵头制定的一套供应链安全标准按 0-3 级衡量构建过程有多难被篡改。Build Level 2 的核心要求是制品与构建过程之间存在密码学绑定且该过程可被第三方独立验证。在 release.yml 第 211-221 行每个平台压缩包和SHA256SUMS都会被签名证明- name: Attest build provenance for release bundles uses: actions/attest-build-provenancev4 with: subject-path: | release/codegraph-* release/SHA256SUMS为什么SHA256SUMS不够因为它和压缩包放在同一个 Release 页面——攻击者若能篡改页面可以连哈希表一起改掉。构建证明则绑定到工作流运行记录篡改无从下手。验证任意下载的压缩包gh attestation verify codegraph-darwin-arm64.tar.gz -R colbymchenry/codegraph一次完整发布背后发生了什么把整条流水线串起来一次发布共 5 大步见 release.yml 头部注释读版本号从 package.json 读取发布前手动 bump整理发布说明scripts/prepare-release.mjs 把 CHANGELOG 里的[Unreleased]区块幂等地提升为[version]并自动提交回 main——保证发布说明不会因为维护者忘了提前整理而残缺构建全部平台6 个平台的自包含捆绑包内置 Node 运行时零编译外加 Rust 提取内核的预编译矩阵——内核构建失败会直接阻塞发布而不是悄悄发一个缺内核的包发布 GitHub Release 签名证明打 tag、上传压缩包与 SHA256SUMS、生成 SLSA 构建证明发布 npm 并回查先平台包、后主 shim 包依赖关系决定顺序发布后会逐个回查 registry确认版本真的出现了——npm publish 打印成功 ≠ 真的上架绿色勾才是真的发货。常见问题速答Q所有版本都有证明吗不是。2026 年 7 月之前发布的版本早于这条流水线不带证明。升级到新版本即可纳入验证范围codegraph upgrade。Qprovenance 和构建证明有什么区别npm provenance 管npm 上的包SLSA 构建证明管Release 页面上的压缩包两者同一套签名基础设施覆盖两种下载渠道。Q普通用户必须验证吗日常使用不强制但对企业用户、或在 CI 中自动安装 CLI 的团队一条npm audit signatures就能把供应链风险变成可审计事实。关键文件清单文件作用.github/workflows/release.yml唯一发布入口可信发布、签名、回查scripts/pack-npm.sh组装主包 平台包的 npm 发布结构scripts/prepare-release.mjs幂等地整理 CHANGELOG 发布说明README.mdVerified releases 官方声明与验证命令一句话总结CodeGraph 把信任我变成了验证我——没有长期令牌、没有本地构建、每个版本都有密码学回执。这正是 npm provenance 与 SLSA 构建证明该有的样子。【免费下载链接】codegraphPre-indexed code knowledge graph, auto syncs on code changes, for Claude Code, Codex, Gemini, Cursor, OpenCode, AntiGravity, Kiro, CoPilot, and Hermes Agent — fewer tokens, fewer tool calls, 100% local项目地址: https://gitcode.com/GitHub_Trending/co0degr/codegraph创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考