每月隔离的安全修补策略
为了帮助Adobe Commerce客户更快地应用关键安全修复，Adobe Commerce现在在修补程序星期二（本月的第二个星期二）提供每月隔离的安全修补程序。 有关日期，请参阅Adobe Commerce发布计划。 这些修补程序可用于Adobe Commerce on Cloud、Adobe Commerce内部部署和Magento Open Source安装。
独立的安全修补程序文件仅包含解决一个或多个特定安全漏洞所需的代码，这些文件以范围狭窄的代码差异文件形式提供，而不是完整的Composer包。 由于这些更改特定于安全漏洞，因此审查、测试和应用这些更改的速度比安全修补程序版本更快，而不会触发安全修补程序版本升级所需的更广泛的依赖项解析和回归测试。 每个每月独立的安全修补程序文件都合并到下一个完整的安全修补程序版本中，因此客户可以通过下一个安全修补程序(-pN)版本获取所有已发布的独立修补程序文件。
独立修补程序如何与其他修补程序类型配合使用
独立的安全修补程序是Adobe Commerce为保持客户的安全性和及时更新而提供的几种修补程序之一。
这两种类型的安全修补程序具有不同的角色：
-
隔离的修补程序只包含漏洞修复，不累积。 它们不会捆绑以前发布的独立修补程序文件。 商家必须按顺序应用补丁，因为每个新补丁（假设先前补丁）都已准备就绪。 要应用独立的安全修补程序，安装必须在其受支持行的最新仅安全修补程序发行版上，因为独立修补程序将专门针对该版本进行测试。
-
安全修补程序(
-pN)每年针对所有受支持的发行行发布，并通过Composer进行部署。 它们包括所有以前发布的安全性、合规性和质量修补程序。 如有必要，Adobe可能会发布其他安全修补程序。
每月独立修补程序优势
整个行业的漏洞发现速度都在加快。 AI辅助分析工具现在扫描大型代码库和表面缺陷的速度远远快于手动检查，缩小了公开和开发之间的窗口。 每月一次的隔离修补程序节奏可在修补程序准备就绪后立即提供修补程序，而不是等到下一个计划的安全修补程序发布时提供修补程序，从而弥补这一缺口。
目标是提高速度，避免不必要的开销。 在下次发布安全修补程序之前，就绪的修补程序不会排在队列中，并且商户的修补程序频率不会超过所需频率。 独立的安全修补程序文件解决了这一矛盾：每个文件都是一个狭隘的、仅用于安全保护的差异 — 与安全修补程序发行版相比，审查和应用要简单得多，因为其范围刻意受限。
此方法之所以有效，是因为单用途修补程序跳过了Composer版本所需的依赖项解析度和完全回归测试，允许根据已知基线构建、验证并快速交付。 在云基础架构上，这些修复捆绑到Commerce的云修补程序中 — 包商家作为其编辑器和部署工作流的一部分进行更新。 更新后，该修复程序会在部署期间自动应用，而无需单独查找或应用修补程序文件。 安全公告中所述的手动修补程序文件工作流适用于不运行Cloud管道的内部部署和Magento Open Source安装。
应用每月隔离的修补程序
要应用每月隔离的安全修补程序文件并保持最新修补程序，请按照以下流程操作：
-
检查发布计划。
新的每月独立修补程序文件将按照发布计划发送。 查看受影响组件和CVE的相应安全公告。 每个公告都链接到发行说明，其中包含安装当月独立修补程序文件的分步说明。
-
使用Commerce版本工具检查Commerce安装的安全状态。
该工具报告当前安装了哪些每月修补程序，哪些修补程序缺失，以及安装仍然对哪些CVE可见。 这样可最终评估所需的操作，而不是仅依赖版本号。
-
确认您的基线版本。
隔离的修补程序仅针对您的产品系列的最新仅安全版本
-p进行测试。 如果落后于该基线，请首先应用它。 -
按顺序应用所有缺失的修补程序。
由于它们不是累积文件，因此不能跳至最新文件。
note NOTE Cloud客户：请先检查Commerce 版本已安装的云修补程序。 该修复可能已包含在内，手动应用它可能会导致冲突或复制该修复。 -
将文件与已安装的组件匹配。
仅应用与CE、EE、B2B或其他组件版本对应的文件。
-
重新运行Commerce版本工具以确认。
验证新修补程序是否显示为已安装，以及相关CVE现在是否报告为受保护。
-
测试，然后部署。
按照正常的更改流程，在升级到生产环境之前在暂存环境中进行验证。
Cloud客户还可以使用Adobe Commerce Patching Automation来通过Admin面板应用或还原修补程序，而不是执行上述手动Git和编辑器步骤。
按部署类型划分的修补程序操作
-p版本，下载与每个已安装的组件匹配的文件，按顺序应用，并使用Commerce版本工具进行验证。常见问题解答
每月隔离的安全修补是一项新的发布策略。 以下问题涉及共同关注的问题。
我是否需要应用每个以前的独立修补程序，还是只需要最新的安全修补程序版本？
你两者都需要。 在应用独立的修补程序之前，请更新到最新的仅安全版本-p发布基线。 每个修补程序仅根据该基线进行测试。 独立修补程序不会累积，因此请依次应用任何缺失的修补程序。
例如，如果您在当前-p版本基线上，但错过了7月和8月的独立修补程序，请依次应用7月、8月和9月。 下一个完整-p发行版将重置该序列，因为它包含所有之前发布的隔离修复。
为什么不只提供一个Composer包，而不是单独的修补程序文件？
在具有多个组件（CE、EE、B2B和Page Builder）的安装中，每月发行版本可能需要单独的修补程序文件，因为每个文件都以特定安装的组件版本为目标。 将所有修复程序合并到一个编辑器包中，会重新引入依赖关系解析问题，并且需要进行全表面回归测试，这些独立修补程序旨在避免风险。 云客户不需要手动应用修补程序。 Commerce云修补程序通过现有部署管道提供相同的修复。
使用分层补丁的补丁程序，如何知道我的安装处于什么安全状态？
在发布每月的安全修补程序后，Adobe Commerce引入了Commerce版本工具，这是一个独立实用程序，可报告哪些修补程序已安装或丢失，以及您的安装受哪些CVE保护。 该工具读取修补程序元数据并提供机器可读的输出以用于报表和连续集成(CI)，而不是依赖版本号。
这是否意味着Adobe已退出累积的版本化安全版本？
不适用。 年度-p版本仍然是主要的累积安全检查点。 对于无法安全等待的CVE，独立的修补程序可补充其节奏。 它们不会替换-p版本。 如果您每年为线路应用计划的安全修补程序版本，则您将保留在完全支持的路径上，并接收之间作为独立文件发布的每个修补程序。
在Composer外部提供修复程序是否会降低默认安装的安全性？
不适用。 投放机制不会影响修复的安全结果。 独立的修补程序应用了以后包含在完整修补程序(-p)发行版中的相同代码更改。 修补程序是以编辑器包还是独立文件的形式提供，这与其有效性无关。 不应用补丁程序的商家将保持其现有的安全基线，直到下一个计划的安全版本发布。 应用独立的修补程序可以更快地提供修补程序，而不是等待一个完整的发布周期，从而减少暴露风险。