一个开源项目的漏洞归维护者凌晨三点在GitHub上收到一条issue，标题只有两个字：“漏洞”。漏洞归点开一看，漏洞归附了一段模糊的漏洞归截图和一句“你们看着办”。没有复现步骤，漏洞归没有环境说明，漏洞归连版本号都没写。漏洞归维护者盯着屏幕，漏洞归脑子里蹦出的漏洞归第一个念头不是“怎么修”，而是漏洞归——这到底该算谁的？

这种场景在开源圈子里太常见了。漏洞被发现的漏洞归那一刻，责任就开始在开发者、漏洞归用户、漏洞归平台、漏洞归甚至整个生态之间来回弹跳。漏洞归有人觉得提交漏洞的人是在帮忙，有人觉得他们是在添乱。更麻烦的是，当漏洞被利用、造成实际损失之后，追责的逻辑往往和修漏洞的逻辑完全不是一回事。

去年有个npm包被曝出原型污染漏洞，影响了几万个下游项目。漏洞的根源是包作者五年前写的一段递归合并函数，当时他还在读大学，代码是从Stack Overflow上抄来改的。被发现的时候，这个包每周下载量已经超过百万次。作者在推特上说了一句话：“我从来没想过会有人这么用我的代码。”这句话底下吵了上千条回复。有人骂他不负责任，有人骂下游开发者不锁版本，还有人骂npm官方审核机制形同虚设。

吵到最后也没吵出个结果。但有一个细节被反复提起：那个漏洞的修复补丁其实三年前就有人在另一个更小的包里提交过，只是没人注意到。信息在生态里流动的时候，漏掉的不只是代码，还有责任本身。

企业用户的态度往往更直接。某次安全会议上，一个金融公司的技术负责人分享过他们的处理流程：发现第三方组件漏洞后，先评估影响面，再决定是等上游修复还是自己打补丁。如果上游响应太慢，他们就直接fork一份自己维护。听起来很果断，但他说这话的时候苦笑了一下——“我们fork了四十多个包，现在自己都快维护不过来了。”

漏洞归属的模糊地带，恰恰是攻击者最喜欢钻的地方。安全研究员@jsoo曾经追踪过一个供应链攻击案例，攻击者专门找那些“看起来有人维护、实际上已经半年没提交”的仓库，提交一个带后门的PR。这些PR往往伪装成代码格式化或者依赖升级，很容易被合并。等漏洞被曝光的时候，原维护者早就失联了，npm官方只能强制下架，留下一堆依赖它的项目在风中凌乱。

法律层面更是一团乱麻。开源许可证里几乎都写着“按原样提供，不提供任何担保”，但真出了事，这条免责声明能不能扛住诉讼，没人敢打包票。欧盟的《网络弹性法案》试图把责任压给“商业使用者”，但怎么定义“商业使用”，又成了新的扯皮点。一个在GitHub上收了五美元赞助的独立开发者，算不算商业使用者？没人说得清。

我自己的看法偏悲观。漏洞归属这个问题，本质上不是技术问题，而是信任分配问题。开源生态建立在“我帮你、你帮他”的默契上，但默契一旦被现实利益撕开，就很难缝回去。修漏洞的人、用漏洞的人、报漏洞的人、管漏洞的人，各自站在不同的立场上，拿着不同的尺子。你很难要求一个凌晨三点还在改代码的维护者去承担企业级的安全责任，但你也很难说服一个被黑了的公司“这锅你得自己背”。

所以下次看到“漏洞”两个字的时候，不妨先别急着问“谁该修”，而是问一句“谁该知道”。知道的人越多，责任就越难藏。至于修不修、怎么修、谁来修——那得看这个漏洞最后落在谁手里，以及那个人当时有没有空。