CentOS Stream 安全更新跟踪

安全更新跟踪要回答三个问题：更新从哪里来、公告从哪里看、什么时候进生产。第一个问题有官方原文可引；第二个问题只有项目博客这一条可核实的订阅入口；第三个问题牵涉安全公告体系本身，本轮没有取得足够证据。

公告与变更渠道：官方博客的订阅入口

官方博客提供订阅入口 /feed/：本轮核对访问该地址返回可订阅的源，页面以 RSS 2.0 形式给出并带一条 Atom 自引用链接，条目即博客文章，可用来跟踪项目公告与版本动态。

把订阅接进流程时，守住三条：

• 订阅源当线索入口，不当结论来源：博客能告诉你「发生了什么」，是否影响你的系统要回到自己的资产清单判断；
• 按固定节奏读，而不是按心情读：把巡检排进例行工作，避免只在出事后回溯；
• 保留时间线：把公告日期与你的动作日期分开记录，复盘时这两条线必须能对上。

更新从哪来：只接收面向 RHEL 的更新

官方 About 页在「What is CentOS Stream?」小节的原文是：Stream 的开发对所有人开放，但由于它只包含面向 RHEL 的更新，因此由 RHEL 团队维护。 这段表述同时界定了更新的范围与维护方，

Note

本页只按原文复述两件事：更新是「面向 RHEL 的更新」，维护方是 RHEL 团队。至于是谁先谁后、时差多少，原文没有给出，本页也不做推断。

安全公告体系的核查结论

本次核对未取得关于「Stream 是否拥有独立于 RHEL 的安全公告体系与补丁节奏跟踪入口」的一手证据。因此本页对这一题不下任何结论：

• 不写「有独立公告体系」，因为没有找到可引用的官方入口；
• 也不写「没有独立公告体系」，因为本次未取得证据不等于官方不存在；
• 需要这条结论时，回查官方渠道当前的实际内容，并把你自己的核对过程与核对日期一并记录下来。

Caution

上游项目的公告渠道是动态信息：入口、列表与展示方式都可能变化。任何写死的结论都会过期，可靠做法是把「回查官方渠道」本身写成例行动作。

生产窗口怎么排

在公告体系尚未查清的前提下，窗口安排只能基于你自己的风险口径：

1. 先有资产清单：哪些主机在哪条版本线上、承载什么业务、能承受多长的中断；
2. 分级窗口：把更新分成「常规窗口可做」与「必须单独评审」两类，别用一套流程处理所有更新；
3. 先验证再推广：在与生产同构的环境先跑一轮，确认业务可用后再推；
4. 留回滚点：每次进窗口前确认回退手段可用，这比事后找原因更重要。

Note

本页不提供「多久打一次补丁」的统一答案：那取决于你的合规要求与业务容忍度，不取决于某个发行版文档的措辞。

与 RHEL 的时差：本轮不写方向

「Stream 上的更新与 RHEL 的更新谁先谁后」是这一题里最容易被写成结论的地方，但它需要可比对的官方时间线作为证据，本轮未取得。因此：

• 本页不写「先到 Stream」或「先到 RHEL」之类的方向性结论；
• 能确定的只有一条：更新面向 RHEL，维护方是 RHEL 团队（见上文官方原文）；
• 需要时差结论时，以官方公告与自己的观察记录为准，并注明核对日期。

相关页

• CentOS Stream 版本与支持 — 版本线与支持窗口
• 用 Stream 预览 RHEL 次版本 — 把更新先放进预览环境观察
• CentOS Stream 仓库与滚动内容 — 更新从哪套仓库来
• CentOS Stream 运维基线 — 把跟踪动作纳入日常
• 官方：关于 CentOS（更新范围与维护方原文）、CentOS 官方博客订阅源（公告入口）