백포팅이란 무엇인가? 절차, 고려 사항, 팁 등

주요 내용

• 백포팅은 업스트림 업그레이드 없이, 최신 릴리스의 수정 사항을 사용자가 실행 중인 이전 버전에 적용하는 것을 말합니다.
• 레드햇은 업스트림 버전을 변경하지 않고 OpenSSL 1.0.1e에서 Heartbleed 취약점을 수정했기 때문에, 버전만 확인하는 스캐너는 어쨌든 이를 문제로 표시합니다.
• 백포트는 버전 번호가 아니라 배포판 공지사항과 패키지 변경 내역을 통해 확인하십시오.
• 표준 지원이 종료되면, 문제 해결은 연장 지원, 유지 관리되는 포크, 또는 자체 팀에 의존하게 됩니다.

스캐너에 따르면 해당 서버에서 취약점이 있는 OpenSSL 버전을라고 표시합니다. 시스템 관리자는 지난달에 패치가 적용되었다고 말합니다. 둘 다 동일한 호스트를 확인하고 같은 패키지를 분석하고 있지만, 취약점에 관해 옳은 말은 한쪽뿐입니다. 이 논쟁은 백포팅 문제 때문입니다. 최신 릴리스의 수정 사항이 여전히 실행 중인 버전에 적용되었지만, 업스트림 버전 번호는 변경되지 않았기 때문입니다. 엔터프라이즈 리눅스 환경에서는, 이러한 종류의 오경보를 추적하는 데 실제 취약점을 처리하는 것보다 더 많은 시간이 소요될 수 있습니다.

이 글에서는 백포팅이 무엇인지, 수정 사항이 반영된 후에도 버전 번호가 그대로 유지되는 이유, 이것이 버전 기반 스캐너에 문제를 일으키는 이유, 수정 사항을 직접 확인하는 방법, 그리고 릴리스의 지원 종료 후에도 누가 지속적으로 백포팅을 제공하는지에 대해 다룹니다.

백포팅이란 무엇인가?

백포팅이란, 소프트웨어 패키지의 최신 버전에서 보안 결함 수정 사항을 추출하여, 여전히 배포 중인 구버전에 적용하는 것을 의미합니다. 이를 통해 최신 업스트림 릴리스로 전환하여 관련 없는 변경 사항까지 모두 도입하지 않고도 취약점을 수정할 수 있습니다.

하지만 실제로 ‘백포트’란 무엇을 의미할까요? 구체적인 예를 들어보겠습니다. OpenSSL의 유지보수 담당자들은 Heartbleed 취약점을 을 1.0.1g 릴리스에서 수정했습니다. 레드햇(Red Hat)의 고객들은 1.0.1e를 사용 중이었는데, 이를 1.0.1g로 업그레이드하면 해당 릴리스들 사이에서 이루어진 다른 모든 변경 사항까지 함께 적용되었을 것입니다. 그래서 레드햇은 하트블리드 수정 사항만을 1.0.1e 코드베이스에 백포트하여 openssl-1.0.1e-16.el6_5.7 를 배포했습니다. 업스트림 기능 기준은 동일하며, 패치된 코드 경로 외부의 동작도 동일하고, 하트블리드 취약점은 더 이상 존재하지 않습니다.

이러한 방식으로 보안 수정 사항을 역포트하는 것은 지난 20년 동안 RHEL, 우분투, 데비안, SUSE 및 이들의 파생 배포판을 포함한 대부분의 리눅스 배포판에서 표준 관행으로 자리잡아 왔습니다. 다음 명령을 실행하세요. RHEL 호스트에서 명령을 실행하면 적용되는 수정 사항 중 상당수가 백포트된 것들입니다.

알고 계셨나요? 릴리스 필드의 마지막 부분을 보면 백포트된 빌드인지 확인할 수 있습니다. openssl-1.0.1e-16.el6_5.7에서 1.0.1e는 업스트림 버전이며, 백포트된 업데이트의 경우 이 버전이 그대로 유지됩니다. 16.el6_5.7 부분은 배포판의 패키지 릴리스 번호이며, 배포판에서 수정된 빌드를 출시할 때마다 변경됩니다.

백포팅의 작동 원리

유지보수 담당자는 업스트림에서 수정 사항을 찾아내고, 변경된 다른 부분들과 분리하여, 변경된 코드베이스에 맞게 조정하고, 회귀 현상을 테스트한 뒤, 업스트림 버전 번호를 그대로 유지한 채 일반 업데이트 채널을 통해 배포합니다.

상류 버전을 그대로 유지하는 것은 수정 자체만큼이나 의도적인 조치입니다. 이는 패치된 코드 경로를 제외한 부분에서 API와 전반적인 동작이 그대로 유지되며, 패키지가 근본적으로는 여전히 동일한 릴리스임을 나타냅니다. 변경되는 것은 배포판의 릴리스 식별자뿐입니다.

1. 상류에서 해결책을 찾아보세요

누군가가 결함을 보고하면, 업스트림 유지보수 담당자가 수정 코드를 작성하고, 이는 최신 릴리스에 반영됩니다. 배포판의 보안 팀은 해당 수정 사항이 포함된 릴리스 자체뿐만 아니라, 결함을 해결하는 정확한 변경 사항이나 일련의 변경 사항을 정확히 파악해야 합니다.

이건 말처럼 쉽지 않습니다. 업스트림 프로젝트에서 보안 수정 사항을 항상 깔끔하고 독립적인 단일 커밋으로 배포하는 것은 아닙니다. 세 개의 커밋에 분산되어 있거나, 대규모 리팩토링 작업에 포함되어 있거나, CVE가 공개되기 전에 모호한 메시지와 함께 병합되어 있을 수도 있습니다. 보안 팀은 이러한 사항을 파악하기 위해 업스트림 저장소, 메일링 리스트, CVE 피드를 지속적으로 모니터링합니다.

이 단계의 결과물은 패치(때로는 여러 커밋을 합쳐서 만든 것)와, 어떤 줄이 결함을 해결하는지, 그리고 그 이유가 무엇인지에 대한 명확한 이해입니다. 이후의 모든 과정은 이 단계가 제대로 이루어지는지에 달려 있습니다. 수정 사항의 절반만 처리하면, 패치되었다고 주장하지만 실제로는 그렇지 않은 패키지를 배포하게 될 것입니다.

2. 관련 없는 변경 사항으로부터 분리하십시오

업스트림에서 제공된 수정 사항은 해당 릴리스에 포함된 다른 모든 요소들—새로운 기능, 리팩토링, 변경된 기본값, 의존성 버전 업데이트 등—과 뒤섞인 채로 도착합니다. 유지보수 담당자는 이 모든 것을 제거합니다.

남은 부분은 해당 결함을 해결하는 데 필요한 최소한의 변경 사항만이어야 하며, 그 외에는 아무것도 없어야 합니다. 이것이 바로 백포팅의 핵심 가치입니다. Ansible 롤을 망가뜨리는 새로운 구성 구문 없이도 보안 수정 사항을 적용할 수 있기 때문입니다.

알아두면 좋은 팁: 일부 배포판 변경 내역에는 백포트된 수정 사항이 유래한 업스트림 릴리스나 커밋이 명시되어 있습니다. 이 경우, 해당 참조 정보는 수정 사항이 어디서 비롯되었는지를 나타낼 뿐, 실제로 설치된 내용을 의미하지는 않습니다. 패키지는 원래의 업스트림 버전을 유지하며, 배포판 릴리스 번호만 변경됩니다. 감사관들은 이 두 가지를 자주 혼동하므로, 증거 자료에 이 차이점을 한 번만 명확히 기재해 두면 검토 과정에서 같은 내용을 다섯 번이나 설명할 필요가 없을 것입니다.

격리 작업에도 판단력이 필요합니다. 어떤 코드 줄이 실제로 수정 대상에 해당하는지 결정하려면 취약점 자체를 이해해야 하는데, 이는 패치를 적용하는 것 보다 훨씬 더 높은 기준을 요구합니다.

3. 기존 코드베이스에 맞게 수정한다

이제 패치를 상황에 맞게 다시 작성해야 합니다. 함수 시그니처가 달라졌고, 데이터 구조의 형태가 변경되었으며, 이전 버전 트리에는 보조 함수가 아직 존재하지 않을 수도 있습니다. 두 릴리스 전에 이름이 변경된 함수를 다루는 수정 사항은 그대로 적용할 수 없습니다.

유지보수 담당자는 기존 코드베이스에서 제공하는 기능을 활용하여 동일한 방어 로직을 재구현합니다. 두 코드베이스의 차이가 크지 않을 때는 이 작업이 금방 끝날 수 있습니다. 하지만 수년 동안 차이가 벌어져 온 경우에는 상당한 규모의 재구현이 필요할 수 있으며, 때로는 아예 불가능할 수도 있는데, 이는 아래에서 다루게 될 실질적인 한계 중 하나입니다.

실제 예시를 들어보자. 경계 검사를 추가하는 독립적인 수정 사항은 대개 포팅하기가 간단하다. 반면, 잠금 모델을 변경하여 경합 조건을 해결하는 수정 사항은 훨씬 더 어렵다. 기존 코드에는 해당 수정 사항이 필요로 하는 잠금 기본 요소가 없을 수 있기 때문이다. 이 경우 유지보수 담당자는 동일한 보안 문제를 다른 방법으로 해결해야 한다.

이것이 바로 “백포트를 누가 관리하는가”가 단순한 마케팅 문구가 아니라 실질적인 조달 관련 질문인 이유입니다. 이 작업을 수행하는 팀의 역량에 따라, ‘패치된’ 시스템이 진정으로 패치되었는지 여부가 결정됩니다.

4. 동작에 변화가 없는지 확인한다

패치된 패키지는 두 가지 기준에 따라 빌드되고 테스트됩니다. 즉, 결함이 수정되었는지, 그리고 수정 과정에서 의도하지 않은 회귀 현상이 발생하지 않았는지 확인합니다.

후반부가 더 까다로운 시험대입니다. 회귀 테스트 모음, ABI 호환성 검사, 통합 테스트가 모두 이 단계에서 실행되는데, 이는 백포트의 핵심 목적이 별도의 마이그레이션 프로젝트로 전환되지 않고 일반적인 패치 주기를 거칠 수 있도록 하는 것이기 때문입니다. 이 약속을 단 한 번이라도 어기면 고객들은 업데이트 채널을 더 이상 신뢰하지 않게 될 것입니다.

엔터프라이즈용 배포판은 라이브러리 패키지의 ABI 호환성을 확보하기 위해 상당한 노력을 기울이고 있으며, 이를 통해 백포트 과정에서 고객이 컴파일한 애플리케이션이 의존하는 심볼이 은밀하게 변경되는 일이 없도록 합니다. 예를 들어 RHEL은 각 릴리스에 대해 명확한 API 및 ABI 호환성 약속을 공개하고 있습니다. 이러한 체계적인 관리가 바로 장기 지원(LTS) 릴리스가 10년 동안 계속 사용될 수 있는 주요 이유 중 하나입니다.

주의: 해당 취약점에 대해 검증된 백포트라고 해서 반드시 귀하의 애플리케이션에 대해서도 검증된 것은 아닙니다. 공급업체의 회귀 테스트는 패키지 자체만을 대상으로 합니다. 핵심 경로에 대해서는 자체적인 스모크 테스트를 계속 수행하십시오.

5. 업스트림 버전을 변경하지 않은 채로 배포합니다.

패키지는 일반 저장소를 통해 배포됩니다. 업스트림 버전은 기존과 완전히 동일하게 유지되며, 배포판의 릴리스 접미사만 변경됩니다.

openssl-1.0.1e-16.el6_5.4 다음과 같이 변경됩니다 openssl-1.0.1e-16.el6_5.7로 변경됩니다. 패키지 관리자의 관점에서 보면 이는 일상적인 업데이트에 불과합니다. 하지만 “1.0.1e” 버전을 “1.0.1g에서 수정됨”이라고 기록된 업스트림 CVE 데이터베이스와 비교하는 버전 기반 스캐너의 관점에서 보면, 마치 아무 조치도 취하지 않은 것처럼 보입니다.

이러한 불일치는 알려진 보고상의 부작용이 있는 의도적인 호환성 선택이며, 리눅스 환경에서 오탐지된 취약점 발견의 가장 흔한 원인 중 하나입니다.

백포팅 대 업그레이드

둘 다 그 결함을 보완합니다. 그 외에는 거의 모든 면에서 차이가 있습니다.

	역이식	업그레이드
제공 내용	최신 업스트림 릴리스로 전환하지 않고, 특정 문제를 대상으로 한 수정	수정 사항 및 추가 기능, 변경된 기본 설정, 수정된 API
안정성에 미치는 영향	기존 동작을 유지하도록 설계됨	행동 양상이 달라질 수 있으므로 검사가 필요합니다
당신을 위한 노력	정기 패키지 업데이트	호환성 테스트, 구성 마이그레이션, 필요한 코드 수정
파손 위험	대규모 업그레이드보다는 낮지만, 0은 아니다	버전 간 격차에 따라 중간에서 높음
누가 그 일을 하나요?	배포판 또는 지원 업체	귀하의 팀
얼마나 오래 지속되는지	백포트를 관리하는 사람이 그만둘 때까지	새롭게 업그레이드된 버전이 자체 EOL에 도달할 때까지

업그레이드를 통해 필요한 특정 수정 사항뿐만 아니라, 전반적인 보안 강화, 더 안전한 기본 설정, 아키텍처 개선까지 얻을 수 있습니다. 반면 백포팅을 통해서는 부수적인 변경을 최소화하면서 특정 수정 사항만 적용할 수 있습니다. 이러한 장단점의 균형 때문에 장기 지원 릴리스에서는 빈번한 리베이스보다는 표적형 유지보수를 선호하는 것입니다.

버전 차이가 충분히 커지면 상황은 역전됩니다. 8년 동안 패키지를 유지해 온 백포트 체인에는 누적된 차이점이 많이 포함되어 있으며, 어느 시점부터는 마이그레이션이 더 실용적인 선택이 될 수 있습니다. 문제는 그 시기를 스스로 정할 수 있는지 여부이며, 지원 종료와 라이프사이클 종료의 비교를 통해 는 이러한 결정을 내리게 만드는 요인들을 다룹니다.

스캐너가 역포트된 수정 사항을 왜 표시하는가

일부 버전 기반 스캐너는 탐지된 패키지 버전을 업스트림 CVE 수정 버전과 비교합니다. 사용자의 패키지 버전이 1.0.1e라고 가정해 봅시다. 데이터베이스에 따르면 Heartbleed 취약점은 1.0.1g 버전에서 수정되었습니다. 스캐너는 사용자의 시스템이 취약하다고 보고합니다. 만약 이러한 판단이 버전 문자열에만 근거한 것이라면, 이는 오탐입니다. 스캐너가 백포트된 수정 사항을 전혀 고려하지 않았기 때문입니다. 레드햇(Red Hat)의 보안 문서에서도 바로 이러한 현상을 지적하고 있습니다.

다음은 처음부터 끝까지 단계별로 설명한 예제입니다.

각 당사자가 보는 관점	가치
설치된 패키지	openssl-1.0.1e-16.el6_5.7
CVE-2014-0160에 대한 업스트림 수정 버전	1.0.1g
나이브 스캐너의 판정	취약한
현재 현황	RHSA-2014:0376을 통해 패치됨

변경 내역부터 확인하여 직접 확인해 보세요. 설치된 패키지에서 해당 CVE가 있는지 확인해 보세요:

rpm -q –changelog openssl | grep CVE-2014-0160

CVE가 표시된다면, 해당 수정 사항이 포함되었다는 확실한 증거이며, 배포판의 보안 권고문을 통해 이를 확인할 수 있습니다. 아직 설치되지 않은 RPM 파일에 대해서도 동일한 확인 방법을 적용할 수 있습니다:

rpm -qp kernel-3.10.0-862.11.6.el7.x86_64.rpm –changelog | grep CVE-2017-12190

데비안과 우분투에서는 이에 해당하는 것이 데비안 변경 내역입니다:

zcat /usr/share/doc/openssl/changelog.Debian.gz | grep CVE-2014-0160

Swap in whatever package you’re checking. Most Debian and Ubuntu packages ship this file at /usr/share/doc/<package>/changelog.Debian.gz. Don’t confuse it with changelog.gz, which is normally the upstream changelog. Debian’s own package changes, backports included, are recorded in changelog.Debian.gz. Minimal and container images often strip /usr/share/doc entirely, and in that case apt changelog <package> fetches the changelog from the archive instead.

세 가지 출처를 확인해 보세요. 각 출처는 서로 다른 질문에 대한 답을 제공하기 때문입니다. 배포판 보안 권고문은 특정 CVE를 수정하는 패키지 빌드에 대한 공식 정보이며, Red Hat, Canonical, Debian은 모두 CVE별로 정확한 수정 패키지 버전을 나열한 페이지를 공개하고 있습니다. 설치된 패키지의 메타데이터와 변경 내역은 호스트에 실제로 무엇이 설치되어 있는지 알려주며, 대개 해당 빌드가 해결하는 CVE를 명시하고 있으므로 빠르게 첫 번째 확인을 할 수 있는 자료가 됩니다. 기계 판독 가능한 피드는 도구 사용을 위한 것입니다. OVAL과 같은 형식, 그리고 공급업체가 공개하는 경우 VEX 또는 CSAF 데이터를 활용하면 스캐너가 버전 문자열을 통해 추측하는 대신 배포판 자체의 평가 결과를 사용할 수 있습니다. 사용 중인 스캐너가 이를 지원하는 경우, 해당 기능을 활성화하십시오.

구조적인 해결책은 단순히 업스트림 버전 일치 여부만 신뢰하는 대신, 실제 패치 상태를 확인하는 툴을 사용하는 것입니다.TuxCare Radar 는 이러한 특정 취약점을 해결하기 위해 기존 스캐너와 함께 작동하도록 설계되었습니다. 이 도구는 배포판 백포트, KernelCare의 재부팅 없이 적용되는 패치, ELS 업데이트를 인식하므로, 패치가 적용된 호스트는 ‘패치 완료’ 상태로 보고되며, 누군가 증명을 요청할 경우 관련 증거를 내보낼 수 있습니다.

전문가 팁: 감사관과 조사 결과에 이의를 제기하기 전에, 변경 내역 항목과 배포판 권고 사항 URL을 함께 내보내세요. “CVE가 패키지 변경 내역에 기재되어 있으며, 공급업체 권고 사항에서도 이 빌드를 확인하고 있습니다”라고 말하면 대화가 끝납니다. “제 말 믿으세요, 백포트되었습니다”라고 말하는 것만으로는 대화가 끝나지 않습니다.

누가 수정 사항을 역포트하며, 그 기간은 얼마나 되는가

일반적으로 이 작업을 수행하는 주체는 세 가지로 나뉩니다. 지원되는 안정 버전을 보유한 업스트림 프로젝트, 배포판 보안 팀, 그리고 확장 지원 업체입니다. 이들 간의 업무 인계 과정에서 시스템 환경이 보안 위협에 노출되기 쉽습니다.

업스트림 프로젝트들은 일반적으로 소수의 지원 브랜치를 유지하며, 때로는 수명이 더 긴 LTS(장기 지원) 브랜치를 포함하기도 하고, 해당 브랜치에 수정 사항을 체리픽하여 반영합니다. 브랜치가 지원 기간을 벗어나면 더 이상 지원이 중단됩니다.

디스트로 보안 팀들은 은 지원 기간 동안 배포하는 버전으로 해당 패치를 역포트합니다. 현재 주요 RHEL 릴리스는 풀 지원(Full Support)과 유지보수 지원(Maintenance Support)을 합쳐 총 10년의 지원 기간을 제공하며, Red Hat은 그 이상의 기간에 대한 확장된 지원도 판매하고 있습니다. RHEL 7은 구형 ELS(Extended Life Cycle) 애드온을 적용받고 있는 반면, RHEL 8.10 이후 버전은 Extended Life Cycle Premium으로 전환되었습니다. Ubuntu LTS는 5년간의 표준 보안 유지보수를 제공하며, Ubuntu Pro를 사용하면 최대 10년, 캐노니컬(Canonical)의 유료 레거시(Legacy) 애드온을 이용하면 최대 15년까지 지원 기간을 연장할 수 있습니다.

확장 지원 제공업체 그 이후부터는 해당 업체가 지원을 이어받게 되며, 이는 제품을 구매한 경우에만 해당됩니다. 때로는 원래 공급업체가 직접 운영하는 유료 프로그램일 수도 있고, 때로는 제3자 업체가 담당하기도 합니다.

일정은 확정되었으며, 많은 운영 시스템의 경우 이미 해당 시점이 지났습니다. 다음은 2026년 9월 기준 현황입니다:

보도자료	표준 지원 종료	현재 상태
Python 2.7	2020년 1월 1일	보안 수정 사항 없음
우분투 16.04	2021년 4월 30일 (ESM은 2026년 5월에 종료됨)	2031년 5월까지 유료 레거시 애드온 전용
CentOS Linux 8	2021년 12월 31일	상류 업데이트 없음
PHP 7.4	2022년 11월 28일	보안 수정 사항 없음
우분투 18.04	2023년 5월 31일 (Ubuntu Pro ESM: 2028년 5월까지)	ESM 전용
PHP 8.0	2023년 11월 26일	보안 수정 사항 없음
CentOS 리눅스 7	2024년 6월 30일	상류 업데이트 없음
RHEL 7	2024년 6월 30일 (레드햇 ELS: 2029년 5월까지)	유료 연장 지원만 제공됩니다
우분투 20.04	2025년 5월 31일 (Ubuntu Pro ESM: 2030년 5월까지)	ESM 전용
PostgreSQL 13	2025년 11월 13일	보안 수정 사항 없음
PHP 8.1	2025년 12월 31일	보안 수정 사항 없음

한 번 릴리스가 그 시점을 넘기면, 표준 업데이트 채널을 통한 수정 사항 제공이 중단됩니다. 그 시점 이후의 보안 유지 관리는 원 제조사나 제3자가 제공하는 유료 연장 지원 프로그램에 의존하거나, 사내 유지 관리에 의존하게 됩니다.

TuxCare의 Endless Lifecycle Support(ELS) 이 기간을 포괄합니다. ELS는 운영 체제, 런타임, 언어 생태계 및 애플리케이션에 대한 표준 지원이 종료된 후에도, 이미 사용 중인 동일한 패키지 관리자를 통해 역포트된 보안 수정 사항을 지속적으로 제공합니다.

지원되는 기술의 지원되는 기술 전체 목록을 확인해 보세요를 확인해 보세요. 패치 적용 과정을 더 자세히 알아보려면 이 백서에서 더 자세히 안내하고 있습니다.

백포팅의 과제와 한계

코드베이스는 점차 갈라집니다. 해가 지날수록 오래된 코드 트리는 새로운 코드 트리와 점점 더 달라집니다. 2년 차에는 문제없이 적용되었던 패치도 7년 차가 되면 상당한 재구현이 필요할 수 있으므로, 코드가 오래될수록 작업은 더 어려워지고 더 느려집니다.

테스트 부담도 커집니다. 새로운 백포트는 이미 수년간의 이전 백포트 및 기타 다운스트림 변경 사항이 반영된 코드베이스에 대해 검증되어야 하며, 이러한 변경 사항들은 서로 상호작용할 수 있습니다. 브랜치에 누적된 수정 사항이 많을수록 회귀 테스트해야 할 부분도 늘어납니다.

일부 수정 사항은 아예 직접 백포트할 수 없는 경우도 있습니다. 업스트림에서 새로운 메모리 모델, 재설계된 권한 시스템, 또는 재작성된 파서 등을 통해 아키텍처를 변경함으로써 결함을 해결한 경우, 이를 적용할 수 있는 독립적인 패치가 없을 수도 있습니다. 이 경우 벤더는 다른 방법을 통해 동일한 보안 결과를 달성하는 맞춤형 완화 조치를 취하거나, 해당 브랜치에서는 결함을 수정할 수 없다는 점을 솔직하게 밝힐 수 있습니다. 두 가지 모두 정당한 조치입니다. 침묵은 그렇지 않습니다.

또한 백포트는 정의상 그 범위가 좁습니다. 백포트는 특정 결함만을 해결합니다. 새로운 주요 버전에 포함될 수 있는 전반적인 보안 강화, 더 안전한 기본 설정, 또는 제거된 레거시 코드 경로 등은 제공하지 않습니다. 오래된 릴리스는 유지보수자가 해결한 모든 CVE에 대한 수정 사항을 포함하고 있으면서도, 최신 릴리스에서 이미 제거되거나 재설계된 레거시 코드와 보안상의 한계를 여전히 그대로 유지할 수 있습니다.

백포팅의 품질은 전적으로 패치를 유지보수하는 주체에 달려 있습니다. 이는 배포판이나 확장 지원 공급업체를 선택할 때 고려해야 할 중요한 기준이므로, 백포팅 소요 시간, 회귀 테스트 절차, 그리고 수정 사항이 포팅되지 않을 경우의 대처 방안에 대해 문의해 보십시오. 이러한 답변은 기능 목록보다 훨씬 중요하며, 취약점 관리 방식과 취약점 우선순위 지정 정책 수립에 직접적인 영향을 미칩니다.

TuxCare를 통해 EOL 이후에도 백포트를 지속적으로 제공받으세요

백포팅은 누군가가 이를 계속 수행하는 동안에만 보안을 보장합니다. 표준 지원이 종료되면, 연장 지원이 제공되지 않는 한 일반적인 업데이트 경로를 통해 수정 사항이 더 이상 제공되지 않습니다. 시스템은 계속 작동하고 CVE는 계속해서 보고되지만, 그 시점부터는 보안 유지가 마이그레이션이나 연장 지원 제공업체에 달려 있습니다.

TuxCare의 ‘Endless Lifecycle Support’ 는 표준 업스트림 또는 공급업체의 지원이 종료된 지 오랜 시간이 지난 후에도 EOL(지원 종료) 운영 체제, 런타임, 언어 생태계 및 애플리케이션에 대한 보안 패치를 지속적으로 제공합니다.

귀사의 스택에 대한 보장 범위를 확인해 보세요, 또는 질문을 남겨주세요 특정 지원 종료 릴리스에 대해 문의해 주세요.

자주 묻는 질문