AI编程工具正重塑软件开发流程，但自动化安装量的激增也为企业安全带来新挑战。Bloom Security最新研究揭示，软件发布基础设施中的弱点与自动化工作流的交集，可能使组织在攻击者未窃取凭据的情况下，暴露于恶意代码风险之中。
AI代理加剧供应链暴露
这项名为“SlugFest”的研究发现，超过1,500个npm软件包存在漏洞，易受涉及GitHub仓库地址的发布攻击影响，累计下载量逾1,000万次。
Bloom对大型企业AI驱动软件安装规模的测量显示，典型终端设备每月通过AI代理安装约70个软件包，开发人员机器则接近350个。研究分析了数十家组织中数百万个AI代理的行为，指出不同类型代理每天安装0.3到1.2个软件包，开发人员机器每天直接安装两到三个。
平均每个终端设备运行三个代理，开发人员机器可能运行五个或更多。这些数据尚未包含间接依赖项，实际软件足迹远超报告总数。这种高频活动为不受信任代码进入环境创造了机会，尤其是当软件包执行包括postinstall钩子在内的安装脚本时，开发人员往往无法逐一审查。
Bloom报告称，曾拦截并阻止某客户AI代理尝试安装其中一个受影响软件包，证实了自动化流程与供应链风险的实际交集。
“SlugFest”漏洞机制解析
该漏洞源于npm可信发布（Trusted Publishing）机制。该系统旨在通过短期凭证替换长期令牌以提升安全性：GitHub Actions工作流获取OpenID Connect (OIDC)令牌，并与npm交换临时发布凭证，从而降低静态密钥泄露风险。
然而，Bloom发现npm最初仅使用GitHub仓库的人类可读地址（slug）建立信任，未立即记录永久仓库标识符。当所有者重命名、转移或删除仓库后，原地址可供他人认领。若软件包的可信发布者绑定仍引用旧地址且未成功发布，新仓库即可满足原始信任配置，从而获取发布权限。这一过程无需窃取合法维护者凭据或入侵账户。
研究人员通过控制的GitHub仓库和npm包演示了该攻击：利用被回收的仓库slug，成功从另一组织的仓库向目标包发布内容。一旦获得权限，攻击者可发布携带恶意postinstall钩子的版本，利用现有声誉和依赖关系自动分发。此外，部分系统仅验证证明存在性而不核对来源仓库，进一步增加了识别难度。
修复历程与安全建议
全注册表扫描显示，受影响软件包月下载量超100万次。Bloom指出，这仅涉及配置为可信发布的部分npm生态，实际风险范围可能更广。
对于企业安全领导层，仅靠依赖项清单已不足以提供充分保护。Bloom建议审计范围应扩展至扩展程序、插件、MCPs和技能等，并实施供应链防火墙及制定AI代理使用政策。
软件包维护者需审查发布权限，运行npm trust list检查仓库地址有效性，并在仓库重命名或转移后重新创建信任绑定。删除绑定时，若不再需要也应移除相关配置。
该漏洞于2026年6月6日通过GitHub HackerOne计划报告，6月9日获验证。经过六次额外查询及调解，Bloom在发布研究成果前复测发现npm已实施修复。npm随后确认补救措施并为沟通延迟道歉。
Bloom提出的解决方案是：在建立信任时存储不可变的仓库和所有者标识符，并在发布授权期间验证OIDC令牌中的仓库标识符。研究人员指出，PyPI的Warehouse已采用此方法，且该问题同样影响npm的GitLab可信发布实现。
核心问题并非自动化发布或AI工具本身不安全，而是自动化放大了信任关系破裂的后果。随着软件创作日益自主化，组织必须确保系统不仅验证源的名称，更要验证其是否为意图信任的真实源。