2024 Red Hat 제품 보안 위험 리포트: CVE, XZ 백도어, SSCA, AI 등등

달달한 차 또는 커피 한 잔을 마시며 Red Hat Product Security 팀의 2024 제품 보안 리스크 리포트를 읽어보세요. 오픈소스 에코시스템과 그 보안 과제에 대한 최신 정보를 얻기 위해 노력하는 사람으로서, 올해의 리포트가 눈에 띄게 길어졌지만 내용의 깊이와 세부 사항은 실망시키지 않았습니다. 실제로 올해 보고서에서 주목할 만한 내용은 AI에 대한 논의입니다. 

숫자 놀이: 상승세, 상승세, 그리고... 잠깐만요

먼저 기초 통계를 분석해 보겠습니다. Red Hat Security Advisories (RHSA)는 2024년에 2,975건으로 최고치를 기록했으며, 지난 몇 년 동안 꾸준히 증가해 왔습니다. 흥미롭게도, 중요(Important) 및 보통(Moderate) 권고 사항은 크게 증가한 반면, 치명적(Critical) 권고 사항은 다소 감소하여 보다 선제적인 보안 관행과 빠른 탐지를 반영하고 있습니다.

CVE(Common Vulnerabilities and Exposures)는 4,272개로 상대적으로 안정적이었던 전년도에 비해 크게 증가했습니다. 이 문제의 원인은 무엇일까요? 이 리포트는 2024년 2월에 Linux Kernel Organization이 CVE 번호 지정 기관(CVE Numbering Authority, CNA)이 되었다는 점을 강조하고 있습니다. 이전에는 할당을 받지 않았던 많은 커널 문제에 CVE를 할당하기 시작했습니다. 이러한 새로운 kernel.org CVE를 필터링하면 추세선이 약간 증가하여 더 친숙하게 표시되며, 이는 Red Hat의 포트폴리오 증가를 반영하는 것일 수 있지만 놀라운 것은 아닙니다. 

더 자세히 살펴보면, 2024년 kernel.org에서 할당된 새로운 CVE 중 대부분은 보통(Moderate) 및 낮음(Low) 등급이며, 이 중 45%만이 현재 Red Hat Enterprise Linux (RHEL) 커널에 영향을 미쳤습니다. 또한 실제 악용 시도가 확인되는 위치와 일치하는 심각 및 중요 취약점에 초점을 맞춰야 합니다. 이러한 접근 방식은 Red Hat이 중요 CVE의 절반 이상을 신속하게 처리하여 7일 이내에 첫 번째 수정 사항을 제공하고 Day 0에 3번의 수정 사항을 제공하는 것으로 입증되었습니다.

위의 맥락 없이 이 지표들을 보면, ‘Red Hat은 도대체 무엇을 하고 있는가?’라는 생각이 들 수 있습니다. CVE 건수는 크게 증가했지만, Red Hat 제품의 근본적인 위험 프로필은 실제로 그에 맞춰 변하지 않았습니다. 이 숫자들은 CVE 건수만으로는 충분하지 않으며, 심각도, 악용 가능성, 관련성도 반드시 함께 고려해야 한다는 점을 강화해 줍니다. 치명적(Critical) 및 중요(Important) 이슈에 대한 Red Hat의 패치 집중은 데이터로 입증되었으며, 실제 악용 사례 대부분이 이 영역에서 발생함을 보여줍니다. 이는 리스크 기반 접근 방식이 가장 합리적이라는 것을 증명합니다.

XZ 백도어: 방 안의 코끼리

2024년 보안 얘기를 하면서 XZ 백도어 사건을 언급하지 않을 수 있을까요? 이 사건은 오픈소스 커뮤니티의 악몽으로 남아 있는 치밀하게 계획된 공급망 공격이었습니다. 2년 넘게 커뮤니티에서 신뢰를 쌓아온 유지보수자가 XZ 라이브러리에 정교한 백도어를 숨겨 넣었던 것입니다. 만약  Andres Freund가 그로 인해 발생한 성능 저하를 발견하지 못했다면, 수많은 시스템의 SSH(Secure Shell) 접속이 위험에 처할 수도 있었습니다. 

이 리포트에서 Red Hat은 오픈소스에 대한 대응을 살펴보고, 내재된 위험을 강조하고 오픈소스 모델의 장점을 소개합니다. 소스 코드와 상호 작용이 공개되었기 때문에 신속한 협업 분석과 정보 공유가 가능했습니다. 또한 이 보고서에서는 Fedora 테스트 및 RHEL 품질 엔지니어링과 같이 자체 파이프라인 내에 존재했던 장벽들을 논의합니다. 이 장벽들이 XZ 백도어를 포착할 수 있었을 가능성이 있지만, 확실히 말할 수는 없습니다.  

XZ 백도어 사건은 경종을 울렸습니다. 이 사건은 오픈소스의 신뢰와 기여 프로세스에 장기적인 영향을 미칠 것입니다. 공급망 공격은 그 수가 증가하고 정교해지고 있습니다. 공격자들은 개발자들이 일상적으로 사용하는 공통 툴과 공유 코드를 표적으로 삼을 방법을 찾아 광범위한 문제를 야기하고 있습니다. 이러한 유형의 공격은 소프트웨어 벤더가 여러 가지 보호 계층을 필요로 한다는 것을 보여줍니다. 사용된 사전 빌드된 코드 부분의 안전성을 자동으로 확인하고, 소프트웨어 빌드를 위한 안전한 어셈블리 라인을 구축하고, 새로운 부분을 추가하기 전에 신중하게 검사합니다. 최근 XZ 보안 문제를 발견하고 차단할 수 있었던 여러 가지 점검 절차가 Red Hat에 있었던 사실은 다행입니다. 이러한 다중 보안 계층이 실제로 큰 도움이 된다는 점을 강조합니다. 보안은 한 번에 완료되는 활동이 아닙니다.

공급망 문제

소프트웨어 공급망 공격(SSCA)의 증가와 오픈소스 구성 요소에 대한 의존도는 거의 믿기지 않지만 통계적으로 사실입니다. Black Duck의 분석은 매우 우려스러운 상황을 보여주는데, 상업용 코드베이스의 무려 97%가 오픈 소스 컴포넌트에 의존하고 있습니다. 

XZ Util 침해와 북한 위협 그룹들이 정교한 고용 사기 수법을 사용해 내부 접근 권한을 획득한 사례는 악의적인 공격자들이 진화하는 전술을 사용하고 있다는 두 가지 예에 불과합니다. 문제는 이런 공격들의 동기가 대부분 알려져 있지 않고, 상당 부분이 미신고 상태라는 점입니다. 공격자가 누군지, 왜 공격하는지 완전히 알지 못하면 효과적인 방어가 어렵습니다. 일부 공격자는 금전적 이익이나 스파이 활동을 목적으로 한다는 것은 알고 있지만, 많은 공격의 목표는 알 수 없습니다. 이는 사이버 위협 상황을 복잡하게 만들고 예측하거나 모델링하는 데 어려움을 줍니다. 개발자와 그들의 접근 지점을 공격 대상으로 삼는 것은 공격자 입장에서 매우 합리적입니다. 왜냐하면 개발자들이 ‘왕관의 열쇠’를 쥐고 있기 때문이며, 이는 우리 디지털 세계를 구축하는 인간 요소가 주요 공격 대상임을 의미하기도 합니다.

이러한 SSCA는 숙련된 익명의 공격자가 중요 오픈소스 종속성에 대한 악용을 확대하고 있음을 보여줍니다. 현대 소프트웨어의 근간이 되는 오픈소스 사용을 중단할 수는 없습니다. 따라서 근본적인 변화가 필요합니다. 보안 침해에 대응할 때뿐만 아니라 개발 라이프사이클 전반에 걸쳐 더욱 사전 예방적인 보안 프로토콜을 임베딩해야 합니다. 여기에는 종속성 평가 개선, 개발자를 위한 강력한 보안 사례, XZ 응답에서 강조한 바와 같이 벤더, 커뮤니티, 사용자가 에코시스템 보안에 투자하는 공동 책임 모델이 포함됩니다. 우리가 의존하는 규모가 방대하기 때문에, 그에 상응하는 보안 투자가 반드시 필요합니다. 우리는 여전히 명백히 몇 발 앞서 나가는 적들에 비해 뒤처진 상태로 대응하고 있습니다.

AI에 대한 찬가

지난 한 해 동안 챗봇에서 코딩 비서, 창의적인 툴에 이르기까지 생성형 AI(Generative AI)가 폭발적으로 증가했습니다. 이러한 추세는 둔화되지 않고 있으며, Gen AI는 앞으로 매년 37%의 속도로 성장 2030년까지 예측됩니다. 이는 실로 놀라운 일입니다. 

하지만 모든 반짝이는 신기술이 그렇듯, 처음에는 사람들이 그것이 무엇을 할 수 있는지에만 집중하는 허니문 단계가 있습니다. 얼마나 빠르게 작동할까요? 얼마나 많은 것을 만들어낼 수 있을까요? 모든 작업의 방식을 어떻게 바꿀 수 있을까요?

하지만 이제 생성형 AI의 진정한 가치를 보게 되었고, 특히 의료, 금융, 정부처럼 규제가 엄격한 산업 분야에서는 실수가 큰 영향을 미칠 수 있기 때문에, 우리는 심각한 문제들에 대해 고민을 시작해야 합니다. AI 사용을 어떻게 안전하고, 보안적이며, 신뢰할 수 있게 할 수 있을까요? AI가 실수를 하지 않거나 사적인 정보를 유출하지 않을 거라고 믿을 수 있을까요? 의사결정자들은 올해 AI에 대한 가장 큰 걱정거리로 데이터 안전성을 꼽고 있습니다. 이는 매우 타당한 말입니다. 개인 정보가 외부로 유출되거나 AI가 보안이 제대로 이루어지지 않아 잘못된 결정을 내리는 것을 원하지 않기 때문입니다. 앞서 언급한 바와 같이, 우리는 이미 오픈소스에서 고위험 표적들이 존재한다는 사실도 알고 있습니다.

제가 감사하게 생각하는 점은 우리가 단순히 AI 유행에 편승하는 것이 아니라는 점입니다. AI를 안전하게 보호하는 방법을 찾기 위해 노력하고 있습니다. 하지만 이는 쉬운 일이 아닙니다. 

Red Hat이 "신뢰 구축: AI의 보안, 안전, 투명성 기반"에서 처음으로 지적하는 것 중 하나는 AI 보안 취약점과 AI 안전 문제를 분리할 필요성입니다:

• 보안 취약점: 해커가 AI 시스템에 침입하는 방법을 찾아내는 경우입니다.
• 안전 문제: 해커가 침입하지 않았더라도 AI 자체가 부정확하거나 편향되었거나 해로운 말을 하는 경우입니다.

이러한 문제는 다르게 해결해야 합니다. 버그를 수정하는 것은 AI에 유해하거나 사실이 아닌 것을 만들어내지 않도록 가르치는 것과는 다르기 때문입니다. 서로 다른 룰북이 필요합니다.

Red Hat과 같은 기업, EU와 미국과 같은 정부, 다양한 산업 그룹이 이 문제를 해결하기 위해 열심히 노력하고 있습니다. 다양한 AI 위험을 추적하기 위한 지침, 표준, 방법을 만들려고 합니다. 이 기술을 처음부터 책임감 있게 구축하여 엔지니어를 교육하고 안전한 설계를 구축하고자 합니다. 중요한 점은 Red Hat이 단순히 말하는 것이 아니라 구축한다는 것입니다.

이 모든 것이 의미하는 바는 무엇일까요? AI 붐은 매우 흥미롭고 많은 것을 변화시킬 수 있습니다. 하지만 신뢰가 관건입니다. 좋은 관계와 마찬가지로 신뢰는 기본입니다. AI의 장점을 최대한 활용하려면 AI와의 관계가 신뢰를 바탕으로 구축되어야 하며, 이는 단순한 데모 그 이상입니다. 이는 기술이 안전하고 안전하며 예상대로 작동하도록 보장하기 위해 보이지 않는 곳에서 열심히 노력하는 데서 비롯됩니다. 적합한 인력이 집중하고 있다는 것은 좋은 소식입니다. 나중에 큰 문제를 해결하려고 하기보다는 지금 신중하게 가드레일을 구축해야 합니다. 이를 위해서는 AI를 신뢰하는 사람들이 필요합니다!  

SDLC의 숨은 노력

2024년, Red Hat은 신뢰할 수 있는 모든 제품 뒤에는 어떤 제품도 결함이 없는지 확인하기 위해 많은 노력이 필요하다는 것을 증명했습니다. 우리의 접근 방식은 단순히 NIST 보안 표준을 따르는 데 그치지 않습니다. Red Hat은 AI 기술을 포함하여 우리가 구축하는 모든 것이 처음부터 신뢰할 수 있고 믿을 수 있는지 검증하는 데 도움이 되는 고유한 방법을 개발하고 있습니다.

Red Hat Secure Software Development Lifecycle(RHSDLC)은 보안에 중점을 둔 소프트웨어 구축 계획을 제공하며, 현재의 실제 보안 문제에 맞춰 더욱 똑똑해지고 정교해졌습니다. 단순히 형식적인 절차를 수행하는 것이 아니라, RHSDLC와 같은 자체 표준을 만들어 소프트웨어 공급망 전체를 시작부터 끝까지 보안 강화하도록 하고 있습니다. 이는 Security Operating Approvals(SOA) 절차를 성숙시켜 타사 도구 검증, 자동화된 점검, 문제가 되기 전에 위험 신호를 포착하는 것을 포함합니다. 마치 누수가 폭포가 되기 전에 작은 물방울 단계에서 잡아내는 것과 같습니다. 저희는 보안 세부 사항을 철저히 탐구하고 신뢰, 투명성, 복원력을 우선시하여 고객이 저희 제품에 대한 신뢰를 갖도록 최선을 다하고 있습니다.

보안 아키텍처 검토(SAR)가 RHSDLC로 표준화된 것을 보고 반가웠습니다. 이러한 검토는 고전적이고 검증된 보안 원칙을 지원합니다. 예를 들어 "필수적인 요소에만 액세스 권한 부여", "방어 계층화" 처음부터 제품 설계에 보안이 포함되도록 합니다. 

마지막으로 RapiDAST가 있습니다. 오픈소스 또는 애플리케이션 개발에 관심이 있다면 이 툴은 숨은 보석과도 같습니다. Red Hat의 동적 애플리케이션 보안 테스트 툴이며 2024년에 몇 가지 심각한 업그레이드가 이루어졌습니다. RapiDASTS는 더욱 강력해졌을 뿐만 아니라 사용하기 쉬워졌습니다. 예를 들어 쿠버네티스 오퍼레이터 테스트 지원, 자동화 개선, 훨씬 간소화된 인터페이스를 제공할 수 있습니다. 이제 결과를 Google Cloud Storage로 바로 내보낼 수 있으므로 협업의 효율성이 높아집니다.

Red Hat은 이 모든 것을 개발자가 제품을 빌드하고 릴리스하는 데 매일 사용하는 바로 그 시스템인 CI/CD 파이프라인에 직접 구축하고 있습니다. 또한 시스템을 안전하게 유지하기 위해 노력하는 개발자, IT 전문가, 최종 사용자 등 툴을 사용하는 사람들에게는 보안 중심 개발에 대한 노력이 정말 중요합니다. 사이버 위협이 끊이지 않는 상황에서 소프트웨어 벤더가 설계 단계부터 테스트 및 구성 요소 추적에 이르기까지 보안에 집중하고 있다는 사실은 안심할 수 있습니다. Red Hat은 보안을 품질 관리의 핵심 요소로 생각하며, 단순히 사후 고려 사항이 아닌 핵심 요소로 생각합니다.

2025년 리포트로 다시 만날 때까지

올해의 리포트는 보안이 항상 변화하고 있음을 상기시킵니다. CVE 보고 방식의 변화, 지속적인 공급망 리스크, AI의 영향 증가, 취약점의 우선순위 지정 등으로 인해 사용자가 고려해야 할 사항이 많습니다.

이와 같은 투명한 보고서를 보유하는 것은 매우 중요합니다. 개발자에서 IT 팀, 호기심 많은 저와 같은 독자들 모두가 현재 상황을 파악하고, 과제를 이해하고, 정보에 근거한 선택을 할 수 있도록 지원합니다. 제 관점에서는 단순히 문제를 방지하는 것이 아니라 이에 대응하는 방법도 중요합니다. XZ 백도어와 같은 사건이 발생했을 때 오픈소스 커뮤니티가 협력한 방식이야말로 협업의 힘입니다!

Red Hat 제품 보안 리스크 리포트 2024 전문을 읽어보세요.