3년, 하나의 근본 원인: 2026년에도 취약점 익스플로잇이 여전히 승리하는 이유

2025년 Sophos 보고서에서 가장 지루한 발견이 가장 중요한 발견이기도 하다

매년 랜섬웨어를 둘러싼 논의는 새로운 공격 기법에 대해 점점 더 목소리를 높인다. AI가 생성한 피싱. 딥페이크를 이용한 소셜 엔지니어링. 적대적 머신러닝(Adversarial Machine Learning). 리빙 오프 더 랜드(Living-off-the-Land) 바이너리. 잘 알려지지 않은 의존성을 통한 공급망 침해. 이러한 서사는 방어자들이 근본적으로 새로운 도구를 필요로 하는, 근본적으로 새로운 위협에 직면해 있다고 어김없이 암시한다.

그리고 매년, 수천 명의 피해자를 대상으로 한 벤더 중립적 설문조사를 기반으로 하는 Sophos의 State of Ransomware 보고서는 동일하게 화려하지 않은 답을 들고 돌아온다.

3년 연속으로, 익스플로잇된 취약점은 랜섬웨어 사고의 가장 흔한 기술적 근본 원인이며, 2025년 공격의 32%를 차지했다.

새로운 AI 기법이 아니다. 제로데이도 아니다. 특이한 공급망 공격도 아니다. 존재했지만 적용되지 않은 패치다. 잘못된 것으로 알려져 있었던 설정이다. 공개된 익스플로잇과 벤더 권고문이 있었지만 대기열에 들어간 채 결코 처리되지 않은 CVE다.

이는 모든 기업 보안 리더를 불편하게 만들어야 하는 발견이다. 새로운 도구를 구매하는 것으로는 해결할 수 없기 때문이다. 이것은 기업 환경이 기술 부채를 축적하는 방식에 관한 구조적 문제이며, 2025년 데이터는 아무리 첨단 탐지 기술에 투자해도 이 격차를 좁힐 수 없음을 시사한다.

BackupSec는 취약점 익스플로잇이 1위 근본 원인으로 계속 유지되는 현상을 하나의 전략적 신호로 해석한다. 알려진 보안 취약점과 해결된 보안 취약점 사이의 격차야말로 어떤 조직이 내년 "몸값을 지불한" 명단에 오를지를 예측하는 가장 신뢰할 수 있는 단일 지표다. 이 글에서는 그 격차가 왜 지속되는지, 왜 예방만으로는 이를 좁힐 수 없는지, 그리고 2026년에 운영되는 조직들에 어떤 아키텍처적 시사점이 있는지 살펴본다.

Sophos 데이터가 실제로 보여주는 것

2025년 Sophos 보고서는 17개국에 걸쳐 3,400명의 IT 및 사이버보안 리더를 대상으로 설문조사를 진행했으며, 이들은 모두 지난 12개월 동안 랜섬웨어 공격을 받은 조직 소속이었다. 사고의 기술적 근본 원인을 물었을 때, 그 분포는 해마다 놀라울 정도로 일관되게 나타났다.

• 익스플로잇된 취약점: 공격의 32% — 3년 연속 1위 원인.
• 탈취된 자격증명: 23% — 2024년 29%에서 하락.
• 악성 이메일: 19%.
• 피싱: 18% — 전년도 11%에서 상승.

업종별 보고서 역시 이러한 패턴을 뒷받침한다. 제조업에서는 익스플로잇된 취약점이 사고의 32%를 차지했으며, 여기서도 1위 원인이었다. 소매업에서는 그 수치가 30%였고, 마찬가지로 1위였다. Sophos가 발표한 사실상 모든 업종별 분석에서 동일한 결과가 반복된다. 즉, 성공한 랜섬웨어 공격의 3분의 1은 벤더가 이미 패치를 제공했고, 보안팀도 이론적으로는 알고 있었지만, 공격자가 먼저 손을 댄 취약점에서 시작된다는 것이다.

이 발견이 전략적으로 중요한 이유는 단지 그 일관성 때문만은 아니다. 취약점 관리 도구, 공격 표면 관리(Attack Surface Management) 플랫폼, 노출 평가 서비스, 패치 자동화에 대한 업계의 3년에 걸친 집중적인 투자에도 불구하고 여전히 1위 원인으로 남아 있다는 사실 때문이다. 투자는 상당했다. 결과는 변하지 않았다.

이는 이 문제의 아키텍처적 본질에 대해 무언가를 말해준다.

패치가 실패하는 이유 — 조직이 패치를 실시하더라도

"공격의 32%가 알려진 취약점에서 시작된다"는 사실에 대한 직관적인 반응은 "그러면 더 빨리 패치하면 된다"는 것이다. 이 반응은 옳지만 운영상으로는 충분하지 않으며, 그 이유를 솔직하게 들여다볼 필요가 있다.

분모의 문제. 일반적인 중견기업은 운영체제, 애플리케이션, 펌웨어, 컨테이너 이미지, SaaS 구성 전반에 걸쳐 수천 개의 개별 소프트웨어 구성 요소를 관리한다. 벤더 권고문은 끊임없이 발표된다. 아무리 최고 수준으로 운영되는 보안팀이라도 CVE가 공개된 당일에 모든 구성 요소를 패치할 수는 없다. "익스플로잇될 수 있는 대상"이라는 분모는 "이번 주에 패치할 수 있는 대상"이라는 처리 역량보다 구조적으로 더 크다.

중요도의 문제. 많은 패치는 다운타임, 회귀 테스트, 또는 매출 연속성을 지켜야 하는 사업 담당자와의 조율을 필요로 한다. 패치가 가장 절실한 시스템들, 즉 외부에 노출된 애플리케이션, 레거시 운영 시스템, OT 및 산업 제어 인프라는 종종 다운타임으로 인한 비즈니스 비용이 가장 큰 시스템이기도 하다. 그래서 패치는 일정이 잡혔다가 연기되고, 일괄 처리되며, 결국 잊혀진다. 공격자들은 이를 알고 있으며, 유지보수 부채를 가장 많이 안고 있을 가능성이 높은 시스템 범주를 특별히 노린다.

발견의 문제. 보이지 않는 것은 패치할 수 없다. Sophos 자체 데이터에 따르면 피해자의 40% 이상이 알려지지 않은 보안 격차를 기여 요인으로 꼽았다. 특히 소매업에서는 사고의 46%가 알려지지 않은 격차에서 비롯된 것으로 나타났다. 이는 조직이 패치하지 않기로 선택한 취약점이 아니라, 조직이 그 존재조차 몰랐던 취약점이다. 섀도 IT, 문서화되지 않은 시스템, 잊혀진 클라우드 워크로드, 자체 의존성 트리를 가진 서드파티 통합. 오늘날 기업의 공격 표면은 실제로 목록화하기가 매우 어려우며, 자산 인벤토리가 보여주는 것과 공격자가 실제로 도달할 수 있는 것 사이의 격차야말로 익스플로잇되는 취약점 대부분이 존재하는 곳이다.

시간 창(window)의 문제. 취약점이 알려져 있고 패치가 제공되더라도, 공개 시점과 실제 악용 시점 사이의 시간은 극적으로 짧아졌다. 위협 행위자들은 보안팀 못지않은 세밀함으로 벤더 권고문을 모니터링하며, 영향력이 큰 CVE에 대한 무기화된 익스플로잇은 이제 공개 후 며칠, 때로는 몇 시간 안에 등장하는 것이 일상이 되었다. 관심을 끌 만큼 심각한 취약점이라면, 5년 전에 존재했던 패치 여유 기간은 더 이상 존재하지 않는다.

이러한 문제들 중 어느 것도 또 다른 취약점 관리 도구를 구매한다고 해서 해결되지 않는다. 이는 기업 환경이 작동하는 방식에 내재된 구조적 특징이며, 막대한 방어 투자에도 불구하고 32%라는 수치가 3년 동안 움직이지 않은 이유를 설명해준다.

AI라는 곁길

짚고 넘어갈 필요가 있다. 2025년 Sophos 데이터는 AI 주도 공격에 관한 지배적인 서사를 바로잡는 데도 유용하다.

2025년 업계의 논의는 AI가 생성한 피싱 캠페인, 딥페이크 기반 소셜 엔지니어링, 머신러닝 기반 탐지 회피 등에 크게 치우쳐 있었다. 이러한 위협은 실재하며 주목할 가치가 있다. 특히 현재 피싱 이메일의 상당수가 AI가 생성한 콘텐츠를 포함하고 있다는 연구 결과를 감안하면 더욱 그렇다.

하지만 Sophos 데이터는 실제로 예산과 관심을 어디에 배분해야 하는지에 대한 유용한 현실 점검을 제공한다. AI가 강화한 피싱은 피싱 관련 사고의 증가(전년 대비 11%에서 18%로)에 기여하고 있다. 그러나 취약점 익스플로잇을 지배적인 진입 벡터의 자리에서 밀어내지는 못하고 있다. 패치되지 않은 시스템에서 시작되는 전체 공격의 3분의 1은 공격자가 더 나은 언어 모델을 손에 넣었다고 해서 줄어들지 않는다. 오히려 AI에 관한 논의는 3년 연속으로 전체 랜섬웨어 사고의 3분의 1을 조용히 유발해 온, 화려하지 않은 구조적 문제로부터 관심을 돌리는 곁길 역할을 해왔다.

기업 리스크 리더들에게 주는 전략적 시사점은, 가장 중요한 방어 투자가 가장 최신 투자라고 주장하는 모든 벤더의 서사를 회의적으로 바라봐야 한다는 것이다. Sophos 데이터는 다른 방향을 가리킨다. 가장 중요한 방어 투자는 어쩌면 취약점 관리라는 지루하고 구조적인 문제가 전체 결과를 좌우하는 비중을 낮춰주는 투자일 수 있다는 것이다.

"비중을 낮춘다"는 것이 실제로 의미하는 바

취약점 익스플로잇을 완전히 없앨 수는 없다는 사실을 받아들이면 다음과 같은 아키텍처적 통찰에 이르게 된다. 전체 공격의 3분의 1이 앞으로도 제때 적용하지 못한 패치에서 계속 시작된다면, 전략적 질문은 "어떻게 하면 더 빨리 패치할 것인가"에서 "패치하지 못했을 때 무슨 일이 벌어지는가"로 옮겨간다.

이는 대부분의 기업 보안 아키텍처가 여전히 회피하고 있는 질문이다.

예방이 효과가 있다고 전제하는 방어 모델에서는 취약점 익스플로잇을 반드시 제거해야 할 실패로 취급한다. Sophos 데이터를 진지하게 받아들이는 방어 모델에서는 취약점 익스플로잇을 나머지 아키텍처가 재앙적인 결과 없이 흡수해야 하는 반복되는 조건으로 취급한다.

제거에서 흡수로의 전환은 성숙한 신뢰성 엔지니어링(Reliability Engineering)이 10년 전에 겪었던 것과 동일한 아키텍처적 전환이다. 분산 시스템에서는 장애를 제거하지 않는다. 장애가 발생했을 때 우아하게 성능이 저하되도록(graceful degradation) 시스템을 설계한다. 장애 간 평균 시간(MTBF)뿐 아니라 평균 복구 시간(MTTR)도 측정한다. 복원력을 예방이 실패한 뒤의 부차적인 뒷수습이 아니라 1차적인 아키텍처 속성으로 취급한다.

기업 보안 역시 매우 서서히 동일한 논리를 적용하기 시작하고 있다. 우리가 보기에 2025년 Sophos 데이터는 이러한 전환이 이미 늦었다는 것을 보여주는 지금까지 가장 강력한 실증적 근거다.

백업 아키텍처가 전환점이 되는 지점

취약점이 익스플로잇되어 공격자가 발판을 마련하면, 그 뒤에 이어지는 일련의 사건은 이미 잘 알려져 있다. 수평 이동(Lateral Movement), 권한 상승, 가치 있는 데이터에 대한 정찰, 유출, 그리고 결국 페이로드 배포다. 오늘날의 위협 행위자들은 랜섬웨어를 배포하기 전 평균 12일에서 22일 동안 침해된 환경 내부에 머무르며, 이 시간을 활용해 그렇지 않았다면 복구를 가능하게 했을 통제 수단을 특정하고 무력화한다.

그러한 통제 수단 중 단연 가장 중요한 것이 바로 백업 환경이다.

익스플로잇된 취약점에서 출발한 시스템으로부터 백업 인프라에 도달할 수 있다면, 그 취약점은 단지 공격을 가능하게 한 것이 아니라 공격이 승리 하도록 만든 것이다. 인터넷에 노출된 애플리케이션의 익스플로잇된 CVE가 아키텍처적으로 중요해지는 이유는 그것이 익스플로잇된 호스트에서 무엇을 하느냐 때문이 아니라, 그 이후 2주 동안 공격자가 여러분의 복구 계층에 대해 무엇을 할 수 있게 만드는가 때문이다.

이것이 Sophos 데이터가 암시하는 아키텍처적 전환점이다. 취약점 익스플로잇은 앞으로도 당분간 1위 근본 원인으로 남을 것이다. 결과를 좌우하는 변수는 그러한 취약점이 필연적으로 익스플로잇될 시스템에서 여러분의 복구 아키텍처에 도달할 수 있는지 여부다.

구체적으로 이는 다음을 의미한다.

아이덴티티 분리. 운영 시스템을 보호하는 자격증명이 백업 인프라에 대한 접근 권한까지 부여해서는 안 된다. 침해된 도메인 관리자 계정이 백업 저장소에 도달할 수 있다면, 여러분의 백업은 패치되지 않은 취약점이 노출시킨 공격 표면의 일부인 셈이다.

검증된 불변성. 소프트웨어 기반 보존 정책은 충분한 권한을 가진 사람이라면 누구든 변경할 수 있다. 하드웨어 또는 플랫폼 차원에서 강제되는 보존 잠금(Retention Lock)은 이를 막기 위해 설계되었지만, "설정되어 있음"과 "실제로 의도한 대로 작동함" 사이의 간극이야말로 많은 기업의 백업 환경이 실제 사고에서 실패하는 지점이다. 불변성이 백업 플랫폼, 스토리지 계층, 또는 하드닝된 저장소 중 어디에서 강제되는지와 무관하게, 중요한 것은 그것이 설정 화면에서 단순히 활성화 되어 있는지가 아니라 적대적인 조건 하에서 테스트 되었는지 여부다.

네트워크 및 신뢰 격리. 운영 시스템과 동일한 네트워크 도메인에 위치한 백업 환경은 위협 모델링 관점에서 운영 환경의 일부일 뿐이다. 논리적, 물리적 격리야말로 백업 인프라를 "또 하나의 표적"에서 "다른 표적들이 살아남지 못할 때 살아남는 계층"으로 바꾸어주는 요소다.

지속적인 복구 검증. 실제 공격의 구체적인 조건에 맞서 테스트되지 않은 백업은 통제 수단이 아니라 가설에 불과하다. 2025년 데이터에 따르면, 백업을 보유하고 있었음에도 불구하고 성공한 랜섬웨어 사고로부터 복구하는 과정에서 기업의 53%가 백업을 사용하지 못했다. 가장 유력한 설명은 그들이 보유한 백업이 실제로 벌어진 시나리오에 맞춰 검증된 적이 없었다는 것이다. 이러한 실패 양상에 대비한 설계를 하려면 단순히 백업을 가동하는 것이 아니라 테스트가 필요하다.

전략적 재구성

기업 리스크 리더들에게, 취약점 익스플로잇이 계속해서 1위 근본 원인으로 남아 있다는 사실은 취약점 관리 프로그램에 대한 비난이 아니다. 이는 취약점 관리가 아무리 잘 수행되더라도 랜섬웨어 방어의 전체 무게를 홀로 감당할 수 없는 구조적 한계를 지니고 있다는 증거다.

공격의 32%가 알려진 취약점에서 시작된다는 Sophos의 발견은 기업 피해자의 48%가 몸값을 지불했다는 발견과 함께 읽어야 한다. 이 두 수치는 서로 연결되어 있다. 이는 복구 계층을 신뢰할 수 없기 때문에 예방이 완벽할 것을 요구받는 방어 태세를 보여준다. 전략적 시정 방향은 예방을 더 완벽하게 만드는 것이 아니라, 예방의 실패가 사업 결과를 좌우하지 않을 만큼 복구를 신뢰할 수 있게 만드는 것이다.

그러한 시정은 아키텍처적인 것이다. 또한 이미 늦은 일이기도 하다. 앞으로 12개월 안에 이 격차를 좁히는 조직은 패치되지 않은 시스템에서 계속 시작될 필연적인 3분의 1의 사고를 복구 계층이 흡수할 수 있는 조직일 것이다. 그렇게 하지 못하는 조직은 해마다 Sophos 보고서의 같은 자리에 계속 등장하게 될 것이다.

BackupSec이 나서는 지점

BackupSec의 서비스는 예방이 Sophos 데이터가 설명하는 비율만큼 실패할 것이라는 전제, 그리고 예방이 실패했을 때 결과를 좌우하는 계층은 비즈니스에 필수적인 데이터의 깨끗하고 격리된 사본을 보유한 복구 인프라와, 그것이 실제로 복원 가능함을 입증하는 운영상의 규율이라는 전제를 바탕으로 구축되었다.

우리의 세 가지 서비스는 각각 취약점 익스플로잇이 1위 근본 원인으로 계속 유지되는 현상이 드러내는 특정한 격차를 해결한다.

• ZeroMON은 백업 운영, 구성 드리프트, 보안 신호에 대한 지속적인 가시성을 제공한다. 이를 통해 취약점이 익스플로잇되어 공격자가 네트워크 내부에서 2주를 보내는 동안, 여러분의 백업 환경을 노리는 정찰 활동이 은밀하게 진행되지 않고 눈에 보이게 된다.
• ZeroTAM은 아키텍처 결정, 용량 계획, 복구 전략을 위한 전담 백업 보안 어드바이저를 여러분의 팀에 제공한다. 이는 패치되지 않은 취약점을 통해 침해될 가능성이 가장 높은 시스템에서 여러분의 백업 계층에 도달할 수 있는지 여부를 좌우하는 구조적 전문성 격차를 해소한다.
• ZeroPEN은 우리가 보기에 32%라는 발견에 가장 직접적으로 대응하는 서비스다. 우리는 익스플로잇된 취약점에서 출발한 공격자와 동일한 방식으로 여러분의 백업 관리 플레인, 접근 통제, 불변성 설정, 격리 태세를 침투 테스트한다. 그런 다음 실제 복원 시나리오를 실행하여 복구가 깔끔하고 완전하며 제때 이루어지는지 검증한다. 그 결과물은 시정해야 할 발견 사항의 목록이 아니다. 그것은 여러분의 백업 계층이 Sophos 데이터가 설명하는 구체적인 조건 속에서도 살아남는다는 것을 입증하는 문서화된 증거다.

BackupSec은 온프레미스로 배포된다. 우리는 읽기 전용 API 접근을 통해 여러분의 백업 애플리케이션에 연결한다. 여러분의 백업 데이터, 텔레메트리, 구성 세부 정보는 여러분의 환경 내부에 그대로 남는다.

32%라는 수치는 운명이 아니다. 그것은 복구 계층이 예방 계층과 함께 실패하도록 구조화되어 있을 때에만 결과를 좌우하는 구조적 조건을 설명하는 것이다. 이 둘을 분리하는 조직은 2026년 랜섬웨어의 지배적인 근본 원인에 더 이상 취약하지 않게 된다. 이는 더 빨리 패치했기 때문이 아니라, 패치 여부가 자신들의 복구 결과를 좌우하지 않는다는 것을 검증했기 때문이다.

백업 침투 테스트와 복구 검증에 대해 BackupSec과 상담하기 →

이 분석은 Sophos의 State of Ransomware 2025 보고서와 2025년의 더 폭넓은 랜섬웨어 연구 동향을 참고했다. 여기 제시된 해석과 프레임워크는 BackupSec 고유의 것이다. 이 분석이 여러분의 특정 환경에 어떻게 적용되는지 논의하고 싶다면, 저희 팀에 문의하기 →