월별 격리 보안 패치 정책

Adobe Commerce 고객이 중요한 보안 수정 사항을 더 빨리 적용할 수 있도록 지원하기 위해 Adobe Commerce은 이제 매달 격리된 보안 패치를 패치 화요일(매월 두 번째 화요일)에 제공합니다. 날짜는 Adobe Commerce 릴리스 일정을 참조하세요. 이러한 패치는 Adobe Commerce on Cloud, Adobe Commerce 온프레미스 및 Magento Open Source 설치에 사용할 수 있습니다.

격리된 보안 패치 파일에는 하나 이상의 특정 보안 취약점을 해결하는 데 필요한 코드만 포함되어 있으며 전체 Composer 패키지가 아닌 좁은 범위의 코드 차등 파일로 제공됩니다. 변경 사항은 보안 취약점에만 해당하므로, 보안 패치 버전 업그레이드에 필요한 광범위한 종속성 해결 및 회귀 테스트를 트리거하지 않고도 보안 패치 릴리스보다 빠르게 검토, 테스트 및 적용할 수 있습니다. 매월 격리된 모든 보안 패치 파일은 다음 전체 보안 패치 릴리스에 접히므로 고객은 다음 보안 패치(-pN) 릴리스를 통해 릴리스된 모든 격리된 패치 파일을 가져올 수 있습니다.

분리된 패치가 다른 패치 유형과 일치하는 방식

격리된 보안 패치는 Adobe Commerce이 고객을 안전하게 보호하고 최신 상태로 유지하기 위해 제공하는 여러 유형의 패치 중 하나입니다.

두 가지 유형의 보안 패치는 서로 다른 역할을 합니다.

월간 격리 패치 혜택

업계 전반에 걸쳐 취약성 발견이 가속화되었습니다. AI 지원 분석 도구는 이제 대규모 코드베이스와 표면 결함을 수동 검토보다 훨씬 빠르게 스캔할 수 있어 공개와 이용 사이의 창구가 줄어든다. 매월 격리된 패치 케이던스는 예약된 다음 보안 패치 릴리스를 기다리지 않고 수정 사항이 준비되는 즉시 제공하여 이 간격을 닫습니다.

목표는 불필요한 간접비가 없는 속도입니다. 준비된 수정 사항은 다음 보안 패치 릴리스까지 큐에 있지 않으며 판매자는 필요 이상으로 자주 패치하지 않습니다. 격리된 보안 패치 파일은 이러한 문제를 해결합니다. 각 파일은 보안 패치 릴리스보다 검토 및 적용하는 것이 훨씬 간단하며 범위가 의도적으로 제한되어 있기 때문에 좁고 보안 전용 차이입니다.

이 방법은 단일 목적 패치가 Composer 릴리스에 필요한 종속성 해결 및 전체 회귀 테스트를 건너뛰고 이를 빌드하고 알려진 기준선에 대해 검증한 다음 신속하게 전달할 수 있기 때문에 작동합니다. 클라우드 인프라에서 이러한 수정 사항이 Commerce용 클라우드 패치(패키지 판매자 업데이트)에 번들로 제공되며 작성기 및 배포 워크플로우의 일부로 업데이트됩니다. 업데이트되면 이 수정 사항은 배포 중에 자동으로 적용되며 찾거나 적용할 별도의 패치 파일이 없습니다. 보안 공지에 설명된 수동 패치 파일 워크플로우는 Cloud 파이프라인을 실행하지 않는 온-프레미스 및 Magento Open Source 설치를 위한 것입니다.

매월 격리된 패치 적용

월별 격리된 보안 패치 파일을 적용하고 최신 수정 사항을 최신 상태로 유지하려면 아래 프로세스를 따르십시오.

Cloud 고객은 Adobe Commerce 패치 자동화를 사용하여 위의 수동 git 및 Composer 단계 대신 [관리] 패널을 통해 패치를 적용하거나 되돌릴 수도 있습니다.

배포 유형별 패치 작업

FAQ

월별 격리된 보안 패치는 새로운 릴리스 정책입니다. 다음 질문은 일반적인 문제를 해결합니다.

이전에 격리된 모든 패치를 적용해야 합니까? 아니면 최신 보안 패치 릴리스만 적용해야 합니까?

둘 다 필요해 격리된 패치를 적용하기 전에 최신 보안 전용 -p 릴리스 기준으로 업데이트하십시오. 각 패치는 해당 기준선에 대해서만 테스트됩니다. 격리된 패치는 누적되지 않으므로 누락된 패치는 순서대로 적용합니다.

예를 들어 현재 -p 릴리스 기준선에 있지만 7월과 8월의 격리된 패치가 누락된 경우 7월, 8월, 9월을 적용합니다. 다음 전체 -p 릴리스는 이전에 발급된 모든 격리된 수정 사항이 포함되어 있으므로 시퀀스를 재설정합니다.

별도의 패치 파일 대신 하나의 Composer 패키지를 배송하는 것은 어떻습니까?

CE, EE, B2B 및 Page Builder 등 여러 구성 요소가 설치된 경우, 각 파일은 설치된 특정 구성 요소 버전을 대상으로 하므로 월별 릴리스에는 별도의 패치 파일이 필요할 수 있습니다. 모든 수정 사항을 하나의 Composer 패키지에 결합하면 종속성 해결 문제가 다시 발생하고 전체 표면 회귀 테스트가 필요하므로 위험 격리 패치가 방지되도록 설계되었습니다. 클라우드 고객은 패치를 수동으로 적용할 필요가 없습니다. Commerce용 클라우드 패치는 기존 배포 파이프라인을 통해 동일한 수정 사항을 제공합니다.

패치가 패치에 레이어드된 경우 내 설치의 보안 상태를 어떻게 알 수 있습니까?

Adobe Commerce은 월별 보안 패치가 릴리스됨에 따라 설치 또는 누락된 패치와 설치 시 보호되는 CVE를 보고하는 독립 실행형 유틸리티인 Commerce 버전 도구을 도입했습니다. 이 도구는 버전 번호에 의존하지 않고 패치 메타데이터를 읽고 보고 및 CI(지속적 통합)를 위해 기계가 읽을 수 있는 출력을 제공합니다.

이것은 Adobe이 버전 관리된 누적 보안 릴리스에서 물러났음을 의미합니까?

아니. 연간 -p 릴리스는 기본 누적 보안 검사점으로 유지됩니다. 격리된 패치는 CVE가 안전하게 대기할 수 없는 케이던스를 보완합니다. -p 릴리스를 바꾸지 않습니다. 매년 라인에 대해 예약된 보안 패치 릴리스를 적용하는 경우 완전히 지원되는 경로에 계속 머무르며 그 사이에 격리된 파일로 발급된 모든 수정 사항을 받게 됩니다.

Composer 외부의 배송 수정 사항이 기본 설치의 보안을 저하하지 않습니까?

아니. 게재 메커니즘은 수정 사항의 보안 결과에 영향을 주지 않습니다. 분리된 패치는 나중에 전체 패치(-p) 릴리스에 포함된 동일한 코드 변경 사항을 적용합니다. 수정 사항이 작성기 패키지로 제공되는지 또는 독립 실행형 파일로 제공되는지 여부는 효과에 아무런 영향을 주지 않습니다. 패치를 적용하지 않는 판매자는 다음 예약된 보안 릴리스까지 기존 보안 기준에 유지됩니다. 격리된 패치를 적용하면 전체 릴리스 주기를 기다리지 않고 수정 사항을 더 빨리 전달하여 노출을 줄일 수 있습니다.

이 항목에 대한 추가 도움말