Vibe Coding 许可证与制品来源：把声明绑定到实际安装摘要

AI 找到一个包的 GitHub 页面，看到 MIT 徽章和绿色 provenance 标记，就可能总结为“来源可信、可商用”。这里混合了三个不同问题：下载字节是否是锁定制品，制品是否由预期身份和材料构建，实际包含文件适用什么许可证与组织政策。任何一个信号都不能替其他两个做结论。

AI 供应链安全给出许可证与依赖风险概览；本篇建立精确制品级对账，不提供法律意见。许可证兼容性和义务必须由组织授权角色依据使用与分发方式判断，AI 只整理可核查材料。

先锁定“实际安装了什么”

记录 registry、包名、精确版本、tarball 地址、包管理器 integrity、独立计算摘要、字节数和取得时间。package-lock 等锁文件描述解析结果与完整性字段，但审查仍要覆盖 workspace、optional、peer、bundled 和平台选择后的实际安装集合。只读 package.json 的直接依赖会漏掉最终产物中的传递代码。

从精确 tarball 枚举所有文件、嵌套归档、预编译二进制、WASM、生成代码、LICENSE/NOTICE/COPYING 与源码映射。注册表 metadata 的 license 是声明，不保证文件集合一致；仓库根 LICENSE 也可能不覆盖 vendored 子目录或双许可证组件。声明冲突、文件缺失或自定义条款进入人工审查，不让 AI 按最相似 SPDX 名称自动归一。

SPDX 提供软件物料、许可证表达式和关系的标准化模型。使用精确 SPDX identifier、AND/OR、exception 与文件级结论表达已确认事实；NOASSERTION 比猜一个宽松许可证更诚实。内部策略再把使用方式、链接/修改/分发和 notice/source 等义务映射为准入、限制或拒绝。

Provenance 证明来源，不证明安全或授权

SLSA provenance 把 subject 与 build materials、builder 等信息关联。验证时先要求 subject digest 等于当前 tarball/制品，再校验签名身份、issuer、builder policy 和透明日志/信任根；不能只看 UI 的“verified”。npm provenance statement 也需要结合发布工作流与包摘要验证。

有效 provenance 可以证明“这个字节由声明构建流程产生”，不能证明源码没有漏洞、maintainer 没有恶意、许可证声明正确，也不能证明组织获准使用。缺 provenance 也不自动证明恶意，但来源状态必须显式降级，并根据依赖关键度决定是否阻断、内部重建或限时接受。

源码 tag 与 tarball 做可重建或可解释对账。若构建不完全确定，至少比较文件清单、入口、生成物来源和语义测试，记录允许差异；找不到对应 revision 或发布包含仓库外动态下载时保持 UNVERIFIED_MATERIALS。RAG 索引制品发布对索引清单与构建链做相似约束，这里对象是代码包和最终应用制品。

让 SBOM 与最终制品闭合

从锁文件生成 SBOM 只是第一步。再从构建输出或镜像扫描实际组件，把源码依赖、bundled 库、native binary 和运行时下载材料与 SBOM 对账。开发-only 工具若不进入发布产物可有不同分发结论，但它仍在构建环境执行，需要供应链安全审查。optional 包按每个目标平台分别确认，不能用 Linux 清单代表 macOS/Windows 制品。

每个组件记录 package URL/坐标、版本、artifact digest、来源状态、许可证材料摘要、政策决定、义务、reviewer 与复审条件。NOTICE、源代码提供或归属文本由发布流水线从批准清单生成，并在最终 artifact 中验证存在，不能只保留在 CI 临时目录。

依赖升级与锁文件兼容门确保 manifest、lockfile 与构建变更原子审查；许可证或 provenance 即使版本号没变，只要 tarball 摘要变化也必须阻断。缓存按摘要寻址，registry 上的可变标签不决定重建内容。

生成代码还要区分模板、schema、生成器和输出的各自许可与归属，生成代码所有权边界可防止只扫描输出文件头而漏掉来源。补丁、fork 或 vendoring 会创建新的派生制品，记录父摘要、修改集、内部 builder 和新的许可证审查，不覆盖上游证据。

故障演练包括 metadata license 与 tarball 文件冲突、缺 NOTICE、同版本摘要变化、provenance subject 不匹配、签名来自未授权 workflow、平台二进制无源码对应、SBOM 漏 bundled 库和缓存回退到网络。任何一项不能用“包很流行”豁免。

最终结论分三栏：完整性/来源验证结果、许可证材料事实、组织使用决定。把它们绑定到实际安装摘要，才能在漏洞、下架、许可证变化或审计时回答“哪个制品、从哪里来、依据什么被允许”，而不是只找到一张已经变化的仓库首页。