AI、漏洞披露与软件供应链风险

近期报告涉及 Linux 权限提升漏洞、被入侵的 npm 软件包、curl 问题以及 GitHub 漏洞。我觉得事态发展令人担忧，但这些事件的原因和影响各不相同。它们同时出现，不能证明每一起都由 AI 发现或利用。

我担心 AI 可能同时加速漏洞发现和利用，改变维护者与用户可用于响应的时间。这是对风险的判断，并不能证明所有系统已经遭入侵，也不能证明攻击者能够自动利用每一个缺陷。

Copy Fail 及后续相关 Linux 报告说明了本地权限提升为何重要：在易受攻击的系统上，权限有限的进程可能获得更高权限。暴露情况取决于内核、配置、发行版和补丁状态，应查看发行版公告，而不能假定所有 Linux 安装的状态相同。

我认为，大量安全报告正在考验我们过去对发现和修复需要多久的假设。我尤其质疑：是否只有专家能发现严重缺陷、较长的协调披露窗口是否总有帮助，以及从公开代码中识别可能涉及漏洞的修复是否仍然困难。

协调披露通常指先私下报告漏洞，留出修复时间，然后再公开细节。90 天等窗口在某些政策中常见，但并不是普遍规则。它的取舍是在给防御方争取时间的同时，承认其他人可能独立发现同一问题。

另一种传统是在公开场合快速修复错误，但不强调其安全含义。这可以推动补丁尽快落地，但修改一旦公开，观察者就可能推断它修复了什么。它从来不能保证保密；AI 辅助审查可能改变分析修改所需的成本和速度。

Jeff Kaufman 用 Copy Fail 的后续事件说明两种做法之间的张力：修复公开分享，安全影响暂时受限，随后另一位观察者识别并披露了其含义。Kaufman 提到，首次报告九小时后又出现独立报告；仅凭时间间隔不能证明 AI 参与。

Kaufman 认为，低调公开修复和长期保密都面临挑战，并建议考虑缩短保密期。我认同这一担忧，但没有一个期限适用于所有项目：更短的窗口可能让防御方更早得到警示，也可能减少准备和分发补丁的时间。

文章介绍了一个小型示例测试：让三个模型判断一个提交是否像安全修复。提供完整提交时，三者都识别了；只提供差异时，它们的判断不同。作者提醒，每个模型只运行一次、没有对照组，因此不能据此可靠比较模型性能。

我担心自动化可能帮助人们优先调查可疑提交，从而缩短修复公开与攻击未修补系统之间的时间。识别可疑修改不等于能可靠地产生可用利用方法，视频也没有测量两者之间的转化率。

上游项目收到补丁，不等于每台设备都已获得它。发行方需要评估、集成、测试和发布更新，用户随后还要安装。披露安排因项目和供应商而异，因此不能笼统地说发行版维护者从不会在公开前获知。

TanStack 的 npm 事件是另一个供应链风险案例。攻击者通过针对发布流程的攻击发布了恶意软件包。AI 可能降低部分安全工作的成本，但视频没有证据证明 AI 导致了这起具体入侵。

我担心，如果攻击更快或更易规模化，学校、医院、开发者和普通用户会受到影响。严重程度因系统而异，关于大范围入侵的预测也存在不确定性。尽管如此，组织仍可以同时规划预防和恢复，而不是依赖完美防御。

我建议将早期披露扩大到一组受信任的下游维护者和运营方，让他们在细节公开前准备更新。这可能减少部分延迟，但也会带来难题：谁有资格、如何保护信息、小项目如何参与，以及更大的知情范围是否增加泄露风险。

我还建议，暂时私下准备部分安全修改，再通知受信任的发行方，并在部署推进后公开源码。这是供讨论的提议，不是已经确立的最佳实践。它需要仔细分析许可、可复现构建、独立审查，以及对闭源修改所需的信任。

我用一个类比来推测：公司发布稳定版本时，可能希望暂时保留实验性功能。这不能证明任何特定团队的真实动机。选择性开放可能帮助部分协调，也可能削弱透明度，并将受影响的社区排除在外。

在我设想的流程中，维护者先评估问题并准备修复，再提醒受信任的下游发行方，之后更广泛地披露修改。难点不只是增加私有分支：参与方还需要公平、安全的流程，并遵守相关许可义务。

我承认这种方式很复杂，最多也只是暂时措施。视频中我把选择描述得很尖锐，但事情不一定只有接受我的提议或放弃开源这两种选项。其他披露、审查、分发和安全开发方法同样值得考虑。

在个人韧性方面，我既考虑防止数据泄露，也考虑保住数据的可用性。可以假设入侵有可能发生，并据此规划恢复；这不意味着有证据表明你的所有数据真的已经被盗。关键问题是：如果唯一可用副本遭到销毁或加密，会发生什么？

我正在制作多份备份，包括更新间隔期间离线或断开连接的副本，以及其他地点的副本。备份只有能恢复时才有用，因此测试恢复和保护备份凭据也很重要。应根据数据的重要性及可接受的损失量选择频率和存储方式。

与家人讨论冒充和紧急情况。熟悉的声音或来电号码本身未必能证明身份；可以约定通过可信渠道核实异常请求。我还建议找出重要记录并制作可访问的备份，适合时也可保留纸质副本。

我问自己，什么证据会改变我的看法。一种可能是，大量发现集中清理了过去积累的缺陷，之后发现速度下降。仅凭公开 CVE 的数量不能确定底层软件是否越来越不安全：报告习惯、范围和发现能力也会影响数字。

另一个值得期待的可能是，维护者比攻击者更早发现并修复更多问题。AI 辅助分析可以帮助防御方，但仍需要专业人员验证结果，也需要资源采取行动。Mozilla 和 curl 的维护者都描述过有用的 AI 辅助发现，以及评估结果所需的人工工作。

我提到 OpenAI 的 Daybreak 公告，作为向项目提供防御性漏洞分析的一个例子。可用性和访问条件可能变化。更大的目标是帮助维护者主动加固软件，而不是假定扫描一次就能保证安全。

安全设计也能减少某些类别的错误：内存安全语言可以防止许多内存安全问题，数据访问时也应强制执行授权边界。这些选择都不能消除所有漏洞；现有系统、配置、依赖和人工审查仍然重要。

我建议大家及时修补操作系统和重要软件，同时从安全修复与供应链风险两个角度评估依赖更新。对所有软件包一律等待固定时间并不总是安全：正在被利用的紧急漏洞可能需要立即处理，而刚发布的依赖则可能值得额外审查。

我仍然认为开源很重要。目标是改进我们信任、审查、分发和更新代码的方式，同时为维护者提供必要支持。安全需要权衡，更快的工具让谨慎协调和恢复规划更加重要。