패치되지 않은 취약점의 위험, 원인 및 해결 방법

주요 내용

• 패치가 적용되지 않은 취약점의 경우, 수정 프로그램이 이미 존재하지만 아직 적용되지 않은 상태입니다.
• 맨디언트의 ‘M-Trends 2026’ 에 따르면, 공격 성공까지 걸리는 평균 시간은 마이너스 7일로, 공격자들은 평균적으로 패치 적용보다 먼저 취약점을 악용하는 것으로 나타났다.
• The 2026년 버라이즌 DBIR 에 따르면, 탐지된 KEV 취약점 중 26%만이 완전히 해결되었으며, 해결까지 걸린 기간의 중앙값은 43일인 것으로 나타났습니다.

대부분의 보안 팀들은 는 모두 비슷한 미처리 과제를 안고 있습니다. 여기에는 선별, 티켓 발행, 일정 배정이 완료되었으나, 유지보수 기간이 분기 말 결산 시기와 겹쳐 조용히 미뤄진 CVE들이 포함되어 있습니다. 이들은 패치되지 않은 취약점이며, 이를 악용하는 것이 공격자들이 초기 접근 권한을 획득하는 가장 주요한 알려진 방법이 되었습니다.

중요한 격차는 패치가 존재하는 시점과 그 패치가 실제로 운영 환경에서 실행되는 시점 사이에 존재합니다. 이 글의 나머지 부분에서는 그 격차가 왜 계속 유지되는지, 그리고 이를 어떻게 해소할 수 있는지 살펴보겠습니다.

패치되지 않은 취약점으로 간주되는 것은 무엇인가

패치되지 않은 취약점이란, 수정 방법이 이미 존재하지만 해당 수정 사항이 적용되지 않은 시스템에서 발생하는 알려진 결함을 말합니다. 여기에는 세 가지 필수 요소가 모두 포함됩니다: 알려진 결함, 이용 가능한 수정 방법, 그리고 아직 해당 수정 사항이 적용되지 않은 시스템입니다.

바로 그 중간 부분, 즉 적용 가능한 수정 사항이야말로 이 항목을 양쪽의 항목과 구별 짓는 요소입니다.

제로데이 취약점은 방어 측이 대응할 충분한 기회를 갖기도 전에, 대개 취약점이 공개되거나 패치가 출시되기 전에 악용됩니다. 수정 패치가 배포되기 전까지는 완화 조치만이 유일한 해결책입니다. 다음은 제로데이 공격 가 작동하는지에 대한 분석은 바로 이러한 사례를 다룹니다.

수명이 다한 소프트웨어 는 또 다른 사례입니다. 수정 패치를 적용할 수는 있지만, 원래 공급업체는 더 이상 패치를 제공하지 않습니다. CentOS 7, PostgreSQL 13, EOL PHP 브랜치 – 실제 CVE, 실제 취약점, 업스트림 지원 없음.

이론적으로 보면, 패치가 적용되지 않은 이 취약점은 세 가지 중 가장 피하기 쉬운 문제입니다. 이미 수정 패치가 존재하며, 대개 무료로 제공되기 때문입니다. 하지만 실제로는 무료 패치라도 테스트 시간과 유지보수 기간이 소요되는데, 이것이 바로 이 글에서 다루고자 하는 내용의 절반을 차지합니다.

취약점 공개부터 악용까지의 시간 간격은 대부분의 패치 주기가 가정하는 것보다 더 짧으며, 이 과정이 항상 순서대로 진행되는 것은 아닙니다.

스테이지	그 일이 일어날 때	무슨 일이 일어나고 있나요?
CVE 공개, 패치 배포	같은 날, 혹은 몇 주 간격으로	중요한 RCE의 경우 종종 함께 사용됨
공개 PoC 또는 익스플로잇 코드	공개 전부터 공개 후 몇 주 후까지	GitHub, 익스플로잇 프레임워크, 연구 보고서
대규모 인터넷 스캔	작동하는 PoC가 나온 지 몇 시간 후	공격자들은 대규모로 노출된 인스턴스의 지문을 파악한다
적극적인 채굴, KEV 상장	공개 전에 시작할 수 있으며, CISA의 확인 후에 KEV 상장이 이루어집니다.	이제 확인된, 실제로 활용되고 있는 공격 경로

중대도와 악용 가능성은 서로 다른 지표입니다. 외부에 노출되지 않은 서비스의 CVSS 9.8은 에지에 존재하는 CVSS 6.5보다 위험도가 낮을 수 있습니다. 다음 안내서를 참조하십시오. CVSS v4.0의 변경 사항에 대한 당사의 안내서를 참조하십시오.

패치되지 않은 취약점이 초래하는 실제 비용

먼저 더 이상 반복해서는 안 될 이 숫자부터 살펴보겠습니다. “패치되지 않은 취약점이 보안 침해 사고의 60%를 유발한다.” 이 수치는 2019년 ServiceNow를 위해 Ponemon Institute가 실시한 설문조사에서 비롯된 것으로, 더 이상 업계 전반의 최신 수치로 인용되어서는 안 됩니다.

최신 데이터는 더 뚜렷한 사실을 보여줍니다. 2026년 버라이즌 DBIR에 따르면, 정보 유출 사고의 31%가 취약점 악용으로 시작되었으며, 이는 전년의 20%에서 증가한 수치입니다. 이로 인해 보고서 역사상 처음으로 버라이즌 데이터셋에서 가장 주요한 초기 접근 경로로 기록되었습니다. 데이터 유출로 인한 비용도 증가했습니다. IBM의 2026년 ‘데이터 유출 비용 보고서’에 따르면 전 세계 평균 침해 사고 비용을 499만 달러로 추산했으며, 이는 사상 최고치입니다.

랜섬웨어는 예외적인 경우입니다. 소포스(Sophos)의 ‘2026년 랜섬웨어 현황’ 설문조사에 따르면, 랜섬웨어 피해자 중 공격의 원인을 악용된 취약점으로 지목한 비율은 18%에 불과했으며. 이는 1년 전 32%에서 감소한 수치이며, 악성 이메일과 피싱이 주요 원인으로 부상했기 때문이다. 패치 적용은 여전히 중요하다. 다만 더 이상 유일한 침입 경로는 아니라는 점이다.

이러한 피해는 규제 위험, 랜섬웨어 갈취, 가동 중단, 규정 준수 위반 사항, 그리고 이 모든 것보다 더 오래 지속되는 평판 손상으로 나타납니다. 패치를 적용하지 않을 경우 발생하는 중요 CVE에 대한 패치를 적용하지 않을 경우 발생하는 실제 비용에 대한 분석 에 대한 분석에서는 각 항목에 대해 더 깊이 다루고 있습니다.

세 가지 침해 사례를 통해 이러한 상황이 어떻게 전개되는지 알 수 있는데, 각 사례마다 사정이 조금씩 다릅니다.

사건	CVE	패치 제공됨	익스플로잇	폴아웃
에퀴팩스	CVE-2017-5638 (Apache Struts 2)	3월 7, 2017	2017년 3월 10일 포털을 스캔한 결과 취약점이 발견되었으며, 5월 13일부터 개인 데이터가 유출되었고, 7월 29일에 이를 탐지했습니다.	1억 4,700만 명에 더해 FTC/CFPB/주 정부와의 합의금 최소 5억 7,500만 달러
MOVEit Transfer	34362	5월 31, 2023	2023년 5월 27일부터 28일까지 Cl0p 취약점을 이용한 대규모 제로데이 공격이 발생했으며, 패치가 적용되지 않은 서버들은 그 후 몇 주 동안 계속해서 공격을 받았습니다.	2,773개 기관, 약 9,580만 명 (Emsisoft)
Log4Shell	44228	Log4j 2.15.0, 2021년 12월 10일, 이후 며칠 뒤 추가 수정 사항이 적용됨	2021년 12월 1일 스캔 결과, 취약점이 공개된 지 몇 시간 만에 대규모 악용 사례 발생	2025년 한 해에만 취약점이 있는 Log4j 다운로드 건수가 약 4,000만 건에 달하며, 이는 해당 연도 전체 다운로드 건수의 약 13%에 해당합니다 (Sonatype)

에퀴팩스(Equifax)는 패치가 적용되지 않은 취약점이 명확히 드러난 사례입니다. 수정 패치는 3월 7일에 배포되었으나, 공격자들은 3일 후부터 포털을 탐색하기 시작했고, 패치가 공개된 지 67일 만에 대규모 데이터 유출이 발생했습니다. MOVEit과 Log4Shell은 제로데이 취약점으로 시작되었으나, 수정 패치가 나온 후에도 많은 설치 환경에서 여전히 취약한 빌드를 계속 사용함에 따라 거의 즉시 패치가 적용되지 않은 취약점 사례로 전환되었습니다.

취약점이 왜 패치되지 않는가 (팀들이 거의 인정하지 않는 이유들)

이들 각각은 합리적이고 국지적인 결정이지만, 조직 전체 차원에서 보면 비합리적인 결과를 초래합니다.

이유	어떤 모습인지	무엇이 그것을 제거하나요?
가동 중단에 대한 우려	커널 CVE 재부팅이 필요하며, 호스트는 상태 유지형이고 장애 조치 기능이 없습니다	재부팅 없는 커널 패치 적용
지원 종료(EOL) 소프트웨어, 업스트림 패치 없음	CentOS 7 호스트에서, 더 새로운 버전에서는 빌드되지 않는 애플리케이션을 실행 중입니다.	공급업체가 지원하는 연장 지원 또는 자금 지원이 제공되는 마이그레이션 일정
결코 적용되지 않는 패치들	자동화 성공률은 98%로 보고된다. 나머지 2%는 아슬아슬한 상황이다.	패치 툴링과 독립적 스캔 간의 조정
미확인 자산	2021년 스테이징 VM, 계약업체의 컨테이너, 잊혀진 서브도메인	지속적이고 상시적인 탐색
테스트에 드는 비용	아무도 완전히 이해하지 못하는 모놀리식 아키텍처를 기준으로 모든 패치에 대해 회귀 테스트를 수행한다	위험 등급별 테스트를 실시하며, 중요한 보안 수정 사항은 단계별 배포를 통해 신속히 적용합니다.
트라이아지 시간보다 많은 CVE	2025년에 48,185건의 CVE가 공개되었습니다. 세 사람이 그 수치를 다 읽을 수는 없습니다.	악용 가능성 기반 필터링

 단순히 데이터의 양만으로도 충분한 이유가 됩니다. 보안 연구원 제리 갬블린이 2025년 CVE 데이터를 분석한 결과 에 따르면 공개된 기록은 48,185건으로, 하루 평균 약 132건에 달했으며, FIRST의 EPSS 페이지에 따르면 에 따르면, 공개된 CVE 중 특정 30일 기간 내에 악용되는 비율은 한 자릿수 초반에 불과합니다. 대기 중인 CVE 대부분은 이번 달에 공격자의 표적이 되지 않을 것입니다. 어려운 점은 그 중 어떤 극히 일부가 공격 대상이 될지 파악하는 것입니다.

그리고 누적 문제도 있습니다. 미뤄진 패치는 미뤄진 리팩토링이 기술적 부채로 쌓이는 것과 마찬가지로 보안 부채로 누적되며, 그 대가는 보안 사고로 나타납니다. 스캐너의 오탐은 상황을 더욱 악화시킵니다. 왜냐하면 오탐을 추적하느라 몇 주를 허비한 팀은 실제 보안 위협이 발생했을 때 필요한 신뢰도를 잃게 되기 때문입니다. OS 수명 종료 상태 역시 이러한 지속적인 탐지 루프의 일부로 포함되어야 합니다.

중규모 환경에서 흔히 나타나는 패턴은 팀이 패치 적용을 의도적으로 거부하는 것이 아닙니다. 몇 달 전부터 구성 관리 에이전트에서 조용히 이탈한 호스트에 대해, 오케스트레이션 도구가 정상 작동으로 보고하는 경우입니다. 누구도 거짓말을 한 것은 아닙니다. 보고 계층이 잘못된 항목을 측정했을 뿐입니다.

공격자들이 패치되지 않은 취약점을 어떻게 악용하는가

공격자의 입장에서 생각해 보자. 제로데이는 연구 시간이 소요되거나, 브로커 시장에서 6자리 수 이상의 비용이 든다. 반면, 공개된 수정 패치가 있는 버그인 ‘n-데이’의 경우, 작동하는 개념 증명(PoC)이 있고 공격 대상으로 삼을 수 있는 노출된 대상이 충분하다면, 쇼단(Shodan) 검색보다 조금 더 드는 비용만으로도 공격이 가능하다. 공격자들은 어쩔 수 없을 때 제로데이를, 가능할 때는 n-데이를 활용하며, 취약점 공개 과정을 통해 n-데이 재고는 매일 보충된다.

맨디언트(Mandiant)의 ‘M-Trends 2026’ 보고서는 그 격차가 얼마나 좁혀졌는지에 대한 구체적인 수치를 제시합니다. 현재 평균 악용 소요 시간은 마이너스 7일로 추정되는데, 이는 평균적으로 패치가 배포되기 전에 악용이 시작된다는 것을 의미합니다. 익스플로잇은 6년 연속 가장 흔한 초기 감염 경로로 1위를 차지해 왔으며, 현재 맨디언트가 침입 지점을 파악할 수 있었던 침해 사례의 32%를 차지하고 있습니다.

CISA의 ‘악용된 것으로 알려진 취약점’ 목록 는 이론적 단계에서 실제 악용 단계로 넘어간 결함에 대한 공개 현황표로, 매주 그 규모가 늘어나고 있습니다. 이 목록이 미국 연방 민간 기관에 부과하는 조치 기한은 2026년에 변경되었습니다. 2021년부터 기관들이 KEV 항목을 수정할 수 있도록 2주(구형 CVE의 경우 6개월)의 기한을 부여해 온 BOD 22-01은, 기존 BOD 19-02와 함께 BOD 26-04, 즉 “위험도에 기반한 보안 업데이트 우선순위 지정”으로 대체되었습니다.

새로운 지침은 일률적인 마감 기한을 적용하는 대신, 네 가지 요소를 기준으로 각 취약점에 점수를 매깁니다. 해당 자산이 대외적으로 노출되어 있는가? 결함이 KEV에 속하는가? 악용이 자동화될 수 있는가? 공격자에게 시스템에 대한 완전한 제어권을 부여하는가, 아니면 부분적인 제어권만 부여하는가? 이러한 질문에 대한 답변에 따라 처리 기한이 결정됩니다. 가장 위험한 조합의 경우 3일의 기한이 주어지며, 완전한 제어권을 부여하는 최고 위험도 KEV 사례의 경우 시스템이 이미 침해되었는지 확인하기 위한 포렌식 선별 조사도 필요합니다. 이들 사이의 모든 경우는 14일 또는 60일의 기간이 주어지며, 4가지 요소 중 어느 하나에도 해당하지 않는 결함은 해당 자산의 다음 예정된 업그레이드 시까지 기다릴 수 있습니다.

심하게 악용되는 많은 취약점은 인터넷에 노출된 서비스와 에지 기기에서 발생하는 원격 코드 실행 결함이며, 때로는 패치를 적용해야 할 취약한 시스템이 심지어 본인의 소유가 아닐 수도 있습니다. MOVEit이 최근의 가장 대표적인 사례입니다. 널리 사용되는 한 파일 전송 제품의 결함으로 인해 수천 명의 하류 사용자가 피해를 입었습니다.

연방 민간 기관의 경우, 최악의 등급에 해당하는 기간은 이제 3일이 상한선이며, 주간 변경 자문위원회는 이 기간을 초과할 수 없습니다. 현재 악용되고 있는 인터넷에 노출된 RCE 에 대한 대응 시간이 3일을 초과한다면, 이는 다음 취약점이 발견되기 전에 반드시 보완해야 할 프로세스상의 허점입니다.

패치되지 않은 취약점이 쌓이는 것을 막는 방법

이는 다섯 가지 변수가 얽혀 있는 프로세스 문제이며, 현황을 파악하기도 전에 우선순위 결정 단계로 바로 넘어가면, 정확히 파악하지도 못한 일부 요소에 대해 우선순위를 정하게 되는 꼴이 됩니다.

패치되지 않은 모든 취약점을 우선적으로 찾아보세요

이 경우, 포괄성이 정교함보다 중요합니다. 자산의 70%만을 다루는 완벽한 우선순위 결정 모델은, 자산 전체를 다루는 조잡한 선별 방식보다 도움이 덜 됩니다.

각 소스마다 놓치는 부분이 다르기 때문에, 여러 각도에서 인벤토리를 구축해야 합니다. 구성 관리 및 에이전트 인벤토리는 에이전트에서 이탈한 항목을 놓치게 됩니다. 클라우드 공급자 API는 온프레미스 시스템과 섀도우 계정을 파악하지 못합니다. 인증 기반 네트워크 스캔은 스캔 기간 동안 전원이 꺼져 있던 호스트를 놓치게 됩니다. DNS 및 외부 공격 표면 탐지를 통해야만, 소유 사실을 아무도 기억하지 못하는 서브도메인을 찾아낼 수 있습니다.

그런 다음 정보를 대조해 보세요. 중요한 부분은 두 목록이 일치하지 않는 부분입니다. 클라우드 인벤토리에는 나타나지만 스캐너 결과에는 나타나지 않는 호스트는 바로 보안 침해를 초래할 수 있는 빈틈입니다. 자산 목록이 정확해지면, 각 호스트에 설치된 패키지와 버전을 해당 호스트에 적용되는 보안 권고 사항과 대조하여, 실제로 어떤 호스트가 취약한지 파악해야 합니다.

보고된 패치가 실제로 적용되었는지 확인하세요. 디스크에 최신 커널 패키지가 있다고 해서 실행 중인 커널이 보호받는 것은 아닙니다. 호스트가 해당 커널로 재부팅했거나 해당 CVE에 대한 실시간 패치를 적용받지 않은 이상, 이는 ‘해결됨’이라는 꼬리표가 붙은 취약점일 뿐입니다.

실제 악용 가능성에 따라 우선순위를 정하십시오

순수한 CVE 건수는 업무량을 나타냅니다. 실제 위험을 파악하려면 세 가지 추가 요소가 필요합니다.

KEV부터 시작하세요. 목록에 등재되었다는 것은 실제 환경에서 악용이 확인되었다는 의미이므로, 해당 취약점이 귀사의 자산에 영향을 미친다면 CVSS 점수와 관계없이 즉시 패치를 적용하세요. 그런 다음 EPSS 점수를 확인하세요. EPSS 점수는 공개된 CVE가 향후 30일 이내에 실제 환경에서 악용될 확률을 0에서 1 사이의 값으로 나타내며, 매일 업데이트됩니다. 이 점수는 무료로 제공되며, 기계가 읽을 수 있는 형식으로 되어 있고, 바로 이러한 의사결정을 위해 설계되었습니다. 마지막으로, 노출 위험과 비즈니스 중요도를 별도로 평가하십시오. 해당 자산이 인터넷에 노출되어 있거나, 공격자가 이미 침투해 있을 가능성이 있는 시스템에서 접근 가능한가요? 민감하거나 규제 대상인 데이터가 저장되어 있나요?

FIRST가 직접 수행한 비교 분석을 통해 효율성이 잘 입증됩니다. CVSS 7점 이상이라는 일률적인 기준을 적용하면 대기 중인 취약점 중 상당 부분이 즉시 수정 대상으로 분류되지만, EPSS 임계값을 적용하면 실제로 악용되는 취약점의 상당 부분을 포착하면서도 필요한 작업량은 극히 일부에 불과합니다. 다만, 그대로 적용할 수 있는 보편적인 기준치는 없습니다. 적절한 임계값은 각 조직의 대기 중인 취약점 현황에 따라 달라집니다.

팀의 자원이 부족한 경우, KEV와 노출 분석부터 시작하고 나중에 EPSS를 단계적으로 도입하세요. 이미 KEV를 안정적으로 적용하고 있다면, EPSS가 위험 감축의 다음 단계가 될 것입니다.

패치를 신속하게 적용하고, 패치를 적용할 수 없는 원인을 제거하십시오.

속도는 프로세스에서 마찰을 제거함으로써 얻어집니다. 배포를 자동화하여 패치 적용이 일회성 프로젝트가 아닌 파이프라인 형태로 진행되도록 해야 합니다. 사람이 직접 일정을 잡아야 하는 패치는 일정이 늦어지는 경향이 있기 때문입니다.

그런 다음 재부팅 의존성을 직접 해결하세요. 재부팅은 커널 패치가 적용되지 않은 채 방치되는 가장 흔한 이유 중 하나입니다. 재부팅은 유지보수 시간을 확보해야 하고, 변경 티켓을 발행해야 하며, 새벽 2시에 누군가가 호스트가 다시 가동되었는지 확인해야 하는 상황을 초래합니다. 재부팅 없이 패치를 적용하는 방식은 때때로 라이브 패칭라고도 불리는 이 방식은 메모리 내의 실행 중인 커널에 수정 사항을 적용하므로, 지원되는 취약점의 경우 서비스 중단 없이 보안 구멍이 메워집니다.

KernelCare 이 솔루션은 주요 엔터프라이즈 리눅스 배포판 전반에 걸쳐 작동하므로, 다양한 운영 체제가 혼합된 환경에서도 OS별로 별도의 도구를 사용할 필요가 없으며, 연중무휴 24시간 가동되는 워크로드는 가동 시간을 희생하면서 CVE 취약점에 노출되는 상황을 피할 수 있습니다.

벤더 패치가 제공되지 않는 EOL(제품 수명 종료) 소프트웨어를 다룹니다.

위에서 언급한 모든 내용은 해당 공급업체가 여전히 수정 패치를 제공하고 있다는 전제 하에 이루어진 것입니다. 단종된 부품의 경우, 원래 공급업체는 수정 패치를 제공하지 않으며, 단순히 업그레이드하라는 일반적인 조언은 애초에 시스템이 왜 여전히 가동되고 있는지에 대한 근본적인 이유를 간과하고 있습니다.

대개는 최신 커널을 지원하지 않는 하드웨어, 특정 OS 버전 하나만 인증한 애플리케이션, 처음부터 다시 진행해야 하는 규제 승인 절차, 혹은 향후 3분기 분량까지 이미 할당된 엔지니어링 리소스 등의 문제 때문입니다. EOL(제품 수명 종료) 일정에 대해 엄중히 경고하는 이메일을 보낸다고 해서 이러한 문제들이 해결되는 것은 아닙니다.

그러면 실행 가능한 세 가지 선택지가 남습니다.

옵션	다음과 같은 경우에 가장 좋습니다	주의하세요
지금 바로 이전하세요	이 앱은 휴대성이 뛰어나며, 이번 분기에 이용 가능한 용량이 있습니다.	미끄러짐은 정상적인 현상이며, 미끄러지는 동안에도 노출은 계속됩니다.
보정 제어만	완전히 격리되어 있으며, 신뢰할 수 없는 입력 경로가 없음	격리는 서서히 무너진다. 방화벽 설정을 한 번만 변경해도 다시 열리게 된다.
공급업체가 지원하는 연장 지원	자신만의 일정에 맞춰 마이그레이션을 진행하는 동안 CVE가 해결되어야 합니다.	어떤 OS 패키지, 런타임 및 라이브러리가 지원 대상인지 정확히 확인하십시오.

그 세 번째 길이 바로 TuxCare의 ‘Endless Lifecycle Support’가 가 담당하는 부분입니다. 이 서비스는 표준 패키지 관리 시스템을 통해, 업스트림 지원이 종료된 런타임, 라이브러리, 프레임워크, 애플리케이션은 물론 이를 기반으로 하는 EOL(지원 종료) 리눅스 배포판에 대한 보안 패치를 제공합니다. 지원 대상 시스템은 관련 문서 기록을 바탕으로 지속적으로 보안 수정 사항을 제공받으며, 마이그레이션은 기업이 실제로 자금을 조달할 수 있는 일정에 따라 진행됩니다.

시정 조치를 확인하고 입증하기

검증 없이 패치를 적용하는 것은 일종의 신념 체계에 불과합니다. 패치 상태를 신뢰하기 어렵게 만드는 두 가지 요인이 있습니다.

첫 번째는 ‘무증상 실패’입니다. 패키지는 설치되었지만 서비스가 재시작되지 않았거나, 호스트가 롤백되었거나, 업데이트가 실행 중인 컨테이너가 아닌 베이스 이미지에 적용된 경우입니다. 두 번째는 ‘오탐’입니다. 스캐너가 버전 문자열을 읽은 후, 백포트된 수정 사항을 놓치고, 이미 해결된 CVE를 여전히 미해결 상태로 표시하는 경우입니다.

효과적인 검증은 몇 가지 구체적인 결과를 낳습니다. 실행 중인 시스템으로부터 수정된 코드가 실제로 로드되었음을 직접 확인할 수 있을 뿐만 아니라, 패치 도구의 보고서와 독립적인 스캔 결과를 대조할 수 있습니다. 각 호스트와 CVE에 대해서는 감사관이 바로 활용할 수 있도록 날짜가 기재된 내보내기 가능한 기록이 생성됩니다. 또한 티켓 관리 시스템에서는 ‘조치 완료’를 ‘확인됨’으로 처리하고, ‘시도됨’은 별도의 상태로 추적합니다.

백포트(backport)를 고려한 검증은 리눅스에서 취약한 부분입니다. 일반적인 스캐너는 배포판이 업스트림 버전 번호를 유지한 채 수정 사항을 백포트한 패키지를 빈번히 잘못 판독하기 때문입니다. 어떤 스캐너를 사용하든, 이미 해결된 CVE에 스프린트 자원을 낭비하지 않도록 스캐너의 검사 결과를 해당 배포판의 보안 권고 사항과 대조하여 확인해야 합니다.

TuxCare가 어떻게 격차를 해소하는가

“패치 제공”과 “패치 적용” 사이의 간극에서 많은 보안 침해 사고가 발생합니다. 이퀴팩스(Equifax)의 경우, 데이터 유출이 시작되기 67일 전부터 이미 수정 패치가 마련되어 있었습니다. Log4Shell의 경우, 첫 번째 패치가 나오기도 전에 공격자들이 이미 활동을 시작했습니다. 이러한 간극을 메우는 팀은 대개 지연의 구조적 원인, 즉 EOL(지원 종료)로 인한 막다른 골목, 빌드에 계속해서 슬그머니 다시 포함되는 취약한 패키지, 그리고 재부팅 문제 등을 제거한 팀들입니다.

TuxCare의 접근 방식은 이 세 가지와 직접적으로 부합합니다. 끝없는 라이프사이클 지원 는 업스트림 공급업체들이 이미 지원을 중단한 런타임, 프레임워크, 애플리케이션 및 운영 체제를 포괄합니다. SecureChain 은 공개 레지스트리를 TuxCare가 관리하는 레지스트리로 대체하며, JavaScript, Python, Java, Go 및 PHP용으로 선별되고 지속적으로 패치되는 패키지를 제공하여, 알려진 취약점이 있는 버전이 새로운 빌드에 포함되지 않도록 돕습니다. KernelCare 는 다양한 Linux 환경 전반에서 재부팅 없이 커널 패치 작업을 처리합니다. 귀사의 위험 프로필에 맞는 솔루션을 선택하십시오.

먼저 신뢰할 수 있는 현황 파악부터 시작하세요. 그런 다음 무엇을 먼저 수정할지 결정하세요.

자주 묻는 질문