一项覆盖2011年至2025年的纵向研究，把Qubes OS发布的109份安全公告（QSB）逐条比对Xen官方维护的464份安全公告（XSA），得出一个反直觉的结果：这109份公告里，87份、占比79.8%，根源在Xen虚拟化层、CPU微架构或其他上游组件，不是Qubes自己写的隔离代码。研究同时发现，Qubes公开披露的节奏在2015年第一季度出现一次结构性变化，2018年之后年度公告数量趋于平稳，不再像早期那样快速攀升。
这两个发现回答的其实是同一个问题：Qubes的公开安全记录是不是已经稳定下来了？答案是披露活动确实不再加速，但这远不等于风险已经平息。研究测量的始终是公开公告本身，不是潜在漏洞总量，更不是Qubes是否真的被攻破过。
十四年109份公告：披露曲线在2018年后走平
研究用变点分析（change-point analysis）拟合季度披露数据，找到的最大断点落在2015年第一季度。此后，季度公告数量在统计上进入平台期，2018年以后基本不再显著增长。
研究者还测试了几种S形漏洞发现模型（vulnerability discovery model）。这类模型能描述性地拟合过去十四年的曲线，但拿来做短期预测，并没有显著优于一个最朴素的滚动均值基线。靠这条曲线去猜明年会有几份公告，目前还不靠谱。
| 指标 | 数值 | 说明 |
|---|---|---|
| QSB公告总数 | 109份 | 2011–2025年，Qubes官方发布 |
| 上游归因公告 | 87份（79.8%） | 根源在Xen、CPU微架构或其他上游组件 |
| 受影响的XSA | 113份/464份 | Xen官方追踪器判定影响Qubes |
| 结构变点 | 2015年第一季度 | 季度披露序列最明显的断裂 |
| 披露平台期 | 2018年至今 | 年度公告量趋于平稳，不再快速增长 |
这份数据说明的是：Qubes的公开安全记录已经进入一个相对稳定的节奏。但“稳定”指的是记录本身，不是漏洞总量，也不是攻击发生频率。
八成问题在上游：隔离架构把风险转移到了Xen和硬件
传统单体操作系统的漏洞公告，大多数指向内核自身的代码缺陷。Qubes反过来——它的公告主要指向的是它选择信任的第三方组件。
这不是Qubes代码质量差，恰恰相反。Qubes的设计思路是用Xen虚拟化把不同任务隔离到互不信任的“qube”里，即便某个隔离域出问题，也不容易波及整个系统。79.8%的上游归因，是这套架构把攻击面转移出去之后的自然结果，既是代价，也是它换来的隔离能力。
官方Xen公告库里464份XSA，有113份被判定影响Qubes，占比约四分之一。这条比例说明Qubes并没有脱离Xen的风险半径，而是长期挂在这条供应链上随之波动。
对正在评估或运维Qubes的安全团队来说，现实的动作是：把Xen补丁和CPU微码更新纳入和Qubes-core补丁同等优先级的响应流程。不能因为核心代码占比低，就压缩这部分的巡检预算。对关注虚拟化供应链安全的研究者来说，这份统计更适合当成一套可复用的归因方法，而不是拿来直接论证“Qubes更安全”或“Qubes更脆弱”。
这份记录证明不了什么：公开公告不是漏洞总量
研究反复划出的边界在这里：它统计的是公开记录，不是潜在漏洞总量，也不是实际发生的入侵事件。披露延迟和公告删失，都会让观察到的曲线比真实情况更平——研究者自己也承认这一点。
作者用负二项分布做了过离散检验，结果稳定。但这只能证明统计方法可靠，不能证明系统本身更安全。
接下来值得盯的，是两条速度：Xen和CPU厂商修补上游漏洞的速度，以及Qubes团队跟进这些XSA、转化为自家QSB的速度。这两条速度如果继续同步，“披露趋稳”才站得住；一旦上游响应变慢而Qubes没跟上，这份平台期随时可能被打破。