기업용 패치 관리: 전략, 라이프사이클 및 도구

주요 내용

• NIST SP 800-40 개정판 4 패치 적용을 예방적 유지보수로 간주하며, 이는 사업 운영에 따르는 표준 비용으로 간주합니다.
• 상시 가동되는 리눅스 서버 군에서는, 재부팅 창으로 인해 수정 프로그램이 준비된 지 한참이 지나도 패치 적용이 지연될 수 있습니다.
• CISA의 BOD 26-04는 일률적인 KEV 마감 기한을 노출 수준, KEV 상태, 자동화 수준 및 영향도를 기준으로 한 단계별 기한으로 변경했습니다.
• 수명 주기가 끝난 시스템에도 여전히 패치가 필요하며, 연장 지원은 사용자가 원하는 일정에 따라 마이그레이션을 완료할 때까지 해당 시스템을 지원합니다.

패치는 2주 전부터 준비가 완료된 상태입니다. 모두 이 패치를 배포해야 한다는 데 동의하고 있습니다. 하지만 변경 검토 위원회는 목요일까지 다시 열리지 않으며, 승인된 유지보수 시간대는 매월 셋째 주 토요일뿐이고, 실제로 수정이 필요한 클러스터는 가동을 중단할 수 없는 클러스터입니다.

이 글에서는 NIST가 기업용 패치 관리를 위해 제시한 패치 수명 주기, 표준 패치와 긴급 패치의 차이, 기존 접근 방식의 한계, 그리고 실제로 평균 패치 소요 시간(MTTP)을 단축시켜 주는 도구가 무엇인지에 대해 살펴봅니다.

엔터프라이즈 패치 관리란 무엇인가

기업용 패치 관리는 조직이 운영하는 모든 시스템에 대해 패치, 업데이트 및 업그레이드를 식별하고, 우선순위를 정하며, 확보하고, 설치하고, 검증하는 과정을 말합니다. 이 정의는 NIST SP 800-40 개정판 4에서 유래한 것으로, 이 문서는 패치 적용을 업무가 한가해질 때나 처리해야 하는 보안 업무가 아니라 예방적 유지보수이자 사업 운영에 수반되는 표준 비용으로 규정하고 있습니다.

여기서 ‘엔터프라이즈’라는 단어는 실질적인 의미를 담고 있습니다. 노트북 한 대에 패치를 적용하는 것은 단순한 작업입니다. 하지만 4개의 데이터 센터, 3개의 클라우드 환경, 그리고 공장 현장에 분산된 8,000대의 리눅스와 윈도우 혼합 시스템에 패치를 적용하는 것은 계획 수립의 문제입니다. 바로 이 때문에 NIST의 가이드가 도구보다는 계획 수립에 중점을 두고 있는 것입니다. 이 가이드의 전체 제목은 말 그대로 “엔터프라이즈 패치 관리 계획 수립 가이드(Guide to Enterprise Patch Management Planning)”로 시작합니다.

또한 패치 관리를 사람들이 흔히 이와 묶어 생각하는 몇 가지 관행과 구분하는 데 도움이 됩니다:

연습	이 질문이 다루는 내용	출력
패치 관리	수정 프로그램이 설치되어 있고, 여전히 설치된 상태인가요?	배포 및 검증된 패치
취약점 관리	무엇이 드러났으며, 그 정도는 어느 정도이고, 우리는 이에 대해 어떻게 대처해야 할까요?	위험 관련 의사결정, 시정 조치 대기열
구성 관리	시스템이 승인된 상태인가요?	강제 기준선, 드리프트 경고
엔드포인트 관리	기기에는 무엇이 들어 있으며, 누가 이를 관리하나요?	재고, 정책, 소프트웨어 배포

이 세 가지 용어는 종종 혼용되지만, 그 차이를 명확히 구분해 두는 것이 좋습니다. ‘패치(patch)’는 이미 설치된 소프트웨어의 문제를 수정하는 것이고, ‘업데이트(update)’는 소프트웨어를 최신 릴리스로 전환하는 것이며, ‘업그레이드(upgrade)’는 대개 새로운 버전으로의 대대적인 전환을 의미합니다. 수정 사항에 대해 간단한 테스트만 진행해야 할지, 유지보수 기간을 확보해야 할지, 아니면 전면적인 마이그레이션 계획을 세워야 할지 결정할 때 이러한 차이는 중요합니다.

기업 패치 관리 라이프사이클의 주요 단계

NIST는 패치 적용 주기를 크게 세 단계로 나눕니다. 즉, 취약점을 파악하고, 대응 방안을 계획한 다음, 수정 조치를 준비·적용·검증·모니터링하여 해당 대응을 실행하는 단계입니다. 실제로 운영되는 패치 팀의 경우, 이는 대개 다섯 가지 실질적인 단계로 세분화됩니다.

1. 자산 및 소프트웨어 현황 조사

발견하지 못한 것은 패치할 수 없습니다. NIST는 단순히 호스트명 목록을 넘어, 각 자산이 실행하는 패키지와 라이브러리 수준까지 세분화된 자산 목록을 작성할 것을 촉구합니다. 또한 취약점 스캔을 통해 매월 또는 분기마다 자산 목록을 갱신하던 기존의 관행은 이제 버려야 한다고 밝히고 있으며, 컨테이너와 자동 확장 그룹이 그 이유를 보여줍니다. 이러한 요소들은 주기적인 스냅샷으로는 포착하기 어려울 정도로 너무 빠르게 변화하기 때문에, 자산 탐지 과정은 자동화되어야 하며 거의 지속적으로 이루어져야 합니다.

2. 위험 우선순위 지정

A CVSS 점수 만으로는 무엇을 먼저 수정해야 할지 알 수 없습니다. 아무도 접근할 수 없는 시스템에 존재하는 9.8점짜리 취약점보다, 인터넷에 노출된 시스템에서 실제로 악용되고 있는 낮은 점수의 취약점이 더 중요합니다. CISA의 ‘알려진 악용 취약점’ 카탈로그 는 실제 환경에서 악용되고 있는 것으로 알려진 취약점에 대한 가장 유용한 무료 정보원 중 하나입니다. CISA는 활발한 악용 증거가 확인된 경우에만 CVE를 등록하기 때문입니다. 심각도만으로 처리 순서를 정하기 전에 이 목록을 확인하십시오.

3. 수집, 검증 및 테스트

NIST의 사전 준비 작업은 패치를 확보하고, 정품이며 변조되지 않았음을 확인한 뒤, 테스트를 수행하고, 적용 일정을 잡는 것으로 요약됩니다. 검증 단계는 가장 쉽게 간과되기 쉬운 단계입니다. 해킹당한 미러 사이트에서 가져오거나 전송 과정에서 변조된 패치도 겉보기에는 완벽하게 정상적으로 보일 수 있으므로, 어떤 것도 설치하기 전에 서명 및 체크섬 검사가 자동으로 실행되어야 합니다.

주의: 정기적인 패치 적용을 미루면 나중에 긴급 패치를 적용하기가 더 어려워집니다. NIST는 새로운 패치가 종종 이전 패치가 먼저 설치되어 있어야만 적용될 수 있다고 지적합니다. 따라서 패치 적용 주기가 3회나 뒤처진 시스템의 경우, 긴급 패치를 적용하기 전에 먼저 뒤처진 패치를 모두 적용해야 할 수도 있습니다.

4. 배포

먼저 소규모 그룹에 적용한 다음, 더 넓은 범위로 확대하고, 마지막으로 모든 사용자에게 적용하세요. NIST는 비상 상황에서도 이 ‘카나리아 테스트’ 단계를 유지하되, 소요 시간을 몇 분에서 몇 시간 사이로 단축할 것을 권장합니다. 이 단계에서 종종 작업이 지연되곤 합니다. 커널 수정 사항은 일반적으로 재부팅이 필요하고, 업데이트된 공유 라이브러리를 사용하는 프로세스는 다시 시작해야 하는데, 이 두 가지 모두 지원 티켓 처리, 일정 조율, 그리고 이를 총괄할 담당자가 필요하기 때문입니다.

5. 검증 및 모니터링

‘검증’이란 패치가 실제로 설치되어 적용되었는지 확인하는 것을 의미합니다. ‘모니터링’이란 다음 달에도 패치가 여전히 적용되어 있는지 확인하는 것을 의미합니다. 오래된 이미지로 시스템을 재구축하거나 이전 스냅샷으로 롤백할 경우, 눈에 띄지 않게 취약점이 다시 발생할 수 있기 때문입니다. 이 두 가지는 서로 다른 작업이며, 이를 통해 감사관이 요청할 증거의 상당 부분이 확보됩니다.

일반 패치 적용 절차 대 긴급 패치 적용 절차

NIST와 CISA는 모두 ‘모든 취약점이 동일한 시급성을 요구하는 것은 아니다’라는 동일한 기본 원칙에 따라 운영됩니다. NIST의 지침서는 네 가지 위험 대응 시나리오(정기 패치, 긴급 패치, 긴급 완화 조치, 패치 불가능한 자산)를 제시하며, 각 자산에 대해 별도의 대응 계획을 갖춘 유지 관리 그룹에 배정할 것을 요구합니다.

표준 패치 적용

정기 패치 작업은 자산 유형별로 정해진 일정에 따라 진행되며, 여기에는 테스트, 승인 및 고정된 작업 기간이 포함됩니다. NIST는 자산이 실제로 필요로 하는 사항, 예를 들어 허용 가능한 가동 중단 시간, 이미 적용된 보안 통제 조치, 침해 발생 시 예상되는 피해 규모 등을 기준으로 자산을 그룹화할 것을 권장합니다. 아래의 주기는 예시일 뿐, 표준은 아닙니다. NIST는 실제 일정을 전적으로 조직의 재량에 맡기고 있으며, 귀사의 일정은 노출 수준, 공급업체 지침, 그리고 귀사가 감수할 수 있는 위험 수준을 고려하여 수립해야 합니다.

자산군	리듬 예시	정전 내성	시험 깊이
인터넷에 노출된 웹 및 앱 서버	7~14일마다	점진적인 전환, 가동 중단 시간 거의 없음	자동화된 연기 테스트 및 회귀 테스트
내부 애플리케이션 서버	월간	예정된 시간대	공통 구성요소에 대한 회귀 분석
데이터베이스 및 상태 유지 클러스터	매월 ~ 분기별	엄격한 창, 장애 조치 필요	전체 회귀 분석
최종 사용자용 노트북	매주 ~ 매달	관용적인	파일럿 링만
OT 및 임베디드 기기	공급업체가 주관하며, 대개 매년 개최됨	매우 제한적	공급업체 인증
연장 지원 대상인 EOL 시스템	공급업체 패치 출시 주기	다르다	공급업체에서 테스트를 거친 백포트

정기적인 패치 적용은 업데이트 기간에 정확히 맞지 않는 자산의 경우 별다른 오류 메시지 없이 실패하는 경향이 있습니다. 24시간 내내 가동되는 시스템의 커널 업데이트는 주기마다 계속 미뤄지다가, 결국 이를 건너뛰는 것이 비공식적인 정책이 되어버립니다. 재부팅이 필요 없는 커널 패치 적용 은 이러한 문제를 우회하는 대신 근본적으로 해결하므로, Red Hat Enterprise Linux 및 기타 상시 가동되는 시스템 군에 널리 적용되는 이유입니다.

긴급 패치

긴급 패치 적용은 별개의 프로세스가 아닙니다. NIST의 지침에 따르면, 카나리아 그룹을 포함하여 일상적인 패치 적용과 동일한 일반적인 접근 방식을 훨씬 더 적극적인 일정에 따라 적용해야 합니다.

비상 모드로 전환하는 기준은 사전에 정책에 명시되어야 합니다. 일반적인 사례로는 CISA의 KEV 목록에 등재된 취약점, 실제 환경에서 악용이 확인된 경우, 자동화된 공격이 가능한 인터넷 연결 시스템, 또는 진행 중인 보안 사고 등이 있습니다. 커널 버그, 아파치 문제, 그리고 OpenSSL 결함 는 이 트랙에 포함되는 전형적인 사례들입니다.

2026년에 변경된 사항: BOD 22-01에 따라, 연방 민간 기관은 KEV 목록에 포함된 문제를 해결할 때 기본적으로 2주의 기한이 주어졌으며, CVE ID가 2021년 이전에 할당된 경우에는 6개월의 기한이 주어졌습니다. 이는 2026년 6월 10일, CISA가 이를 다음과 같이 대체하면서 변경되었습니다. BOD 26-04로 대체하면서 변경되었습니다. 새로운 지침은 일률적인 마감 기한 대신 네 가지 요소를 고려합니다. 즉, 해당 자산이 대외적으로 노출되었는지, CVE가 KEV 목록에 포함되어 있는지, 공격자가 익스플로잇을 자동화할 수 있는지, 그리고 익스플로잇에 성공했을 때 공격자가 어느 정도의 통제권을 얻게 되는지(CISA는 이를 ‘기술적 영향’이라 부름)입니다. 가장 위험한 조합의 경우 3일의 기간이 주어지며, 최고 위험 등급의 KEV 조합은 시스템이 이미 침해되었는지 확인하기 위한 포렌식 선별 조사도 필수입니다. 그 외의 조합에는 14일 또는 60일의 기간이 적용되며, 어떤 기준에도 해당하지 않는 사례는 다음 예정된 업그레이드 시까지 기다릴 수 있습니다. 전체 지침에는 총 16가지 조합이 모두 명시되어 있습니다.

아직 패치가 제공되지 않는 경우, NIST는 이에 대한 별도의 대책도 마련해 두었습니다. 바로 ‘긴급 완화 조치’로, 실제 수정본이 출시될 때까지 시간을 벌 수 있게 해줍니다.

상시 가동 시스템의 경우, 수정안이 마련되고 테스트를 마쳤음에도 불구하고 재부팅 승인 절차 때문에 긴급 패치 작업이 지연될 수 있습니다. 클러스터형 데이터베이스에서 커널 버그가 발생하면, 해당 노드에서 트래픽을 분산시키고, 페일오버를 수행하며, 시스템을 재시작한 뒤 모든 것이 정상적으로 작동하는지 다시 확인해야 할 수 있습니다. 이러한 일련의 절차에는 일반적인 긴급 변경 프로세스에서 다루는 것 이상의 승인이 필요한 경우가 많습니다. 각 시스템 그룹에 대한 긴급 재부팅 시간대를 사전에 승인해 두는 것이 도움이 됩니다. 지원되는 경우, 재부팅 없이 패치 적용을 통해 커널 및 라이브러리 수정 시 재부팅 단계를 완전히 생략할 수 있습니다.

기업 환경에서 기존 패치 관리 방식이 한계에 부딪히는 이유

기존의 패치 관리 방식은 필요할 때마다 시스템을 오프라인 상태로 전환할 수 있다고 가정했습니다. 하지만 기업 환경은 그렇게 운영되지 않으며, 이로 인해 세 가지 문제가 계속해서 발생하고 있습니다.

1. 유지보수 시간대에는 항상 여유 시간이 부족하다

한 지역 보험사가 1,200대의 RHEL 서버를 운영 중인데, 작업을 수행할 수 있는 시간이 한 달에 딱 4시간뿐이라고 상상해 보세요. 커널 업데이트, 데이터베이스 패치, 펌웨어 업데이트, 새로운 애플리케이션 릴리스 등이 모두 이 4시간을 차지하려고 경쟁하고, 이 시간 내에 처리되지 못한 작업은 30일을 더 기다려야 합니다. 여러분이 직접 수치를 대입해 보더라도 질문은 똑같습니다. 이번 달에는 어떤 작업이 뒤로 밀리게 될까요?

The 2026년 버라이즌 DBIR 에 따르면, 중대한 취약점을 완전히 해결하는 데 걸리는 시간의 중앙값이 전년도의 32일에서 43일로 늘어났습니다. 버라이즌은 CISA의 KEV 목록에 포함된 취약점을 중대한 취약점으로 간주하며, 이 중 완전히 해결된 비율은 38%에서 26%로 감소했습니다. 이러한 현상의 일부는 취약점 발생 건수 증가로 설명할 수 있는데, 조직당 패치해야 할 취약점의 중앙값이 전년 대비 50% 증가했기 때문이다. 나머지 절반은 처리 능력 문제다. 많은 경우 패치는 이미 존재하지만, 이를 테스트하고 배포하며 검증할 여유를 확보하는 것이 어려운 실정이다.

2. 일부 소프트웨어는 더 이상 패치를 제공받지 않게 된다

배포판이나 런타임의 지원 기간이 종료되면, 새로운 CVE가 계속해서 발견되더라도 공급업체의 보안 수정 제공은 중단됩니다. NIST는 이를 단호하게 지적합니다. 소프트웨어의 지원 기간이 종료되었기 때문에 패치가 영원히 출시되지 않을 수도 있다는 것입니다. 여전히 CentOS 7 을 여전히 사용 중인 사람이라면 그 상황이 어떤지 정확히 알고 있을 것이며, RHEL 7 를 사용 중이면서 확장 지원 계약이 없는 사용자들도 마찬가지입니다. 스캐너는 매달 같은 CVE를 계속 표시하지만, 수정 사항 열은 여전히 비어 있을 뿐입니다.

일반적인 선택지는 기존 버전에서 마이그레이션하거나, 자체 일정에 맞춰 마이그레이션을 계획하는 동안 평소 사용하던 패키지 관리자를 통해 패치를 계속 받아볼 수 있도록 하는 유료 연장 지원 서비스를 이용하는 것입니다.

3. 팀들은 불완전한 정보를 바탕으로 우선순위를 정하고 있다

여전히 많은 팀이 스캐너 보고서의 CVSS 점수를 기준으로 처리 대기자열을 정렬하고 있습니다. 하지만 이 수치는 해당 취약점이 실제로 악용되고 있는지, 소프트웨어의 지원 기간이 이미 만료되었는지, 심지어 취약한 코드가 여전히 메모리에 로드되어 있는지 여부를 전혀 반영하지 못합니다. 이 수치만으로 정렬하면 실제 위험을 반영하지 않는 숫자에 따라 순위가 매겨진 수천 개의 항목으로 구성된 처리 대기자열이 만들어지게 됩니다. 

맨디언트의 ‘2026 M-Trends’ 보고서 에 따르면, 익스플로잇이 6년 연속으로 가장 흔한 초기 감염 경로로 나타났으며, 전체 침입 사례의 32%를 차지했습니다. 또한 맨디언트는 익스플로잇까지 걸리는 평균 시간을 -7일로 추산했는데, 이는 패치가 출시되기도 전에 이미 익스플로잇이 일상적으로 발생하고 있음을 의미합니다. 익스플로잇 상태, 노출 여부, 실제로 실행 중인 프로그램 등 더 풍부한 맥락을 바탕으로 구축된 대기열은 실질적인 조치로 이어질 수 있는 정보로 변모합니다.

이 세 가지 문제는 서로 악순환을 일으킵니다. 우선순위 지정 대기열이 제대로 관리되지 않으면 잘못된 작업이 먼저 처리됩니다. 극히 짧은 유지보수 기간에는 그 잘못된 대기열의 일부만 처리할 여유가 있을 뿐입니다. 또한 수명 종료 시스템에 대한 문제점은 공급업체에서 패치를 제공하지 않기 때문에 매달 그대로 방치됩니다. 미처리 작업이 쌓이고, 새로운 패치는 종종 이전 패치에 의존하기 때문에 다음 달의 유지보수 기간에 드는 비용은 이번 달보다 더 많이 듭니다. 인력이 충분히 갖춰진 팀이라 해도 결국 문제 해결에 몇 주가 걸리게 되는 이유는 쉽게 알 수 있습니다.

현대 기업을 위한 패치 관리 모범 사례

다음에 설명할 내용의 대부분은 이미 수행하고 있는 작업의 순서를 조정하는 방법에 관한 것이며, 각 변경 사항은 앞서 언급한 병목 현상 중 하나를 해결하기 위한 것입니다. 첫 번째 변경 사항은 대개 도구 추가를 의미합니다. 재부팅 없이 실행 중인 시스템에 패치를 적용하는 것은 프로세스 변경만으로는 해결할 수 없는 문제이기 때문입니다.

1. 재부팅을 핵심 공정에서 제외하기

커널 및 라이브러리 수정과 관련하여 패치 적용 속도를 높이기 위해 취할 수 있는 가장 중요한 조치 중 하나는 수정 사항 적용과 이를 위한 시스템 중단 시간 예정을 분리하는 것입니다. 재부팅 없이 패치 적용(라이브 패치라고도 함)은 수정된 코드를 실행 중인 커널이나 메모리 내의 해당 라이브러리 코드에 직접 적용하므로, 다음 주 토요일 유지보수 시간을 기다릴 필요 없이 단 몇 분 만에 수정 사항이 적용될 수 있습니다.

TuxCare의 KernelCare는 는 70개 이상의 리눅스 배포판 버전에 걸친 커널 CVE에 대해 이 기능을 제공하며, LibCare는 는 glibc와 OpenSSL에 대해서도, 이에 의존하는 서비스를 재시작하지 않고 동일한 기능을 제공합니다. 여러 배포판을 혼합하여 운영 중인 환경이라면 이러한 폭넓은 지원이 중요합니다. 공급업체가 제공하는 라이브 패치 서비스는 일반적으로 자사 배포판에 묶여 있기 때문에, 여러 배포판을 혼합하여 사용하는 환경에서는 배포판마다 별도의 도구를 번갈아 사용해야 하는 상황이 발생할 수 있습니다.

실무상: OCLC 약 1만 대의 시스템을 운영하고 있으며, 대부분은 RHEL이고 소수의 CentOS 시스템이 포함되어 있습니다. 재부팅 없이 패치를 적용하는 방식으로 전환한 후, OCLC는 연간 73건이던 패치 관련 서비스 중단 건수가 0건으로 줄어들었으며, CVE 패치에 소요되는 시간을 72% 단축하고, 취약점 노출 기간을 115일에서 12일로 단축했다고 보고했습니다.

재부팅을 예약하기 전에, 재부팅이 실제로 필요한지 확인해 보는 것이 좋습니다. RHEL 계열 시스템에서는 다음 명령어를 실행하면 새로운 커널이나 glibc와 같은 설치된 업데이트로 인해 전체 재부팅이 필요한지 여부를 확인할 수 있습니다:

재시작 필요 -r

데비안과 우분투는 /run/reboot-required 파일을 통해 동일한 상황을 알립니다. 한 가지 주의할 점은, 두 검사 모두 실시간 패치를 고려하지 않기 때문에 KernelCare가 이미 패치를 적용한 호스트라도 재부팅이 필요하다는 표시가 나타날 수 있습니다. 실제로 재부팅이 필요한 사항을 파악한 후에는, 나머지 워크플로우에서 자동화의 이점을 누릴 수 있습니다.

2. 전체 라이프사이클 자동화

많은 팀이 패치를 실제로 배포하는 단계만 자동화하고, 인벤토리 관리, 유효성 검사, 검증 단계는 수동으로 처리합니다. 즉, 프로세스 중 자동화된 유일한 단계가 자동화되지 않은 다른 단계에서 나온 오래된 정보를 바탕으로 작동하는 경우가 많습니다. 탐지, 서명 유효성 검사, 카나리아 배포, 그리고 패치가 실제로 적용되었는지 확인하는 작업은 모두 동일한 파이프라인에 포함되어야 합니다.

3. 클라우드 및 온프레미스 환경을 동일한 정책 하에 통합

클라우드와 온프레미스에 서로 다른 패치 정책을 적용하면 증거 자료가 두 가지로 나뉘는 경향이 있으며, 이로 인해 감사가 필요 이상으로 어려워집니다. 자동 확장 그룹은 이 부분에서 흔히 간과되는 사각지대입니다. 2개월 전 이미지로 생성된 인스턴스는 부팅되는 순간부터 지난 2개월간의 보안 패치가 누락될 수 있으므로, 이러한 격차를 해소하려면 패치된 기본 이미지와 지속적인 런타임 패치 적용이 모두 필요합니다. 해결책은 두 환경을 아우르는 유지보수 그룹을 정의하고, 해당 그룹에 동일한 우선순위 규칙, 검증 요건 및 보고 체계를 적용하는 것입니다.

TuxCare의 엔터프라이즈 패치 관리 솔루션

위에서 언급한 병목 현상과 모범 사례의 모든 내용은 동일한 결론을 가리킵니다. 즉, 가장 큰 성과는 제약 조건을 우회하여 일정을 조정하는 것이 아니라, 그 제약 조건을 제거함으로써 얻을 수 있다는 것입니다. TuxCare의 제품 라인은 바로 이러한 개념을 바탕으로 구축되었으며, 각 제품은 위 섹션에서 다룬 서로 다른 문제점을 해결합니다.

KernelCare 는 배포 병목 현상을 직접 해결합니다. 이 솔루션은 재부팅 없이 실행 중인 시스템에 커널 보안 패치를 자동으로 배포하며, 단일 에이전트로 RHEL, CentOS, Ubuntu, Debian, Oracle Linux, Amazon Linux, CloudLinux 등 70개 이상의 배포판 버전을 지원합니다. 이는 패치 적용 자체보다 재부팅 승인을 받는 데 더 오랜 시간이 소요되는 모든 환경에서, 특히 24시간 연중무휴로 운영되는 워크로드와 클러스터형 데이터베이스에 가장 중요한 요소입니다. 이 솔루션은 Windows 시스템이나 타사 Windows 소프트웨어를 위해 설계되지 않았으므로, 대부분의 혼합 환경에서는 해당 측면을 처리하기 위해 별도의 도구를 함께 사용합니다.

LibCare 는 이 개념을 공유 라이브러리로 확장합니다. 이 도구는 glibc와 OpenSSL에 의존하는 프로세스를 재시작하지 않고도 실행 중인 프로세스 내부의 glibc와 OpenSSL에 패치를 적용함으로써, KernelCare가 커널 수준에서 해결하는 것과 동일한 종류의 사용자 공간 코드 재시작 간극을 해소합니다.

무한 라이프사이클 지원 는 도입 과정의 병목 현상을 해결합니다. 배포판이나 런타임이 지원 종료(End of Life) 단계에 접어들면, 더 이상 공급업체에서 제공하는 패치를 확보할 수 없게 됩니다. ELS는 리눅스 운영 체제, 언어 런타임, 라이브러리, 애플리케이션 등 전체 스택에 걸쳐 지원이 종료된 오픈소스 버전에 대한 보안 패치를 지속적으로 제공하므로, 팀은 패치가 적용되지 않은 시스템을 계속 사용할지, 아니면 서둘러 마이그레이션을 진행할지 선택해야 하는 곤란한 상황에 처하지 않아도 됩니다.

SecureChain 는 운영 체제(OS) 자체보다는 코드베이스가 끌어오는 오픈소스 종속성을 대상으로, 더 상류 단계에서 작동합니다. 이 솔루션은 공개 레지스트리 대신 엄선된 저장소를 활용하며, 여기서 JavaScript, Python, Java, Go, Rust, PHP 등 다양한 언어의 패키지를 소스 코드부터 재컴파일하고, 악성코드를 검사하며, 새로운 CVE가 발견될 때마다 SLA에 따라 패치를 적용합니다. 이는 OS 수준의 패치로는 결코 해결할 수 없는 공급망 위험입니다.

이 네 가지 제품을 종합하면, 이 기사에서 살펴본 문제점들을 해결할 수 있습니다. TuxCare는 현재까지 오픈 소스 소프트웨어에서 14,000건 이상의 취약점을 수정했습니다.

일정부터 시작하세요

대규모 패치 작업이 어려운 주된 이유는 기술적인 측면보다는 운영상의 문제에 기인하는 경우가 많습니다. 수정 패치는 준비되어 있지만, 유지보수 시간대는 확보되지 않은 상태입니다. 재부팅을 핵심 프로세스에서 제외하고, 지원 종료(EOL) 시스템을 노출된 상태로 두지 않고 패치를 적용하며, 실제로 악용되고 있는 취약점을 기준으로 우선순위를 정하면 나머지 작업들은 훨씬 더 관리하기 쉬워집니다.

TuxCare TuxCare는 사용자가 기존 워크플로우를 그대로 유지한 채 패치 작업을 더 빨리 하도록 요구하는 대신, 스케줄링 문제 중 특정 부분을 해결하는 데 초점을 맞춰 각 도구를 개발합니다.

아직 자신의 프로그램에서 가장 큰 취약점이 어디에 있는지 파악 중이라면, 다음 가이드를 참고해 보세요. Linux 패치 관리 가 좋은 출발점이 될 것입니다. 이미 파악하셨고, 귀사의 환경에 맞춰 산정된 견적을 원하신다면, 당사의 가격 안내 페이지를 확인해 보세요.

자주 묻는 질문