AutoRAG 供应链安全门禁（Supply-chain Gates）全解析：从许可证合规到可溯源发布

AutoRAG 供应链安全门禁Supply-chain Gates全解析从许可证合规到可溯源发布【免费下载链接】AutoRAGAutoRAG: Now your agent can find anything in your computer. It gets smarter if you are using it frequently.项目地址: https://gitcode.com/GitHub_Trending/au/AutoRAG供应链安全门禁是 AutoRAG 开源项目在谁能改许可证、谁能合并依赖之外用自动化工具为每一次代码变更、每一次 npm 发布设定的硬性校验红线。本文围绕仓库根目录 docs/supply-chain.md 展开系统讲解 AutoRAG 的五道门禁SCA、CVE、SBOM、LicenseNOTICE、SAST与发布门禁的执行逻辑、本地 CLI 工具用法、许可证白名单策略的源码级实现以及v*发布时 GitHub Release 资产的生成与校验方式。读完本文你将掌握 AutoRAG 供应链治理的完整脉络并能用bun scripts/supply-chain/evaluate.ts在本地复现许可证与 NOTICE 门禁。一、治理边界谁有权决定许可证供应链门禁并不改变项目许可证本身它只负责守住许可证边界。AutoRAG 的所有权与治理在 GOVERNANCE.md 中定义项目所有者是 Marker Inc.持有项目版权与 NomaDamas 共同持有见 LICENSE、源码仓库及其他项目资产变更项目许可证、迁移/删除仓库等所有权级事项最终决定权保留给 Marker Inc.运营组织是 NomaDamas负责日常代码评审、Issue 分类、路线图与发布规划贡献采用 MIT 协议所有通过 PR 合入main的贡献都按 MIT 许可详见 GOVERNANCE.md 的 Contributing 一节。在许可证兼容性上AutoRAG 2.0 采用双许可分布npm 分发的根包为 MIT而legacy/Python 版 AutoRAG为 Apache-2.0。因此供应链门禁的职责非常明确——它不改变上述许可约定而是确保第三方生产依赖始终与当前分发形态兼容只允许宽松许可permissive进入生产依赖copyleftGPL/AGPL/SSPL以及无法识别的许可证一律 fail closed拒绝通过。二、五道门禁总览AutoRAG 的供应链治理由五类门禁 发布门禁构成每条 PR、每次调度扫描、每次发布各有分工。下表直接继承自 docs/supply-chain.md门禁工具何时阻断SCAactions/dependency-review-actionPR 引入 high 及以上安全公告或引入白名单之外的许可证CVEGoogle OSV-Scanner 可复用工作流PR 上出现新漏洞按调度与 npm 发布时执行全量扫描SBOMAnchore Syftanchore/sbom-action缺少 CycloneDX/SPDX 产物发布时对 SBOM 进行 attestation签名背书License NOTICEbun scripts/supply-chain/evaluate.ts gate许可证命中白名单之外或NOTICE文件过期SASTGitHub CodeQLJS/TS 与 Python 中出现新的 codeql alertsRelease.github/workflows/release.yml 的needs: [supply-chain]供应链可复用工作流失败时npm publish 无法执行这六行表格是整套治理的总纲前三者由 GitHub 生态的开源 Action/工作流承担License NOTICE 由仓库自研脚本实现Release 门禁把前四者与发布动作强绑定。下面逐一深入。三、SCA 与 CVE 门禁PR 阶段的风险拦截3.1 SCA 依赖审查SCA软件成分分析门禁使用actions/dependency-review-action其配置位于 .github/dependency-review-config.yml关键项如下fail-on-severity: high fail-on-scopes: - runtime - development license-check: true vulnerability-check: true comment-summary-in-pr: on-failure allow-licenses: - 0BSD - Apache-1.1 - Apache-2.0 - BSD-2-Clause - BSD-3-Clause - MIT - MPL-2.0 # ...完整清单见配置文件需要特别指出的是这份allow-licenses清单与AUTORAG_SUPPLY_CHAIN_POLICY中的白名单保持一致同一份名单在 .github/dependency-review-config.yml 与 scripts/supply-chain/policy.ts 中各自维护。它在 CI 中的接入方式见 .github/workflows/supply-chain.yml 的dependency-reviewjob仅当事件为pull_request时运行并使用config-file指向仓库内的这份配置。PR 一旦引入 high 及以上fail-on-severity: high的已知漏洞或落入白名单之外的许可证该 job 就会失败并在 PR 上给出评论摘要comment-summary-in-pr: on-failure。3.2 CVE 漏洞扫描OSV-ScannerCVE 门禁由 Google 的 OSV-Scanner 可复用工作流承担在 .github/workflows/supply-chain.yml 中分两条路径osv-pr事件为pull_request或merge_group时使用google/osv-scanner-action/.github/workflows/osv-scanner-reusable-pr.ymlv2.6.0对新引入的依赖做增量漏洞检测osv-full事件为workflow_call被发布流程调用或schedule每周一 07:17 UTC 的定时扫描见cron: 17 7 * * 1时使用osv-scanner-reusable.ymlv2.6.0做全量扫描。两个 job 都需要actions: read、contents: read、security-events: write权限以便把扫描结果写入 GitHub 安全告警。四、SBOM 门禁生成与签名背书SBOM软件物料清单由 Anchore Syft 生成同样在 .github/workflows/supply-chain.yml 的sbomjob 中定义一次生成两种格式CycloneDX JSONformat: cyclonedx-json输出autorag.cdx.jsonSPDX JSONformat: spdx-json输出autorag.spdx.json。两个步骤都通过upload-artifact: true把产物上传为autorag-cyclonedx.json与autorag-spdx.json工件供后续发布流程下载dependency-snapshot仅在非 PR 事件下启用。当事件为workflow_call即发布流程调用时还会额外执行actions/attest-sbomv2对autorag.cdx.json做SBOM attestation——这是将 SBOM 与仓库、提交、版本绑定的签名背书保证消费者拿到的 SBOM 可追溯到 AutoRAG 官方发布。sbomjob 为此声明了attestations: write、id-token: write等权限。五、License NOTICE 门禁自研脚本的本地可复现校验与前几道门禁不同许可证与 NOTICE 门禁使用仓库自研脚本bun scripts/supply-chain/evaluate.ts gate实现它在 CI 的license-notice-gatejob 中执行.github/workflows/supply-chain.yml并且在本地完全可复现。5.1 三条子命令从 scripts/supply-chain/evaluate.ts 的主函数可以看到脚本支持三个命令缺省命令为gate# 1. 门禁校验默认许可证白名单 NOTICE 比对 可选 CVE 文件 bun scripts/supply-chain/evaluate.ts gate --sbom sbom.local.cdx.json # 2. 重新生成 NOTICE当门禁因 NOTICE 过期而失败时执行 bun scripts/supply-chain/evaluate.ts notice # 3. 本地生成 CycloneDX SBOM bun scripts/supply-chain/evaluate.ts sbom --sbom sbom.local.cdx.json支持的 flagscripts/supply-chain/evaluate.ts 的parseFlagsFlag作用默认值--sbom path指定 SBOM 输出路径sbom/gate命令sbom.cdx.json仓库根--cves path提供本地 CVE 结果 JSON 数组文件供门禁评估gate命令不传入则跳过 CVE 检查CI 中的用法是gate --sbom sbom.local.cdx.json这样本地 CycloneDX 文件会作为副产品上传actions/upload-artifact的local-cyclonedx工件同时门禁本身仍会做许可证与 NOTICE 校验。5.2 门禁的四个检查项源码视角从 scripts/supply-chain/policy.ts 的evaluateReleaseGate与 scripts/supply-chain/evaluate.ts 的main可以还原出gate的执行顺序许可证检查evaluateLicenses(components, AUTORAG_SUPPLY_CHAIN_POLICY)遍历所有生产依赖用 SPDX 表达式求值器判断是否落入白名单NOTICE 检查将按当前依赖生成的 NOTICE 文本与仓库根 NOTICE 逐字节比对不一致即视为过期SBOM 检查在gate中sbomOk恒为true本地生成本身不构成阻断CVE 检查仅当传入--cves时执行。四个子项的通过与否汇入evaluateReleaseGate按GATE_ORDER [sbom, license, cve, notice]输出缺失项missing数组。失败时进程退出码为 1并向 stderr 打印提示supply-chain gate failed; run bun scripts/supply-chain/evaluate.ts notice if NOTICE is stalegate的最终输出是一个 JSON 摘要包含ok、missing、denials形如组件名: 拒绝原因与cves形如CVE 编号:严重级别四个字段便于 CI 与本地脚本解析。5.3 许可证白名单与 SPDX 表达式求值AutoRAG 的供应链策略在 scripts/supply-chain/policy.ts 中集中定义export const AUTORAG_SUPPLY_CHAIN_POLICY: SupplyChainPolicy { projectLicenses: [MIT, Apache-2.0], allowLicenses: ALLOW_LICENSES, // 29 个宽松许可 ID failOnCveSeverity: high, // 高及以上 CVE 阻断 unknownLicense: deny, // 未知许可证拒绝 };白名单共 29 项全部为宽松许可0BSD、Apache-1.1、Apache-2.0、Artistic-2.0、BlueOak-1.0.0、BSD-2-Clause、BSD-3-Clause、BSD-3-Clause-Clear、BSL-1.0、CC-BY-3.0、CC-BY-4.0、CC0-1.0、HPND、ISC、MIT、MIT-0、MPL-2.0、MS-PL、NCSA、OpenSSL、PostgreSQL、PSF-2.0、Python-2.0、Unicode-3.0、Unicode-DFS-2016、Unlicense、WTFPL、X11、Zlib。copyleft 的 GPL/AGPL/SSPL 不在其列未知许可证默认拒绝。值得注意的实现细节是evaluateSpdxExpression它内置了一个完整的SPDX 表达式解析器scripts/supply-chain/policy.ts 的tokenize、parseOr、parseAnd、parsePrimary支持OR/AND布尔组合与括号嵌套WITH例外条款如GPL-2.0 WITH Classpath-exception-2.0后缀归一化MIT会被归一化为mit-or-later后查表。依赖的许可证声明来源在 scripts/supply-chain/inventory.ts 的licenseFromPackageJson依次解析package.json的字符串license字段、对象形式{type}、以及licenses数组多个用OR连接。所有生产依赖package.json的dependencies都会从node_modules读取包元数据并纳入评估——这意味着bun install之后在本地运行gate结果与 CI 一致。六、NOTICE 的生成与含义NOTICE 是随发布包分发的第三方归属声明由bun scripts/supply-chain/evaluate.ts notice自动生成并写回仓库根目录。从 scripts/supply-chain/inventory.ts 的generateNotice可以看到其结构AutoRAG Copyright (c) 2025 NomaDamas / Marker Inc. Root package license: MIT legacy/ package license: Apache-2.0 Third-party production dependencies: 包名版本 License: SPDX 表达式 ...按包名排序逐项列出除第三方依赖外NOTICE 还会固定引用 licenses 目录下的嵌入运行时与模型合规文件llama.cpp 的 MIT 许可、Qwen3 Embedding 通知、Apache-2.0、Gemma 系列条款、licenses/embedding-assets.json 等。由于 NOTICE 是按当前依赖快照生成的任何依赖增删或版本变更都会导致 NOTICE 过期这正是gate中 NOTICE 比对检查的意义所在——这也是 CI 在门禁失败时报错提示重新运行notice命令的原因。七、SAST 门禁CodeQL 静态扫描SAST静态应用安全测试由 GitHub CodeQL 承担在 .github/workflows/supply-chain.yml 之外还配合 CI 的代码扫描配置覆盖 JS/TS 与 PythonAutoRAG 同时包含src/的 TypeScript 实现与legacy/的 Python 实现。一旦 CodeQL 分析产生新的 alertsPR 即被阻断已有告警的收敛同样纳入门禁范围。八、Release 门禁供应链失败则无法发布发布流程定义在 .github/workflows/release.yml只针对v*标签触发且与 AutoRAG 2.0 的 npm 分发强绑定标签与版本强校验发布 job 会先用 Node 读取package.json的version若GITHUB_REF_NAME不等于v版本则直接报错退出legacy Python 版本须走legacy-v*标签见 .github/workflows/publish.yml永远不可能触发本工作流供应链门禁先行publishjob 声明needs: [supply-chain]即复用 .github/workflows/supply-chain.ymlworkflow_call触发。只要其中的依赖审查、CVE 全量扫描、SBOM 生成与 attestation、LicenseNOTICE 门禁任一失败npm publish 就不会执行发布前完整流水线bun install --frozen-lockfile→vitest run全量测试 →bun run build构建 → 下载 SBOM 工件 → 校验嵌入合规清单node scripts/check-embedding-manifest.mjs→ 暂存发布资产 → 以npm publish --provenance --access public发布--provenance启用 npm 来源证明依赖id-token: write权限。九、GitHub Release 资产与本地暂存9.1 Release 附带资产清单GitHub 本身会从标签自动附加源码 zip/tar 包。每个v*发布在此基础上额外上传npm pack tarball构建产物包含dist/与skills/LICENSE、NOTICE与GOVERNANCE.md供应链 job 生成的CycloneDX/SPDX SBOM覆盖上述所有文件的SHA256SUMS.txt校验清单。明确不做的事不要附加node_modules也不要上传第二份整树 zip——避免发布资产臃肿与冗余。9.2 本地暂存命令构建完成后可先在本地暂存发布资产进行核对bun scripts/supply-chain/stage-release-assets.ts --out release-assets这是 scripts/supply-chain/stage-release-assets.ts 的 CLI 入口支持三个 flagFlag作用--out dir输出目录必填--sbom-dir dir从指定目录复制.cdx.json/.spdx.json等 SBOM 文件发布流水线用--sbom-dir sboms传入下载的工件目录--embedding-assets额外下载并校验嵌入运行时llama.cpp 等的固定版本归档9.3 暂存流程的源码级细节从 scripts/supply-chain/stage-release-assets.ts 的stageReleaseAssets可以还原完整流程前置校验dist/index.js必须存在否则报dist/index.js is missing; build before staging release assets——先构建、后暂存复制合规文件LICENSE、NOTICE必选缺失即失败GOVERNANCE.md可选存在嵌入资产暂存若存在 licenses/embedding-assets.json会按清单下载 pinned 的 llama.cpp 运行时归档逐字节校验 SHA-256哈希不匹配立即失败并校验归档内必须包含清单声明的archiveMembers同时把整个 licenses 目录复制进产物npm pack以--pack-destination输出 tarball复制 SBOM从--sbom-dir筛选 CycloneDX/SPDX 文件生成校验清单对暂存目录内除SHA256SUMS.txt外的所有文件计算 SHA-256输出${digest} ${name}格式的 [SHA256SUMS.txt]并保证至少存在一个.tgztarball。发布流水线在 .github/workflows/release.yml 中实际执行的命令是bun scripts/supply-chain/stage-release-assets.ts --out release-assets --sbom-dir sboms --embedding-assets随后softprops/action-gh-release将release-assets/**整树附加到 GitHub Release消费者可以用SHA256SUMS.txt逐一核验下载产物的完整性。十、测试与持续验证供应链门禁并非只写不测仓库在 test/supply-chain 下提供了三组针对性测试test/supply-chain/policy.test.ts覆盖许可证白名单判定、SPDX 表达式求值含OR/AND/WITH/归一化、CVE 严重级别阈值与 release gate 组合逻辑test/supply-chain/release-gate.test.ts验证门禁缺失项的输出顺序与失败行为test/supply-chain/release-assets.test.ts通过注入确定性归档字节downloadAsset测试缝验证资产暂存、SHA-256 校验与归档成员检查。此外scripts/check-embedding-manifest.mjs 在 CI 的license-notice-gatejob 与发布流程中都会执行用于校验嵌入资产清单的完整性。整套设计确保同一套门禁逻辑在本地、PR 与发布三种场景下行为一致且每一步都有测试兜底。结语AutoRAG 的供应链治理把许可证归属GOVERNANCE.md 与双许可分布与依赖合规docs/supply-chain.md 描述的五道门禁分层处理前者由治理文档与版权持有方决定后者完全自动化、fail closed并且关键环节LicenseNOTICE、本地 SBOM、资产暂存都可以在本地用 Bun 脚本一键复现。对于想在自己的开源项目里建立类似供应链防线的团队这份白名单策略 自研门禁脚本 可复用 CI 工作流 发布资产哈希校验的组合本身就是一份可直接借鉴的完整参考实现。【免费下载链接】AutoRAGAutoRAG: Now your agent can find anything in your computer. It gets smarter if you are using it frequently.项目地址: https://gitcode.com/GitHub_Trending/au/AutoRAG创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考