打开网易新闻 查看精彩图片

3月底,一个被数百万开发者日常调用的JavaScript库悄然沦陷。OpenAI上周公布的调查报告显示,这个名为Axios的HTTP请求库在供应链攻击中被植入恶意版本,而攻击路径恰好穿过了OpenAI为macOS应用签名的自动化流程。

数字证书在软件生态里扮演的角色,有点像古代商队的通关文牒——系统见到它就放行,不问来路。一旦文牒被伪造, malware(恶意软件)就能大摇大摆穿过城门。OpenAI的应对策略很产品经理思维:宁可错杀,绝不赌概率。证书直接作废轮换,老版本应用统统设定死期。

攻击路径复盘:一次典型的供应链"搭便车"

攻击路径复盘:一次典型的供应链"搭便车"

Axios作为JavaScript生态中最流行的HTTP客户端之一,周下载量以千万计。攻击者在3月底向npm仓库推送了恶意版本1.14.1,而OpenAI的macOS应用签名流程恰好通过GitHub Actions自动化脚本拉取了这个版本。

「该工作流有权访问用于签名macOS应用的证书及公证材料,包括ChatGPT Desktop、Codex、Codex-cli和Atlas。」OpenAI在公告中披露了权限范围。这意味着攻击链条一旦打通,理论上可以触及OpenAI旗下所有桌面级产品的签名凭据。

供应链攻击的可怕之处正在于此:你信任的工具,成了别人的跳板。企业安全团队通常会对直接依赖做审计,但对依赖的依赖、工具链的工具链,监控盲区层层叠加。这次事件里,OpenAI的签名自动化流程成了那个"被借道的第三方"。

公司事后分析判定,证书"很可能未被成功窃取"。但"很可能"三个字在安全语境里等于掷硬币——OpenAI选择了最保守的处置方案:证书立即轮换,所有旧签名应用进入倒计时。

5月8日死线:老版本将直接断网

5月8日死线:老版本将直接断网

新证书已于近期部署,OpenAI给出了明确的版本门槛。ChatGPT Desktop需升级至1.2026.051,Codex App需26.406.40811,Atlas需1.2026.84.2。这些版本号是识别新证书签名的唯一标识。

「自2026年5月8日起,旧版本macOS桌面应用将不再接收更新或支持,且可能无法正常运行。」OpenAI的警告措辞相当直接。企业IT管理员需要把这个日期写进日历——届时未升级的设备可能面临功能中断,而非仅仅是安全警告。

证书轮换在软件行业不算罕见,但公开设定"功能死线"的做法相对少见。多数厂商选择静默推送,让用户无感过渡。OpenAI的强硬姿态,侧面反映了此次事件的风险评级——宁可承受用户投诉,也不留一丝被利用的窗口。

公告同时强调,目前没有证据表明用户数据被访问、知识产权遭泄露,或软件本身被篡改。这三重否认是标准危机公关话术,但结合证书轮换的激进程度,读者可以自行判断风险敞口的真实大小。

macOS签名机制:信任链的"单点故障"设计

macOS签名机制:信任链的"单点故障"设计

苹果的应用签名体系建立在证书信任链之上。开发者向苹果申请证书,用私钥签名应用,用户设备用公钥验证。整个模型的安全假设是:私钥绝对保密,证书颁发机构可信。

这个设计在理论上无懈可击,实践中却处处是人性漏洞。私钥存储在开发者的构建服务器上,而构建服务器又依赖自动化工具链,工具链再依赖开源库——信任链的末端往往系于某个默默无闻的npm包维护者。

GitHub Actions这类CI/CD(持续集成/持续部署)工具进一步放大了风险。工作流脚本通常拥有高度敏感的权限,却和普通的代码依赖混在同一套生态里。攻击者不需要攻破OpenAI的服务器,只需要在Axios的更新里藏一段恶意代码,就能让OpenAI的签名流程"自愿"交出权限。

这次事件暴露的结构性问题,远超出OpenAI单一案例。任何使用自动化签名流程的开发者,都在面对类似的攻击面。证书轮换是止血,但止血不能替代重构信任模型。

用户行动清单:三步完成自保

用户行动清单:三步完成自保

对于普通macOS用户,操作门槛其实很低。打开任意一款OpenAI桌面应用,进入关于页面核对版本号,低于门槛值的立即更新。企业环境需要批量排查,建议用MDM(移动设备管理)工具统一推送。

更深层的问题是:你的设备上还躺着多少"可能过期"的证书签名应用?多数用户从未检查过。macOS的钥匙串访问工具可以列出所有受信任证书,但界面设计得像个考古现场——苹果显然不希望你真的去翻。

这次事件给行业提了个醒:证书有效期管理应该成为终端安全的基础配置,而非事后补丁。OpenAI把死线设在2026年5月8日,给了14个月缓冲期,但谁也无法保证下一个供应链漏洞不会把窗口压缩到14天。

供应链攻击正在从"高级威胁"变成"基础操作"。去年xz utils后门事件、今年Axios投毒事件,攻击者越来越擅长在开发者最不设防的环节埋雷。防御方的应对策略,或许需要重新思考"信任但验证"的边界——在自动化时代,验证本身也可能被自动化攻破。

OpenAI的证书轮换是一次昂贵的止损。更值得关注的是,当GitHub Actions工作流拥有签名私钥访问权限时,整个架构设计是否从一开始就把鸡蛋放在了易碎的篮子里?下次供应链攻击来临时,有多少厂商会愿意像OpenAI这样摊牌,而不是让用户在不知情中承担风险?