月別隔離セキュリティパッチポリシー

Adobe Commerceのお客様が重要なセキュリティ修正を迅速に適用できるよう、Adobe Commerceでは、パッチ火曜日（月の第2火曜日）に毎月の個別セキュリティパッチを配信するようになりました。 日付については、Adobe Commerce リリーススケジュール ​を参照してください。 これらのパッチは、Adobe Commerce on Cloud、Adobe Commerce オンプレミス、およびMagento Open Sourceのインストールで使用できます。

分離されたセキュリティパッチファイルには、1つ以上の特定のセキュリティ脆弱性を解決するために必要なコードのみが含まれ、完全なComposer パッケージではなく、範囲が狭いcode-diff ファイルとして配信されます。 変更はセキュリティ脆弱性に固有であるため、セキュリティパッチバージョンのアップグレードに必要なより広範な依存関係の解決と回帰テストをトリガーすることなく、セキュリティパッチリリースよりも迅速にレビュー、テスト、および適用できます。 毎月の個別のセキュリティパッチファイルは、次の完全なセキュリティパッチリリースに折り畳まれるため、お客様は、次のセキュリティパッチ（-pN）リリースを通じて、リリースされたすべての個別パッチファイルを取得できます。

分離されたパッチが他のパッチタイプと適合する仕組み

分離されたセキュリティパッチは、Adobe Commerceがお客様に安全かつ最新の状態を維持するために提供するパッチの1つです。

セキュリティパッチには、次の2種類があります。

月別の個別パッチのメリット

脆弱性の発見は、業界全体で加速しています。 AIを活用した分析ツールにより、大規模なコードベースをスキャンし、手作業によるレビューよりもはるかに迅速に欠陥を特定できるようになりました。これにより、情報開示と悪用の間の時間を短縮できます。 毎月の個別パッチケイデンスでは、次に予定されているセキュリティパッチリリースを待つのではなく、準備ができた時点で修正を提供することで、このギャップを埋めます。

目標は、不要なオーバーヘッドのないスピードです。 準備完了の修正プログラムは、次のセキュリティパッチリリースまでキューに入れられず、加盟店は必要以上に頻繁にパッチを適用しません。 分離されたセキュリティパッチファイルはその緊張を解決します：それぞれが狭い、セキュリティのみの差分です。その範囲は意図的に制限されているため、セキュリティパッチリリースよりもレビューと適用がはるかに簡単です。

このアプローチは、単目的パッチがComposer リリースに必要な依存関係の解決と完全な回帰テストをスキップして、ビルドし、既知のベースラインに対して検証し、迅速に出荷できるため、機能します。 クラウド基盤では、これらの修正はCommerceのクラウドパッチ（パッケージ販売者がコンポーザーとデプロイメントワークフローの一部として更新する）にバンドルされます。 更新すると、デプロイメント中に修正が自動的に適用され、別のパッチファイルが見つからないか適用されません。 セキュリティ速報に記載されている手動パッチファイルワークフローは、Cloud パイプラインを実行しないオンプレミスおよびMagento Open Source インストール用です。

月別の分離パッチの適用

毎月の隔離されたセキュリティパッチファイルを適用し、最新の修正プログラムを最新の状態に保つには、次の手順に従います。

Cloudのお客様は、Adobe Commerce Patching Automationを使用して、上記の手動Gitおよびコンポーザー手順の代わりに、管理パネルからパッチを適用または元に戻すこともできます。

展開タイプ別のパッチアクション

FAQ

毎月の隔離セキュリティパッチは、新しいリリースポリシーです。 次の質問では、一般的な懸念に対処します。

過去に適用したすべての個別パッチまたは最新のセキュリティパッチリリースのみが必要ですか？

両方とも必要です。 分離されたパッチを適用する前に、最新のセキュリティのみの-p リリースベースラインにアップデートしてください。 各パッチはそのベースラインに対してのみテストされます。 分離されたパッチは累積されないので、見落とされたパッチは順番に適用します。

例えば、現在の-p リリースベースラインに属しているものの、7月と8月の個別パッチが適用されていない場合は、7月、8月、9月を適用します。 次の完全な-p リリースでは、以前に発行されたすべての個別の修正が含まれているため、シーケンスがリセットされます。

個別のパッチファイルではなく、1つのComposer パッケージを出荷するだけではよいですか？

複数のコンポーネント（CE、EE、B2B、Page Builder）を使用するインストールでは、各ファイルが特定のインストール済みコンポーネントバージョンをターゲットとしているため、毎月のリリースでは個別のパッチファイルが必要になる場合があります。 すべての修正を1つのComposer パッケージに組み合わせると、依存関係の解決の問題が再び発生し、完全なサーフェス回帰テストが必要になります。分離されたパッチのリスクは、回避するように設計されています。 クラウドをご利用のお客様は、パッチを手動で適用する必要はありません。 Commerce用のクラウドパッチは、既存のデプロイメントパイプラインを通じて同じ修正を行います。

パッチがパッチにレイヤー化されている場合、インストールのセキュリティ状態を知るにはどうすればよいですか？

毎月のセキュリティパッチのリリースに伴い、Adobe Commerceは、インストールされているパッチまたは欠落しているパッチと、インストールで保護されているCVEを報告するスタンドアロンユーティリティであるCommerce Version Toolを導入しました。 バージョン番号に依存するのではなく、パッチメタデータを読み取り、レポートと継続的インテグレーション（CI）用に機械で読み取り可能な出力を提供します。

これは、Adobeが累積的なバージョン付きセキュリティリリースから一歩下がったことを意味しますか？

いいえ。 年次-p リリースは、引き続き主要な累積セキュリティ チェックポイントです。 分離されたパッチは、CVEのケイデンスを補完し、それを安全に待つことはできません。 これらは-p リリースを置き換えるものではありません。 毎年、予定されているセキュリティパッチリリースをラインに適用すると、完全にサポートされているパスに残り、その間に個別のファイルとして発行されたすべての修正を受け取ります。

Composer以外で修正プログラムを送信すると、デフォルトのインストールの安全性が低下しませんか？

いいえ。 配信メカニズムは、修正のセキュリティ結果に影響を与えません。 分離されたパッチは、後でフルパッチ （-p）リリースに含まれるのと同じコード変更を適用します。 修正がComposer パッケージとして配信されるか、スタンドアロンファイルとして配信されるかは、その有効性に影響しません。 パッチを適用しないマーチャントは、次に予定されているセキュリティリリースまで、既存のセキュリティベースラインを維持します。 分離されたパッチを適用すると、完全なリリースサイクルを待つのではなく、より早く修正を行うことで露出を減らすことができます。

このトピックの詳細ヘルプ