OmniRoute 供应链安全门npm Provenance、SBOM、CVE 扫描与 Scorecard 的完整防线【免费下载链接】OmniRouteNever stop coding. Free MIT AI gateway: one endpoint, 352 providers (150 free), 1200 models Kimi, Claude, GPT, Gemini, GLM, DeepSeek, MiniMax. Works with Claude Code, Codex, Cursor, OpenCode, Cline Copilot. Quota-aware auto-fallback, RTKCaveman compression saves 15-95% tokens, MCP/A2A, Desktop/PWA. Built by 550 contributors项目地址: https://gitcode.com/GitHub_Trending/om/OmniRouteOmniRoute 同时发布 npm 包与 Docker 镜像两类构件供应链攻击面因此横跨包注册表与容器镜像两条链路。本文基于仓库文档 docs/security/SUPPLY_CHAIN.mdPhase 8 · Block A「Supply-Chain Gates」完整讲解这套安全门的组成、工作机制与运维手册读者将了解 7 道门的分工provenance、SBOM、CVE 扫描、ratchet 门禁、npm 与 Docker 发布流水线中的具体接入位置以及当「未动依赖的 PR 突然被 CVE 门禁打红」时该如何处置。门矩阵7 道门的工具、位置与阻断策略OmniRoute 发布的构件是 npm 包加 Docker 镜像。这些门Gate提供 provenance溯源、SBOM软件物料清单与 CVE 扫描能力全部基于开源工具直接接入发布工作流。整体策略是advisory-first先建议、后阻断新门先以只报告不阻断的模式上线跑通第一个全绿greenrelease 之后再提升为阻断式。Gate工具所在位置是否阻断产物SLSA provenance (npm)npm --provenanceOIDCnpm-publish.yml仅在发布本身失败时npmjs 徽章 /npm audit signaturesSBOM (npm)cyclonedx/cyclonedx-npmnpm-publish.yml仅在生成失败时Release 附件 workflow artifactSBOM (镜像)anchore/sbom-actionsyftdocker-publish.ymlmerge jobadvisoryCycloneDX artifactTrivy CVE (SARIF)aquasecurity/trivy-actiondocker-publish.ymlmerge jobadvisorySARIFHIGHCRITICAL→ Security 标签页Trivy CRITICAL gateaquasecurity/trivy-actiondocker-publish.ymlmerge job阻断可修复的 CRITICAL 触发exit-code: 1osv vulnCountosv-scannercheck:vuln-ratchet --ratchetci.ymlquality-extended阻断ratchetmetrics.vulnCountdirection:downOpenSSF Scorecardossf/scorecard-actionscorecard.ymlcronadvisorySARIF → Security 徽章npm 侧SLSA Provenance 与 CycloneDX SBOMnpm 发布工作流 npm-publish.yml 中provenance 与 SBOM 两条链的落点如下SLSA provenance最终执行npm publish $TARBALL --provenance --access public --tag $TAG --ignore-scripts通过 GitHub OIDCTrusted Publishing换取短期凭证全程不需要NPM_TOKEN密钥。这里有一个值得注意的实现细节npm 会拒绝来自 self-hosted runner 的--provenance请求422 Unsupported GitHub Actions runner environment因此工作流把「构建 验证 tarball」放在高内存 runner 上完成再拆出一个独立的stage-npmjob 在 GitHub 托管 runner 上执行上传——该 job 拥有id-token: write权限正是为了保住 SLSA 认证不回归。SBOM 生成在发布前运行npx cyclonedx/cyclonedx-npm --ignore-npm-errors --output-format JSON --output-file sbom-npm.cdx.json产物既作为 workflow artifact 上传也在对应的 GitHub Release 存在时通过gh release upload挂到 Release 附件上。文档指出这一步曾在一次 workflow_dispatch 发布中被跳过之后 SBOM 只能从 run 的 artifact 手工补挂——这也是为什么现在的条件判断同时覆盖release与workflow_dispatch两种事件。发布 job 中还有一道与供应链直接相关的防线复用 CI 构建产物next-buildartifact作为发布 tarball 前会用head_repository.full_name github.repository强制过滤 fork 上产生的 run。工作流注释明确说明这是一条 supply-chain guard对应 CodeQL 规则 actions/artifact-poisoning防止 fork 攻击者构造的字节码进入 npm 发布物。Docker 侧Trivy 两步扫描SARIF 可见性 CRITICAL 阻断门镜像 CVE ratchet 在 docker-publish.yml 的mergejob 中使用了两个 Trivy 步骤这是理解整套设计的核心Trivy image scanSARIFadvisoryseverity: HIGH,CRITICAL、exit-code: 0。它把 HIGHCRITICAL 级别的发现持续上报到仓库 Security 标签页SARIF 通过github/codeql-action/upload-sarif上传category 为trivy-image但绝不阻断发布。Trivy CRITICAL gateblockingseverity: CRITICAL、ignore-unfixed: true、exit-code: 1。它只在存在可用修复方案的 CRITICAL CVE 出现时让 release 失败。两个步骤共享trivyignores: .trivyignore配置即被接受风险的可修复 CVE 在同一个文件中有唯一、可审计的归属地。ignore-unfixed的设计意图是基础镜像中尚未有上游补丁的 OS 级 CVE例如 Debian trixie 里尚无 patch 的包不应当红整个 release——工作流注释补充说明这类 CVE 绝大多数是 local-only 且不可从代理请求面触达属于运维人员无法行动的噪音。SBOM 侧同样接入在mergejobanchore/sbom-actionv0以cyclonedx-json格式生成sbom-image.cdx.jsonartifact标记为 advisorycontinue-on-error: true。两个 Trivy 步骤都由if: needs.prepare.outputs.version ! main守卫即只对版本化镜像tag 发布执行扫描门禁main浮动渠道不做阻断。CI 侧osv-scanner 的 vulnCount Ratchet依赖包层面的 CVE 门禁不是独立工作流而是嵌入 ci.yml 的quality-extendedjob通过npm run check:vuln-ratchet -- --ratchet执行对应实现是 scripts/check/check-vuln-ratchet.mjs。其机制在源码中清晰可见度量脚本以--format json --lockfile package-lock.json调用osv-scanner解析results[].packages[].vulnerabilities当存在groups字段时用groups.length做去重同一漏洞出现在多个包中只计一次输出vulnCountN及按严重度的分布。比较evaluateVulnRatchet(current, baseline)返回regressed: current baseline方向为down——漏洞计数只允许下降不允许上升。基线读取自 config/quality/quality-baseline.json 的metrics.vulnCount当前仓库中该指标为value: 27、direction: down、dedicatedGate: true。阻断语义无--ratchet时脚本永远 exit 0advisory加--ratchet后只有实测值超过基线才 exit 1。ci.yml中quality-extendedjob 的注释进一步说明了「混合模式」job 级不再整体continue-on-error三个 ratchet 阻断步骤Secret scan / Workflow lint / Bundle size失败即挂掉 job而依赖外部二进制或外部状态的步骤scanner 安装、vuln/osv ratchet、oasdiff、circular-deps保持 advisory 语义通过步骤级continue-on-error与脚本自身的 SKIP 行为保证「基础设施缺失永不阻断」。scanner 二进制gitleaks、osv-scanner、actionlint、zizmor在安装步骤中通过gh release download下载——工作流注释专门解释了为何放弃未认证的curl api.github.com匿名请求限流 60 次/小时/IP被限流时返回空 body安装会静默失败导致所有门自我 SKIP、指标永远无法产生。OpenSSF Scorecard仓库级姿态的聚合度量.github/workflows/scorecard.yml 以 cron每周一 07:27加默认分支 push 触发使用ossf/scorecard-actionv2.4.4输出results.sarifartifact 并通过publish_results: true生成 OpenSSF 徽章。值得注意的是当前实现的定位工作流注释说明security-events: write权限已被移除——Scorecard 的发现是供应链/姿态评分而非代码漏洞上传到 code-scanning Security 标签页会淹没真正的 CodeQL 告警。因此它保持 advisory 状态只保留徽章与可下载的 SARIF。Scorecard 与 Phase 7 的门形成互补zizmor 审计的是 workflow 文件本身而 Scorecard 度量的是整个仓库的姿态分支保护、CODEOWNERS、依赖更新等聚合得分。CVE 方差为什么没动依赖的 PR 会突然变红这是文档中最具运维价值的一节。osv 与 Trivy 都对比持续增长的 CVE 数据库一个完全不触碰任何依赖的 PR也可能因为某个既有依赖刚刚被披露新 CVE 而突然变红osv实测vulnCount超过基线Trivy镜像中新增可修复的 CRITICAL。这是阻断式 CVE 门的预期运维行为而不是产品回归。处置路径按优先级排序升级受影响的依赖首选——通过package.json的overrides升级传递依赖或在打过补丁的基础镜像上重建容器。仓库中有真实先例基线注释_scanner_remediation_2026_06_15记录了 vulnCount 从 13 降到 10 的处置——通过 overrides 升级 form-data 与 vite 两个传递依赖后osv-scanner 确认 0 HIGH 残留。无上游修复时osv手动重设 config/quality/quality-baseline.json 中metrics.vulnCount的基线值注意npm run quality:ratchet -- --update不覆盖专用门需手工编辑保持direction: down并附理由说明与追踪 issue。Trivy在 .trivyignore 中逐行添加 CVE-ID每行附理由注释与追踪 issueignore-unfixed: true已自动覆盖没有补丁的 CVE无需在此登记。.trivyignore文件头本身就是策略说明书它强调此文件只用于「可修复但必须临时接受」的罕见场景例如上游修复尚未进入所 pin 的基础镜像 tag或受影响组件可证明不可从请求面触达并要求列表保持短小、每次 release 复查、过期条目即债务。优雅 SKIP测量失败永不阻断osv 与 Trivy 两个阻断门都实现了统一的分层语义check-vuln-ratchet.mjs的实现把它落到了代码层osv-scanner不在 PATH → 输出vulnCountSKIP reasonbinary-absentexit 0网络不可达 osv.dev、执行超时、JSON 解析失败 → 输出vulnCountSKIP reason...exit 0基线文件缺失或指标不存在 → 视为无法 ratchet同样 exit 0。即测量measurement失败永不阻断只有测到的回归measured regression才阻断。main()中先findOsvScanner()探测二进制runOsvScanner()用无 shell 插值的方式执行防注入只有拿到有效 JSON 后才进入applyRatchet()做比较与退出码决策。BacklogScorecard 从 advisory 走向 blocking文档最后给出了一条待办在第一个带 Scorecard 报告的绿色 release 之后为 Scorecard 增加score ratchet冻结实测分数分数不允许下降。这条 backlog 与「advisory-first跑绿一次再升阻断」的整体策略一脉相承也与 osv/Trivy 当初的晋升路径一致基线注释中可见_osv_flip_blocking与_trivy_flip_blocking两条记录两者都在 v3.8.27 周期末从 advisory 提升为阻断。小结这套供应链门的设计可以概括为三条原则其一先可见、后阻断——SARIF 步骤先让 HIGHCRITICAL 在 Security 标签页可见阻断步骤只收窄到「可行动的」CRITICAL其二只阻断可行动的信号——ignore-unfixed与优雅 SKIP 共同保证运维者不会为不可修复的基础镜像 CVE 或一次扫描器网络抖动买单其三接受 CVE 方差作为常态——门禁红时的标准动作是升级依赖、有据可查地重设基线而非回滚代码。对任何同时维护 npm 包与容器镜像的项目docs/security/SUPPLY_CHAIN.md 配合 npm-publish.yml、docker-publish.yml、scorecard.yml 与 check-vuln-ratchet.mjs 构成了一份可直接参考的门禁落地清单。【免费下载链接】OmniRouteNever stop coding. Free MIT AI gateway: one endpoint, 352 providers (150 free), 1200 models Kimi, Claude, GPT, Gemini, GLM, DeepSeek, MiniMax. Works with Claude Code, Codex, Cursor, OpenCode, Cline Copilot. Quota-aware auto-fallback, RTKCaveman compression saves 15-95% tokens, MCP/A2A, Desktop/PWA. Built by 550 contributors项目地址: https://gitcode.com/GitHub_Trending/om/OmniRoute创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 OmniRoute 供应链安全门：npm Provenance、SBOM、CVE 扫描与 Scorecard 的完整防线
OmniRoute 供应链安全门npm Provenance、SBOM、CVE 扫描与 Scorecard 的完整防线【免费下载链接】OmniRouteNever stop coding. Free MIT AI gateway: one endpoint, 352 providers (150 free), 1200 models Kimi, Claude, GPT, Gemini, GLM, DeepSeek, MiniMax. Works with Claude Code, Codex, Cursor, OpenCode, Cline Copilot. Quota-aware auto-fallback, RTKCaveman compression saves 15-95% tokens, MCP/A2A, Desktop/PWA. Built by 550 contributors项目地址: https://gitcode.com/GitHub_Trending/om/OmniRouteOmniRoute 同时发布 npm 包与 Docker 镜像两类构件供应链攻击面因此横跨包注册表与容器镜像两条链路。本文基于仓库文档 docs/security/SUPPLY_CHAIN.mdPhase 8 · Block A「Supply-Chain Gates」完整讲解这套安全门的组成、工作机制与运维手册读者将了解 7 道门的分工provenance、SBOM、CVE 扫描、ratchet 门禁、npm 与 Docker 发布流水线中的具体接入位置以及当「未动依赖的 PR 突然被 CVE 门禁打红」时该如何处置。门矩阵7 道门的工具、位置与阻断策略OmniRoute 发布的构件是 npm 包加 Docker 镜像。这些门Gate提供 provenance溯源、SBOM软件物料清单与 CVE 扫描能力全部基于开源工具直接接入发布工作流。整体策略是advisory-first先建议、后阻断新门先以只报告不阻断的模式上线跑通第一个全绿greenrelease 之后再提升为阻断式。Gate工具所在位置是否阻断产物SLSA provenance (npm)npm --provenanceOIDCnpm-publish.yml仅在发布本身失败时npmjs 徽章 /npm audit signaturesSBOM (npm)cyclonedx/cyclonedx-npmnpm-publish.yml仅在生成失败时Release 附件 workflow artifactSBOM (镜像)anchore/sbom-actionsyftdocker-publish.ymlmerge jobadvisoryCycloneDX artifactTrivy CVE (SARIF)aquasecurity/trivy-actiondocker-publish.ymlmerge jobadvisorySARIFHIGHCRITICAL→ Security 标签页Trivy CRITICAL gateaquasecurity/trivy-actiondocker-publish.ymlmerge job阻断可修复的 CRITICAL 触发exit-code: 1osv vulnCountosv-scannercheck:vuln-ratchet --ratchetci.ymlquality-extended阻断ratchetmetrics.vulnCountdirection:downOpenSSF Scorecardossf/scorecard-actionscorecard.ymlcronadvisorySARIF → Security 徽章npm 侧SLSA Provenance 与 CycloneDX SBOMnpm 发布工作流 npm-publish.yml 中provenance 与 SBOM 两条链的落点如下SLSA provenance最终执行npm publish $TARBALL --provenance --access public --tag $TAG --ignore-scripts通过 GitHub OIDCTrusted Publishing换取短期凭证全程不需要NPM_TOKEN密钥。这里有一个值得注意的实现细节npm 会拒绝来自 self-hosted runner 的--provenance请求422 Unsupported GitHub Actions runner environment因此工作流把「构建 验证 tarball」放在高内存 runner 上完成再拆出一个独立的stage-npmjob 在 GitHub 托管 runner 上执行上传——该 job 拥有id-token: write权限正是为了保住 SLSA 认证不回归。SBOM 生成在发布前运行npx cyclonedx/cyclonedx-npm --ignore-npm-errors --output-format JSON --output-file sbom-npm.cdx.json产物既作为 workflow artifact 上传也在对应的 GitHub Release 存在时通过gh release upload挂到 Release 附件上。文档指出这一步曾在一次 workflow_dispatch 发布中被跳过之后 SBOM 只能从 run 的 artifact 手工补挂——这也是为什么现在的条件判断同时覆盖release与workflow_dispatch两种事件。发布 job 中还有一道与供应链直接相关的防线复用 CI 构建产物next-buildartifact作为发布 tarball 前会用head_repository.full_name github.repository强制过滤 fork 上产生的 run。工作流注释明确说明这是一条 supply-chain guard对应 CodeQL 规则 actions/artifact-poisoning防止 fork 攻击者构造的字节码进入 npm 发布物。Docker 侧Trivy 两步扫描SARIF 可见性 CRITICAL 阻断门镜像 CVE ratchet 在 docker-publish.yml 的mergejob 中使用了两个 Trivy 步骤这是理解整套设计的核心Trivy image scanSARIFadvisoryseverity: HIGH,CRITICAL、exit-code: 0。它把 HIGHCRITICAL 级别的发现持续上报到仓库 Security 标签页SARIF 通过github/codeql-action/upload-sarif上传category 为trivy-image但绝不阻断发布。Trivy CRITICAL gateblockingseverity: CRITICAL、ignore-unfixed: true、exit-code: 1。它只在存在可用修复方案的 CRITICAL CVE 出现时让 release 失败。两个步骤共享trivyignores: .trivyignore配置即被接受风险的可修复 CVE 在同一个文件中有唯一、可审计的归属地。ignore-unfixed的设计意图是基础镜像中尚未有上游补丁的 OS 级 CVE例如 Debian trixie 里尚无 patch 的包不应当红整个 release——工作流注释补充说明这类 CVE 绝大多数是 local-only 且不可从代理请求面触达属于运维人员无法行动的噪音。SBOM 侧同样接入在mergejobanchore/sbom-actionv0以cyclonedx-json格式生成sbom-image.cdx.jsonartifact标记为 advisorycontinue-on-error: true。两个 Trivy 步骤都由if: needs.prepare.outputs.version ! main守卫即只对版本化镜像tag 发布执行扫描门禁main浮动渠道不做阻断。CI 侧osv-scanner 的 vulnCount Ratchet依赖包层面的 CVE 门禁不是独立工作流而是嵌入 ci.yml 的quality-extendedjob通过npm run check:vuln-ratchet -- --ratchet执行对应实现是 scripts/check/check-vuln-ratchet.mjs。其机制在源码中清晰可见度量脚本以--format json --lockfile package-lock.json调用osv-scanner解析results[].packages[].vulnerabilities当存在groups字段时用groups.length做去重同一漏洞出现在多个包中只计一次输出vulnCountN及按严重度的分布。比较evaluateVulnRatchet(current, baseline)返回regressed: current baseline方向为down——漏洞计数只允许下降不允许上升。基线读取自 config/quality/quality-baseline.json 的metrics.vulnCount当前仓库中该指标为value: 27、direction: down、dedicatedGate: true。阻断语义无--ratchet时脚本永远 exit 0advisory加--ratchet后只有实测值超过基线才 exit 1。ci.yml中quality-extendedjob 的注释进一步说明了「混合模式」job 级不再整体continue-on-error三个 ratchet 阻断步骤Secret scan / Workflow lint / Bundle size失败即挂掉 job而依赖外部二进制或外部状态的步骤scanner 安装、vuln/osv ratchet、oasdiff、circular-deps保持 advisory 语义通过步骤级continue-on-error与脚本自身的 SKIP 行为保证「基础设施缺失永不阻断」。scanner 二进制gitleaks、osv-scanner、actionlint、zizmor在安装步骤中通过gh release download下载——工作流注释专门解释了为何放弃未认证的curl api.github.com匿名请求限流 60 次/小时/IP被限流时返回空 body安装会静默失败导致所有门自我 SKIP、指标永远无法产生。OpenSSF Scorecard仓库级姿态的聚合度量.github/workflows/scorecard.yml 以 cron每周一 07:27加默认分支 push 触发使用ossf/scorecard-actionv2.4.4输出results.sarifartifact 并通过publish_results: true生成 OpenSSF 徽章。值得注意的是当前实现的定位工作流注释说明security-events: write权限已被移除——Scorecard 的发现是供应链/姿态评分而非代码漏洞上传到 code-scanning Security 标签页会淹没真正的 CodeQL 告警。因此它保持 advisory 状态只保留徽章与可下载的 SARIF。Scorecard 与 Phase 7 的门形成互补zizmor 审计的是 workflow 文件本身而 Scorecard 度量的是整个仓库的姿态分支保护、CODEOWNERS、依赖更新等聚合得分。CVE 方差为什么没动依赖的 PR 会突然变红这是文档中最具运维价值的一节。osv 与 Trivy 都对比持续增长的 CVE 数据库一个完全不触碰任何依赖的 PR也可能因为某个既有依赖刚刚被披露新 CVE 而突然变红osv实测vulnCount超过基线Trivy镜像中新增可修复的 CRITICAL。这是阻断式 CVE 门的预期运维行为而不是产品回归。处置路径按优先级排序升级受影响的依赖首选——通过package.json的overrides升级传递依赖或在打过补丁的基础镜像上重建容器。仓库中有真实先例基线注释_scanner_remediation_2026_06_15记录了 vulnCount 从 13 降到 10 的处置——通过 overrides 升级 form-data 与 vite 两个传递依赖后osv-scanner 确认 0 HIGH 残留。无上游修复时osv手动重设 config/quality/quality-baseline.json 中metrics.vulnCount的基线值注意npm run quality:ratchet -- --update不覆盖专用门需手工编辑保持direction: down并附理由说明与追踪 issue。Trivy在 .trivyignore 中逐行添加 CVE-ID每行附理由注释与追踪 issueignore-unfixed: true已自动覆盖没有补丁的 CVE无需在此登记。.trivyignore文件头本身就是策略说明书它强调此文件只用于「可修复但必须临时接受」的罕见场景例如上游修复尚未进入所 pin 的基础镜像 tag或受影响组件可证明不可从请求面触达并要求列表保持短小、每次 release 复查、过期条目即债务。优雅 SKIP测量失败永不阻断osv 与 Trivy 两个阻断门都实现了统一的分层语义check-vuln-ratchet.mjs的实现把它落到了代码层osv-scanner不在 PATH → 输出vulnCountSKIP reasonbinary-absentexit 0网络不可达 osv.dev、执行超时、JSON 解析失败 → 输出vulnCountSKIP reason...exit 0基线文件缺失或指标不存在 → 视为无法 ratchet同样 exit 0。即测量measurement失败永不阻断只有测到的回归measured regression才阻断。main()中先findOsvScanner()探测二进制runOsvScanner()用无 shell 插值的方式执行防注入只有拿到有效 JSON 后才进入applyRatchet()做比较与退出码决策。BacklogScorecard 从 advisory 走向 blocking文档最后给出了一条待办在第一个带 Scorecard 报告的绿色 release 之后为 Scorecard 增加score ratchet冻结实测分数分数不允许下降。这条 backlog 与「advisory-first跑绿一次再升阻断」的整体策略一脉相承也与 osv/Trivy 当初的晋升路径一致基线注释中可见_osv_flip_blocking与_trivy_flip_blocking两条记录两者都在 v3.8.27 周期末从 advisory 提升为阻断。小结这套供应链门的设计可以概括为三条原则其一先可见、后阻断——SARIF 步骤先让 HIGHCRITICAL 在 Security 标签页可见阻断步骤只收窄到「可行动的」CRITICAL其二只阻断可行动的信号——ignore-unfixed与优雅 SKIP 共同保证运维者不会为不可修复的基础镜像 CVE 或一次扫描器网络抖动买单其三接受 CVE 方差作为常态——门禁红时的标准动作是升级依赖、有据可查地重设基线而非回滚代码。对任何同时维护 npm 包与容器镜像的项目docs/security/SUPPLY_CHAIN.md 配合 npm-publish.yml、docker-publish.yml、scorecard.yml 与 check-vuln-ratchet.mjs 构成了一份可直接参考的门禁落地清单。【免费下载链接】OmniRouteNever stop coding. Free MIT AI gateway: one endpoint, 352 providers (150 free), 1200 models Kimi, Claude, GPT, Gemini, GLM, DeepSeek, MiniMax. Works with Claude Code, Codex, Cursor, OpenCode, Cline Copilot. Quota-aware auto-fallback, RTKCaveman compression saves 15-95% tokens, MCP/A2A, Desktop/PWA. Built by 550 contributors项目地址: https://gitcode.com/GitHub_Trending/om/OmniRoute创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考