这款恶意软件由 Red Hat 签名
本周，窃取凭据的代码以 Red Hat 的名义送到了开发者手中。威胁并非来自你信任圈之外——它来自圈子内部。审查无法让你逃过这一劫，但你可以让自己的凭据远离它的触及范围。
本周，由 Red Hat 签名的代码试图窃取你的凭据。
攻击者入侵了一名 Red Hat 开发者的账户，发布了官方 Red Hat 软件包的篡改版本。只要有机器安装了其中之一，隐藏的代码便会自动运行，伸手去抓一切有价值的东西——云密钥、访问令牌、登录凭据，任何能打开一扇门的东西。然后，它利用窃取到的凭据继续传播。
注意这其中的形态。Red Hat 不是目标——你才是。 他们的名字、他们受信任的账户、你上千次不假思索就使用的安装流程：这些不是受害者，而是武器。这次攻击并没有绕过你的信任圈，而是堂而皇之地从正门走了进来，手里拿着你亲手签发的通行证。这正是供应链攻击与其他一切威胁的不同之处——危险不是某个你能拦下的陌生人，而是你早已选择信任、并替你投递了恶意载荷的供应商。而这一次是 Red Hat：地球上安全成熟度最高的公司之一，有真正的代码审查，有真正的预算。恶意代码还是以他们的名义发了出去。
于是有一个你无法回避的结论：如果连 Red Hat 都无法保证你从他们那里安装的东西是干净的，那就没有人能保证了。你的框架不能，你的 CI 供应商不能，你从没读过、深埋三层的那个依赖也不能。你迟早会运行自己没写过、也没能彻底审查的代码。这不是流程上的失误——这就是「在别人的软件之上构建」本身的含义。
继续扫描。继续锁定版本。继续审查。这些都值得做——只是别依赖它们，因为这一周它们一样都帮不上忙：恶意软件是带着信任光环来的。真正的问题不是如何把坏代码挡在门外，而是：当坏代码在你的机器上运行时，你保护好你的密钥了吗？
对绝大多数人来说，诚实的答案是：没有。看看这次攻击抓走了什么——环境变量、散落在文件里的令牌，然后它径直走向云端的密钥管理服务，请它们交出全部内容。因为 2026 年的凭据就是这样存放的：堆在一处，任何正在运行的东西都能伸手够到。一次被污染的安装拿走的不是一个密钥，而是全部——然后继续蔓延。
解决之道，是不再把凭据放在你的代码够得着的地方。让它们与你保持一臂之遥。
这正是 Clavitor 的核心理念。你的密钥不存放在你的运行环境里；没有任何东西躺在 .env 文件里等着被读取。程序——或者 AI agent——永远不会持有凭据本身，它得到的只是使用某个凭据的能力，在需要的那一刻才即时取用——绝不存储，绝不缓存——由我们遍布六大洲的 21 个节点之一送达，因此离你最近的副本永远只有几毫秒之遥，并且仅限于那一个被明确授权的密钥，每一次读取都有审计记录。当恶意安装脚本四处摸索密钥时，它找到的是一间空房。
而且我们假设凭据终究会有被截获的一天——所以 agent 所携带的东西，一旦被盗也几乎毫无用处。它只能从被签发的那台机器上使用——把它偷走、从攻击者自己的服务器上使用，就会被拒绝。它受到速率限制并被持续监控：每分钟只能取用为数不多的几个密钥，因此无法把你的保险库抽干；而一旦它的取用超出平常的那一小撮，就会触发警报并被锁定。蠕虫的整套策略——快速抓取一切、四处使用——就此撞上一堵墙。
我们不做刀枪不入的承诺：如果某个凭据恰好在恶意软件运行的那一刻正被使用，那这一个确实可能被截获——再好的架构也改写不了物理定律。但这恰恰是关键。Red Hat 这次攻击之所以如此具有破坏性，正是因为一次安装就能掏空整个密钥库并将其变为武器。一臂之遥，加上被绑定在单台机器、被限流到细水长流的凭据，把「他们拿走了一切并四处蔓延」变成了「他们或许在传输途中截获了一个密钥，而它在别处根本用不了」。这就是一场灾难与一行脚注之间的差别。
这款恶意软件由 Red Hat 签名。你靠审查是过不了这一关的。就当坏代码终会进来——并确保它进来时，你的密钥不会就那样躺在那里等着它。
（该攻击活动公开追踪名为「Miasma」，是 Shai-Hulud 系列自我传播 npm 蠕虫的一个变种。相关技术分析值得一读；本文要谈的，是这类事件中从一次到下一次始终不变的那一部分。）
Sources: