首先从Hermes agent依赖管理的一段注释聊起。
# Core — every direct dep is exact-pinned to ==X.Y.Z (no ranges).
# ...
# This was tightened on 2026-05-12 in response to the Mini Shai-Hulud
# worm hitting mistralai 2.4.6 on PyPI; if that release had been
# captured by `mistralai>=2.3.0,<3` rather than an exact pin, every
# install in the hours before the quarantine would have pulled it.
https://github.com/NousResearch/hermes-agent/blob/main/pyproject.toml#L14
Hermes Agent项目为了应对Mini Shai-Hulud蠕虫病毒对mistralai软件包的攻击,将所有直接依赖固定到了特定版本上,避免被更新的、有问题的传递依赖安装到用户端。注释里同时提到,团队的一个应对措施是会审核新版本的依赖,确定安全性后方才更新依赖列表。至于接近于白盒的代码审核,人工和自动化各占多少比例,无从知晓了。
这是一起典型的针对软件供应链攻击的案例。简单的安装方式把用户推向了面对供应链安全的最前沿。一旦软件包受到攻击污染,在用户端的安装过程中是完全不可控的。使用==运算符将直接依赖固定到特定的版本上是一种选择,但其无法从根本上消除用户直接面对软件供应链安全威胁的现实问题。与此同时,在从代码到交付的整个开发流程中,在依赖管理方面也增加了额外的成本。
为了应对这种局面,以下是几点思考。
1. 左移应对软件供应链攻击的措施。在开发阶段即引入CI/CD平台,为每一次拉取请求(Pull Request)执行完整的验证流程。
注:CI/CD在本文中指的是持续集成和持续交付。
这个流程至少应包含代码克隆,依赖分析和获取,软件构建,代码安全分析检查,漏洞扫描。依赖分析获取阶段应下载构建软件所需的所有直接和间接(传递)依赖,并在构建阶段实现网络隔离的构建过程。这些措施确保潜在的问题能够尽可能的在开发阶段被发现、被解决。在合并拉取请求后,应当再次验证。
2. 锁定依赖。以Python项目为例,使用pip-compile和uv等工具生成锁定文件,可以是requrements.txt亦或是uv.lock,必须包含软件包的哈希值。项目主分支上的锁定文件可以按需定期更新,其内容必须经过CI/CD流程验证。
3. 自动化依赖版本更新。有了CI/CD平台和依赖锁定文件的加持,团队能更有信心地依靠自动化过程升级依赖。依赖更新服务会创建拉取请求,其会通过相同的CI/CD流程被验证。拉取请求包含了版本更新的所有关键信息,可以支持团队做进一步的审核以决定是否合并。
4. 软件交付策略。随软件应用的软件包一起交付的还应包含证明(Attestation)、签名(Signature)和SBOM数据。
前述的依赖锁定文件通常作为软件源代码包的一部分发布,其也可以被独立发布,作为用户端安装的依据。这点不同于使用pip和npm这类软件包管理工具安装的常规做法。交付的媒介根据目标定位可以以多种形式呈现。打包好的通常有二进制软件包、源代码包、容器镜像。独立的安装脚本也很流行,例如:
curl -fsSL https://../install.sh | bash无论采取哪种方式,推荐的安装方式都应基于以锁定的、经过开发阶段验证过的软件包集合为基础的分发媒介。
Agent开发与应用方兴未艾,以Python、Go、Typescript各式语言实现的各类Agent应用层出不穷。无论其开源还是闭源,势必会将大量软件包纳入开发流程实现各类功能,并最终进入到个人、企业、组织的计算环境中。开源项目在其中扮演了重要的角色。在Agent应用领域,包含软件代码在内,其覆盖的组件也更加广泛,如大语言模型、代码生成过程、RAG等。这更凸显了前置软件供应链安全应对措施的重要性。
夜雨聆风