글로벌 오픈소스 기업 레드햇은 3일 AI 기반 취약점 탐색이 급증하는 이른바 ‘취약점 대재앙(Vulnpocalypse)’ 시대일수록 발견된 문제의 공개 시점을 신중하게 조율해야 한다고 강조했다. 국내 해킹 사고들이 AI 때문에 발생했다는 의미는 아니지만, 취약점을 찾아내는 기술의 발전이 기업의 보안 부담을 키우는 새로운 변수라는 설명이다.
보안 취약점은 프로그램이나 시스템의 허점이다. 공격자가 이를 악용하면 정보를 빼내거나 시스템에 침입할 수 있다. 과거에는 전문가가 오랜 시간 분석해야 찾을 수 있었던 문제도 이제 AI를 활용하면 더 빠르게 발견할 수 있다. 레드햇은 지난 4월 공개된 앤스로픽의 ‘클로드 미토스 프리뷰’ 이후 이러한 변화가 더욱 뚜렷해졌다고 평가했다.
그러나 발견된 문제가 실제 해킹으로 이어지는지 확인하고, 수정 프로그램을 만들고, 기업들이 이를 설치하는 작업에는 시간이 걸린다. AI가 하루에 수많은 의심 사례를 찾아내더라도 이를 검증할 개발자와 보안 담당자가 함께 늘어나는 것은 아니다.
◇해커보다 먼저 고칠 시간 확보해야
레드햇이 강조하는 원칙은 ‘조율된 취약점 공개’다. 취약점을 발견한 연구자가 즉시 인터넷에 공개하는 대신 개발사, 보안업체 등과 먼저 정보를 공유하고 수정 일정과 공개 시점을 협의하는 방식이다.
가령 기업들이 널리 사용하는 프로그램에서 심각한 결함이 발견됐다고 가정해 보자. 이를 고치기 전에 구체적인 공격 방법을 공개하면 해커도 같은 정보를 이용할 수 있다. 반대로 개발사가 수정 프로그램을 준비할 시간을 확보하면 이용자들이 공격에 대비할 가능성이 커진다.
이때 공개를 잠시 미루는 기간을 ‘보안 엠바고’라고 부른다. 취약점을 숨기기 위한 조치가 아니라 방어자에게 준비 시간을 주려는 것이다. 다만 이미 공격이 진행 중이거나 관련 정보가 유출됐다면 수정이 끝나지 않았더라도 위험과 임시 대응 방법을 신속히 알려야 한다.
2021년 발생한 ‘로그4쉘(Log4Shell)’ 사태는 보안 대응이 얼마나 복잡한지 보여준다. 널리 쓰이는 오픈소스 프로그램 ‘로그4j’에서 심각한 결함이 발견되자 여러 기업이 자신들의 시스템에 해당 프로그램이 포함됐는지부터 조사해야 했다. 수정판이 나와도 기업마다 업데이트하고 정상 작동 여부를 확인해야 해 대응이 끝나기까지 시간이 필요했다.
◇AI가 쏟아낸 제보, 소수 개발자가 검증
부담이 특히 큰 곳은 소규모 오픈소스 프로젝트다. 오픈소스는 프로그램의 설계도에 해당하는 소스코드를 공개해 누구나 살펴보고 개선할 수 있도록 한 소프트웨어다. 수많은 기업이 이용하지만 관리 업무는 개발자 한두 명이 맡기도 한다.
AI가 찾아낸 의심 사례가 모두 실제 취약점인 것도 아니다. 이미 알려진 문제이거나 공격에 활용하기 어려운 사례도 있다. 이를 일일이 검증하다 보면 정작 위험한 문제를 고칠 시간이 줄어들 수 있다. 오픈소스 프로젝트 ‘컬(curl)’이 제보 급증에 따른 부담을 이유로 위험도가 낮은 취약점의 처리 방식을 바꾼 것도 이런 맥락이다.
레드햇은 위험이 낮은 문제는 공개적으로 논의하되 악용 가능성이 큰 결함은 수정 준비가 끝날 때까지 정보 공유 범위를 제한하는 등 차등 대응을 제안했다. 기업들도 개발자에게 신속한 수정을 요구하는 데 그치지 말고 검증과 테스트에 인력을 지원해야 한다는 입장이다.
에밀리 폭스 레드햇 포트폴리오 보안 아키텍트는 “취약점 대응에는 조율이 필요하고, 생태계 전체에 걸친 진정한 조율에는 사람 사이의 신뢰가 필요하다”며 “기계의 속도가 이러한 신뢰를 대체하지는 못한다”고 강조했다.
이어 “AI가 취약점을 발견하는 속도는 앞으로도 빨라질 것이며, 이에 맞춰 대응 방식도 발전해야 한다”며 “보안 분야의 리더십은 누가 먼저 취약점을 공개하는지 경쟁하는 데 있지 않다. 생태계 전체가 안전하게 발전할 수 있도록 지원하고, 그 과정에서 신뢰를 지켜나가는 데 있다”고 밝혔다.
