[기획/미토스 이후, 취약점 대응①] 취약점 쏟아져도, 패치는 느린 이유

앤트로픽의 인공지능(AI) 모델 미토스를 기점으로 AI의 소프트웨어 취약점 탐색 능력이 빠르게 발전하고 있다. AI가 대량의 취약점을 찾고 공격코드까지 만들 수 있게 되면서, 이를 어떻게 빠르게 분석, 검증하고 대응, 관리할 지가 주요 과제로 떠올랐다. 바이라인네트워크는 ‘미토스 이후, 취약점 대응’ 기획 시리즈로 AI 이후 취약점 관리와 대응 체계가 어떻게 달라져야 하는지 살펴본다. 첫 회에서는 기업의 패치 과정에서 발생하는 병목을 짚어 봤다. <편집자 주> 

앤트로픽은 미토스 프리뷰를 이용해 1000개가 넘는 오픈소스 프로젝트에서 취약점 후보 2만3019건을 찾았다. 이 가운데 미토스가 높음 또는 심각 수준으로 평가한 취약점은 6202건으로 나타났다. 이같은 결과는 AI가 방대한 소스코드를 분석해 결함을 대량으로 찾아낼 수 있다는 사실을 보여준다. 문제는 취약점 발견이 곧 패치로 이어지지는 않는다는 점이다. 앤트로픽은 5월 22일 기준 281개 오픈소스 프로젝트에 취약점 1596건을 공개했다. 이 가운데 원 개발 프로젝트에서 패치가 확인된 취약점은 97건에 불과했다.

AI가 찾은 취약점 후보는 보안 연구자와 소프트웨어 유지 관리자의 검증을 거쳐야 한다. 실제 결함으로 확인되면 수정 코드를 만들고 기존 기능에 문제가 생기지 않는지도 시험해야 한다. 앤트로픽에 따르면, 미토스가 찾은 높음 또는 심각 수준의 취약점 하나를 패치하는 데 평균 2주가 걸린다.

AI가 찾아내는 취약점이 늘어날수록 검증과 수정 단계에 쌓이는 작업도 많아진다. 소프트웨어 개발사가 패치를 내놓은 뒤에는 이용 기업의 조치가 시작된다. 기업은 취약점의 영향을 받는 서버와 단말을 찾아야 한다. 실제 공격 가능성과 자산 중요도를 따져 적용 순서를 정하고 패치가 서비스 장애를 일으키지 않는지도 시험해야 한다. 배포 뒤에는 재부팅과 적용 결과 확인이 필요하다.

그러나 현장에서는 이 과정이 순서대로 이어지지 않는다. 취약한 자산을 찾지 못하거나 적용 순서를 정하는 데 시간이 걸린다. 장애 우려로 테스트와 변경 승인이 길어지고 배포 뒤 검증이 누락되기도 한다.

미국 국립표준기술연구소(NIST)는 기업 패치 관리를 패치의 식별과 우선순위 설정, 확보, 설치, 적용 결과 검증으로 정의한다. NIST는 자산이 클라우드와 모바일, 운영기술(OT) 등으로 흩어지고 설치된 소프트웨어 구성요소가 늘면서 많은 조직이 패치를 따라가지 못하고 있다고 지적하기도 했다.

버라이즌의 ‘2026 데이터 침해 조사 보고서(DBIR)’에 따르면 취약점 악용은 전체 침해사고의 31%에서 초기 침투 경로로 나타났다. 보고서가 분석한 조직에서 미국 사이버보안·인프라보안국(CISA)의 ‘알려진 악용 취약점(KEV)’이 완전히 조치된 비율은 26%였다. 전년 38%보다 12%포인트 낮아졌다. 완전 조치까지 걸린 기간의 중앙값도 32일에서 43일로 늘었다. 조직이 처리해야 할 주요 취약점의 중앙값은 전년보다 50% 증가했다.

첫 병목은 ‘보이지 않는 자산’

통합 엔드포인트 관리 기업 태니엄은 패치 과정의 첫 번째 병목으로 ‘자산 식별’을 꼽았다. 기업이 특정 소프트웨어의 취약점을 알아도 해당 제품을 어느 서버와 단말에서 사용하는지 확인하지 못하면 조치를 시작할 수 없다는 것이다.

기업은 자산 대장이나 구성관리데이터베이스(CMDB)를 운영한다. 그러나 기록된 자산과 실제 운영 환경이 항상 일치하는 것은 아니다. 재택근무용 노트북과 이동 단말은 확인 시점에 꺼져 있거나 사내망 밖에 있을 수 있다. 개발·시험 서버와 클라우드 인스턴스, 외부 협력사가 운영하는 시스템도 목록에서 빠질 수 있다.

태니엄은 이를 “(자산을) 몰라서 패치를 못 하는 지연”이라고 설명했다. 취약한 자산이 있다는 사실을 파악하지 못하니 패치가 늦어질 수 밖에 없는 것이다.

자산 식별은 취약점 대응의 출발점이다. CISA도 미국 연방기관을 대상으로 한 ‘자산 가시성과 취약점 탐지 개선 지침(BOD 23-01)’에서 기관이 보유한 자산과 해당 자산의 취약점을 지속해서 확인하도록 요구했다.

태니엄은 패치 과정을 ▲자산 식별 ▲우선순위 판단 ▲테스트·승인 ▲배포 ▲재부팅 ▲검증 6단계로 구분하면서, 이 가운데 ‘자산 식별’과 ‘테스트·승인’에서 지연이 가장 많이 발생한다고 설명했다.

국내 한 금융사의 최고정보보호책임자(CISO)는 “취약점 패치는 영향을 받는 자산 확인과 위험도 판단, 테스트, 변경 승인, 배포, 조치 검증 단계를 거친다”며 “이 가운데 영향을 받는 자산을 확인하고 실제 위험도를 판단하는 데 가장 많은 시간이 걸린다”고 설명했다.

취약점 점수로는 우선순위 못 정한다

취약한 자산을 찾은 뒤에는 무엇부터 고칠지 결정해야 한다. 기업은 확인한 취약점을 한 번에 모두 고칠 수는 없다. 취약점의 기술적 심각도를 0점부터 10점까지 나타내는 공통 취약점 평가 시스템(CVSS) 점수만으로 적용 순서를 정하기도 어렵다.

태니엄 관계자는 “실제 공격에 쓰이는지, 외부 인터넷에 노출된 자산인지, 핵심 업무를 처리하는 시스템인지를 따져야 한다”며 “공격자가 취약점을 이용해 관리자 권한을 얻거나 다른 내부 시스템으로 이동할 수 있는지도 확인해야 한다”고 설명했다.

문제는 취약점 정보와 자산 중요도, 인터넷 노출 정보가 서로 다른 시스템에 흩어져 있다는 점이다. 담당자는 각 시스템의 정보를 모아 실제 위험을 판단해야 한다.

CISA도 CVSS 점수만으로 대응 순서를 정하지는 않는다. CISA의 ‘이해관계자별 취약점 분류(SSVC)’는 실제 악용 여부와 조직에 미칠 영향을 바탕으로 대응 우선순위를 나눈다. CISA는 지난 6월 발표한 ‘위험 기반 보안 업데이트 우선순위 지침(BOD 26-04)’에서도 미국 연방기관이 위험에 따라 보안 업데이트를 처리하도록 했다.

위험 기반 우선순위는 국내 금융권에서도 중요한 과제로 다루고 있다. 금융위원회는 지난 2일 공개한 ‘프런티어 AI 보안위협 금융분야 대응요령’에서 취약점의 심각도와 악용 가능성, 핵심 업무·자산에 미칠 영향, 외부 노출 수준, 관련 법률을 함께 고려해 패치 우선순위를 정하도록 했다. 고위험 취약점을 일 단위로 관리하고 취약점 점검과 패치 업무를 프로그램 개발·배포 체계와 연결해 조치 기간을 줄이는 방안도 제시했다.

한 금융사 CISO는 “실제로 패치 과정에서는 자산 확인과 위험도 판단에 가장 많은 시간이 소요된다”며 “같은 취약점이라도 적용된 시스템의 역할과 외부 노출 여부에 따라 조치 순서가 달라진다”고 설명했다.

“알아도 못한다”…시스템 장애와 승인 절차 때문

다음 병목은 ‘장애 위험’과 ‘변경 승인’이다. 패치 대상을 확인하고 우선순위를 정해도 곧바로 적용하는 데는 여러 한계가 있다.

태니엄은 테스트와 변경 승인을 패치 과정에서 가장 많은 시간이 드는 구간으로 꼽았다. 패치 파일 배포는 짧은 시간 안에 끝낼 수 있지만 시스템 안정성 검증과 내부 승인, 정기점검 일정 때문에 적용까지 수일에서 수주가 걸릴 수 있다는 설명이다.

태니엄 관계자는 “이는 앞에서 말한 몰라서 못하는 자산 식별과는 다르게, 알아도 못 하는 지연”이라고 설명했다. 취약점과 대상 자산을 파악했지만 서비스 장애 위험과 내부 절차 때문에 패치하지 못하는 경우다.

미국 국립표준기술연구소(NIST)도 빠른 패치와 충분한 테스트 사이의 충돌을 패치 관리의 대표적인 문제로 짚는다. 패치를 빨리 적용하면 공격자가 취약점을 이용할 수 있는 기간은 줄어든다. 대신 테스트가 부족해 운영 장애가 발생할 가능성이 커진다. 반대로 테스트 기간을 늘리면 장애 가능성은 낮아지지만 공격에 노출되는 기간이 길어진다.

이런 병목은 금융과 결제 시스템처럼 중단 없이 서비스를 제공해야 하는 업종에서 더 뚜렷하다. 전자금융감독규정은 정보처리시스템의 긴급하고 중요한 패치 사항에 즉시 보정 작업을 하도록 규정한다. 하지만 금융사는 패치가 거래와 고객 서비스에 미칠 영향도 함께 검토해야 한다.

한 금융사 CISO는 “우선순위는 보안 취약점의 제거”라면서도 “서비스 장애 가능성을 완전히 없애기는 (현실적으로) 어렵다”고 설명했다. 이어 “소프트웨어 공급사와 협력하고 실제 운영 환경과 비슷한 테스트 환경을 마련할 필요가 있다”고 덧붙였다.

이어 그는 “자동화 시스템이 패치로 인한 장애가 없다는 판단까지 내릴 수 있다면 이상적”이라며 “하지만 이는 현재는 전문가가 판단해야 할 영역”이라고 말했다.

금융위가 최근 AI 보안 테스트와 긴급 패치 과정에서 발생한 일정 범위의 전산장애를 면책하기로 한 것도 이러한 현실을 반영한 조치다. 금융위는 지난달 30일 면책심의위원회를 열고 금융사가 보안 목적의 AI로 취약점을 점검하거나 금융당국과 금융보안원이 전파한 취약점에 긴급 패치를 적용하다 경미한 전산장애를 일으킨 경우 제재를 면제하기로 했다. 신속한 복구와 소비자 보호조치를 시행해야 한다는 조건을 달았다.

금융위는 금융사 임직원이 시스템 오작동과 제재 가능성을 지나치게 우려하면 보안 조치를 신속하게 추진하기 어렵다는 금융업계 의견을 반영했다고 설명했다.

면책을 받으려면 검증 환경에서 패치를 먼저 적용해 정상 작동 여부와 영향을 확인해야 한다. 장애가 발생했을 때 이전 상태로 되돌리는 롤백(Rollback), 기능을 즉시 중단하는 킬스위치(Kill Switch), 장애 모듈 격리와 대체 서비스 절차도 마련해야 한다.

배포했다고 조치가 끝난 것은 아니다

패치 파일을 서버와 단말에 보냈다고 취약점 조치가 끝나는 것은 아니다. 단말이 꺼져 있거나 사내망에 연결되지 않았다면 배포 명령을 받지 못할 수 있다. 망 분리와 대역폭 부족, 관리 에이전트 오류도 패치 전달을 막는다.

또 패치가 전달돼도 실제 적용까지는 추가 작업이 필요하다. 일부 패치는 소프트웨어를 다시 실행하거나 운영체제를 재부팅해야 한다. 애플리케이션을 다시 배포하거나 설정을 변경해야 하는 경우도 있다. 24시간 운영하는 서버나 생산 설비는 바로 재기동하기 어려워 패치 파일만 전달된 상태가 이어질 수 있다.

적용 결과를 확인하는 작업도 남는다. 어느 장비가 정상적으로 조치됐고 어떤 장비가 빠졌는지 확인하지 않으면 실패한 작업도 완료된 것으로 처리될 수 있다. 미국 국립표준기술연구소(NIST)는 패치가 정상적으로 설치돼 실제로 작동하는지 검증해야 한다고 권고하면서, 다수 자산의 적용 여부를 확인하려면 자동화가 필요하다고 설명한다.

태니엄 관계자는 “패치 배포 자체는 취약점 조치 과정에서 비교적 빠르게 이뤄진다”며 “배포 결과를 확인하는 검증 절차가 수작업으로 진행되거나 생략되는 경우가 더 큰 문제”라고 말했다. 이어 “패치 전달과 재부팅, 적용 결과 검증까지 끝나야 취약점 조치가 완료된다. 현실적으로 보면 패치를 하는데 정말 많은 제약사항이 있다”고 덧붙였다.

글. 바이라인네트워크
<곽중희 기자>god8889@byline.network