文章总结： 本文分析软件包来源证明与供应链安全的关系，指出有来源证明不等于包安全，来源证明仅提供可追溯性，不能替代对代码内容的安全审查。文章解析可信发布机制、来源证明局限性及发布流程风险，建议维护者关注高权限流程输入，使用者需分别核验来源、版本变更及运行时行为，并采取版本固定、限制脚本执行等具体措施。
综合评分： 85
文章分类： 供应链安全,安全意识,解决方案
软件包有来源证明，为什么供应链仍可能被投毒？
原创
IDC老徐
IDC老徐
信息安全动态
2026年9月20日 06:00
湖北
在小说阅读器读本章
去阅读
在公众号小说中沉浸阅读
软件包页面上出现来源证明，通常是一件好事。使用者终于可以进一步核对：这个产物对应哪个代码来源，又经由怎样的构建流程产生。
但如果采购或开发规范把“有来源证明”直接写成“可以安全使用”，就把可追溯性扩大成了另一项保证。npm的官方文档明确说明，来源证明不保证软件包没有恶意代码。
GitHub在2026年7月28日回顾了npm与GitHub Actions近期的供应链防护改进。可信发布、工作流保护和分阶段发布分别作用于不同环节。理解这些环节，比把它们汇总成一个“可信”标签更有用。
可信发布，先减少可被拿走的长期凭证
传统自动发布往往需要在持续集成系统中保存发布令牌。令牌一旦泄露，攻击者可能在其权限和有效期内使用它。凭证存活越久，发现、轮换和清理所需面对的窗口也越长。
npm的可信发布通过OIDC建立包仓库与指定持续集成工作流之间的信任关系，使发布过程不必继续依赖长期npm写入令牌。这减少了一类可长期保存、复制和滥用的秘密。
然而，可信发布主要回答的是“这个工作流是否被允许发布”。如果被允许的工作流本身执行了不可信代码，或者构建输入被不当替换，授权仍可能被用于发布不希望出现的产物。用短期身份替代长期秘密，不会自动修正构建逻辑。
迁移时还要检查旧路径是否保留。启用一种新发布方式，并不天然等于传统令牌、人工发布或其他连接已经停用。只有逐项确认实际允许的路径，才能判断凭证风险收敛了多少。
来源正确，为什么内容仍然可能有问题
来源证明提供可验证的关联，帮助使用者审查代码来源与构建过程。它的价值在于减少“拿到一个包，却说不清怎么来的”这种不确定性。
但“出自预期流程”和“实现了预期行为”不是同一判断。假设一个项目通过正常权限合入了一段有害变更，再由原来的工作流完成构建发布。证明可以如实描述这次构建，代码仍可能有问题。这个假设不需要签名算法失效，也不需要伪造构建身份。
更细一层，证明所覆盖的信息也有范围。核验者需要确认产物与证明对应，并将其中的仓库、工作流等身份与自己的预期比较。只验证签名在密码学上成立，却不检查是谁以什么流程签出的，可能接受一个完全无关来源的有效证明。
所以，来源证明是后续审查的依据，不是审查已经完成的结果。其生成能力还受平台和仓库条件限制，不能反过来断言“没有证明的包必然恶意”。缺少证明意味着需要用其他材料补足来源判断，而不是直接作出内容结论。
图1｜发布授权、来源核验和行为审查回答三个不同问题；任一项通过，都不自动代替另外两项。
发布者要守住的，是高权限流程的输入
对维护者来说，接入可信发布以后，重点应转到能够影响发布的代码、工作流配置和外部输入。
尤其要分开普通验证任务与真正发布任务。前者可能处理外部贡献，后者能够取得发布权限。如果不可信任务能改写后续发布使用的缓存、文件或配置，就可能把低权限入口的影响带到高权限阶段。单独缩小验证任务自身的令牌权限，并不总能阻断这种间接影响。
图2｜箭头表示产物或配置的影响路径。进入发布流程前应核查上游输入，避免低权限任务间接改变高权限发布。
GitHub近期的改进中包含对不可信触发条件、代码检出和共享缓存的保护。这些变化提醒团队核查自己的实际流程：哪些输入经过审查才会进入发布环境，哪些配置可改变发布身份，以及最终批准的产物是否就是实际发布的产物。
分阶段发布可以在自动构建与正式放行之间增加一次检查，但审批者必须看到可核对的版本与产物。如果只批准“本次流水线成功”，没有确认变更内容，新增审批未必能识别已经通过正常流程进入的恶意逻辑。
使用者需要多做哪一层判断
消费端至少应分别回答：来源是否符合预期，这个版本改了什么，以及安装和运行时允许它接触什么。来源核验通过后，后两项仍然存在。
对会进入发布流水线、能够执行安装脚本或接触敏感数据的依赖，审查应更严格。安装前后的代码执行环境尽量不持有无关写入凭证，也不应默认获得任意网络访问。这样做不会证明包无害，却能减少一个恶意依赖进一步获取其他能力的机会。
限制脚本也有真实代价：某些依赖确实需要构建或初始化步骤。可以逐项核准必要脚本及其执行环境，不能因为遇到兼容问题就恢复所有依赖的无限制执行。
版本固定和更新等待能够提高变更的可控性，却不应变成长期停在旧漏洞上的理由。普通更新可以留出审查和观察时间；紧急安全修复则需要按本地暴露情况评估加速路径，并保持来源核验与回退准备。
当包的影响只限于低权限测试环境时，来源核验与受控更新可以构成主要入口检查；当它能接触发布凭证、生产数据或安装时执行代码时，还需要审查行为并隔离执行能力。有来源证明应当让审查更有依据，而不是让审查提前结束。
推荐阅读
公众号所有文档下方阅读原文获取
免责声明：
本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。
任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。
本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。
本文转载自：信息安全动态 IDC老徐
IDC老徐《软件包有来源证明，为什么供应链仍可能被投毒？》